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
messages 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 identity and reroute the packets to this destination.
While this approach has the huge advantage that it does work
will 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 a operator in New York and wants to call his colleague B (which is
registered to a service provider in Sydney and who is sitting in the same
office in a private network), the media would have to flow first from Tokyo
via New York then via Sydney and then back to Tokyo. Considering the
speed of light, the delay would at least be around one second; practically
it would be much higher although 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 from 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 should be a shorter path, it will
switch to this shorter path. If there is no other way of 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 case when 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
intolerable media delay.
To address this problem, TURN [5] comes into play. The idea
behind 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 automatically pick the TURN server with the shortest delay. In the
Tokyo example, a TURN server located in Japan will reduce the delay
14 • Architecture
[ 4 S N A T F
S N O M
]
I L T E R