Mastering NAT Traversal: How ICE, STUN, and TURN Enable WebRTC Connections

WebRTC enables peer‑to‑peer real‑time audio/video communication, but when one or both participants are behind a NAT (Network Address Translation), direct IP connectivity is blocked. ICE (Interactive Connectivity Establishment) is employed to discover a viable transport path.

1. NAT Network Address Translation

1.1 What is NAT?

NAT was introduced in RFC 1994 as a temporary solution to IPv4 address exhaustion, allowing multiple private IP addresses to share a single public IP by mapping internal addresses and ports to external ones. It has become a fundamental part of internet infrastructure, present in routers, firewalls, and proxy devices.

1.2 NAT Types

Four main NAT types exist:

Full cone

Restricted cone (IP‑restricted)

Port‑restricted cone

Symmetric

Full cone NAT allows any external host to send packets to the internal host once a mapping is created. IP‑restricted cone only permits packets from previously contacted external IPs. Port‑restricted cone further limits to the specific external port. Symmetric NAT creates a unique mapping for each destination, making traversal extremely difficult.

1.3 NAT Type Detection

Detection involves a series of STUN‑based tests (test1‑test5) to determine whether the host is behind a NAT, and if so, which type. The process checks connectivity, compares external IPs, and evaluates consistency of mappings across multiple servers.

2. STUN/TURN Protocols

When peers are behind NATs, direct UDP packets cannot reach each other. STUN (Session Traversal Utilities for NAT) helps a host discover its public IP and port, while TURN (Traversal Using Relays around NAT) provides a relay server when direct communication fails.

2.1 STUN

Defined in RFC 3489 and refined in RFC 5389, STUN allows a client to obtain its external address and test connectivity.

Obtain peer’s IP and port

Check connectivity between endpoints

Maintain NAT bindings

Typical STUN workflow:

Deploy a STUN server (e.g., CoTURN).

Client sends a binding request to the server.

Server replies with the observed IP and port.

Client extracts its public address from the response.

2.2 TURN

Specified in RFC 5766, TURN acts as a relay when direct peer‑to‑peer paths are unavailable. It allows a client to send and receive media through a middle‑box, supporting multiple peer connections.

3. ICE Connection Mechanism

3.1 Collecting ICE Candidates

Each WebRTC endpoint gathers candidates of three types:

host : local IP and port.

srflx : server‑reflexive address (public IP after NAT).

relay : TURN relay address.

Candidate description example:

<code>IP: xxx.xxx.xxx.xxx
port: number
type: host/srflx/relay
priority: number
protocol: UDP/TCP
usernameFragment: string
...</code>

3.2 ICE Connection Flow

a. Connectivity Checks

After exchanging candidates via signaling, endpoints perform connectivity checks in priority order (host → srflx → relay). STUN requests are sent; successful responses confirm a viable path.

b. Selecting the Candidate Pair

The ICE agent maintains a sorted list of candidate pairs based on calculated cost (e.g., round‑trip time). The pair with the lowest cost that passes checks is selected for media transmission.

c. Keep‑alive and ICE Restarts

To keep NAT bindings alive, ICE sends periodic checks (≈ every 15 seconds). If a change in network conditions is detected, ICE restarts, re‑collecting candidates and repeating the process.

4. Summary

WebRTC’s ICE framework, which incorporates STUN and TURN, provides a systematic way to discover and maintain the best possible transport channel across NATs. Understanding NAT traversal basics and the ICE workflow helps developers build robust real‑time communication applications.