WebRTC: signaling, ICE, relays and media servers

WebRTC is a suite of APIs and protocols for real-time media and data. It does not define your room, identity, authorization or signaling transport. A production call therefore has an application control plane, an ICE path-selection process, required transport security, and optionally TURN relays or media servers.

Signaling is application-owned

JSEP defines how RTCPeerConnection controls offer/answer and signaling state. The application decides how session descriptions, candidates and policy messages move between peers. WebSocket is common, but not required by WebRTC.

The signaling service does not inherently “switch off after the handshake”. Applications may need it for trickled candidates, glare handling, adding/removing tracks, ICE restart after network change, authorization updates, moderation, hangup and reconnect. Keeping signaling available does not mean media must traverse it.

SDP/JSEP processing has no universal 100 ms guarantee. Measure signaling queueing, client state transitions, candidate gathering, checks, DTLS and first decoded media separately.

ICE selects a candidate pair

An agent gathers host candidates plus server-reflexive candidates through STUN and relayed candidates through TURN as configured. It exchanges candidates over the application signaling channel. ICE forms ordered local/remote candidate pairs and runs STUN connectivity checks.

A successful check creates a valid pair. The controlling agent nominates a pair according to the ICE procedure; “the first packet that answers always wins” is not an accurate rule. Trickle ICE allows gathering and checking to overlap, but it adds state that signaling and clients must order, authenticate and deduplicate.

After ICE selects a path, DTLS establishes keying on that path and WebRTC media uses SRTP. ICE consent and liveness still matter after setup. Network changes can require an ICE restart with new credentials and another signaling exchange.

TURN is stateful and authenticated

A TURN client creates an authenticated allocation. The allocation is associated with a client/server 5-tuple, relayed address, lifetime, permissions and optional channel bindings. It must be refreshed; merely sending arbitrary peer traffic does not replace the refresh contract.

A selected ICE pair can contain one relayed candidate, so one endpoint’s TURN allocation may be sufficient for that path. Both endpoints may gather relay candidates for policy and reachability, but “both always allocate and send through TURN” is not a protocol invariant. Client-to-TURN can use transports allowed by TURN, including TCP/TLS when UDP is blocked; the relay still has exact transport rules defined by the specification.

TURN placement and capacity affect latency and cost. Measure relay share by network/region, allocation failures, permission failures, egress, port capacity and tails. Do not ship a guessed “15–20% relay” or cost figure as a universal law.

SFU behavior

For a conference, each participant usually establishes a separate WebRTC transport to an SFU. The SFU selects and forwards RTP streams or negotiated simulcast/SVC layers. It is not a magic loss repair engine. Retransmission requires that the requested packet still be cached, and FEC can recover only loss covered by the negotiated code/redundancy.

An SFU commonly terminates each DTLS-SRTP transport. That is encrypted in transit but does not by itself hide media payload from the SFU. If the product requires payload end-to-end encryption across an untrusted SFU, add an application media transform/key-management design and document which metadata remains visible.

Mesh, SFU, MCU and broadcast/CDN choices depend on participant count, uplink, device decode budget, latency, recording/compositing and trust. No fixed participant cutoff applies to every codec, device and network.

Scenarios

Application-defined signaling transports JSEP offer/answer under explicit identity and state policy.

Candidate gathering, checks, valid pairs, nomination and DTLS are shown in protocol order.

An authenticated lifetime-bound TURN allocation contributes a relayed candidate without requiring a fictitious allocation invariant on both peers.

Separate SFU transports, layer selection, bounded retransmission and the E2EE boundary are explicit.

Signaling remains available to exchange new ICE credentials/candidates after a path failure.

Operational checklist

• Authenticate signaling messages and bind them to room membership, peer identity and authorization state.
• Configure TURN credentials with bounded lifetime; monitor allocation, permission and capacity failures.
• Collect standards-based stats for candidate type, selected pair, RTT, jitter, loss, frames and bitrate.
• Put deadlines on setup and restart; make teardown idempotent and clean up TURN/SFU state.
• Test NAT/firewall matrices, network handoff, packet loss, reordering, bandwidth collapse and regional failure.
• State whether “encrypted” means transport encryption to an SFU or application E2EE across it.

Primary sources

• RFC 9429, JSEP: https://www.rfc-editor.org/rfc/rfc9429.html
• RFC 8445, ICE: https://www.rfc-editor.org/rfc/rfc8445.html
• RFC 8838, Trickle ICE: https://www.rfc-editor.org/rfc/rfc8838.html
• RFC 8656, TURN: https://www.rfc-editor.org/rfc/rfc8656.html
• RFC 8825, WebRTC overview: https://www.rfc-editor.org/rfc/rfc8825.html
• W3C WebRTC API: https://www.w3.org/TR/webrtc/