News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Direct connectivity issue (due to SIP "Contact")

Started by oleg, May 20, 2011, 05:37:54 PM

Previous topic - Next topic

oleg

Obihai,

Thank you for recently added options to support NAT traversal for URL calls. That solved bunch of issues.
Now the only problem prevents me from replacing old PAP2T with OBi - absence of direct connectivity with Linksys devices. I previously described the problem here http://www.obitalk.com/forum/index.php?topic=483.msg2881#msg2881 (see for details)

In short - regardless of NAT/STUN settings OBi device sends local network IP address in SIP "Contact" field. It causes other party to send undeliverable ACK and session never establishes.
The solution would be to make it flexible - give users a choice to send "Contact" with local IP or NAT detected IP or with manually entered SIP URI.

Could you please consider that simple change in following releases?

Thank you
---oleg

RonR

oleg,

In the original post you referenced, you asked:

Quote from: oleg on March 25, 2011, 05:38:53 PM
P.S. Has anybody success receiving calls via ipKall? That seemed to suffer from the same issue. I can't say ere ipKall sends ACK to, but OBi does not receive it.

I replied at the time that I could not get IPKall to work with the OBi either, even though it worked well with a PAP2.

Since then, there was a firmware update that made some changes to SIP handling.  I recently found I no longer have problems with IPKall, IPComms, and others:

http://www.obitalk.com/forum/index.php?topic=895.0

I now also use a PAP2 as an extension off of the OBi:

http://www.obitalk.com/forum/index.php?topic=718.msg5467#msg5467

oleg

Hi Ron,

I just verified OBi110 (running software 1.2.1 Build: 2286) with ipKall - SIP stuck on the same. The phone rang, when answered - OBi sent "200 OK", and continued repeating "200 OK" (because never received ACK).

A while ago (with previous OBi software release) I tested OBi incoming call from my friend's Linksys - failed to establish session. The log on Linksys side shown that ACK is being sent to my OBi's local IP (undeliverable from Linksys side). The only place where my local IP was exposed to Linksys was the "Contact" header sent by my OBi110.

Your setup with PAP2 as an extension is very interesting indeed, but's that's not my case. In your setup both devices run on the same LAN. In mine - OBi110 works behind NAT and connecting through internet.



RonR

oleg,

Do you have the appropriate SIP port forwarded in your router to your OBi?

I don't know if this will help you, but here is a Syslog from my OBi for an incoming call from IPComms (it works equally well with IPKall).

obi-support2

oleg,

You have this issue because you do not REGISTER on your SP1/2 main service.

Have you tried to enable X_KeepAliveEnable and set X_KeepAliveMsgType = stun,
(also set X_KeepAliveServer and X_KeepAliveServerPort to point to a valid stun server)?

Take a look at the NAT Traversal section in OBi Admin Guide. These options should
help with your particular situation.

Thank you.
OBIHAI Support Staff

RonR

Quote from: obi-support2 on May 21, 2011, 12:31:17 AM
You have this issue because you do not REGISTER on your SP1/2 main service.

Have you tried to enable X_KeepAliveEnable and set X_KeepAliveMsgType = stun,
(also set X_KeepAliveServer and X_KeepAliveServerPort to point to a valid stun server)?

Take a look at the NAT Traversal section in OBi Admin Guide. These options should
help with your particular situation.

FWIW, I have equal success with no registration.  There needs to be a ProxyServer specified (127.0.0.1 works fine), but X_RegisterEnable can be disabled and X_KeepAliveServer and X_KeepAliveServerPort can be left blank.  I tested this before making the post about using DID's with the OBi.

oleg

RonR,

I am talking about the following part (from your log):

sendto 409a2996:5060(701)

SIP/2.0 200 OK
Call-ID: 4badf5336d2f1bcb11aa38807942a7ec@64.154.41.150
CSeq: 102 INVITE
Content-Length: 231
From: "2341234567" <sip:2341234567@64.154.41.150:5060>;tag=as1700e7ce
To: <sip:ipcomms@xxxxxxxx.dyndns.org>;tag=SP25d7da5ec7f09888c
Via: SIP/2.0/UDP 64.154.41.150:5060;branch=z9hG4bK0e1ed3b5;received=64.154.41.150;rport=5060
Server: OBIHAI/OBi110-1.2.1.2309
Contact: "RonR" <sip:u1234500000@192.168.1.140:5060>
Content-Type: application/sdp
v=0
o=- 6495 1 IN IP4 123.123.123.123
s=-
c=IN IP4 123.123.123.123
t=0 0
m=audio 16800 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=xg726bitorder:big-endian

