<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {mso-style-priority:99;
        mso-style-link:"Balloon Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif";}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.BalloonTextChar
        {mso-style-name:"Balloon Text Char";
        mso-style-priority:99;
        mso-style-link:"Balloon Text";
        font-family:"Tahoma","sans-serif";}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I have spent many hours working on <b>NAT issues on client end</b>, my server has a public address. <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>With CISCO brand phones I did not need any non-standards compliant settings, just turning on all the choices in the CISCO web setup NAT section. However, with Polycom 335 phones (as of Dec 2012) I could not get registered or get audio without the following:<o:p></o:p></span></p><p class=MsoNormal>* NDLB-connectile-dysfunction<o:p></o:p></p><p class=MsoNormal>* NDLB-force-rport<o:p></o:p></p><p class=MsoNormal>* Enable SIP ALG on my FIOS router.<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>With those setting however, this has worked perfectly. Also note that when I turned on SIP ALG, my Cisco phones quite working until I added the NDLB parameter/variable to the Cisco <user> in the directory. They seem to be quite complimentary but seem be requirements for each other.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I really tried to stay away from SIP ALG because so many posts were so negative about it. Without the NDLB “flags” I could never see any difference when enabling SIP ALG. The combination for me has been fantastic.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>HOWEVER, since there are so many different versions of “success” in the IRC and Wiki, I am pretty sure that other router brands with different SIP ALG implementations and/or other phone brands or even firmware versions may need different configurations. It is almost like we just need a checklist that says try these combinations until you find one that fits your site.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>HTH,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>sean<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] <b>On Behalf Of </b>Cal Leeming [Simplicity Media Ltd]<br><b>Sent:</b> Sunday, December 16, 2012 11:15 AM<br><b>To:</b> FreeSWITCH Users Help<br><b>Subject:</b> [Freeswitch-users] NAT traversal - the final say..!<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><b><span style='color:red'>Any and all feedback on this thread would be much welcomed.</span></b><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Hello,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>There seems to be a large number of discussions surrounding NAT traversal, as well as lots of documentation, but with no concrete answers. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The following REGISTER is sent from a phone.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><p class=MsoNormal>REGISTER sip:<a href="http://1.2.3.4:5060">1.2.3.4:5060</a> SIP/2.0<o:p></o:p></p></div><div><p class=MsoNormal>Via: SIP/2.0/UDP 192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport<o:p></o:p></p></div><div><p class=MsoNormal>Max-Forwards: 70<o:p></o:p></p></div><div><p class=MsoNormal>Contact: <<a href="sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513">sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513</a>><o:p></o:p></p></div><div><p class=MsoNormal>To: "foxx"<<a href="http://sip:2000@1.2.3.4:5060">sip:2000@1.2.3.4:5060</a>><o:p></o:p></p></div><div><p class=MsoNormal>From: "foxx"<<a href="http://sip:2000@1.2.3.4:5060">sip:2000@1.2.3.4:5060</a>>;tag=83311448<o:p></o:p></p></div><div><p class=MsoNormal>Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.<o:p></o:p></p></div><div><p class=MsoNormal>CSeq: 7 REGISTER<o:p></o:p></p></div><div><p class=MsoNormal>Expires: 120<o:p></o:p></p></div><div><p class=MsoNormal>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE<o:p></o:p></p></div><div><p class=MsoNormal>Supported: replaces<o:p></o:p></p></div><div><p class=MsoNormal>User-Agent: 3CXPhone 6.0.25732.0<o:p></o:p></p></div><div><p class=MsoNormal>Content-Length: 0<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal>As you can see, the client's public IP is not specified anywhere. FreeSWITCH offers several ways around this, the main ones being;<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>* NDLB-connectile-dysfunction<o:p></o:p></p></div><div><p class=MsoNormal>* NDLB-force-rport<o:p></o:p></p></div><div><p class=MsoNormal>* apply-nat-acl<o:p></o:p></p></div><div><p class=MsoNormal>* sip-force-contact<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>So, I'd like to present the following arguments;<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>* Are there any other negative aspects about using NDLB-connectile-dysfunction, other than it is a non compliant RFC hack?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>* 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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>* 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.<o:p></o:p></p></div></div></body></html>