WebRTC media connections: ICE, STUN and TURN

How do you deal with the fact that most endpoints have been assigned a private IP address behind some form of firewall?

Before I answer that question let me define a few terms. These are pretty basics stuffs in networking.

Public IP Address 

The IP address that is globally unique across the Internet. Only one device may be in possession of a public IP address.

Private IP Address

This is an IP address that is not globally unique and may exist simultaneously on many different devices. A private IP address is never directly connected to the Internet. Devices that possess a private IP address will be in their own unique IP space (e.g. different companies or domains). The chances are extremely high that the device you are using to read this blog article has acquired a private IP address.

 Network Address Translation (NAT)

This gives private IP addresses access to the Internet. NAT allows a single device, such as a router, to act as an agent between the Internet (populated with public IP addresses) and a private network (populated with private IP addresses). A NAT device can use a single public IP address to represent many private IP addresses.

Symmetric NAT
A Symmetric NAT not only translates the IP address from private to public (and vice versa), it also translates ports. There are various rules as to how that translation and mapping occurs, but it’s safe to say that with symmetric NAT, you should never expect that the IP address/port of the source is what the destination will see.

Now I can return to the problem. How do two WebRTC clients communicate with each other when there is a good chance that neither has an IP address and port that the other can send directly to?


This is where the Interactive Connectivity Establishment (ICE) comes in.

ICE is a framework that allows WebRTC to overcome the complexities of real-world networking. It’s ICE’s job to find the best path to connect peers. It may be able to do that with a direct connection between the clients, but it also works for clients where a direct connection is not possible (i.e. behind NATs).

In the case of asymmetric NAT, ICE will use a STUN (Session Traversal Utilities for NAT) server. A STUN server allows clients to discover their public IP address and the type of NAT they are behind. This information is used to establish a media connection. The STUN protocol is defined in RFC 3489.


In most cases, a STUN server is only used during the connection setup and once that session has been established, media will flow directly between clients.

 

If a STUN server cannot establish the connection, ICE can turn to TURN (pardon the pun). Traversal Using Relay NAT (TURN) is an extension to STUN that allows media traversal over a NAT that does not do the “consistent hole punch” required by STUN traffic. TURN servers are often used in the case of asymmetric NAT.

Unlike STUN, a TURN server remains in the media path after the connection has been established. That is why the term “relay” is used to define TURN. A TURN server literally relays the media between the WebRTC peers.

Clearly, not having to use TURN is desirable, but not always possible.  Every WebRTC solution must be prepared to support both service types and engineered to handle the processing requirements placed upon the TURN server.

 

You will have to tell your webRTC application where to find STUN and TURN servers.