<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">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">sip:2000@1.2.3.4:5060</a>></div><div>From: "foxx"<<a href="http://sip:2000@1.2.3.4:5060">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">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>