<!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>
Thanks Alex for your explanation.<BR>
<BR>
Does this NAT-mapping means that TAPI would also be possible ??<BR>
<BR>
Jonas.<BR>
<BR>
On Tue, 2009-07-14 at 06:33 -0400, Alex Balashov wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
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>