When does a TURN relay become unavoidable for two peers behind NATs, and what does relaying through a TURN server cost compared with a direct path?
answer
- when no direct pair passes
- per-destination ports on both sides
- every byte crosses the server twice
- allocations, permissions, channels
- ranked last on purpose
basics
~20 sA TURN relay is unavoidable when no direct candidate pair passes ICE checks, typically because both NATs allocate per-destination ports and filter by port, or UDP is blocked. It costs server bandwidth, latency, per-packet overhead and credentialed state.
solid answer
~50 sTURN (RFC 8656, which obsoletes RFC 5766) is needed when hole punching cannot work: both NATs use endpoint-dependent mapping, or one does and the other filters on the sender's address and port, or a firewall blocks the UDP the peers would use, in which case the client can reach TURN over TCP or TLS instead. The client sends an **Allocate** request, normally authenticated, and receives a **relayed transport address** on the server; it installs **permissions** for peer IP addresses and exchanges data through **Send/Data indications** or, more cheaply, a bound **channel**. The costs are real: every byte crosses the server, so the operator pays for the bandwidth; the detour adds latency; Send and Data indications add 36 bytes per packet; and allocations, permissions and channel bindings must be refreshed. That is why RFC 8656 advises using TURN only when no direct path exists, and why ICE gives relayed candidates the lowest priority.
go deeper
Remember that TURN is the relay used when the peers cannot reach each other directly, and that it is the fallback, not the first choice.
Explain the Allocate, permission and send steps, and how Send indications differ from channels in overhead.
Name the NAT pairings and network conditions that force a relay, and reason about the bandwidth, latency and refresh costs that relayed sessions add in production.
Plan relay capacity and placement from the share of sessions that cannot go direct, and decide whether a privacy-driven relay-only policy is worth its bandwidth bill.
## When a relay is the only path **TURN** (Traversal Using Relays around NAT, RFC 8656) is an extension of STUN in which a public server relays packets for a client. It is the fallback when no direct path exists. That happens when: - **Both NATs use endpoint-dependent mapping.** Each side's packets to the other leave from a new public port, so neither side's advertised address is right, and hole punching fails. - **One NAT uses endpoint-dependent mapping and the other filters on address and port.** The packets from the newly allocated port arrive from a port the filtering side never sent to. - **UDP is blocked.** A network that blocks outbound UDP stops both STUN checks and the data. TURN lets the client reach the server over TCP or TLS-over-TCP while the server still uses UDP toward the peer. - **The application chooses it.** An application can deliberately use only relayed candidates so that peers never learn each other's addresses, trading cost for privacy. That is a policy choice, not a protocol requirement. Under ICE (RFC 8445) the decision is made by testing, not prediction: relayed candidates get type preference 0, the lowest, so a relayed pair is selected only when the direct pairs fail their checks. ## How TURN relays 1. **Allocate.** The client sends an Allocate request, normally authenticated with STUN's long-term credential mechanism, which TURN clients and servers must implement. The server reserves a **relayed transport address** for that client and, in the same success response, reports the client's server-reflexive address. An allocation's default lifetime is **10 minutes**; the client keeps it with **Refresh** requests, and RFC 8656 recommends servers cap the lifetime at no more than 3600 seconds. 2. **Permit.** A **CreatePermission** request installs permissions for peer IP addresses. The server relays an inbound packet only if its source IP matches a permission; the source port is not checked. RFC 8656 says this mimics the address-dependent filtering of a NAT that complies with RFC 4787. A permission lasts **5 minutes** unless refreshed. 3. **Send.** The client either wraps each datagram in a **Send indication** carrying the peer's address, with the server returning inbound data in **Data indications**, or binds a **channel** to the peer with **ChannelBind** and then sends **ChannelData** messages. Channel numbers run from `0x4000` to `0x4FFF`, and a binding lasts **10 minutes** unless refreshed. Peers see the relayed address as the client's address. One allocation can serve several peers, each with its own permission. ## What relaying costs | Cost | Where it comes from | |---|---| | **Bandwidth** | every packet crosses the server in and out; RFC 8656 notes the server typically needs a high-bandwidth connection and calls this a high cost to the provider | | **Latency** | the path detours through the relay instead of running directly between the peers | | **Per-packet overhead** | Send and Data indications add 36 bytes per datagram; ChannelData uses a 4-byte header instead | | **State and refresh** | allocations, permissions and channel bindings all expire and must be refreshed | | **Operations and abuse** | credentials must be issued to clients, and quotas on allocations and bandwidth keep the server from becoming an open relay | The bandwidth line usually dominates. A direct session costs the operator nothing per byte; a relayed one is paid in full, twice through one server's network interface. ## Keeping relay usage low - **Always try direct first.** RFC 8656 itself advises using a TURN server only when a direct path cannot be found, and ICE's ordering does exactly that. - **Prefer channels for steady streams.** The 4-byte ChannelData header matters when each packet carries little data. - **Encrypt end to end anyway.** TURN over TLS or DTLS protects the client-to-server leg, but the relay still handles whatever the application sends. - **Place relays near users.** The latency cost depends on how far the relay sits from both peers. ## Points that are easy to get wrong - TURN does not replace STUN; it extends it, and a TURN server's Allocate success response carries an `XOR-MAPPED-ADDRESS` with the client's server-reflexive address. - A permission is keyed on the peer's IP address alone, not on its port. - Relaying is not a different traversal technique that always loses; it is the one that almost always works, which is precisely why it is kept as the last resort.
- Why does a TURN permission check only the peer's IP address and not its port?RFC 8656 designed permissions to mimic the address-dependent filtering of an RFC 4787-compliant NAT, so a TURN relay is no more permissive than such a NAT would be. A peer behind its own NAT may reach the relay from a port the client could not predict; checking the address alone lets those packets through while still refusing addresses the client never permitted.
- If a client's network blocks UDP entirely, can TURN still help?Yes. A TURN server MUST support UDP between client and server and SHOULD support TCP, TLS-over-TCP and DTLS-over-UDP. A client on a UDP-blocking network can reach the server over TCP or TLS, and the server still relays UDP to the peer from the relayed transport address. TCP between the server and peers is a separate extension.
saying these in an interview costs you the question
- TURN is only needed when the peers are on different continents.
- A TURN permission admits only the exact peer IP address and port.
- Relaying through TURN costs the operator nothing beyond running one server.
- ICE prefers relayed candidates because they are the most reliable.
- Once allocated, a TURN relay address stays reserved until the client disconnects.