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

Mon Dec 17 20:41:58 MSK 2012

NDLB-connectile-dysfunction and sip-force-contact are both pretty
much deprecated but remain functional as a last resort.
Most problems can be solved with one of agressive-nat-detection,
NDLB-force-rport, or apply-nat-acl

agressive-nat-detection and apply-nat-acl are both geared at the 'how' NAT
is detected rather then the how to deal with it which is now centralized
into the core of sofia with fs_path support.

Stay tuned for the refresh of the FS Book where I just finished a large
chapter on NAT.  Kind of ironic that the following week everyone joins
forces to document NAT so that's great.

On Mon, Dec 17, 2012 at 11:20 AM, Cal Leeming [Simplicity Media Ltd] <
cal.leeming at simplicitymedialtd.co.uk> wrote:

> Hi Mario,
>
> If at all possible - feel free to just dump into the thread, and I can
> take care of getting it into a nice format into the wiki (everyones credits
> will be kept of course).
>
> Same for everyone else!
>
> Cal
>
>
> On Mon, Dec 17, 2012 at 5:08 PM, Mario G <mario_fs at mgtech.com> wrote:
>
>> I am planning on putting up an example of how I have 2 WAN lines both
>> available to FreeSwitch, both used at the same time (load balanced), both
>> are failover for each other. I have tested pulling plugs, etc. There is
>> nothing in FreeSwitch defined for the lines and it runs with "-nonat", the
>> router does SIP ALG fine. I thought the setup example might be useful to
>> someone since it took so long to figure it out. The only hold up has been
>> that I have other wiki updates to do and had FreeSwitch issues this year,
>> each time one is fixed another comes up (memory leak right now) so that has
>> eaten up all the time I could put into the wiki. I have already started it
>> and promise to post on the ML once it's up, should be in the next 2 months.
>> It may help someone in the same situation and requirements.
>> Mario G
>>
>>
>> On Dec 17, 2012, at 6:17 AM, Cal Leeming [Simplicity Media Ltd] wrote:
>>
>> Any other experiences/thoughts from others on this?
>>
>> Feedback so far has been great, lets keep it coming guys!
>>
>> Cal
>>
>> On Sun, Dec 16, 2012 at 9:52 PM, João Mesquita <jmesquita at freeswitch.org>wrote:
>>
>>> My take on the subject is that we are trying to tackle 2 different
>>> problems at once.
>>>
>>> On one hand we have how NAT works and what problems it create on a VoIP
>>> world. I really was not able to find any condensed documentation on the
>>> internet that would describe with VoIP in mind what a admin need to know
>>> about SIP packets and NAT handling. If there was one, we could just add a
>>> link to the wiki page. Since NAT has no "one configuration" fix, user NEEDS
>>> to know about it in order to fix his own scenario.
>>>
>>> On the other hand, we have how FS particularly deals with NAT (client
>>> and server side). I think there is more documentation to be added/created
>>> on that end as well. NAT is a complicated matter indeed and understanding
>>> Sofia profiles alone is a challenge. Add NAT to the mix and the
>>> configuration can look like black magic.
>>>
>>> So, question is, who can elaborate/contribute/find a definitive guide to
>>> NAT so we can lecture users and who knows all about the NAT handling
>>> internals so we can document each and every option available?
>>>
>>> João Mesquita
>>>
>>>
>>>
>>> On Sun, Dec 16, 2012 at 6:21 PM, Cal Leeming [Simplicity Media Ltd] <
>>> cal.leeming at simplicitymedialtd.co.uk> wrote:
>>>
>>>> It seems that most of us agree there is no single answer to fix NAT
>>>> problems - the double-NAT is something I hadn't thought about.
>>>>
>>>> Sean mentioned having a checklist of approaches, which would be good
>>>> addition for the documentation fix.
>>>>
>>>> I agree that enabling NAT HACK by default could break clients that are
>>>> functioning normally, but not if it is only enabled automatically under
>>>> certain conditions (described in the original email).
>>>>
>>>> However - the upside is that it gives another layer of "this just
>>>> works".. the downside is that it gives users a reason to not bother looking
>>>> at why their NAT is broken in the first place.
>>>>
>>>> With that in mind, I'm thinking that just a documentation fix is the
>>>> answer here, to avoid user lazyness.
>>>>
>>>> Cal
>>>>
>>>> On Sun, Dec 16, 2012 at 7:53 PM, Steven Ayre <steveayre at gmail.com>wrote:
>>>>
>>>>> "There seems to be a large number of discussions surrounding NAT
>>>>> traversal, as well as lots of documentation, but with no concrete answers. "
>>>>>
>>>>> Part of the problem is that:
>>>>>
>>>>>    - Not all NAT implementations function in the same way (eg some
>>>>>    rewrite ports others do not)
>>>>>    - Not all SIP ALG implementations work the same/work
>>>>>    - Not all clients handle NAT in the same way
>>>>>    - You can encounter other odd situations such as double NAT that
>>>>>    further complicate matters
>>>>>
>>>>> So what works in one case might not work in another, so it's hard to
>>>>> give a concrete 'this is how to do it' that'll work in all cases. And often
>>>>> that means you need to find a failing client first then put in a NDLB
>>>>> workaround for that specific client. You could enable them by default, but
>>>>> that then can cause problems in other cases where the clients handle NAT
>>>>> correctly.
>>>>>
>>>>> Roll on NAT-less IPv6 for true end-to-end connectivity*. :o)
>>>>>
>>>>> -Steve
>>>>>
>>>>>
>>>>>
>>>>> On 16 December 2012 16:15, Cal Leeming [Simplicity Media Ltd] <
>>>>> cal.leeming at simplicitymedialtd.co.uk> wrote:
>>>>>
>>>>>> *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
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _________________________________________________________________________
>>>>> 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
>>>
>>>
>> _________________________________________________________________________
>> 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
>
>

-- 
Anthony Minessale II

FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire

AIM: anthm
MSN:anthony_minessale at hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888 at conference.freeswitch.org
googletalk:conf+888 at conference.freeswitch.org
pstn:+19193869900
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20121217/d1aec968/attachment-0001.html 