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

Mon Dec 17 20:08:19 MSK 2012

I am planning on putting up an example of how I have 2 WAN lines both available to FreeSwitch, both used at the same time (load balanced), both are failover for each other. I have tested pulling plugs, etc. There is nothing in FreeSwitch defined for the lines and it runs with "-nonat", the router does SIP ALG fine. I thought the setup example might be useful to someone since it took so long to figure it out. The only hold up has been that I have other wiki updates to do and had FreeSwitch issues this year, each time one is fixed another comes up (memory leak right now) so that has eaten up all the time I could put into the wiki. I have already started it and promise to post on the ML once it's up, should be in the next 2 months. It may help someone in the same situation and requirements.
Mario G

On Dec 17, 2012, at 6:17 AM, Cal Leeming [Simplicity Media Ltd] wrote:

> Any other experiences/thoughts from others on this?
> 
> Feedback so far has been great, lets keep it coming guys!
> 
> Cal
> 
> On Sun, Dec 16, 2012 at 9:52 PM, João Mesquita <jmesquita at freeswitch.org> wrote:
> My take on the subject is that we are trying to tackle 2 different problems at once.
> 
> On one hand we have how NAT works and what problems it create on a VoIP world. I really was not able to find any condensed documentation on the internet that would describe with VoIP in mind what a admin need to know about SIP packets and NAT handling. If there was one, we could just add a link to the wiki page. Since NAT has no "one configuration" fix, user NEEDS to know about it in order to fix his own scenario.
> 
> On the other hand, we have how FS particularly deals with NAT (client and server side). I think there is more documentation to be added/created on that end as well. NAT is a complicated matter indeed and understanding Sofia profiles alone is a challenge. Add NAT to the mix and the configuration can look like black magic.
> 
> So, question is, who can elaborate/contribute/find a definitive guide to NAT so we can lecture users and who knows all about the NAT handling internals so we can document each and every option available?
> 
> João Mesquita
> 
> 
> 
> On Sun, Dec 16, 2012 at 6:21 PM, Cal Leeming [Simplicity Media Ltd] <cal.leeming at simplicitymedialtd.co.uk> wrote:
> It seems that most of us agree there is no single answer to fix NAT problems - the double-NAT is something I hadn't thought about.
> 
> Sean mentioned having a checklist of approaches, which would be good addition for the documentation fix.
> 
> I agree that enabling NAT HACK by default could break clients that are functioning normally, but not if it is only enabled automatically under certain conditions (described in the original email). 
> 
> However - the upside is that it gives another layer of "this just works".. the downside is that it gives users a reason to not bother looking at why their NAT is broken in the first place.
> 
> With that in mind, I'm thinking that just a documentation fix is the answer here, to avoid user lazyness.
> 
> Cal
> 
> On Sun, Dec 16, 2012 at 7:53 PM, Steven Ayre <steveayre at gmail.com> wrote:
> "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
> 
> 
> 
> _________________________________________________________________________
> 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
> 
> 
> 
> _________________________________________________________________________
> 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
> 
> 
> 
> _________________________________________________________________________
> 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
> 
> 
> _________________________________________________________________________
> 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/20121217/11b0bf2f/attachment-0001.html 