skip to content

In WebRTC, what does setting iceTransportPolicy to "relay" change about ICE candidates, and when is forcing every call through TURN worth its cost?

level: seniorimportance: nice to knowfreq 7%

answer

  1. only relayed candidates surface
  2. raddr and rport hidden too
  3. the far side keeps its own
  4. a callee before answering
  5. read at each gathering phase

basics

~20 s

With iceTransportPolicy relay, the ICE agent surfaces and checks only relay candidates, so the far peer never learns this endpoint's own addresses. It costs relay bandwidth and a detour on every call, and the call fails outright if no TURN server answers.

solid answer

~50 s

`RTCIceTransportPolicy` has two values: `all` (the default) and `relay`. Under `relay`, JSEP (RFC 9429) says the implementation **MUST NOT** expose disallowed candidates, use them as the source of checks, or leak them through the `raddr`/`rport` of a relay candidate; the W3C API also refuses remote mDNS and DNS candidates. It restricts this endpoint only: the far peer's candidates may still be host or server-reflexive, so you still see its addresses. Worth it when address privacy matters more than quality — a callee hiding its location from an unknown caller until it answers, as JSEP's own example puts it, or a policy that all media crosses an audited relay. As a default it adds latency, relay cost and a hard dependency on TURN. It is not an encryption setting: media is already DTLS-SRTP end to end. A changed policy applies from the next gathering phase, so switching mid-call needs an ICE restart.

go deeper

for a junior

Recall the two values, all and relay, and that all is the default.

for a middle

Explain what relay filters, including the related-address rule, and why it limits only this endpoint's candidates.

for a senior

Show the mid-call switch from relay to all with an ICE restart, and the availability risk relay-only adds when TURN fails.

for a principal

Decide where relay-only is a product requirement and where it is cost without benefit, and who must then be trusted with addresses.

## The two values `iceTransportPolicy` is a member of WebRTC's `RTCConfiguration`. It decides which of this endpoint's **candidates** (addresses at which it can receive packets) the ICE agent may surface to the application and use for connectivity checks. | Value | Candidates allowed | Typical use | |---|---|---| | `all` (default) | host, server-reflexive, peer-reflexive and relay | normal calls; direct paths win when they work | | `relay` | relay candidates only, obtained from TURN servers | address privacy, mandated relaying | Under `all`, RFC 8445's recommended type preference of 0 for relayed candidates keeps relay pairs at the bottom of the check list, so TURN carries the call only when nothing direct works. Under `relay`, nothing else exists to try. ## What `relay` hides, and what it does not JSEP (RFC 9429) is strict about the local side. During a gathering phase the implementation **MUST NOT**: - expose a disallowed candidate to the application; - use one as the source of connectivity checks; - leak one indirectly, for example in the `raddr`/`rport` (related address) fields of a relay candidate. The W3C API also refuses, under `relay`, remote candidates that need external resolution, such as mDNS and DNS candidates. What it does **not** do: - **Hide the far peer's addresses.** The policy filters this endpoint's candidates. If only the callee uses `relay`, the caller still sends host and reflexive candidates, and the callee sees them. - **Hide this endpoint from the relay operator.** The TURN server sees the client's public address, timing and volume, though not the media. - **Encrypt anything.** WebRTC media is always protected end to end by DTLS-SRTP; relaying adds no protection and removes none. ## What it costs - **Bandwidth:** every call crosses a relay, in both directions, on the provider's bill. - **Latency:** media detours through the relay even between two machines on the same network. - **Availability:** if every TURN server fails or rejects the credential, gathering ends with no candidates and the call fails; nothing can fall back. - **Capacity planning:** relay capacity has to cover all calls, not the minority that cannot connect directly. - **Diagnosis:** with no direct fallback, a TURN outage or a rejected credential looks to users like a total outage, so the `icecandidateerror` events and relay health need alerting of their own. - **Geography:** two users in one city served by a relay on another continent pay that round trip on every packet, so relay-only usually implies relays near every user population. ## Changing the policy mid-call JSEP says the policy is read at the start of each gathering phase and the implementation **MUST** allow it to change mid-session. Applying a change takes: 1. `setConfiguration()` with the new `iceTransportPolicy`. 2. `restartIce()`, so the next offer carries new ICE credentials. 3. An offer/answer exchange through the signalling channel, which starts a new gathering phase under the new policy. 4. New checks; media keeps flowing on the old pair until a new one is selected. ## When it is worth it | Situation | Verdict | |---|---| | A callee who should not reveal location to an unknown caller | worth it until the call is accepted, then switch to `all` | | An organisation requiring all media to cross a relay it audits | worth it; the cost is the policy's price | | Testing that TURN works at all | worth it in a test build, never as the default | | A general wish for privacy or security with no threat named | usually not; it buys a detour, not encryption | JSEP describes the first case directly: start relay-only, then change to all candidates "for lower operational cost" once the user takes the call. Browsers may also limit address exposure on their own (the IP-handling modes of RFC 8828); `relay` is the application's stronger, explicit version.

  • A callee wants privacy until answering but a direct path afterwards; how do you switch?
    Create the connection with `iceTransportPolicy` `relay`. When the user accepts, call `setConfiguration()` with `all`, then `restartIce()`; the next offer carries new ICE credentials, and the gathering phase it starts collects host and server-reflexive candidates too. ICE can then select a direct pair, while media keeps flowing over the relay until it does. JSEP describes this case as its own example.
  • Does relay-only hide the user's address from the TURN operator?
    No. The relay sees the client's public address on its own leg, plus timing and volume. It cannot read the media, which is DTLS-SRTP encrypted between the peers. Relay-only moves address exposure from the far peer to the relay operator, so it is worth having only when you trust that operator more than the peer.

A relay-only policy is like having all your post sent to a forwarding address: a stranger who writes to you learns only the forwarding box, never your home, but every letter takes the detour and the box costs rent. You still see the stranger's return address unless they rent a box too.

saying these in an interview costs you the question

  • Setting relay is what makes WebRTC media encrypted.
  • If one side uses relay, neither peer learns any address of the other.
  • iceTransportPolicy defaults to relay, so direct paths must be opted into.
  • A new policy set with setConfiguration applies at once to the live pair.
  • A relay candidate still exposes the host address in its related address.