Problem with local address rather than the external address in the Via header...

[slicemaster]

Well, I've been dinking around with my new OBi-110 for a few days and I've been able to get everything working more or less. I however have run in to a road block when it comes to completing certain types of calls. I have traced the issue to the address in the Via header with the help of my VoIP provider but have yet been able to resolve the issue. Like I say, for the most part most calls are not effected by this problem but it is rather inconvenient that certain types of calls will not function properly until this issue is resolved. I have all the STUN options on the OBi-110 enabled and configured to the best of my knowledge but the issue still persists. I was wondering if Anyone knows of anyway to force the OBi-110 to send the external address rather than the NATed address like its supposed to. Here is a snippet displaying the issue from my VoIP provider's logs.

!!NOTICE!! - The device reports internal NATed IP address in Via header!

Jan 10 20:28:20 west /usr/local/sbin/kamailio[4423]: INFO: <script>: SIP message from udp:76.26.60.144:5060
REGISTER sip:sip.callwithus.com:5060 SIP/2.0
Call-ID: 85445c72@192.168.0.103
Content-Length: 0
CSeq: 2410 REGISTER
From: "MY NAME" <sip:MYCALLWITHUSNUMBER@sip.callwithus.com>;tag=SP138bad33463767d9d
Max-Forwards: 69
To: "MY NAME" <sip:MYCALLWITHUSNUMBER@sip.callwithus.com>
Via: SIP/2.0/UDP 192.168.0.103:5060;branch=z9hG4bK-57e7f819;rport
Authorization: DIGEST algorithm=MD5,nonce="TwzmKU8M5P0JlAHRSYG/BTUENnJm8ZOC",realm="sip.callwithus.com",response="caba25
ccf6242b5f38bb0025dded247f",uri="sip:sip.callwithus.com:5060",username="MYCALLWITHUSNUMBER"
User-Agent: OBIHAI/OBi110-1.3.0.2651
Contact: "MY NAME" <sip:mycallwithusnumber@76.26.60.144:5060>;expires=60;+sip.instance="<urn:uuid:00000000-0000-0000-0000-9c
adef0074f0>"
Allow: ACK,BYE,CANCEL,INFO,INVITE,NOTIFY,OPTIONS,REFER
Supported: replaces

So...There it is, any ideas on how i can resolve this problem with the Via header?

thanks,

[Stewart]

It is unusual for a server to use the Via header to determine if a client is behind a NAT.  I believe that by default, NAT mapping on most client devices does not rewrite the Via header, i.e. the client's local private IP address is used.  Linksys ATAs and IP phones have an option Substitute VIA Address, which causes the public IP to be used.

I suspect that your Linksys devices have that option set, and it's needed for CWU to work as you would like.  You can easily test if this hypothesis is true.  Unfortunately, I don't believe that the OBi has such a feature.

If your present situation is causing something to malfunction, please explain.  If it's merely causing CWU to proxy the audio, which you suspect is needlessly adding to latency, you might check if it really makes a significant difference.  If the IP Geo gods have not failed me, it appears that you are in the Los Angeles area and CWU's data center is in the Bay Area.  Well, the route from your Seattle DID to you probably goes through Silicon Valley anyhow, so incoming calls are most likely unaffected.

On outgoing "local" calls, latency might be worse if CWU's upstream is in Southern California.  Use SIP Debug on your Linksys device to see where the media server is located.  Or, make test calls both ways to 909-390-0003 (echo test in Ontario, California) and compare latency.  There is no ringback or prompt; just start talking and you should hear your voice echoed back.

Also, check your private messages.

[slicemaster]

Thanks for the responce...and the tip via PM...I just missed that one entry, but thanks for catching that.
Anyways, you're exactly right with regards to the linksys/Sipura having the options to set the Via header, and this is indeed the this is one of the "golden" settings that allow peer calling to work correctly. Luckily, my ipkall incoming works fine as well as all my pots calls with callwithus. However, like I say, peer calling is problematic. I've done some test calling with my sipura devices and the experence the same issues as the obi if I do not have the via header settings set. So this is clearly the problem. Any chance for obihai fixing this bug soon? Other than this one issue, I love my device...I'm just bummed because peer calling doesn't work correctly. As a side note for proof that this via header issue is indeed the cause of the problem, I connected the obi directly to my modem and the issues went away...

[Stewart]

Can you be specific as to what calls fail, e.g. calls to other CWU customers, calls via CWU speed dial to SIP URI, calls via OBi speed dial, etc?  What goes wrong with these calls, e.g. does called phone ring, device show connected, SIP error, audio problems, etc?

[slicemaster]

The issues are only with uri calls...between my callwithus accounts. I have the destinations configured as local speed dials on both my obi and my sipura devices. In either case, the phone will generally ring but in some cases their will be either no audio or one way audio. I have done some testing with ny sipura devices and calls between then have no problems ever. Additionally, alls between my sipura devices and my android sipdroid client have no problems... As a side note the via header is properly reflecting the external address on both the sipura and sipdroid clients.

[Stewart]

I'm sure that there is a workaround.  Are these devices behind the same NAT or different NATs?  Can you please describe one failure in detail: which device initiates the call, which side gets audio, etc.

As a quick shot, try setting X_SymmetricRTPEnable.

It's after 1 AM here and I've got to get to bed, but I'll take a look in the morning and try to post a workaround, if the above doesn't help.

[slicemaster]

Well, after some relatively unhelpful dialog with Obihai, email correspondence with CallWithUs, and also time and effort in research it would seem this issue is not going to be fixed. Everything I have read about the via field says that for proper implementation of stun the local address in that field needs to be substituted out for the external address discovered via the stun server. Obihai tech support refuses to acknowledge this as a problem, and this is too bad, but at least it's working for the most part. It's just sad that a five year old Sipura device does a better job of nat traversal than the top of the line Obihai...

None, the less, all things said and done, I do like my new Obihai.
I just wish the support team would acknowledge the folly and fix it.

[Ostracus]

Hmmm, wondering if a local SIP proxy wouldn't work? Say one installed on the router?*

*_{Assuming your router accepts alternative firmware.}