[asterisk-users] Asterisk and several clients behind NAT

[jonas kellens]

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,
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20090717/df18ed25/attachment.htm