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

Sun Dec 16 21:48:26 MSK 2012

In my experience there is no 'fix all' procedure, you just have to use sip
traces to diagnose individual setups to get around the problems. More often
than not I find that the NAT routers at the client end are causing the
problems, but different phone/router combinations produce different results.

In my current setup, I have freeswitch 1:1 NAT mapped behind pfSense (on
someone else's network at the moment) and with the ext-sip-ip and
ext-rtp-ip set to stun:stun.freeswitch.org and my phones at home not using
STUN behind an OpenWRT-based router, everything is working fine. I did have
to install the extra connection tracking modules onto my home router,
though.

But that's just one setup.

On 16 December 2012 17:33, Avi Marcus <avi at avimarcus.net> wrote:

> My main experience is with the Linksys/Cisco (sipura) SPA-2102 ATA.
>
> I always disable ALG in the router.
>
> I turn on NAT ping of 15 seconds in the Linksys.
> And.. here's the variable part - I also turn on 2-5 of the VIAs. I haven't
> really pinned that one down.
>
> This is not strictly NAT related... but has bit me a few times: devices by
> default want to use :5060 for their SIP. Not all are smart enough to see
> something else is using it and try a different port automatically.
>
> And for your peace of mind, try to never need NAT on the server.
>
> -Avi
>
>
> On Sun, Dec 16, 2012 at 7:15 PM, Cal Leeming [Simplicity Media Ltd] <
> cal.leeming at simplicitymedialtd.co.uk> wrote:
>
>> 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<https://mail.google.com/_/mail-static/_/js/main/m_i,t,it/rt=h/ver=dQ95YePrryI.en./sv=1/am=!rQczwx1unpD1BO2bNKsLUpXXtiIjaa01SgsJmP23wMtqPKKB37R0dPvFB_9tzlm4wJdbIQ/d=1>
>>> >****
>>>
>>> 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
>>>
>>>
>>
>> _________________________________________________________________________
>> 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
>>
>>
>
> _________________________________________________________________________
> 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
>
>

-- 
*Andrew Cassidy BSc (Hons) MBCS SSCA*
Managing Director

*T <info at cassidywebservices.co.uk> *03300 100 960
*F<info at cassidywebservices.co.uk>
 *03300 100 961
*E <info at cassidywebservices.co.uk> *andrew at cassidywebservices.co.uk
*W <info at cassidywebservices.co.uk> *www.cassidywebservices.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121216/036f7313/attachment-0001.html 