NAT & Firewall TraversalKnowledge baseWebRTC · RFC 5766 / RFC 8656

Deep Dive into TURN: Traversal Using Relays around NAT

by Provider Adminlast verified 2026-07-29

Overview

This guide provides a comprehensive overview of TURN (Traversal Using Relays around NAT), the critical media relay protocol used when direct peer-to-peer connectivity fails. You will learn about TURN allocation lifecycles, data transport optimization via ChannelBind, integration with ICE, and best practices for securing production deployments. Practical configuration examples using Coturn demonstrate how to implement TURN in real-world VoIP and WebRTC environments.

Illustration for Deep Dive into TURN: Traversal Using Relays around NAT

Key takeaways

TURN acts as a media relay server of last resort when direct P2P connection attempts via STUN fail due to Symmetric NATs or strict enterprise firewalls.
The protocol establishes an Allocation on the relay server, which provides a public IP and port tuple dedicated to forwarding media streams.
ChannelBinding significantly reduces per-packet overhead from 36 bytes (Send/Data Indication) down to 4 bytes during active media sessions.
Securing TURN requires long-term credentials or time-limited ephemeral tokens (HMAC-SHA1) to prevent unauthorized relay abuse and bandwidth theft.
ICE prioritizes candidate pairs based on latency and path efficiency, placing TURN relay candidates at the lowest priority due to resource usage.

Prerequisites

Understanding of IPv4/IPv6 networking, UDP/TCP transport protocols, and NAT types (Symmetric, Port-Restricted).
Familiarity with the ICE (Interactive Connectivity Establishment) protocol framework.
Root or sudo access to a public Linux server for deploying relay software such as Coturn.

Guide

section #1
Introduction to TURN and the NAT Traversal Problem In IP communications, direct peer-to-peer media paths are ideal for low latency and minimal infrastructure cost. However, Network Address Translation (NAT) devices and restrictive firewalls frequently block incoming UDP packets from unknown external sources. While STUN (Session Traversal Utilities for NAT) allows endpoints to discover their public-facing IP address and port mapping, STUN fails when one or both endpoints sit behind Symmetric NATs or restrictive enterprise firewalls that alter port mappings per destination IP. TURN (Traversal Using Relays around NAT), specified in RFC 5766 and updated for IPv6 in RFC 8656, solves this problem by establishing an intermediate public relay server that buffers and forwards media packets between peers.
section #2
The TURN Protocol Lifecycle: Allocations and Permissions The TURN transaction begins when a client behind a NAT sends an Allocate request to the TURN server over UDP, TCP, or TLS. The server authenticates the client and allocates a dedicated public IP address and port known as the Relayed Transport Address. To prevent unauthorized traffic forwarding and amplification attacks, the client must explicitly install permissions for peer IP addresses using CreatePermission requests. Once permissions are granted, any media sent to the TURN server's allocated port from the specified peer IP address is relayed directly to the client, and vice versa.
section #3
Optimizing Media Flow: Send/Data Indications vs. Channel Binding TURN offers two mechanisms for sending data: Send/Data Indications and Channel Binding. Send/Data Indications wrap raw RTP payload in STUN/TURN message headers, adding 36 bytes of overhead per packet. To minimize bandwidth and CPU overhead during high-frequency RTP media streams, clients initiate a ChannelBind request. This binds a peer's IP address and port to a 16-bit Channel Number (range 0x4000 to 0x7FFF). Subsequent packets use a minimal 4-byte channel header consisting of the channel number and packet length, drastically improving framing performance and reducing bandwidth consumption.
```
Send/Data Indication Framing Overhead:
+-------------------+--------------------+------------------+
| STUN/TURN Header  | XOR-PEER-ADDRESS   | Raw Data Payload |
| (20 Bytes)        | Attribute (16 B)   | (RTP Packet)     |
+-------------------+--------------------+------------------+
Total Framing Overhead = 36 Bytes

ChannelBinding Framing Overhead:
+-------------------+--------------------+------------------+
| Channel Number    | Length             | Raw Data Payload |
| (2 Bytes)         | (2 Bytes)          | (RTP Packet)     |
+-------------------+--------------------+------------------+
Total Framing Overhead = 4 Bytes
```
section #4
Role of TURN in ICE Candidate Gathering Interactive Connectivity Establishment (ICE) uses STUN and TURN to gather transport candidates for session negotiation in WebRTC and modern SIP endpoints. Candidates fall into three categories: Host candidates (local interfaces), Server Reflexive candidates (discovered via STUN), and Relay candidates (obtained via TURN Allocations). During ICE connectivity checks, host-to-host and reflexive paths are tested first due to lower latency and absent server bandwidth costs. Relay candidates carry the highest administrative cost (lowest priority value in SDP), serving as a fallback mechanism when direct paths fail.
```
a=candidate:1 1 UDP 2130706431 192.168.1.50 5000 typ host
a=candidate:2 1 UDP 1694498815 203.0.113.5 5000 typ srflx raddr 192.168.1.50 rport 5000
a=candidate:3 1 UDP 16777215 198.51.100.10 60000 typ relay raddr 203.0.113.5 rport 5000
```

section #5

Deploying a Production Coturn Relay Server Coturn is the standard open-source implementation of TURN and STUN servers. A secure production deployment requires listening on standard UDP/TCP ports (3478) and TLS/DTLS ports (5349). Utilizing dynamic ephemeral credentials (REST API authentication secret) ensures that third parties cannot hijack the relay. Below is a foundational `turnserver.conf` configuration file optimized for secure operations and dynamic authentication.

listening-port=3478
tls-listening-port=5349
realm=turn.example.com

# Enable REST API time-limited ephemeral credentials
use-auth-secret
static-auth-secret=c7d8f9e0a1b2c3d4e5f6a7b8c9d0e1f2

# Certificate paths for TLS/DTLS support
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem

# Security and resource limits
 dynamic-quota=10
 total-quota=1000
 max-bps=300000
 cipher-list="HIGH"
 
 # Prevent loopback relay misuse
 no-loopback-peers
 no-multicast-peers
 
 syslog

section #6
Security, Ephemeral Credentials, and Dimensioning Allowing unauthenticated relay access risks severe resource exhaustion and high bandwidth bills. Modern WebRTC platforms generate dynamic credentials using HMAC-SHA1 signature tokens containing an expiration timestamp (e.g., `timestamp:username`). The TURN server validates the token against a shared static secret without needing database lookups. Dimensioning TURN capacity requires provisioning adequate network throughput: a single 100 kbps audio call consumes 200 kbps bidirectional bandwidth on the relay, while a 2 Mbps video stream requires 4 Mbps total relay throughput. Enterprise capacity planning must account for peak concurrent relayed sessions and CPU usage for TLS/DTLS packet decrypt/encrypt steps.

Deep Dive into TURN: Traversal Using Relays around NAT

Overview

Key takeaways

Prerequisites

Guide

Further reading