[asterisk-users] Asterisk and several clients behind NAT

[jonas kellens]

Asterisk can 'ping' the clients behind NAT with the qualify-option so
the NAT-tables and routes are kept open.

What happens when one resets the router (where the NAT-tables are
kept)  ?? Do NAT-tables get flushed when a router is reset ??

Does the public IP-address needs to be a static IP-address ??? How can
Asterisk use qualify to clients that are behind a dynamic public
IP-address once registered ?? The clients are not aware that the public
IP-address has changed and will not re-register automatically ?! Would
dyndns be a solution ?

Thanks for the feedback !

Jonas.


On Tue, 2009-07-14 at 06:33 -0400, Alex Balashov wrote:

> jonas kellens wrote:
> 
> > Is it possible to have several clients behind NAT to register to an 
> > Asterisk-server with a public IP-address ?
> > 
> > When Asterisk receives an incoming call, how will it know @ which 
> > private IP-address the client is reachable ?
> > 
> > I guess it is impossible for Asterisk to directly contact the private 
> > client behind the NAT ?! Or to distinguish between the private clients ?!
> > 
> > Is there an easy solution to this ? How does hosted IP-PBX services work 
> > then ?!
> 
> 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/20090723/91ed2e12/attachment.htm