[Freeswitch-users] NAT traversal - the final say..!

[Sean Devoy]

I have spent many hours working on NAT issues on client end, my server has a
public address.  

 

With CISCO brand phones I did not need any non-standards compliant settings,
just turning on all the choices in the CISCO web setup NAT section.
However, with Polycom 335 phones (as of Dec 2012) I could not get registered
or get audio without the following:

* NDLB-connectile-dysfunction

* NDLB-force-rport

* Enable SIP ALG on my FIOS router.

With those setting however, this has worked perfectly.  Also note that when
I turned on SIP ALG, my Cisco phones quite working until I added the NDLB
parameter/variable to the Cisco <user> in the directory.   They seem to be
quite complimentary but seem be requirements for each other.

 

I really tried to stay away from SIP ALG because so many posts were so
negative about it.  Without the NDLB "flags" I could never see any
difference when enabling SIP ALG.  The combination for me has been
fantastic.

 

HOWEVER, since there are so many different versions of "success" in the IRC
and Wiki,  I am pretty sure that other router brands with different SIP ALG
implementations and/or other phone brands or even firmware versions may need
different configurations.  It is almost like we just need a checklist that
says try these combinations until you find one that fits your site.

 

HTH,

sean

 

From: freeswitch-users-bounces at lists.freeswitch.org
[mailto:freeswitch-users-bounces at lists.freeswitch.org] On Behalf Of Cal
Leeming [Simplicity Media Ltd]
Sent: Sunday, December 16, 2012 11:15 AM
To: FreeSWITCH Users Help
Subject: [Freeswitch-users] NAT traversal - the final say..!

 

Any and all feedback on this thread would be much welcomed.

 

Hello,

 

There seems to be a large number of discussions surrounding NAT traversal,
as well as lots of documentation, but with no concrete answers. 

 

The NAT related wiki documentation is tedious, and depending on the outcome
of this thread, I'd like to spend some time cleaning it up.

 

The most common problem (the same as ours) was having a router with broken
ALG and a softphone that does not seem to work with STUN.

 

The following REGISTER is sent from a phone.

 

REGISTER sip:1.2.3.4:5060 SIP/2.0

Via: SIP/2.0/UDP
192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport

Max-Forwards: 70

Contact: <sip:2000 at 192.168.1.102:57787;rinstance=0c7190b115a36513>

To: "foxx"<sip:2000 at 1.2.3.4:5060>

From: "foxx"<sip:2000 at 1.2.3.4:5060>;tag=83311448

Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.

CSeq: 7 REGISTER

Expires: 120

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY,
REFER, INFO, MESSAGE

Supported: replaces

User-Agent: 3CXPhone 6.0.25732.0

Content-Length: 0

 

As you can see, the client's public IP is not specified anywhere. FreeSWITCH
offers several ways around this, the main ones being;

 

* NDLB-connectile-dysfunction

* NDLB-force-rport

* apply-nat-acl

* sip-force-contact

 

The one that has worked in our case was "NDLB-connectile-dysfunction"
(otherwise known as NAT HACK), however there seems to be a lot of negative
comments about using this.

 

>From what I can tell, the general argument is that NAT HACK is considered a
non RFC compliant hack, and the SIP phones should be doing a better job of
keeping to the RFCs.

 

In principle, this is a fair argument - but in practise, it's not a
reasonable assumption that all phones are RFC compliant, and (imho) not a
reasonable argument to have this functionality disabled by default.

 

So, I'd like to present the following arguments;

 

* Are there any other negative aspects about using
NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?

 

* Why is NDLB-connectile-dysfunction not enabled by default when certain
conditions are met? In the event that FreeSWITCH receives a REGISTER from a
phone specifying a Contact/Via as 192.168.0.0/16, but received on a public
IP, then it should be obvious that NAT is broken and automatically try to
circumvent it.

 

* People seem to get confused between server side and client side NAT
problems, and that they both need to be resolved in a different way. The
documentation doesn't seem to reflect this clearly.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121216/b0fa8b3c/attachment-0001.html