What is a TURN server? A TURN server relays WebRTC traffic around NATs and firewalls, keeping voice, video and data flowing without drops.

The NAT & Firewall problem

Network address translation (NAT) lets many devices which are behind it and have private IP addresses share a single public IP address, but

NAT also changes source ports and blocks the unsolicited inbound traffic.

When two devices are each behind their own firewall and NAT, they have knowledge of only their own private IP address and any inbound packets from any other outside peer are dropped.

Analogy: imagine there are two offices each at the end of a busy hallway. Alice can walk out to send mail and access the hallway (internet) and Bob can do the same. But each of them cannot open other's office door from the outside. A relay receptionist (TURN servers) in the hallway is the only way to pass envelopes back and forth
Failed to connect peers through NAT

How WebRTC and ICE try to connect

Interactive Connectivity establishment or ICE is WebRTC's 3 step way to piercing those locked doors:

  1. Host Candidates- each peer first tests its own local (that is private) IPs. This way if both the devices are on a local network using LAN or VPN they can easily connect
  2. STUN Candidate- the peer asks a STUN server for its (device's own) public IP/port number and uses that to connect to another device by sharing this information with the other client. This fails on Symmetric NATs or firewall rules that block inbound UDP traffic
  3. TURN candidate- Lastly each peer allocates a relay address on a TURN server and all the media is sent through the TURN server, thus guaranteeing connectivity.

Example of iceServers array (Metered.ca STUN + TURN)

const pc = new RTCPeerConnection({
  iceServers: [
    {
      urls: [
        "stun:relay.metered.ca:80",
        "stun:relay.metered.ca:443"
      ]
    },
    {
      urls: [
        "turn:relay.metered.ca:80",
        "turn:relay.metered.ca:443",
        "turn:relay.metered.ca:443?transport=tcp"
      ],
      username: "YOUR_TURN_USERNAME",
      credential: "YOUR_TURN_PASSWORD"
    }
  ]
});
How TURN servers work

TURN vs STUN at a Glance

The success figures here are used from the Chrome UMA metrics and other production grade studies that show roughly one in five WebRTC calls must fall back on TURN

let us consider the differences between STUN and TURN using a table

Criterion STUN Server TURN Server
Connectivity Works when NAT is less restrictive and allows UDP traversal Works 100% of the time through any firewall or NAT type.
Bandwidth cost none just requires a one of handshake around 1KB (this is because no traffic travels through STUN servers all the traffic travels peer-to-peer) High because every data packet travelles through the turn servers. the data is encrypted end-to-end
Success rate fails 20-25% of the time. ICE first tries STUN and then as a fallback uses TURN Always works

How TURN server works (Step by Step)

Here is how the TURN server works step by step

  1. Allocation request: Here each peer sends a ALLOCATE request to the TURN server over UDP/TCP/TLS
  2. Relay address issued: The TURN server replies with relay transport address (public IP + port) that other peers can send data to.
  3. Packets flow A -> TURN -> B and back: Both the peers send the data to the relay and the TURN server forwards the data in each other's way
  4. Connection is kept alive: Peers periodically send the REFRESH or ChannelBind messages so that the allocation does not expire.
How TURN Server relays traffic

When do you actually need TURN?

Even through ICE first tries direct or STUN assisted paths, roughly 20 percent traffic goes through TURN servers

Two large scale studies from reputed sources indicate that one in five webrtc calls require a TURN server to connect.

Why these failures happen

Scenario What breaks the direct/STUN path Real-world examples
Enterprise Wi-Fi / corporate firewalls Strict firewall policies block UDP and port ranges only allows 443/80 Office or corporate networks
Carrier Grade NAT (CG-NAT) The mobile ISP terminates thousands of devices behind a single public IP address and uses the Symmetric NAT rules that reject unsolicited inbound traffic. cellular 4G/5G networks some small fiber providers
Public hotspots and hotels additional captive-portal proxies and other rate-limiters rewrite or throttle UDP and does not allow connections Airports or hotels even coffee shop wifi
Gov networks With Deep packet inspections blocks unknown UDP flows regions with strict internet controls

Free & Hosted Options for TURN server

In this section we are looking at some of the free as well as paid options for getting a TURN server for you application.

Open Relay Project

Open Relay Project

OpenRelayProject is a free turn server for use. OpenRelay provides 20 GB of free monthly turn server usage. It is distributed all over the world, so you get low latency and high throughput

And it is a good option if you need a free turn server

Metered.ca TURN servers

Metered is a Canadian corporation that offers TURN server service, that is distributed all over the world and offers high throughput, low latency turn servers

Metered has features like 99.999% Uptime and 100 plus edge pops etc

Metered also has excellent support features like 24X7 emergency support number, tech support by engineers etc.

CoTURN

CoTURN is a free and open source turn server, that you have can install in your VM in any cloud and get the TURN server for free.

But remember there are costs associated with running you own turn server like VM costs and bandwidth costs.

Also, costs associated with running and maintaining the turn server code including updating and security etc.

Service What makes it a good choice Notable specs and perks
Open Relay Project Truly free turn server service 20 GB monthly Cap
Metered TURN 10X higher throughput, automatic geo-routing along with geo-fencing capabilities, powerful APIs UDP/TCP/TLS/DTLS support, usage stats, AI-friendly low latency network with awesome support
CoTURN Open Source TURN server software that you can run on any cloud provider AWS, AZURE or Google free but you need to pay for cloud compute and bandwidth

Self Hosting the TURN server with CoTURN

In this section we are going to learn how to set up a functional TURN server using CoTURN in any VM running Ubuntu/Debian

Here is an easy 7 step formula you can use to set it up

Step 1 Spin a cloud VM

  • Create a small VPS (1 vCPU/1GB RAM is good enough) with a public Ipv4 address, generally you get the IP address free with the VM
  • In the provider that could be AWS, GCP or Azure go to the firewall or security-group and all
    • 3478/udp – the standard STUN/TURN port.
    • 3478/tcp – TURN over TCP fallback.
    • 5349/tcp – TURN over TLS (recommended for networks that allow only TLS-443-style traffic).
    • 49152-65535/udp – optional high-range UDP relay ports for maximum throughput.

Step 2 Install the CoTURN package

The CoTURN is free and open source so you can easily install it using apt like this 

sudo apt-get update
sudo apt-get install coturn -y

This package also installs the systemd service unit and helper tools such as turnutiles_uclient

Step 3 Create a minimal configuration

open the configuration file like this

sudo nano /etc/turnserver.conf

paste this essential configuration then save and exit

# Ports
listening-port=3478
tls-listening-port=5349

# Your DNS domain (or anything you want to set here)
realm=myapp.example.com

# If your VM has both a private and public IP (EC2, GCP, Azure etc.)
external-ip=232.34.234.45

# Simple long-term credential for a quick test
user=lamicall:VeryStrongPassword
lt-cred-mech

# Helpful extras
fingerprint              # adds fingerprints your STUN messages
#cert=/etc/ssl/certs/fullchain.pem
#pkey=/etc/ssl/private/privkey.pem
Optional:For greater security you can also replace the static user= line with static-auth-secret=<RANDOM_SECRET> so that you can generate short lived credentials instead of hardcoding your passwords

Step 4: Enable and start the service

Set the Ubuntu or Debian to start the service at boot and then start it right now

echo "TURNSERVER_ENABLED=1" | sudo tee -a /etc/default/coturn
sudo systemctl enable --now coturn
sudo systemctl status coturn

after this you will get something like

Listening on:(UDP) 3478
Listening on:(TCP) 5349

you can also check manually if the turn server is running by 

# ctrl-c to stop the logs
sudo journalctl -u coturn -f

look for lines 

Listening on:(TLS) 5349
Total General servers: 1
SQLite DB connection success: /var/lib/turn/turndb

if you see fatal or Cannot bind then usually firewall or something else is blocking the ports 3478/5349

Step 5 Smoke-test using the TURN server testing page

  • go to https://www.metered.ca/turn-server-testing in your chrome or safari
  • Enter
    • TURN url: turn:<YOUR_PUBLIC_IP>:3478 (or turns:<IP>:5349 if you enabled TLS)
    • Username: lamicall
    • Password: VeryStrongPassword
  • Click on the Add server then Launch server test

TURN Server FAQs

Here we look at some of the commonly asked questions with regards to the TURN server.

Do all WebRTC calls use TURN?

No. Chrome UMA telemetry data and other production grade studies show that only about 20-25% WebRTC data sessions go through a TURN server

For 75-80% of the WebRTC sessions a direct connection is successful using STUN so no media is sent through the TURN servers.

Why is there a gap like this? This is because by default TURN server is only used when all other ways to connecting to the peer are unsuccessful, this is to save costs and is done by the ICE protocol automatically.

Is TURN the same as a signalling server?

No, turn servers are different from signalling servers. here is a table that illustrates the differences

TURN Server Signalling Server
Role Relays data when peer-to-peer connections fail Relays SDP/ICE messages so that the peer devices can negotiate
Standardized? yes (IETF RFC 8656) NO- WebRTC deliberately leaves signalling server non-standardized. This means you can use anything like Websocket REST others for signalling
In the media path? yes the media is relayed through the TURN server NO Once ICE have negotiated, there is no need for signalling server. unless you want to re-negotiate
Resource Load High CPU and Bandwidth requirements low mostly small JSON or text messages

Conclusion

  1. NAT and Firewall (The Need for TURN Servers)
    1. Most Consumer and enterprise networks are behind NAT and firewall that blocks inbound traffic
    2. These barriers does not allow peer-to-peer media flows unless TURN servers are used
  2. ICE's Three layered Playbook
    1. Host candidates try a private LAN connection first
    2. Then ICE uses STUN to find out the private IP/port number of the devices in order to establish a direct connection with the peer. This works 80% of the time
    3. Lastly the ICE fallbacks to TURN which relays the data through its servers.
  3. STUN vs TURN in one sentence
    1. STUN is a lightweight option that just tells the devices which are behind NAT what their public IP and port number is
    2. TURN relays the traffic through its servers to the devices across the internet
  4. Deployment choices
    1. Hosted TURN services such as Open Relay and Metered let you paste credentials and go
    2. You can also self host with CoTURN that gives you full control but you need to bear costs regarding VM and bandwidth plus do maintenance security and updates.