Information concerning STUN/TURN
The following is a brief description of what a STUN/TURN service does and what problems it solves for audio/video or softphone communication between two clients. Afterwards the main application cases are recorded.
This description is intended to provide a basic understanding of the topic and does not go into more detail.
Components and terms
NAT - Network Address Translation (RFC 2663)
NAT describes the translation of "internal" IPv4 address space on the LAN to "external" IPv4 addresses (and ports) on the Internet. This increases the security of the internal network, by preventing direct, unwanted access to internal addresses from outside.
A NAT device is e.g. a router connecting a LAN to the Internet.
In addition to a normal NAT router, these routers will not only track internal client addresses, but also destination addresses contacted by you and permit data from these addresses only to enter the internal network. A third party Client cannot send data to the internal client, even if the IP addresses (and ports) were known. In this scenario audio/video communication is only possible by using a TURN server.
NAT Traversal refers to techniques for setting up and maintaining connections through a devices implementing NAT. These techniques include STUN and TURN.
STUN - Session Traversal Utilities for NAT (RFC5389)
This protocol makes identification of a client behind a NAT device possible through its public IP address.
The client on the LAN making the call can then provide its IP address (and port number) to the client to be called, in order to make direct communication (a peer-to-peer connection) possible.
TURN - Traversal Using Relays around NAT (RFC5766)
A server in the Internet which implements the TURN protocol makes it possible for two clients to exchange data without a direct connection ("relay server"). This must be done if it is not possible for a client-to-client connection to be established.
ICE - Interactive Connectivity Establishment (RFC5245)
With the help of STUN and TURN, two clients can exchange the connection information (and other data) detected with the help of the ICE protocol. The information must be transmitted using an internal service (a so-called signaling server). This service must be accessible from both clients.
Both clients will be collected ICE information, so-called ICE candidates. For this purpose, both clients will collect various candidates (potential protocols and the associated IP addresses with ports) from their LANs. The two clients then exchange these candidates over signaling servers then attempt to reach the other client by using the most appropriate candidate.
Signaling Server are used for indirect exchange of data between two clients. This may be a service that is accessible from both clients (eg a UCServer in a network) or more services, which are interconnected by federation (eg two UCServer of two companies which have established a XMPP Federation).
Samples STUN and STUN/TURN
Sample: Successful communication by help of a STUN Server
Sample: Successful communication by help of a STUN-/TURN Server
Use Cases STUN/TURN Services
In the following the main use cases of STUN/TURN services are described in more detail.
Direct communication is possible (STUN & TURN services are not needed)
To receive media streams from Client B, Client A has to send his contact information (IP address and port) to Client B. This is usually done via a signaling server to which both clients must have a connection. As long as both clients are in the same LAN, direct communication is not a problem. Fig. 1 clarifies this situation. In Step 1, Client A will send its IP address and port to Client B using the signaling server. In Step 2, Client B can begin sending a media stream to Client A.
Sample Fig. 1: A client is directly accessible. Client B can send the media stream directly to client A.
One client is behind a NAT router
If both Client A and Client B are in different LANs and separated by a NAT router, the scenario above will fail. Because Client A does not know that it should use the public IP address and port for the NAT router for transferring to Client B, Client will tell Client B to use the local IP address and port. Because that address is not accessible for Client B, transferring the media stream will fail.
Sample Fig. 2: Unsuccessful connection setup through a NAT router.
The non-accessibility problem can be solved by using a STUN server as shown in Fig. 3. With the help of the STUN server, Client A can determine its public IP address & port in Step 1. It can then transmit the correct information to Client B, which can then send its media stream to the public IP address of the NAT router. The NAT router will then forward the media stream to Client A.
Sample Fig. 3: Successful communication with the help of a STUN server
At least one client cannot be reached from outside the network (symmetric NAT router).
The previous solution will not work for all NAT implementations. There is a class of NAT systems, indicated by the term symmetric NAT, which open a port not just for one LAN Client A, but rather open a port for each individual connection. As a consequence, Client A can still request its public IP address & port from the STUN server, which would be invalid for connections with Client B.
Sample Fig. 4: Unsuccessful communication attempt through a symmetric NAT setup
Because the correct public port cannot be determined from the STUN server, sending the media stream from Client B will fail.
In order to solve the problem with the a "Symmetric NAT", a TURN server is needed (see Fig. 5). Once Client A determines that direct and STUN connections are not possible (step 1), he may notify Client B via the Signaling Server about a common known TURN server (step 2). In step 3, both clients are connected through the TURN server and are able to communicate.
Sample Fig. 5: Successful communication attempt via a "symmetric NAT", using a TURN server
Because the useful data will be transferred directly through the TURN server, a TURN server must fulfill very high demands with regard to bandwidth, in particular given multiple parallel connections. For this reason, this solution will only be chosen when there are no other options for transferring data.