Mastering WebRTC: NAT Traversal, ICE, STUN, TURN & RTP Explained

P2P

RTC (Real‑Time Communication) is a peer‑to‑peer (P2P) protocol that enables direct audio‑video transmission between users without routing through a server, reducing server load and latency.

NAT "Wall"

Because most devices sit behind NAT routers, they do not have public IPv4 addresses. NAT translates private addresses to a shared public address, maintaining a mapping table and applying two security policies: timeout of mappings and a firewall‑like "NAT wall" that can drop inbound packets.

Common NAT types are:

Full Cone NAT – any external address can reach the internal host.

Restricted Cone NAT – only previously contacted external IPs can reach the host.

Port‑Restricted Cone NAT – both IP and port must have been contacted.

Symmetric NAT – mapping depends on the destination, making inbound connections difficult.

ICE – NAT "Hole Punching"

ICE (Interactive Connectivity Establishment) coordinates the two peers to traverse NAT and establish a direct connection. It relies on two helper protocols:

STUN

TURN

STUN

STUN (Session Traversal Utilities for NAT) helps a client discover its public address and NAT type, and can assist in NAT hole‑punching.

Typical STUN detection steps:

Check if a NAT exists by comparing the address returned by a STUN server with the client’s local address.

Test for Full Cone NAT by seeing if the client receives a packet from a second STUN server IP.

Test for Symmetric NAT by comparing ports from two different STUN requests.

Test for port restrictions by sending a request to a third port and observing if the client receives it.

NAT "Hole Punching" Scenarios

When only one side is behind NAT, the NAT can be opened by the client behind NAT sending a packet first. When both sides are behind non‑symmetric NATs, both clients send packets to create holes. When both are behind symmetric NATs, direct hole punching fails and TURN is required.

TURN

TURN (Traversal Using Relays around NAT) acts as a relay server when STUN cannot establish a direct P2P path, forwarding media between the two clients.

Quick NAT Compatibility Check

Assign each NAT type a rank (Full Cone = 1, Restricted Cone = 2, Port‑Restricted Cone = 3, Symmetric = 4). If the sum of the two peers’ ranks is ≥ 7, direct hole punching is unlikely and TURN must be used.

SDP

SDP (Session Description Protocol) is a text format used by RTC peers to exchange session information. Example format:

Session description (session‑level)
  v= (protocol version)
  o= (originator and session identifier)
  s= (session name)
  c=* (connection information – optional)
  t= (time the session is active)
  a=* (zero or more session attribute lines)
  ...
Media description (if present)
  m= (media name and transport address)
  c=* (optional connection information)
  a=* (zero or more media attribute lines)

Typical SDP from a real session includes version, origin, session name, timing, ICE credentials, media lines for audio and video, codec information, and fingerprint for security.

Transport Layer Choice: UDP vs TCP

UDP is connectionless, low‑latency, and suitable for real‑time audio‑video where occasional packet loss is acceptable.

TCP provides reliable, ordered delivery but incurs higher latency due to connection setup and retransmissions.

Because real‑time media tolerates some loss but not high latency, UDP is the preferred transport for RTC.

RTP

RTP (Real‑time Transport Protocol) runs over UDP and handles packetization and reassembly of media frames. It works together with RTCP, which provides QoS feedback and congestion control.

Summary

RTC is a P2P protocol, but NAT prevents direct communication; ICE (using STUN and TURN) enables NAT traversal, after which UDP carries media via RTP/RTCP to achieve low‑latency audio‑video transmission.