News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Problem with multi-level routing

Started by R7tt, April 20, 2012, 08:56:51 AM

Previous topic - Next topic

R7tt

I have finished to setup my OBi100 as following:

SP1 = GV primary    Connected and works OK
SP2 = SIP             Registered and works Ok

Here is what I want to do with my OBi:
A caller dials my GV number --> SIP routes the call to my cell (instead of GV forwarding the call).

Here is the problem that puzzles me:

X_InboundCallRoute (SP1) : {ph,sp2(123456789)} - does not work
X_InboundCallRoute (SP2) : {ph,sp2(123456789)} - works fine

Can someone give me an idea what could be a possible cause of this problem? Thanks in advance.

Thank you very much in advance.

Stewart

Confirm that the calling phone is not associated with your GV account and that Google Chat is the only forwarding phone enabled in GV.

On a failing call, what does caller hear?  What is logged at GV?  What, if anything, appears in OBi's Call History?  Does phone connected to OBi ring?  If so, what happens when answered?  Does your cell phone ring?  If so, what happens when answered?

R7tt

Quote from: Stewart on April 20, 2012, 09:18:02 AM
Confirm that the calling phone is not associated with your GV account and that Google Chat is the only forwarding phone enabled in GV.

On a failing call, what does caller hear?  What is logged at GV?  What, if anything, appears in OBi's Call History?  Does phone connected to OBi ring?  If so, what happens when answered?  Does your cell phone ring?  If so, what happens when answered?

Stewart:

Thanks for your reply. I just looked into things you suggested.

This is what's happening when someone makes a call to sp1 (GV): Instead of forwarding the call to SP2 and to my cell, the caller hears GV voicemail greeting after 5~6 rings. And this is what I see in my call history:

Terminal ID                       GoogleVoice1                       SP2
Peer Name
Peer Number                     xxxxx(caller's #)                  xxxxx(my cell #)
Direction                           Inbound                              Outbound
09:45:20                          Ringing
09:45:20                                                                    End Call (403 Forbidden)

To me everything appears to be OK. Any idea why my cellphone wouldn't ring?

Of course, I can simply enter my cellphone info in GV as a forwarding number but I will have to pay international call rate since my cellphone carrier is not US based. On the other hand, my SIP provider is located in the same country as my cellphone carrier (cheaper rate than GV international calling rate).

Thanks again.

RonR

Quote from: R7tt on April 20, 2012, 05:54:29 PM
Terminal ID                       GoogleVoice1                       SP2

...

09:45:20                                                                    End Call (403 Forbidden)

Any chance your SIP provider doesn't support G711U?  Google Voice uses G711U and I don't believe the OBi supports transcoding, which would be necessary on such a bridged call.

Stewart

If you have set X_SpoofCallerID, try turning that off -- most providers won't allow spoofing (either at all, or the way OBi does it).

Otherwise, there may be a good alternate forwarding scheme.  What country are you in?  Cell phone provider?  Present SP2 provider?  Rate they are charging for calls to your cell phone?  Is it important to show the original caller's number on your cell phone?

You might try SIP Debug for clues as to why your call is being rejected with a 403 (provider may add a Warning header, SIP may be obviously malformed, etc.)

R7tt

Quote from: RonR on April 20, 2012, 06:06:11 PM
Quote from: R7tt on April 20, 2012, 05:54:29 PM
Terminal ID                       GoogleVoice1                       SP2

...

09:45:20                                                                    End Call (403 Forbidden)

Any chance your SIP provider doesn't support G711U?  Google Voice uses G711U and I don't believe the OBi supports transcoding, which would be necessary on such a bridged call.


Thanks. I contacted my SIP provider and found out that they support both G711U and G729.


R7tt

Quote from: Stewart on April 20, 2012, 06:40:25 PM
If you have set X_SpoofCallerID, try turning that off -- most providers won't allow spoofing (either at all, or the way OBi does it).

Otherwise, there may be a good alternate forwarding scheme.  What country are you in?  Cell phone provider?  Present SP2 provider?  Rate they are charging for calls to your cell phone?  Is it important to show the original caller's number on your cell phone?

You might try SIP Debug for clues as to why your call is being rejected with a 403 (provider may add a Warning header, SIP may be obviously malformed, etc.)

I got it! Just like you suggested it WAS X_SpoofCallerID related issue (I found out that the box was checked in web configthe even though was unchecked in OBi expert). Thank you.

Now I now encounter another unexpected problem:
If the other party calls sp2 (sip -> my cell) : works beautifully.
If the other party calls sp1 (gv-> sip -> my cell) : the caller cannot hear me but I can hear the caller and it happens every single instance.

Any idea why this is happening?

Stewart

Please provide as much detail as possible about your setup.  Modem make/model?  Separate router, if any?  SIP provider?  Using STUN?  On a failing call, does OBi's Call Status show RTP packets coming in on SP2?  Going out on SP1?

R7tt

Quote from: Stewart on April 22, 2012, 12:14:49 AM
Please provide as much detail as possible about your setup.  Modem make/model?  Separate router, if any?  SIP provider?  Using STUN?  On a failing call, does OBi's Call Status show RTP packets coming in on SP2?  Going out on SP1?

Two questions:

1) What is STUN?
2) How do I check OBi's Call Status to figure out RTP packet info?

TIA.

Stewart

General info on STUN: http://en.wikipedia.org/wiki/STUN .
OBi-specific info: see the "STUN and ICE" of the OBi Device Admin Guide.
If your provider offers a STUN server, use that.  Otherwise, stun.counterpath.net should work.
If STUN doesn't help, try forwarding the RTP port range (set by LocalPortMin to LocalPortMax; 16600-16999 will cover the defaults for both SPx) of UDP ports to the OBi.  If still no luck, you'll need to use SIP Debug (or perhaps capture traffic) to see what's going wrong.

To see call status, log into the OBi at the address reported when you dial ***1.  Username/password are admin/admin, or as reported on OBiTalk portal.  Expand Status, click on Call Status.  With the OBi idle, this will be empty.  Make a failing test call.  After answering your cell and confirming the trouble (and while the call is still in progress), click Call Status again and you should see the info.