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

[Avi Marcus]

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