Understanding TURN Servers: The Backbone of WebRTC Connectivity

When you make a video call or share a file over WebRTC, your device ideally connects directly to the other peer. But in the real world, most users are behind NATs (home routers, firewalls, corporate proxies). That’s where TURN servers come in.

TURN = Traversal Using Relays around NAT It’s essentially a relay server that passes media between peers when they can’t connect directly.

🌍 1. The Ideal Case: Direct Peer-to-Peer

Photo by Shubham Dhage on Unsplash

 Client A  ──────────────── Client B
   (192.168.x.x)             (203.x.x.x)

If NATs and firewalls allow it, clients can connect directly using STUN (Session Traversal Utilities for NAT). This is fastest and uses the least bandwidth.

🚧 2. The Problem: NAT & Firewall Blocking

 Client A  ──X── NAT ───────── NAT ──X── Client B

Photo by Adi Goldstein on Unsplash

• Corporate firewalls may block inbound UDP.
• Some NATs don’t allow hole-punching.
• Result → connection fails.

🔄 3. The Solution: TURN as a Relay

 Client A ─────► TURN Server ◄───── Client B
              (Public IP, Port)

Photo by Magic Keegan on Unsplash

• Both clients connect to a public TURN server.
• TURN allocates a relay address (IP:port).
• Media flows through the TURN server instead of directly between clients.

Yes, it’s slower than direct P2P (extra hop), but it guarantees connectivity.

🛠️ 4. TURN Server Architecture

   ┌───────────────┐              ┌───────────────┐
   │   Client A    │              │   Client B    │
   └───────┬───────┘              └───────┬───────┘
           │                              │
           │  Allocate Relay Candidate    │
           │──────────────►               │
           │          ┌───────────────────┴──────────┐
           │          │          TURN Server         │
           │          │ ┌─────────────────────────┐ │
           │          │ │ Authentication (STUN)   │ │
           │          │ │ Relay Allocation        │ │
           │          │ │ Channel Management      │ │
           │          │ │ RTP/RTCP Media Relay    │ │
           │          │ └─────────────────────────┘ │
           │          └───────────┬─────────────────┘
           │                      │
           │    Media Relay       │
           │◄────────────────────►│

TURN in ICE Flow

WebRTC uses ICE (Interactive Connectivity Establishment) to try multiple connection methods:

1. Host Candidates — Direct local IPs.
2. Server Reflexive Candidates — From STUN servers (public NAT-mapped IPs).
3. Relay Candidates — From TURN servers.

If the first two fail, ICE falls back to relay candidates.

Connection Priority:
   Host → STUN → TURN

🔑 How TURN Works (Step by Step)

1. STUN/Authentication Client requests credentials and a relay candidate from TURN.
2. Relay Allocation TURN assigns a public relay address (e.g., 34.120.55.12:58743).
3. Candidate Exchange Clients exchange this info over a signaling server (like Matrix, SIP, or custom WebSocket).
4. Media Flow Clients send packets to TURN → TURN forwards them to the other peer.

⚡ Why TURN is Essential

• Always works: Even behind strict NAT/firewalls.
• Fallback: Used only if direct (P2P/STUN) paths fail.
• Critical for WebRTC apps: Video calls, conferencing, gaming, etc.

Yes, it’s more expensive (bandwidth & CPU on server side), but without it, many users couldn’t connect at all.

Deployment-

                +------------------+
                |   TURN Server    |
                | (coturn, etc.)   |
                +------------------+
                 ^              ^
                 |              |
             Internet        Internet
                 |              |
          +-------------+   +-------------+
          |   Peer A    |   |   Peer B    |
          +-------------+   +-------------+

✅ In summary-

• STUN = find your public IP.
• TURN = relay when all else fails.
• Without TURN, your WebRTC app will break for a lot of users.
• Popular TURN servers: coturn, pion/turn, Twilio ICE servers.

Photo by Joshua Reddekopp on Unsplash