[asterisk-users] Asterisk and several clients behind NAT

[Alex Balashov]

You're welcome.

What's TAPI?

--
Sent from mobile device

On Jul 17, 2009, at 5:38 AM, jonas kellens <jonas.kellens at telenet.be>  
wrote:

> Thanks Alex for your explanation.
>
> Does this NAT-mapping means that TAPI would also be possible ??
>
> Jonas.
>
> On Tue, 2009-07-14 at 06:33 -0400, Alex Balashov wrote:
>>
>>
>> Yes, this problem has a solution.  The NAT gateway creates a UDP  
>> state
>> mapping between internal source ports and external source (and
>> destination, since most user agents are symmetrical nowadays) ports.
>>
>> The NAT gateway then allocates different external UDP ports for
>> different "connections" being tracked in this manner.
>>
>> Consider, for example, two phones - 192.168.1.10 and 192.168.1.11 -
>> registering to an outside SIP UAS through a NAT gateway whose public
>> address is 67.194.23.55.  The NAT gateway maps the source ports in a
>> random or pseudorandom manner akin to:
>>
>>     192.168.1.10:5060 --> 67.194.23.55:32947
>>     192.168.1.11:5060 --> 67.194.23.55:47948
>>
>> If far-end NAT traversal is enabled on the UAS (in the case of  
>> Asterisk,
>> that's nat=yes in sip.conf), the Contact URI supplied in the REGISTER
>> message is ignored and the actual "received" IP and port on the  
>> network
>> and transport layer is used in its place.  The latter is what is  
>> stored
>> as the contact binding.
>>
>> Later, a call comes in and the UAS maps it back to  
>> 67.194.23.55:47948 or
>> 32947 depending on which registrant it is destined to go to.
>>
>> This scenario is not without its problems.  Some user agents do not
>> behave symmetrically.  Some firewall/NAT router ALGs (application  
>> layer
>> gateways) break this process, though they mean well and try to be
>> helpful.  But by far the most pressing problem is that many NAT  
>> gateways
>> rather quickly age the temporary state information (internal:external
>> UDP port mapping) out after a relatively short period of inactivity.
>> That is why many far-end NAT traversal approaches implement a  
>> policy of
>> periodically "pinging" the stored ("received") contact with some  
>> sort of
>> message that causes a bidirectional exchange of communication, and
>> therefore causes the NAT gateway to reset its expiration timer for  
>> that
>> "connection" state.  In Asterisk, the OPTIONS messages generated when
>> the qualify=yes option is enabled in sip.conf fulfill this function.
>>
>> Hope that helps,
>>
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users