NAT Transversal
shap:
Quote from: oleg on March 25, 2011, 05:38:53 pm
I have faced similar problem replacing Linksys PAP2 with OBi110. I have several friends directly connecting to my ATA and vice versa. "Directly" means SIP INVITE packet is sent from source ATA to destination ATA with no third party. This works with no provider involved. Each of us has dynamic DNS (or equivalent), ATA signalling port exposed to internet...
Here is one of problems introduced by OBi110 (I have no good solution yet):
Friend's ATA sends INVITE to my OBi, my OBi110 responds with "Trying", than "Ringing", than "200 OK". In turn friend's ATA sends ACK. The problem is that ATA sends ACK to the address received in "Contact" header of "200 OK" - OBi uses local network IP address there.
ATA behavior makes sense: destination ATA may think that INVITE went through a proxy, but wants to send ACK directly to calling party. SIP standard (RFC 3261) illustrates the same (see diagram http://tools.ietf.org/html/rfc3261, page 11)...
As result OBi never receives that ACK and call may not be established.
My OBi110 is registered with GV on SP1. SP2 configured for SIP with STUN (but without registration). Thus OBi knows external IP address. Even more - it sends correct external IP in "200 OK" SDP payload (data for RTP). Why it would not use the same known external IP in "Contact"? ???
May I suggest to OBi team:
- consider using known external IP in "Contact" (Linksys adapters do that)
- make "Contact" configurable in device settings
- combine both approaches (like OBi handles setting "SPx Service"->"SIP Credentials"->"URI").
Any suggestions to solve direct connectivity problem are very welcome, I might overlook some useful settings...
P.S. Has anybody success receiving calls via ipKall? That seemed to suffer from the same issue. I can't say where ipKall sends ACK to, but OBi does not receive it.
---oleg
I think that the correct behavior should be as with PAP2T - device should send a local IP in all headers, unless there is a public ip specified in some configuration field.
Currently, it creates a problem with local devices (sitting on the same internal VLAN and try to access Obi110) - they need to send RTP packages to the public IP (came from the Contact header for RTP) that is in turn loopbacked at router to the correct NAT IP using port forwarding setting. This also demand configuring firewall rules.
I am using SipToSis and have this problem. Here is from SIPToSis manual:
"If your ATA or PBX is giving out your public IP address to a SipToSis setup on your local network then it will not work properly. You will have to correct the problem in the ATA or PBX setup. Note: If you have setup SipToSis with a contact_url to use a public IP instead of a local network you will not be able to make calls through the gateway from any SIP source using a local network IP. "
ObiTeam - do you think you can add this to the feature request in new versions of firmware ?
oleg:
Quote from: shap on April 21, 2011, 02:37:59 pm
I think that the correct behavior should be as with PAP2T - device should send a local IP in all headers, unless there is a public ip specified in some configuration field.
That statement is partially incorrect. PAP2T without configured public IP and with enabled NAT traversal (and working STUN) places public IP:port in headers, rather than local.
However, PAP2T provides some flexibility (use STUN or not, configure public IP or not). OBi ought to make the same if not better.
shap:
Maybe you are right - I did not used the STUN server and in my case all IP's in SIP headers were local IP (192.168.1.x).
Navigation
[0] Message Index
[*] Previous page