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

Symmetric NAT 

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 

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 

Signaling server are used for indirect exchange of data between two clients. This may be a service that is accessible from both clients (e.g. a UCServer in a network) or more services, which are interconnected by federation (e.g. two UCServer of two companies which have established a XMPP Federation).

Examples of STUN and STUN/TURN

Example: Successful communication by help of a STUN server

Example: 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 the 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.

Example 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. Transferring the media stream will fail because that address is not accessible for Client B.

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

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

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

To solve this problem with "Symmetric NAT", a TURN server is required (see following figure). As soon as Client A determines that direct and STUN connections are not possible (step 1), it can inform Client B via the Signaling Server that it should establish a connection to a jointly known TURN server (step 2). In step 3, both clients have a connection to the TURN server and can now exchange data via it.

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.

Further information

Wissenswertes zu STUN/TURN für die Nutzung von Audio/Video und Softphone bei ProCall Enterprise

Wissenswertes zu STUN/TURN für die Nutzung von Audio/Video und Softphone bei ProCall Enterprise

Wissenswertes zu STUN/TURN für die Nutzung von Audio/Video und Softphone bei ProCall Enterprise