My take on the subject is that we are trying to tackle 2 different problems at once.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div class="gmail_extra"><br clear="all"><div>João Mesquita<br></div><br>
<br><br><div class="gmail_quote">On Sun, Dec 16, 2012 at 6:21 PM, Cal Leeming [Simplicity Media Ltd] <span dir="ltr"><<a href="mailto:cal.leeming@simplicitymedialtd.co.uk" target="_blank">cal.leeming@simplicitymedialtd.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<div>
<br></div><div>Sean mentioned having a checklist of approaches, which would be good addition for the documentation fix.</div>
<div><br></div><div>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). </div>
<div><br></div><div>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.</div>
<div><br></div><div>With that in mind, I'm thinking that just a documentation fix is the answer here, to avoid user lazyness.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Cal</div></font></span><div class="HOEnZb">
<div class="h5"><div><br><div class="gmail_quote">On Sun, Dec 16, 2012 at 7:53 PM, Steven Ayre <span dir="ltr"><<a href="mailto:steveayre@gmail.com" target="_blank">steveayre@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>"There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. "<div>
<br></div></div><div>Part of the problem is that:</div><div><ul><li>Not all NAT implementations function in the same way (eg some rewrite ports others do not)</li>
<li>Not all SIP ALG implementations work the same/work</li><li>Not all clients handle NAT in the same way</li><li>You can encounter other odd situations such as double NAT that further complicate matters</li></ul><div>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.</div>
<div><br></div><div>Roll on NAT-less IPv6 for true end-to-end connectivity*. :o)</div><div><br></div><div>-Steve</div><div><br></div><div><br><br><div class="gmail_quote"><div><div>On 16 December 2012 16:15, Cal Leeming [Simplicity Media Ltd] <span dir="ltr"><<a href="mailto:cal.leeming@simplicitymedialtd.co.uk" target="_blank">cal.leeming@simplicitymedialtd.co.uk</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div><b><font color="#ff0000">Any and all feedback on this thread would be much welcomed.</font></b></div>
<div><br></div>
<div>Hello,</div><div><b><font color="#ff0000"><br></font></b></div><div>There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. </div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>The following REGISTER is sent from a phone.</div><div><br></div><div><div>REGISTER sip:<a href="http://1.2.3.4:5060" target="_blank">1.2.3.4:5060</a> SIP/2.0</div><div>Via: SIP/2.0/UDP 192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport</div>
<div>Max-Forwards: 70</div><div>Contact: <sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513></div><div>To: "foxx"<<a href="http://sip:2000@1.2.3.4:5060" target="_blank">sip:2000@1.2.3.4:5060</a>></div>
<div>From: "foxx"<<a href="http://sip:2000@1.2.3.4:5060" target="_blank">sip:2000@1.2.3.4:5060</a>>;tag=83311448</div>
<div>Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.</div><div>CSeq: 7 REGISTER</div><div>Expires: 120</div><div>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE</div><div>
Supported: replaces</div><div>User-Agent: 3CXPhone 6.0.25732.0</div><div>Content-Length: 0</div><div><br></div></div><div>As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being;</div>
<div><br></div><div>* NDLB-connectile-dysfunction</div><div>* NDLB-force-rport</div><div>* apply-nat-acl</div><div>* sip-force-contact</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>So, I'd like to present the following arguments;</div><div><br></div><div>* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?</div>
<div><br></div><div>* 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 <a href="http://192.168.0.0/16" target="_blank">192.168.0.0/16</a>, but received on a public IP, then it should be obvious that NAT is broken and automatically try to circumvent it.</div>
<div><br></div><div>* 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.</div>
<br></div></div><div>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></div></blockquote></div><br></div></div>
<br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org" target="_blank">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org" target="_blank">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div>
</div></div><br>_________________________________________________________________________<br>
Professional FreeSWITCH Consulting Services:<br>
<a href="mailto:consulting@freeswitch.org">consulting@freeswitch.org</a><br>
<a href="http://www.freeswitchsolutions.com" target="_blank">http://www.freeswitchsolutions.com</a><br>
<br>
FreeSWITCH-powered IP PBX: The CudaTel Communication Server<br>
<a href="http://www.cudatel.com" target="_blank">http://www.cudatel.com</a><br>
<br>
Official FreeSWITCH Sites<br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<a href="http://wiki.freeswitch.org" target="_blank">http://wiki.freeswitch.org</a><br>
<a href="http://www.cluecon.com" target="_blank">http://www.cluecon.com</a><br>
<br>
FreeSWITCH-users mailing list<br>
<a href="mailto:FreeSWITCH-users@lists.freeswitch.org">FreeSWITCH-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
<br></blockquote></div><br></div>