I presently have a Sipura SPA-2000 and SPA-3000 in operation.
My method of NAT Transversal is as follows:
1. Forward Router Port 506x to the Sipura NAT IP address.
2. Place my WAN IP address in the Sipura Ext IP: configuration field.
The Sipura uses the WAN IP instead of the NAT IP for the SIP packets.
This method works well without requiring a STUN server or an Outbound Proxy.
Question
I would like to use the same NAT Transversal method with the OBi110. I use mostly direct IP (peer to peer) dialing and do not want to rely on any 3rd party servers.
I've been through the configuration manual for the OBi110 and couldn't find any configuration setting for EXT IP:.
1. Can the method that I've been using with the Sipura boxes be used with the OBi110?
2. Is there a better method of accomplishing the same end result?
My router is a Linksys WRT54GS Version 1.1 running DD-WRT firmware.
There is no equivalent of EXT IP in the OBi110. OBi110 has to discover the external IP address automatically in one of two ways:
1. If the device registers with an external server, it can discovers the external IP address from the response to the REGISTER message, OR
2. You can enable STUNEnable and assign a valid STUNServer (there should be many free public STUN servers out there), under ITSP A/B - General section
Quote from: obi-support2 on March 24, 2011, 10:01:49 PM
There is no equivalent of EXT IP in the OBi110. OBi110 has to discover the external IP address automatically in one of two ways:
1. If the device registers with an external server, it can discovers the external IP address from the response to the REGISTER message, OR
2. You can enable STUNEnable and assign a valid STUNServer (there should be many free public STUN servers out there), under ITSP A/B - General section
Is
EXT IP a parameter that you would consider adding to the firmware?
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
Quote from: oleg on March 25, 2011, 05:38:53 PMP.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.
I just tried IPKall.
IPKall -> PAP2 : Works
IPKall -> OBi : Fails
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 ?
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.
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).