STUN, TURN, ICE — explained without the mystery, with the security trade-offs spelled out
A practical walkthrough of how WebRTC and SIP-over-WebSocket calls reach their destination across home routers, mobile networks, hotel Wi-Fi and corporate firewalls. Three protocols do the work: STUN, ICE and TURN. Each one carries a security and sovereignty decision — this page makes those decisions visible.
The problem: most of the internet hides behind NAT
A residential router, a mobile carrier, a corporate firewall — almost every internet endpoint sits behind a Network Address Translator. Your laptop thinks it has the address 192.168.1.42; the wider internet sees you as a port behind your ISP's public IP. SIP and WebRTC media (RTP) want to flow directly between two endpoints, but neither endpoint can reach the other's private address. STUN, ICE and TURN are the three protocols that solve this in a standards-defined way.
STUN: discovering your public address (RFC 8489)
STUN — Session Traversal Utilities for NAT — is the simplest piece. A client opens a UDP socket, sends a single binding request to a STUN server on the public internet, and the server replies with the source IP and port it saw. That pair is the client's NAT-translated public endpoint. The client now knows what address remote peers should send media to.
What you learn
Your server-reflexive (srflx) candidate — the IP and port any host on the public internet can send packets to so they reach you. ICE uses this address as one option to offer the remote peer.
What STUN does NOT do
It does not authenticate, encrypt media, traverse symmetric NATs by itself, or hold any session state. Each binding is a one-shot question and answer.
stun.google.com or any other third-party STUN, that telemetry leaves your boundary. CodeB ships its own STUN responder inside the tenant SBC so the discovery stays in your stack.ICE: pairing and picking the winning path (RFC 8445)
Interactive Connectivity Establishment is the framework that decides which of many possible network paths the call actually uses. Each peer gathers candidates — host (local interface), srflx (learned via STUN), and relay (allocated on a TURN server) — and shares them via the signalling channel. ICE then forms candidate pairs and runs STUN connectivity checks across each pair. The pair that works at highest priority wins, and that pair carries the media.
Priority order
Host (direct LAN) beats srflx (NAT-reflexive) beats relay (TURN). ICE picks the highest-priority pair where both checks pass. A relayed pair only wins if every direct option failed.
Trickle ICE
Candidates are sent incrementally as soon as gathered, so media can start on a working pair while slower paths are still being explored. Cuts perceived call-setup latency from seconds to sub-second.
ICE restart
If the selected pair fails mid-call (NAT mapping rotated, link switched), ICE restart re-runs the whole exercise without tearing down the SIP or WebRTC session. The call recovers transparently.
TURN: relay-of-last-resort (RFC 8656)
Some networks block UDP, some NATs assign a new port for each destination (symmetric NAT), some firewalls only allow outbound TCP on 443. When STUN-discovered direct paths fail, TURN — Traversal Using Relays around NAT — takes over. The client authenticates against a TURN server, requests a relay allocation, and gets back a public IP and port. The remote peer sends to that relay, the TURN server forwards to the client; the client sends back through the same relay.
TURN over UDP
Default and fastest, port 3478. The bridge spends a single hop on packet rewriting; latency overhead is typically under 5 ms.
TURN over TCP
Survives firewalls that block UDP entirely. Port 3478. Slightly higher latency, head-of-line blocking risk on lossy links.
TURN over TLS (TURNS)
Works when only port 443 outbound is permitted — hotel Wi-Fi, locked-down enterprise. Same TLS port as HTTPS; indistinguishable from web traffic on the wire.
What CodeB does differently
Most cloud meeting and SBC vendors ship a NAT-traversal stack that quietly relies on third-party STUN and TURN infrastructure. CodeB's Sovereign SBC bundles STUN, ICE-Lite and TURN inside the same Windows process, on the same tenant, behind the same firewall as the rest of your stack — with safety rails for the failure modes that cause most one-way-audio incidents.
Built-in TURN with auto-generated keys
The TURN long-term credential and REST shared secret are generated on first boot, written to per-tenant storage, and propagated to the WebRTC signalling layer — no manual keygen, no copy-paste, no shared cloud key.
Relay IP refuse-on-private
If the configured relay IP is private or loopback, the allocate handler refuses the request with 437 and logs an error — never hands out an unreachable relay. The TURN startup also re-resolves Turn:ExternalIp from configuration on hot-reload.
ICE-Lite for legacy phones
Older SIP hardphones and SBCs that don't speak ICE still get NAT-resilient audio. The bridge injects ICE-Lite attributes into its SDP and responds to STUN binding requests on the negotiated RTP port.
Symmetric RTP fallback
For endpoints behind aggressive NATs that ICE cannot fully solve, the bridge learns the remote's actual source address from the first received RTP packet and rewrites the outbound destination — one-way audio fixed without operator intervention.
Force-relay knob
Operators can pin a session, a user, or an entire tenant to TURN-only ICE pairing — useful when policy requires every call to traverse the auditable relay path, or for diagnostics on otherwise-broken networks.
ICE-restart on link change
The browser-side conference client detects ICE state failures and runs ICE restart automatically, including a rollback path for restarts that fire while a previous offer is still in flight — transparent recovery during mobile-network handovers and Wi-Fi flips.
How it stacks up: third-party cloud vs sovereign SBC
Typical cloud meeting / cloud SBC
- STUN endpoints hosted by the vendor or by Google/Cloudflare; metadata leaves your boundary.
- TURN relay sits in the vendor's cloud; the vendor sees source IPs, destination IPs and call durations.
- TURN credentials are managed centrally by the vendor — you trust their key rotation.
- Force-relay or relay-IP allow-listing is rarely exposed; the operator cannot pin traffic to a specific egress.
- Compliance posture is "the vendor says so" — useful for marketing, harder for a CISO to defend at audit.
CodeB Sovereign SBC
- STUN responder lives in the same process as the SBC; nothing leaves the tenant.
- TURN relay is hosted on your own infrastructure; you are the only party that sees packet metadata.
- TURN credentials are auto-generated and stored under
App_Data/<tenant>; you can rotate at any time. - Force-relay per-tenant or per-session; pin entire user populations to the auditable path.
- Compliance posture is "look at the wire" — the relay is in your DC, you decide what gets logged.
Standards referenced on this page
Every protocol behaviour described above is grounded in a published Internet standard. The intent of this page is that you can verify each claim against the wire format and reference implementation — not just our marketing copy.
- RFC 8489 — Session Traversal Utilities for NAT (STUN) — datatracker.ietf.org/doc/html/rfc8489
- RFC 8656 — Traversal Using Relays around NAT (TURN) — datatracker.ietf.org/doc/html/rfc8656
- RFC 8445 — Interactive Connectivity Establishment (ICE) — datatracker.ietf.org/doc/html/rfc8445
- RFC 8829 — JSEP / DTLS-SRTP key exchange — datatracker.ietf.org/doc/html/rfc8829
- RFC 5763 + RFC 5764 — DTLS-SRTP framework — rfc5763 · rfc5764
- RFC 3711 — Secure Real-time Transport Protocol (SRTP) — rfc3711
- RFC 7118 — The WebSocket Protocol as a Transport for SIP — rfc7118
Operator questions, answered
Why does my browser see 10.0.0.4 as the remote candidate?
If the remote peer is an SBC running on a cloud VM with a NAT'd public IP, its locally-bound interface is private (e.g. an Azure VNet on 10.0.0.0/8). The SBC must explicitly advertise its public IP in SDP and STUN responses; if it leaks the private bind address, the browser cannot send return media. The CodeB SBC bundles Bridge.PublicIp rewrite and refuses TURN allocations that would advertise a private relay address.
Why does my call work with TURN over TCP/443 but not UDP?
Many corporate firewalls and hotel Wi-Fi setups block outbound UDP entirely. ICE will exhaust UDP pairs and only the TCP/443 (TURNS) candidate succeeds. Pinning the session to TURNS via the force-relay knob removes the negotiation latency on networks where you already know UDP will fail.
Can I run the SBC with only ICE-Lite and no TURN?
Yes — if every endpoint you care about can reach your SBC's public IP directly and you accept that ICE-Lite cannot help an endpoint behind a symmetric NAT reach another endpoint behind a symmetric NAT. For a typical browser-to-hardphone deployment ICE-Lite alone is usually sufficient. TURN is required when both endpoints are NAT'd and one of them is a browser on a hostile network.
What does NIS2 want me to say about NAT traversal?
NIS2 (Directive (EU) 2022/2555) Article 21 mandates risk-management measures including supply-chain security and incident handling. A NAT-traversal stack that uses third-party STUN and TURN servers is a supply-chain dependency: their outages become yours, their telemetry includes your traffic. Documenting that you self-host STUN and TURN inside the tenant boundary makes both audit and incident response simpler.
Does TURN add CO2?
A relayed call sends the same byte count over the same paths it would have anyway plus one extra hop through the relay. The relay hop is a small percentage of the overall transit cost when the relay is geographically close to one of the peers. For sovereign deployments the relay should live in the same region as the SBC; that minimises both latency and unnecessary cross-region traffic.
How do I see whether my call went peer-to-peer or via TURN?
The browser's RTCPeerConnection.getStats() reports the selected candidate pair under candidate-pair@selected; each end has a type of host, srflx, prflx or relay. The CodeB conference client surfaces this in the diagnostic log line pair@connected alongside packet counters.
NAT traversal that stays inside your tenant
CodeB's Sovereign SBC ships STUN, ICE-Lite and TURN built-in — auto-generated credentials, per-tenant storage, hot-reloadable relay IP, refuse-on-private safety. No third-party metadata leakage, no shared cloud keys, no "the vendor says so".
Get your own tenant → Sovereign SBCFrequently asked questions
What is the difference between STUN, ICE and TURN?
STUN (RFC 8489) is a protocol a client uses to discover its own public IP and port as seen from a server on the public internet. ICE (RFC 8445) is the framework that uses STUN to gather candidate addresses and then pair-tests them between two peers to pick the best one. TURN (RFC 8656) is a relay-of-last-resort that forwards media when no direct pair works, for example when both peers are behind symmetric NATs. In a real WebRTC call all three usually run together and ICE picks the winning path.
Why do most cloud meeting vendors send our media through third-party servers?
Default-hosted STUN and TURN endpoints reduce engineering cost: the vendor outsources NAT-traversal infrastructure. The trade-off is that a third party sees the media path, learns who is talking to whom, and often holds the keys to relay sessions. For NIS2, DORA, CRA and GDPR-sensitive deployments, that third-party hop is a problem. CodeB's SBC ships TURN and STUN built in, so the relay path stays inside your tenant boundary.
What does ICE-Lite mean and when is it used?
ICE-Lite (RFC 8445 section 2.7) is a reduced ICE role for endpoints that already have a stable public address, typically servers and SBCs. The ICE-Lite endpoint does not gather candidates of its own; it simply responds to STUN binding requests sent by the full-ICE peer. This is the right mode for an SBC that bridges hardphones, browsers and trunks because the SBC is reachable and never needs to traverse a NAT itself.
Can TURN traffic be inspected by a man-in-the-middle?
TURN itself is a relay protocol and does not encrypt media. WebRTC media is encrypted end to end with DTLS-SRTP (RFC 8829 section 4.1.4) regardless of which path it takes. A TURN operator can see the IP addresses and packet sizes but not the audio or video content. To prevent even the TURN operator from observing call metadata, the TURN server should be inside your own administrative boundary, as it is with CodeB's built-in TURN.
Why does my call sometimes have one-way audio when going via TURN?
The most common cause is a mis-advertised relay address. If the TURN server is bound to an internal interface like 10.0.0.4 and erroneously echoes that internal IP in its allocate response, the remote peer learns an unroutable address and cannot send media back. The fix is to ensure the TURN server explicitly advertises the public IP that NAT translates to and to refuse allocations if the configured IP is in a private range. CodeB's TURN server enforces this at the allocate handler.
What is a srflx candidate and where does it come from?
A srflx (server-reflexive) candidate is an IP/port pair learned by sending a STUN binding request to a server. The server replies with the source address it saw, which is the NAT-translated public address of the client. The browser then offers that srflx candidate to the remote peer as a possible media destination. Most home and mobile NATs cooperate enough that the srflx pair works directly without needing TURN relay.