Traversal Using Relays Around NAT - Protocol Overview

Protocol Overview

The process begins when a Client Computer ("Client") wants to contact a Peer Computer ("Peer") for a data transaction, but cannot do so due to both Client and Peer being behind respective NATs. If STUN is not an option because one of the NATs is a symmetric NAT (a type of NAT known to be non-STUN compatible), TURN must be used.

First, the Client contacts a TURN server with an "Allocate" request. The Allocate request asks the TURN server to allocate some of its resources for the Client so that he/she may contact Peer. If allocation is possible, the server will allocate an address for Client to use as a relay, and send the Client a "Allocation Successful" response, which contains a "allocated relayed transport address" located at the TURN server.

Second, the Client sends in a CreatePermissions request to the TURN server to create a permissions check system for Peer/Server communications. In other words, when Peer is finally contacted and sends information back to the TURN server to be relayed to Client, the TURN server uses the permissions to verify that the Peer to TURN server communication is valid.

After permissions have been created, Client has two choices of sending the actual data, (1) he/she can use the Send mechanism, or (2) he/she can reserve a channel using the ChannelBind request. The Send mechanism is more straight forward, but contains a larger header, 36 bytes, that can substantially increase the bandwidth in a TURN relayed conversation. In contrast, the channel method is lighter: the header is only 4 bytes, but it requires a channel being reserved which needs to be periodically refreshed, among other considerations.

Using either method, Send or channel binding, the TURN server will receive the data from Client and relay it to Peer using UDP datagrams, which contain as their Source Address the "Allocated Relayed Transport Address". The Peer receives the data and responds, again using a UDP datagram as the transport protocol, sending the UDP datagram to the relay address at the TURN server.

The TURN server receives the Peer UDP datagram, checks permissions and if they are valid, sends it back to Client.

This process gets around even symmetric NATs because both the Client and Peer can at least talk to TURN server, which has allocated a relay IP address for communication.

While TURN is more robust than STUN in that it can traverse more types of NATs, it is prudent to note that a TURN communication relays the entire communication through the server requiring far more bandwidth than STUN protocol (which typically only resolves the public facing IP address then relays the information to Client and Peer for them to use in direct communication). For this reason, the ICE protocol mandates STUN usage as a first resort, and TURN usage when dealing with symmetric NATs, or other situations where STUN cannot be used.