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

Mon Dec 17 00:52:18 MSK 2012

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