I wonder whether this router is one that doesn't rewrite the external port, but accepts traffic to that external port from any IP (allowing hole punching to work) therefore can only map that external port to a single internal device.<div>
<br></div><div><br><div><br><br><div class="gmail_quote">On 21 December 2012 14:27, Sean Devoy <span dir="ltr"><<a href="mailto:sdevoy@bizfocused.com" target="_blank">sdevoy@bizfocused.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I just wanted to add a note “for the record”. This is specific to my Polycom 335s and my FIOS router, but probably has much broader implications to NAT in general.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I was searching for a way to eliminate SIP ALG on my router since it is disdained by many. I was successful. The main difference was that I had to set each phones local SIP signaling port to a unique number. When any two used the same port (like 5060), the second one would not register. It appears that some routers (I suspect many routers) do not map a single external port to multiple local destinations well. My extensions were 101 to 106, so I set the local SIP ports to 5101 to 5106. They still all connect to the same SERVER port (5060). This is just helping the NAT’ed Router determine the route of external packets back to the intended device (phone). I still had the 2 NDLB settings on for these user profiles as mentioned below.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Just FYI: On the polycom 335s, the setting through the web interface are SETTINGS=>SIP local port # and SETTINGS=>NETWORK=>NAT sip signaling port. They should match.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I cannot swear this, but I am pretty sure I had a similar issue with multiple lines on CISCO 504Gs. Each line had to have a unique local port.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">It is certainly easy enough to imagine how it would be much simpler to “map” multiple “one to one” external ports to internal ports than to code for a single external port having multiple internal “candidates” on the same port. In actuality, the final IP address and PORT should be present and this should not be a problem – but it is, A LOT of the time. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">HTH,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Sean<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in"><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""> <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a> [mailto:<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a>] <b>On Behalf Of </b>Sean Devoy<br>
<b>Sent:</b> Sunday, December 16, 2012 11:57 AM<br><b>To:</b> 'FreeSWITCH Users Help'<br><b>Subject:</b> Re: [Freeswitch-users] NAT traversal - the final say..!<u></u><u></u></span></p></div></div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p><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. <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></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:<u></u><u></u></span></p>
<p class="MsoNormal">* NDLB-connectile-dysfunction<u></u><u></u></p><p class="MsoNormal">* NDLB-force-rport<u></u><u></u></p><p class="MsoNormal">* Enable SIP ALG on my FIOS router.<u></u><u></u></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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">HTH,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">sean<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></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""> <a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">freeswitch-users-bounces@lists.freeswitch.org</a> [<a href="mailto:freeswitch-users-bounces@lists.freeswitch.org" target="_blank">mailto:freeswitch-users-bounces@lists.freeswitch.org</a>] <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..!<u></u><u></u></span></p><p class="MsoNormal"><u></u> <u></u></p><div>
<p class="MsoNormal"><b><span style="color:red">Any and all feedback on this thread would be much welcomed.</span></b><u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Hello,<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></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. <u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">The following REGISTER is sent from a phone.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><div><p class="MsoNormal">
REGISTER sip:<a href="http://1.2.3.4:5060" target="_blank">1.2.3.4:5060</a> SIP/2.0<u></u><u></u></p></div><div><p class="MsoNormal">Via: SIP/2.0/UDP 192.168.1.102:57787;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport<u></u><u></u></p>
</div><div><p class="MsoNormal">Max-Forwards: 70<u></u><u></u></p></div><div><p class="MsoNormal">Contact: <<a>sip:2000@192.168.1.102:57787;rinstance=0c7190b115a36513</a>><u></u><u></u></p></div><div><p class="MsoNormal">
To: "foxx"<<a href="http://sip:2000@1.2.3.4:5060" target="_blank">sip:2000@1.2.3.4:5060</a>><u></u><u></u></p></div><div><p class="MsoNormal">From: "foxx"<<a href="http://sip:2000@1.2.3.4:5060" target="_blank">sip:2000@1.2.3.4:5060</a>>;tag=83311448<u></u><u></u></p>
</div><div><p class="MsoNormal">Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.<u></u><u></u></p></div><div><p class="MsoNormal">CSeq: 7 REGISTER<u></u><u></u></p></div><div><p class="MsoNormal">Expires: 120<u></u><u></u></p>
</div><div><p class="MsoNormal">Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE<u></u><u></u></p></div><div><p class="MsoNormal">Supported: replaces<u></u><u></u></p></div><div>
<p class="MsoNormal">User-Agent: 3CXPhone 6.0.25732.0<u></u><u></u></p></div><div><p class="MsoNormal">Content-Length: 0<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></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;<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">
* NDLB-connectile-dysfunction<u></u><u></u></p></div><div><p class="MsoNormal">* NDLB-force-rport<u></u><u></u></p></div><div><p class="MsoNormal">* apply-nat-acl<u></u><u></u></p></div><div><p class="MsoNormal">* sip-force-contact<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">So, I'd like to present the following arguments;<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></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?<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></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" 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.<u></u><u></u></p>
</div><div><p class="MsoNormal"><u></u> <u></u></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.<u></u><u></u></p>
</div></div></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></div>