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

[Steven Ayre]

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

Part of the problem is that:

   - Not all NAT implementations function in the same way (eg some rewrite
   ports others do not)
   - Not all SIP ALG implementations work the same/work
   - Not all clients handle NAT in the same way
   - You can encounter other odd situations such as double NAT that further
   complicate matters

So what works in one case might not work in another, so it's hard to give a
concrete 'this is how to do it' that'll work in all cases. And often that
means you need to find a failing client first then put in a NDLB workaround
for that specific client. You could enable them by default, but that then
can cause problems in other cases where the clients handle NAT correctly.

Roll on NAT-less IPv6 for true end-to-end connectivity*. :o)

-Steve



On 16 December 2012 16:15, Cal Leeming [Simplicity Media Ltd] <
cal.leeming at simplicitymedialtd.co.uk> wrote:

> *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.
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121216/5d9a8a63/attachment-0001.html