RxFrom:409a2996:5060

ACK sip:u1234500000@192.168.1.140:5060 SIP/2.0
Via: SIP/2.0/UDP 64.154.41.150:5060;branch=z9hG4bK1fa4cd3b;rport
Max-Forwards: 70
From: "2341234567" <sip:2341234567@64.154.41.150:5060>;tag=as1700e7ce
To: <sip:ipcomms@xxxxxxxx.dyndns.org>;tag=SP25d7da5ec7f09888c
Contact: <sip:2341234567@64.154.41.150:5060>
Call-ID: 4badf5336d2f1bcb11aa38807942a7ec@64.154.41.150
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.6.2.13
Content-Length: 0

Note highlighted "Contact" - it contains your Obi local IP address. ipcomms server is smart enough to recognize mistake and it sends ACK to correct endpoint. Linksys device does not.

I am curious to see log with ipKall - could you please show?

And yes, I have port forwarded.
And I had tcpdump on WAN side of my router when I was troubleshooting ipKall first time - ACK did not come to my router. Later I noticed the same with Linksys and checked the log on Linksys side - that revealed the mystery - ACK sent to wrong address.

obi-support2,

as I said before and above ACK is being sent to undeliverable destination - how it may be related to NAT???


RonR

Give me a couple minutes and I'll post a Syslog for IPKall...

RonR

Sorry for the long delay - lots of distractions here today.

Here's the Syslog for an incoming call from IPKall.

oleg

RonR,

attached is my very recent test with ipKall. Comparing logs I've noticed a few minor differences
- previously I used different local port. I've changed to 5060 (default) and re-tested - nothing changed.
- in your log user in "INVITE" is not the same as in "Contact"
                 INVITE sip:ipkall@xxxxxxxx.dyndns.org SIP/2.0
                 Contact: "RonR" <sip:u1234500000@192.168.1.140:5060>
unless it was result of obfuscation - can you point where do you specify them? may be it does the trick?
- you have never OBi software (OBIHAI/OBi110-1.2.1.2309)...


RonR

Quote from: oleg on May 21, 2011, 10:34:23 AM
                  INVITE sip:ipkall@xxxxxxxx.dyndns.org SIP/2.0

IPKALL is set to forward to:

SIP Phone Number: ipkall
SIP Proxy: xxxxxxxx.dyndns.org

The 'SIP Phone Number' is ignored by the OBi.  I set it to the DID's name (ipkall, ipcomms, etc.).

Quote from: oleg on May 21, 2011, 10:34:23 AM
                  Contact: "RonR" <sip:u1234500000@192.168.1.140:5060>

u1234500000 is the AuthUserName of the SIP provider configured on SP2.  It doesn't have to be registered (in fact, that SIP provider is down this morning and the OBi is trying unsuccessfully to register over and over).

Quote from: oleg on May 21, 2011, 10:34:23 AM
- you have never OBi software (OBIHAI/OBi110-1.2.1.2309)...

This is an intermediate version to fix the bug that was introduced in 2286 that causes X_SkipCallScreening to fail on anonymous incoming Google Voice calls.

obi-support2

oleg,

Port forwarding will not help with this situation.
You want OBi to use external IP in contact, but you don't want to register the main service.
OBi needs to figure out the external transport address. OBi WILL NOT use the one
that is used in the SDP.

Please try the X_KeepAlive ... feature as explained in the OBi admin guide.
It is relevant.
OBIHAI Support Staff

oleg

RonR,
Quote from: RonR on May 21, 2011, 10:46:21 AM
The 'SIP Phone Number' is ignored by the OBi. 
that's quite strange. In Linksys ATAs those must be the same, otherwise ATA would disregard incoming call. That makes OBi more open (for both good and bad)...

