en two user agents behind NATs, a signaling and media relay protocol such as TURN is required, which is described in the next section. SIP Clients and Servers Table 3.1 Type of Address Translation Translation Internet No translation; client has a public IP address Full cone NAT Constant mapping between private IP address and public IP address Restricted cone NAT Constant mapping, but an outgoing packet is needed to open incoming path Symmetric NAT Different public IP address mapping is used based on destination IP address 3.12.2 TURN Protocol The TURN protocol [13] allows a client to obtain a transport IP address and port that it can receive packets sent from a single IP address in the public Inter- net. For some NAT topologies such as a client behind a symmetric NAT, using a relay located in the public Internet is the only approach that allows communi- cation to take place. Similar to STUN, a TURN client can use DNS SRV records for the domain of the service provider. TURN uses an identical syntax to STUN and reuses the Shared Secret Request and Shared Secret Response packets to estab- lish the shared secret. The client can also use Binding Request and Binding Response packets to detect and categorize the NAT in the path. A client uses an Allocate Request to request a relay IP address and port number be returned in an Allocate Response packet. Requests for transport addresses to be used for UDP must be sent using UDP while requests for transport addresses for TCP transport must be sent using TCP. TURN, due to its triangular routing, will result in increased packet latency and increased probability of packet loss. TURN should only be used when it is the only approach available (i.e., the IP addresses obtained using STUN will not work). Note that TURN can be used instead of a B2BUA to provide an ano- nymizer service. Figure 3.9 shows a SIP client behind a NAT using STUN and TURN to obtain a transport IP address and setting up a session as a result. Note that the resulting SIP and RTP messages are routed through the