One major issue with end-to-end communication between pairs of endpoints is that, in many cases, those endpoints do not reside in the public Internet, but in a private address space behind Network (and Port) Address Translators (NATs). As the Internet grew from a DARPA project into planetary scale network, it was quickly clear that the 232 address space for IPv4 would sooner or later run out.
In the 1990s, multiple strategies were developed to delay the IPv4 address exhaustion, amongst those was the design of a NAT. NATs hide the endpoint’s real IP address from the rest of the world, which makes it difficult to set up a peer-to-peer, a direct connection between endpoints. That is where assistive frameworks — including STUN and TURN (or Traversal Using Relay NAT) — come in handy.
Based on our data at callstats.io, we observe that, on average about 30% of the P2P conferences has one endpoint connect via a TURN server. These users would not be able to communicate without the assistance from a TURN relay server. Thus, it is pertinent for developers to understand what a TURN server is, and why it is necessary to so many WebRTC call events.
ICE and STUN
Before considering TURN, we need to define two more acronyms.
ICE stands for Interactive Connectivity Establishment and defines a systematic way of finding possible communication options between two endpoints (through NATs and Firewalls), including using relays as necessary.
STUN stands for Session Traversal Utilities for NAT. STUN provides the requesting endpoint its public IP address. STUN is a relatively lightweight process—lightweight because once STUN provides a publicly-reachable IP address for the requestor, it is no longer involved in the conversation.
When an endpoint is behind a NAT, it only sees its local IP address. Other endpoints in the call would be unable to use this local IP address to connect to endpoint, as it might be a private address or the firewall does not allow access. In such cases, this endpoint can ask a STUN server to provide its public IP address. The participants then use the ICE procedures and attempt to establish a connection using the public IP address and if the connection is successfully set up, media flows directly between the users, without any active intermediary. For all practical purposes, the STUN then drops out of sight, waiting for the next query.
However, the above situation is successful only for some NATs. In some NAT implementations, the port will be translated to some other port, along with the IP address to which it is attached. This situation is called “symmetric NAT”. The public IP address of the STUN process is not enough to establish connectivity here, as the port would also need translation.
That is where a TURN server becomes essential.
How TURN works
The above figure sketches the operation of ICE in a simplified manner. The figure depicts the nodes of Alice (A) and Bob (B) with two and one network interfaces, respectively, all of which support both IPv4 and IPv6.
As a result, Alice has four host addresses (A1, A1v6, A2, A2v6) and Bob has two (B1, B1v6). These are the addresses within their own addressing realms, i.e., in this specific case behind NAT A and NAT B. These host addresses are obtained locally from the operating system (1).
To determine their public realm IP addresses, each node interacts with a STUN server and learns its server-reflexive addresses: C(A1), C(A2) and D(B1), D(B1v6), respectively (2). A TURN relay server may also offer STUN capabilities and offer one of its (public) addresses to the endpoint to relay packets through. In this case, a node (B) can bind to a relayed address residing on the TURN server: D, Dv6. Both endpoints exchange their addresses in an offer (3) and answer (4), and once this exchange, both endpoints start probing (in priority order) to determine which addresses are mutually reachable (5). As soon as at least one workable address pair has been found, the nodes can start sending media streams (6).
The above process illustrate how a TURN server facilitates conversations between peers behind different NAT firewalls. It also acts as a relay — holding and buffering content before forwarding it to the client on the usable port it has discovered and cataloged with the client’s public IP address. TURN servers need a reasonable amount of network I/O capacity to relay media between participants and the size of the server typically depends on the number of concurrent endpoints.
Take Your TURN
There are multiple open-source TURN servers (e.g., coturn or restund) that you can run on any of the cloud providers. These servers are well maintained and great to use in your service. Alternatively, instead of scaling your own servers (especially when your media traffic is low) you can use one of the several TURN Platforms as a Service (PaaS) providers.
The main thing to watch out while scaling your TURN servers is hairpinning. Hairpinning occurs when participants in a relatively close proximity send their media to a TURN server in a relatively far of location. For example, two users in Germany might be sending their media to a TURN server in the East Coast of the US, when there could easily be servers in Ireland, the Netherlands, or even in Germany itself. On the other hand, services might prefer hairpinning when the user-base in a particular region might be low, for example, users in Southeast Asia might be relayed by servers in Hong Kong or Singapore.
TURN servers are essential and each WebRTC implementation places different demands on the TURN component based on their service needs and where your customers are located. The best approach is to count on securing the use of a stable and scalable TURN server from the start of your project. Monitor the use of the TURN server, and try to model the usage growth as your WebRTC traffic increases.
You should also read our latest WebRTC industry report, it compares the performance (gathering time and time to first media, RTT and fraction losses) of direct P2P connections with TURN relays and SFU/bridges.
Build better WebRTC products with callstats.io. Quick to integrate to all the major WebRTC providers. Take a look at our SDK library.
