Concepts: STUN vs TURN

A relay is a fallback, not the default path. Understanding when WebRTC actually uses one — and why Baton returns several transport URLs at once — explains everything else in these docs.

STUN — find your public address

STUN lets a client discover its own public IP and port as seen from the internet (a server-reflexive, or srflx, candidate). When both peers can reach each other directly, that's the whole job: media flows peer-to-peer and no relay is involved. STUN is cheap and stateless.

TURN — relay when direct fails

When a symmetric NAT, a deny-all firewall, or a corporate proxy blocks a direct path, the peers can't connect on their own. TURN provides a relay: both peers send media to the relay, and it forwards packets between them. That produces a relay candidate. Relaying costs bandwidth, so it's only used when it has to be.

When is a relay actually used?

For most consumer networks, direct or STUN-assisted connections succeed and no relay is needed. A relay typically carries roughly 10–25% of connections — the ones behind hard NATs, mobile carrier-grade NAT, or restrictive enterprise and hospital firewalls. Those are exactly the connections that fail silently without a working TURN server, which is why the relay has to be dependable even though it's the minority path.

The relay is the minority path — but it's the one that fails silently without a dependable TURN server.

Why several transport URLs come back

A single credential request returns multiple URLs so the browser's ICE agent can try them in parallel and keep whichever connects first:

You don't choose between these — you hand the whole array to the client and let ICE negotiate. See the API reference for the exact response.