TURN (Traversal Using Relays around NAT) is used in WebRTC when direct peer-to-peer connections fail and media must be relayed through a server.
- Used when NAT/firewall blocks P2P
- Increases latency
- Increases cost
It is a standard method of NAT traversal used in WebRTC. It is defined in IETF RFC 5766.
STUN, TURN, ICE – getting WebRTC sessions to connect can be easier than you think. Check out my free mini course on the topic:
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
The table below offers a general comparison between the two severs – STUN and TURN:
| STUN | TURN | |
|---|---|---|
| Purpose | Discover public IP of the user’s device | Relay media on behalf of a user |
| Frequency of use | Used in most WebRTC sessions | Used as a fallback, when no direct media route is found |
| Cost | Inexpensive, often free | Expensive at scale, based on bandwidth use |
| Quality impact | No media quality impact | Might affect quality depending on deployment and location |
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.
Commercial realities: built vs buy
Using a third party managed TURN service isn’t hard. It requires a few minutes or hours of integration and that’s about it. There is very little vendor lock-in as well, making it a great alternative, especially for small and medium sized deployments.
This is why in many cases, there is a build vs buy decision to be made when using TURN.
- Self hosting your own TURN service is usually cheaper to maintain and operate when it comes to bandwidth costs (compared to the managed alternative), but requires DevOps effort of setting up a global footprint of TURN servers to keep these servers as close as possible to all potential users. There is also the headache of configuring and securing TURN servers properly over time
- Managed TURN services offer a “peace of mind” when it comes to DevOps, maintenance and security but comes at a bandwidth cost. They are built around the notion of economies of scale, catering multiple clients with high volumes of traffic in aggregate. The upside here is that such services are hard to replicate on a shoestring budget and for small deployments
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.
Troubleshooting TURN and connectivity issues in WebRTC? rtcStats has great visualization and analysis covering this in detail.
Create your free account on rtcstats.com
