"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>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">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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>_________________________________________________________________________<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></div>