Snom 4S Manuale Utente

14 • Architecture

[  

S N O M

  4 S   N A T   F

I L T E R

  ]

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. The delay would at least be around one 

second 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.

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).