[Freeswitch-users] NAT traversal - the final say..!

Fri Dec 21 20:34:15 MSK 2012

Can you add this information to the wiki:

http://wiki.freeswitch.org/wiki/Interop_List#Routers

You can just about copy and paste this email right in there. Ping me if you
have any questions.

Thanks,
MC

On Fri, Dec 21, 2012 at 6:27 AM, Sean Devoy <sdevoy at bizfocused.com> wrote:

> 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.****
>
> ** **
>
> 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.****
>
> ** **
>
> 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.****
>
> ** **
>
> 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.
> ****
>
> ** **
>
> 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. ****
>
> ** **
>
> HTH,****
>
> Sean****
>
> ** **
>
> *From:* freeswitch-users-bounces at lists.freeswitch.org [mailto:
> freeswitch-users-bounces at lists.freeswitch.org] *On Behalf Of *Sean Devoy
> *Sent:* Sunday, December 16, 2012 11:57 AM
> *To:* 'FreeSWITCH Users Help'
> *Subject:* Re: [Freeswitch-users] NAT traversal - the final say..!****
>
> ** **
>
> I have spent many hours working on *NAT issues on client end*, my server
> has a public address.  ****
>
> ** **
>
> 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:****
>
> * NDLB-connectile-dysfunction****
>
> * NDLB-force-rport****
>
> * Enable SIP ALG on my FIOS router.****
>
> 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.****
>
> ** **
>
> 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.****
>
> ** **
>
> 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.**
> **
>
> ** **
>
> HTH,****
>
> sean****
>
> ** **
>
> *From:* freeswitch-users-bounces at lists.freeswitch.org [
> mailto:freeswitch-users-bounces at lists.freeswitch.org<freeswitch-users-bounces at lists.freeswitch.org>]
> *On Behalf Of *Cal Leeming [Simplicity Media Ltd]
> *Sent:* Sunday, December 16, 2012 11:15 AM
> *To:* FreeSWITCH Users Help
> *Subject:* [Freeswitch-users] NAT traversal - the final say..!****
>
> ** **
>
> *Any and all feedback on this thread would be much welcomed.*****
>
> ** **
>
> Hello,****
>
> ** **
>
> There seems to be a large number of discussions surrounding NAT traversal,
> as well as lots of documentation, but with no concrete answers. ****
>
> ** **
>
> 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.****
>
> ** **
>
> 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.****
>
> ** **
>
> The following REGISTER is sent from a phone.****
>
> ** **
>
> REGISTER sip:1.2.3.4:5060 SIP/2.0****
>
> Via: SIP/2.0/UDP 192.168.1.102:57787
> ;branch=z9hG4bK-d8754z-b31b18401713de75-1---d8754z-;rport****
>
> Max-Forwards: 70****
>
> Contact: <sip:2000 at 192.168.1.102:57787;rinstance=0c7190b115a36513>****
>
> To: "foxx"<sip:2000 at 1.2.3.4:5060>****
>
> From: "foxx"<sip:2000 at 1.2.3.4:5060>;tag=83311448****
>
> Call-ID: NGQyMjJkODlhMzQ1ZWY4ZDk4ZjZmZWRhODU0NWE5YWI.****
>
> CSeq: 7 REGISTER****
>
> Expires: 120****
>
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY,
> REFER, INFO, MESSAGE****
>
> Supported: replaces****
>
> User-Agent: 3CXPhone 6.0.25732.0****
>
> Content-Length: 0****
>
> ** **
>
> As you can see, the client's public IP is not specified
> anywhere. FreeSWITCH offers several ways around this, the main ones being;
> ****
>
> ** **
>
> * NDLB-connectile-dysfunction****
>
> * NDLB-force-rport****
>
> * apply-nat-acl****
>
> * sip-force-contact****
>
> ** **
>
> 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.****
>
> ** **
>
> 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.****
>
> ** **
>
> 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.****
>
> ** **
>
> So, I'd like to present the following arguments;****
>
> ** **
>
> * Are there any other negative aspects about
> using NDLB-connectile-dysfunction, other than it is a non compliant RFC
> hack?****
>
> ** **
>
> * 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 192.168.0.0/16, but received on a
> public IP, then it should be obvious that NAT is broken and automatically
> try to circumvent it.****
>
> ** **
>
> * 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.****
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> 
> 
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>

-- 
Michael S Collins
Twitter: @mercutioviz
http://www.FreeSWITCH.org
http://www.ClueCon.com
http://www.OSTAG.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121221/66be31f0/attachment.html 