TURN as in TURN server stands for Traversal Using Relays around NAT.
It is a standard method of NAT traversal used in WebRTC. It is defined in IETF RFC 5766.
TURN Server
TURN is used to relay media via a TURN server when the use of STUN isn’t possible.
The decision whether to use STUN or TURN is orchestrated by a protocol called ICE.
Since it relays all media through it, this can be a rather expensive endeavor (costing in bandwidth and CPU at a data center). This is why public TURN servers aren’t usually available and every service needs to install and maintain its own server (or pay for a hosted service).
TURN can use different transport protocols to relay its media:
- TURN/UDP – relaying media over UDP. This is the preferred method for handling real time media
- TURN/TCP – relaying media over TCP. This method can be seen as a fallback to UDP when UDP isn’t reachable from the device to the TURN server
- TURN/TLS – relaying media over TLS. This method is used for “worst case” scenario when nothing else can be used
Each of the mechanisms above is independent of the other. ICE is used to determine which of these transport protocols can be used for a given scenario.
WebRTC has revolutionized real-time communication, but it comes with its own set of challenges, especially when dealing with Network Address Translators (NATs) and firewalls.
Why WebRTC Needs to Deal with NATs and Firewalls
WebRTC is designed to facilitate peer-to-peer communication directly between browsers. However, this becomes a challenge when a firewall is involved. The firewall can block the direct flow of media from one browser to another, making it essential for WebRTC to find a way to traverse these firewalls.
The Challenge of Private and Public IPs
When a user is behind a firewall, their device is usually assigned a private IP address, like 10.0.0.1. This private IP is not directly accessible from the public network. The NAT device at the edge of the network assigns a public IP address to the user’s traffic as it moves into the public network. The challenge here is that WebRTC inside a browser only has access to the private IP address, making it impossible to establish a direct connection.
How STUN Servers Help
To overcome this, a STUN (Session Traversal Utilities for NAT) server can be used. The user can query the STUN server to find out their public IP address. Once the public IP is known, it can be shared with the other peer, allowing for a direct connection. This process also creates a “pinhole” in the NAT device, enabling incoming traffic from the other peer.
The Limitations of STUN
While STUN works well in many scenarios, it falls short when dealing with symmetric NATs. In such cases, the mapping of private and public IPs is such that it blocks incoming traffic from any other destination other than the one the original pinhole message was sent to, making STUN ineffective. This is where TURN servers come into play.
The Role of TURN Servers
TURN (Traversal Using Relays around NAT) servers act as a relay for all the traffic between the peers. If a direct connection can’t be established, the TURN server steps in to relay the media. However, this comes at a cost—increased bandwidth usage, higher server-side CPU load, and potential latency.
Comparing STUN and TURN
- Purpose: STUN is used to discover public IP, while TURN is used to relay media
- Frequency of Use: STUN is used almost always, and TURN is used as a fallback
- Cost: STUN is generally inexpensive, while TURN can be costly, especially at scale
- Quality Impact: STUN has no quality impact, but TURN might affect quality depending on deployment
Making the Choice: ICE Protocol
The ICE (Interactive Connectivity Establishment) protocol helps in deciding whether to use STUN or TURN. ICE collects different types of candidates (host, server-reflexive, and relay candidates) and performs connectivity checks to determine the best path for the media flow.
Conclusion
Understanding the roles of STUN and TURN servers is crucial for anyone working with WebRTC. While STUN servers help in most cases, TURN servers are the go-to solution for more complex scenarios involving symmetric NATs. By leveraging the ICE protocol, you can make an informed decision on which to use, ensuring a smooth and efficient real-time communication experience.
