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

Cal Leeming [Simplicity Media Ltd] cal.leeming at simplicitymedialtd.co.uk
Sun Dec 16 20:15:17 MSK 2012


Hi Sean,

Thank you for the detailed reply.

The more info we can get about individual NAT experiences, the better - I'm
hoping others will follow suit!

Cal

On Sun, Dec 16, 2012 at 4:57 PM, Sean Devoy <sdevoy at bizfocused.com> wrote:

> 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] *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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121216/d4b8a43b/attachment-0001.html 


Join us at ClueCon 2011 Aug 9-11, 2011
More information about the FreeSWITCH-users mailing list