well, I made both ("Number" on ipKall side and "AuthUserName" on OBi110 side) the same as yours  :) - it did not change anything  :(

will try to register (as per obi-support2 advise), although I do not see why it may be relevant...


RonR

Setting:

X_KeepAliveEnable : (checked)
X_KeepAliveServer : stun.ideasip.com
X_KeepAliveServerPort : 3478
X_KeepAliveMsgType : stun

does change the Contact field to the public IP address.

However, with that I get no audio in either direction on IPKall calls.

oleg

#14
Quote from: obi-support2 on May 21, 2011, 10:50:15 AM
Port forwarding will not help with this situation.
I agree. But doesn't KeepAlive serve the same purpose - to keep NAT port open and forwarded to OBi?

Quote from: obi-support2 on May 21, 2011, 10:50:15 AM
You want OBi to use external IP in contact, but you don't want to register the main service.
OBi needs to figure out the external transport address. OBi WILL NOT use the one
that is used in the SDP.
I have SP1 registered with GV. SP2 was not registered. OBi had my external address from two sources: GV on SP1 and STUN on SP2. External IP was correctly placed into all places, except "Contact" - why?

But registration did the trick - when I registered SP2 - "Contact" field got external IP address and incoming ipKall call came through. Note that I changed nothing related to KeepAlive and NAT.

Thus two questions:
- why registration is required for correct "Contact"?
- how incoming ipKall worked in RonR case?


oleg

#15
FWIW, I removed registration and added X_KeepAlive*** settings (exactly as RonR shown above).
Contact had external IP and ipKall session established (and had both way audio).
The OBi admin guide indeed describes this way of NAT traversal, but (once again) why without registration or KeepAlive external IP known to OBi can be used everywhere, but not in "Contact" field ???

And I still vote for flexibility - why not allow user to configure "Contact" with SIP URI (sip:1234@sip.host.com) containing reliable host name rather than IP.

obi-support2

A transport address includes an address and a port number. Two transport addresses are required per SIP call; one for SIP signaling and one for RTP media. Let's also refer to a private to external transport address map as a "binding". To achieve peer-to-peer communication, the device needs to discover SIP and RTP binding. When your device REGISTER, there is an opportunity for your SP to tell the device what the SIP binding is (try comparing the Via header of the REGISTER request and the corresponding 200 OK response); this solves the SIP binding discovery problem. RTP binding on the other hand has to be discovered with a  STUN transaction. However, if you don't REGISTER (or your SP is not co-operative), another STUN transaction is required to discover the SIP binding (the OBi does this using the Keep Alive feature).

We prefer STUN or the equivalent than hard coded EXTERNAL IP configuration (as used in other implementation) since external IP address may change from time to time for most users.

I am sure there will be further enhancements as the demand grows. Thank you.
OBIHAI Support Staff

oleg

#17
 :-[ Well, you are right, I totally forgot about port - in my setup external port never differs from internal (linux based routers normally preserve port number)...

When REGISTER - it perfectly makes sense to take SIP binding from response.
Otherwise it seems much more logical to call STUN for both SIP and RTP when call is being initiated. Why one can be resolved on demand while other requires periodical check in keep-alive manner? Separating them is also counterintuitive - I would never guess that "Contact" included internal address because of lack of STUN resolution when the log shown STUN interaction and RTP endpoint was correct.

Quote from: obi-support2 on May 22, 2011, 04:17:22 PM
We prefer STUN or the equivalent than hard coded EXTERNAL IP configuration
I never suggested configuring external IP. It can be done of course (if someone has static IP), but it makes much more sense to configure SIP URI.
Quote from: oleg on May 21, 2011, 11:58:04 AM
... allow user to configure "Contact" with SIP URI (sip:1234@sip.host.com) containing reliable host name rather than IP.

Thank you for the help (now I can retire PAP2T)



Seattleweather

This is an old post.  But I would like to know if you are able to receive the call by using sip:xxx@xxx.no-ip.org to reach your Obitalk directly from outside. If the answer is yes, please show how.  Thanks.

Stewart

This is a complex issue, depending on your router and the capabilities of the external source.

In general, if you forward the UDP port specified by the X_UserAgentPort setting for the SPx in question to the private IP address of the OBi, an external call will look like an incoming call to SPx (though with a different destination number) and you can set the InboundCallRoute to route it as desired.

For more specific advice, post details about your application, e.g. "I'd like calls to my IPKall DID to ring my cell phone via GV."