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