Optimizing The Media Path For Symmetrical Nat - Snom 4S NAT Filter Admin Manual

When the NAT Filter sees a message that contains information
about sending media (session description protocol, SDP), it opens a local
globally routable port on behalf of the user agent and patches these mes-
sages in a way that the destination will send media via this port. The NAT
Filter will relay the media to the user agent like it relays SIP messages.
Using symmetrical RTP, it can detect the user agent's public media iden-
tity and reroute the packets to this destination.
While this approach has the huge advantage that it works with
all kinds of NAT, it has the disadvantage that it increases the media path
significantly. For example, when a user A in Tokyo is registered with an
operator in New York and wants to call his colleague B (who is registered
with a service provider in Sydney and sitting in the same office in a private
network), the media would have to flow first from Tokyo to New York, then
to Sydney and then back to Tokyo. Considering the speed of light, the
delay would at least be around one second; in reality it would be much
higher even though the user agents are located in the same network.
Unfortunately, it is not trivial to make the media path shorter.
There have been some attempts to reduce the problem, but it is much
easier to address the problem starting at the user agent. If the user agent
uses ICE, it will try all addresses listed in the SDP attachment, including
the port allocated by the NAT Filter. If there is a shorter path, it will switch
to this shorter path. If there is no other way or if the other side does not
support ICE, it will fall back to the NAT Filter-allocated port which will work
in all cases.
2.2.8 Optimizing the Media Path for Symmetrical
NAT
In the cases where both user agents are behind symmetrical NAT,
the NAT Filter approach will ensure that media will flow between the user
agents. However, the Tokyo example shows that this might result in intol-
erable media delay.
To address this problem, TURN [5] comes into play. The idea be-
hind this approach is to allocate identities on several places in the Internet
and to propose all of the allocated ports to the other user agent. If the
ports are allocated on all continents, the other user agent will automati-
cally pick the TURN server with the shortest delay. In the Tokyo example,
a TURN server located in Japan will reduce the delay to a tolerable level
(even when there is no direct path between the user agents).
14 • Architecture
[ 4 S N A T F
S N O M
]
I L T E R