<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.24.5">
</HEAD>
<BODY>
Asterisk can 'ping' the clients behind NAT with the qualify-option so the NAT-tables and routes are kept open.<BR>
<BR>
What happens when one resets the router (where the NAT-tables are kept) ?? Do NAT-tables get flushed when a router is reset ??<BR>
<BR>
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 ?<BR>
<BR>
Thanks for the feedback !<BR>
<BR>
Jonas.<BR>
<BR>
<BR>
On Tue, 2009-07-14 at 06:33 -0400, Alex Balashov wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
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,
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>