Fundamentals
STUN, TURN and ICE: How Media Finds a Path
Two endpoints behind two different NATs want to exchange voice directly. Neither knows an address at which the other can actually be reached — their private addresses are meaningless abroad, and their public mappings depend on the NAT's mood. STUN, TURN and ICE are the standardized toolkit for solving exactly this: discover candidate addresses, test which pairs actually pass traffic, and relay through a server when no direct path exists. Born in the WebRTC world, these mechanisms increasingly appear in mainstream VoIP endpoints.
This guide explains each protocol's role, the candidate-gathering ritual, and where the toolkit succeeds and fails compared with SBC-anchored designs.
The three roles
| Protocol | Role | Key fact |
|---|---|---|
| STUN (RFC 8489) | Discovery: a server reflects your public IP/port mapping back to you ('server-reflexive address') | Cheap and stateless; the discovered mapping may not hold for other destinations behind symmetric NAT |
| TURN (RFC 8656) | Relay: a server allocates a public relay address and forwards media when no direct path works | Always works (it's just a relay), costs bandwidth and a few ms; the fallback that guarantees connectivity |
| ICE (RFC 8445) | Orchestration: gathers all candidates (host, server-reflexive, relay), tests pairs with STUN checks, nominates the best working pair | Prefers direct paths, falls back to relay; the negotiation you see as extra SDP candidates and connectivity checks |
ICE in motion (and its failure shapes)
An ICE endpoint advertises a bundle of candidate addresses in its SDP — its LAN address, its STUN-discovered public mapping, a TURN relay address — each with a priority. Both ends then run connectivity checks: STUN requests between every candidate pair, effectively asking 'can you hear me on this path?' The highest-priority pair that answers both ways gets nominated, and media flows there. The failure shapes are instructive: all direct checks fail, relay works (symmetric NAT or restrictive firewall — calls work, with relay latency), checks succeed one way only (stateful filtering asymmetries), and ICE completes but media dies later (mapping expiry without keepalives, or a mid-call network change — Wi-Fi to Ethernet — that ICE's consent freshness should catch and re-route). When troubleshooting ICE-based endpoints, the capture shows the checks themselves: pairs that never answer are the diagnosis.
Reason about a traversal problem
- Identify the design first: is this endpoint ICE/STUN-based, or SBC-anchored? The fixes live in different houses; most hosted desk-phone fleets are anchored and never run ICE.
- In the capture, read the SDP candidates: what addresses did each side advertise? A missing server-reflexive candidate means STUN never answered (blocked 3478, dead server).
- Follow the connectivity checks: which pairs were tried, which answered? One-way answers point to firewall state rules on the silent side.
- If calls land on the TURN relay permanently, ask why direct paths lose — relay is a valid design, but an accidental all-relay design adds cost and delay worth understanding.
- For media that starts then dies: check consent/keepalive behavior and whether a network change (new IP, NAT reboot) invalidated the nominated pair mid-call.
Frequently asked questions
- Does classic SIP desk-phone VoIP use ICE?
- Mostly not end-to-end: desk phones typically register to a platform whose SBC anchors media — a different traversal philosophy (always relay at a known point). ICE dominates in WebRTC, mobile apps and newer UC clients, and is spreading as those clients join business phone systems.
- STUN vs TURN in one sentence each?
- STUN tells you what you look like from the internet (so peers can try reaching you directly); TURN lends you its own address when they can't. ICE runs the contest between all the options.
- Why prefer SBC anchoring if ICE exists?
- Predictability and services: anchoring gives the provider a fixed point for recording, emergency calls, QoS and lawful duties, at the cost of media hairpinning. ICE gives optimal direct paths when it can, at the cost of complexity. Enterprise designs often blend them (ICE to the SBC).