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

[Tim St. Pierre]

Just throwing this out there -

As it's clear how many problems NAT causes, why don't we all step up the pressure on phone 
manufacturers and ISPs to provide working IPv6 implementations so we can put NAT behind us 
  as soon as possible.

Just saying -

-Tim


Cal Leeming [Simplicity Media Ltd] 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 <http://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 <http://sip:2000@1.2.3.4:5060>>
> From: "foxx"<sip:2000 at 1.2.3.4:5060 
> <http://sip:2000@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 
> <http://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