One way incoming audio, no outgoing audio [GV+SS+CC/Obi100]

[tcl4u]

I have an Obi100. Since we will not be able to use GoogleVoice directly soon, I am looking into other ways to keep using GV. Found one suggestion to use Sipsorcery.com + callcentric.com to dial out using GV. Basically I connect to SipSorcery, where I register with CallCentric. I dial with SimpleDialPlan with my GoogleVoice account, with the CallCentric number as the callback number.

I have no problem with incoming calls (got a real number for the CC number), it works fine. For outgoing calls, the recipient's phone will ring, I can hear the other party, yet I cannot be heard. There is only one way incoming audio. The log below shows that the call setup all goes well (I trimmed a bit).

I searched around and read a bunch of posting, including the explanation of NAT and RTP issues. I don't think it is my router/NAT's problem, as I can hear the other party. But just to be sure, I changed my Obi box to restrict the RTP port to be from 16600 to 16607 and set up virtual servers on my router to map incoming 16600-16607 ports to Obi's 16600-16607. As I expected, this does not help.

And, when using a soft phone like X-Lite (having it connecting to sipsorcery.com), I can dial out and get audio in both directions. Since my computer and Obi100 both sit behind the same router/NAT, this is another proof that NAT is not the issue.

And, with soft-phone working, I think it is not sipsorcery.com issue either (BTW, the log from softphone call is identical). This leaves Obi100 box. I suppose it is a configuration issue for Obi100.

Has anyone seen this problem? Any suggestion on how to fix it? Thanks!

DialPlan 01:11:51:118 sip1(6116): New call from udp:50.138.230.177:63529 successfully authenticated by digest.
...
DialPlan 01:11:51:243 sip1(6116): SDP on GoogleVoiceCall call had public IP not mangled, RTP socket 50.138.230.177:16606.
DialPlan 01:11:51:243 sip1(6116): UAS call progressing with Ringing.
...
DialPlan 01:11:54:337 sip1(6116): Google Voice Call callback received.
DialPlan 01:11:54:352 sip1(6116): Answering client call with a response status of 200.
DialPlan 01:11:54:399 sip1(6116): Google Voice Call was successfully answered in 3.16s.
DialPlan 01:11:54:399 sip1(6116): Dialplan cleanup for myname.
DialPlan 01:11:54:633 sip1(6116): Dial plan execution completed with normal clearing.

[giqcass]

The best I can tell this is a Sipsorcery issue.  Have you posted this question over there on their forum?  One way audio is not unusual but the fact that it is coming in and not going out is unusual.  I would often recommend a proxy or port forwarding.

Just as a test I recommend putting your obi in the DMZ temporarily for troubleshooting.  Make a few test calls then let us know whether it is working.

[tcl4u]

I did post at sipsorcery forum, but there is no advice yet, except another guy who is having the same issue with same setup and looking for an answer.

Yes, this is unusual. Most people have problem with incoming audio, which often is the result of NAT blocking the arbitrary UDP port.

But I don't think this is the issue for me. I did the testing of changing OBi box to use small UDP port range and mapped all those ports. No luck.

And the fact that using a softphone on my computer, which sits behind the same router/firewall/NAT, works, indicates that this is not a NAT port-forwarding issue.

And since it can work with a softphone, it is hard to point the finger at sipsorcery. I originally thought it must be something at sipsorcery, but when I saw the followup post to my post at sipsorcery forum from the guy who had the same issue  being able to use his cell phone with CsipSimple to get it work, I tried with my own softphone and it works. To sipsorcery, whether it is from a softphone or an OBi box, it should act the same. It is for this reason I now think it is more likely a configuration issue with OBi box than with sipsorcery.

[tcl4u]

Just to fully test out the NAT issue, I put the Obi box into DMZ and tried to make a few calls. No luck. Same issue, I can hear the incoming, but no outgoing audio.

NAT/firewall is not the issue here. It got to be some configuration with OBi box.

BTW, I just installed an app on my cell phone and registered it with the same sipsorcery account. I can make a call with audio going both directions. Another proof that sipsorcery is doing its job. And if the OBi box is already in DMZ, it got to be the box itself.

[giqcass]

At this point if you are sure it's an Obi related issue a factory reset might be needed.

[tcl4u]

I went into Obi Expert Page and reset the expert config. This does not help.

Is this the same as factory reset? If not, how do I do a factory reset?

Thanks.

[azrobert]

I tried a SipSorcery call and the following is what I captured in the log:
SDP on GoogleVoiceCall call had RTP socket mangled from 192.168.1.100:16806

Notice that mine is mangled and yours is not mangled.

I don't understand mangled, but I do know it can cause audio problems. There is a Mangled option on the sys.Dial function, but not GoogleVoiceCall.

I would post another question on the SipSorcery forum and supply the above info.

There is an access hole for the factory reset button on the bottom of the OBi. Press it with a paper clip and hold until the OBi starts to re-boot.

[tcl4u]

I did the factory reset. It does not help me.

"mangled" indicates whether the recipient needs to discover the sender's public IP. If the sender already sends a public IP, then there is no mangle. On the other hand, if the recipient (sipsorcery here) needs to find the sender's public IP because the IP it gets is a private one, then it is called mangled.

I actually found the setting for OBI100. It is called X_DiscoverPublicAddress under expert menu, Service Providers, ITSP Profile A SIP. The default is checked, which means OBI100 will discover the public IP for the box and use it for establishing the call. When it sends a public IP, sipsorcery does not have to mangle.

Nevertheless, whether I check it or uncheck it, I have the same result. I also noticed that X-Lite uses different set of ports for RTP. I tried those set and still no luck.

[azrobert]

Thanks for the info. You came here with a problem and you end up teaching me something.

I was testing something and forgot to set X_DiscoverPublicAddress back to default. I'm now getting Not Mangled. Sorry for the false information.