Operating Mode

The estos STUN/TURN Server is implemented as system service which provides STUN- und TURN-Server functionality.

The following briefly describes what a STUN/TURN service is and which problems can be solved with it in the audio/video communication environment. Subsequently, the main use cases are being described.

This description is intended to give a basic understanding of the subject without going too much into 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 stands for Session Traversal Utilities for NAT (see 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 means Traversal Using Relays around NAT (see 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 means Interactive Connectivity Establishment (see 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 (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).

Use cases

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.

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 in Step 2 (see Fig. 2).

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.

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.

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.

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.