STUN vs TURN: Direct Paths, Relays & ICE Testing | Callaba
More live video workflow notes and product updates.
STUN and TURN are not competing server choices. STUN helps a WebRTC endpoint learn an address that may be reachable through its NAT. TURN gives the endpoint a relay address and carries media when a direct candidate pair cannot work. A production design normally offers both to ICE, then verifies which path each call actually selected.
ICE chooses a path; STUN and TURN supply candidates
Start with the path Callaba actually exposes
Callaba documents browser video rooms, participant join flows, and instance-wide WebSocket and TURN connectivity settings. That is the operational boundary to start from: protect room-control credentials, configure the reachable domains, then test media from the networks your participants actually use.
The public product contract does not currently expose a per-participant ICE candidate dashboard, TURN allocation history, or relay-utilization view. Browser statistics and TURN service logs therefore remain important when a room opens but audio or video does not move.
| What you observe | What it proves | What it does not prove |
|---|---|---|
| Participant token works | The join request was authorized | ICE found a usable media route |
| WebSocket stays connected | Signaling is reachable | RTP can cross the participant network |
| Relay candidate is nominated | Media is using TURN | The relay has enough capacity for good quality |
STUN discovers an address; it does not relay the session
RFC 8489 defines STUN as a tool for other NAT-traversal protocols. A Binding request can reveal the IP address and port seen by the STUN server. ICE uses that result to form a server-reflexive candidate and test whether another endpoint can reach it.
That discovery is useful, but the RFC is explicit: STUN alone is not a complete NAT-traversal solution. A restrictive firewall, symmetric address mapping, enterprise policy, or blocked UDP path can leave every direct pair unusable. Repeating the same Binding request will not turn STUN into a relay.
TURN reserves a relay and carries traffic
RFC 8656 defines TURN. A client authenticates, creates an allocation, receives a relayed transport address, and installs permissions for peers. The server then forwards traffic between the client and the permitted peer.
Relay is the robust fallback because each participant needs to reach the TURN service rather than establish a direct media path through both NATs. The operational cost shows up immediately: packets travel through the relay, so bandwidth, regional placement, authentication, allocation lifetime and port reachability become production dependencies. Plan TURN capacity from concurrent relayed bitrate in both directions, not from room count alone.
ICE makes the final choice
RFC 8445 defines ICE candidate gathering and connectivity checks. Host candidates come from local interfaces, server-reflexive candidates commonly come from STUN, and relayed candidates come from TURN. ICE pairs local and remote candidates, checks them, and nominates a valid pair.
Do not force relay merely because it is predictable, and do not disable it merely because most office tests connect directly. Prefer the best working path under an explicit policy. Keep a relay fallback for hostile networks, then measure how often it is selected and whether that percentage changes by browser, site, ISP or release.
Choose transports for real participant networks
UDP is usually the preferred media transport because late packets can be discarded without waiting for retransmission. Some managed networks block arbitrary UDP, so a TURN deployment may also need TCP or TLS reachability on an allowed port. That fallback can improve connection success, but it cannot remove congestion or head-of-line delay.
Test from a corporate guest network, mobile carrier, home NAT, VPN, IPv6 network and any geography that matters. Record the selected local and remote candidate types, protocol, relay region, round-trip time, packet loss, jitter, bitrate and rendered frames. A green room-status badge is too coarse to explain why one site has frozen video.
Treat TURN credentials and capacity as live infrastructure
Use short-lived credentials issued by a trusted backend. Keep the shared secret out of browser bundles and logs. Synchronize clocks, rotate secrets deliberately, and alert separately on authentication failures, allocation failures and exhausted relay ports.
Capacity planning needs a failure assumption. If a network-policy change moves many calls from direct paths to relay at once, the normal relay percentage is no longer a safe baseline. Load-test allocations and sustained bidirectional media, watch egress and per-region saturation, and retain enough headroom for a sudden fallback event.
Everyone joins, but one office receives no media
Remote staff join the same room successfully from home, while participants behind one corporate firewall see names but no video. The team first blames camera permissions. Compare browser permission results, ICE candidate-pair changes, connectivity-check errors and TURN authentication logs. The affected office gathers candidates but cannot complete a direct UDP pair, and its firewall also blocks the configured relay transport. Make the approved TURN endpoint reachable through the agreed firewall path, reconnect with fresh credentials, and verify that a relayed pair is nominated, inbound frames increase and audio remains continuous. The fix is proven by media counters, not by the participant list.
Prove both the direct path and the fallback
- Separate signaling from media. Log room authorization, WebSocket state and ICE state independently.
- Collect every candidate type. Confirm host, server-reflexive and relay gathering where expected.
- Exercise direct and relay paths. Test normal policy, a blocked direct path and an explicitly relayed session.
- Inspect the nominated pair. Record candidate types, protocol and relay region without storing sensitive addresses longer than necessary.
- Measure media. Verify packets, frames, loss, jitter, round-trip time and recovery after a network change.
- Test failure capacity. Model a sharp increase in relay use, not only the usual average.
STUN vs TURN FAQ
Do I need both STUN and TURN?
For broad WebRTC reachability, usually yes. STUN supports direct-path discovery; TURN supplies the relay candidate used when direct candidate pairs fail.
Does TURN replace ICE?
No. TURN provides relayed candidates. ICE gathers candidates, runs checks and selects the working candidate pair.
Why does a room connect without video?
Authorization and signaling can succeed while every media candidate pair fails. Inspect ICE state, the nominated pair, TURN logs and actual media counters.
Does Callaba expose TURN settings?
Callaba documents instance-wide TURN and WebSocket connectivity configuration for video calls. Test that configuration from representative participant networks and verify the selected media path in browser and relay evidence.