A one-to-one WebRTC video call is pitched as 'serverless'; which server roles does it still need, and why does each one exist?
answer
- only the media path is direct
- who carries the offer and answer
- learning your outside address
- relay when no pair connects
- groups, recording and telephony bridges
basics
~20 sWebRTC still needs a signalling service to carry offers, answers and candidates, which the standards leave to the application; STUN to learn public addresses; TURN to relay when no direct path works; and media servers only for groups, recording or gateways.
solid answer
~50 sOnly the **media path** is peer-to-peer. Before it exists, the two browsers must exchange session descriptions and ICE candidates, and neither JSEP (RFC 9429) nor the W3C API says how: the application runs a **signalling** service, usually over HTTPS or WebSocket. A **STUN** server lets each peer learn the public address its NAT gives it, so it can advertise a candidate the far side can reach. A **TURN** server relays the still-encrypted packets when no direct pair succeeds; RFC 8835 makes TURN support mandatory, including TURN over TCP and over TLS for networks that block UDP. **Media servers** are optional for one-to-one: they appear for group calls, server-side recording or bridging to telephony, and each one joins the call as a WebRTC endpoint. The honest pitch is 'peer-to-peer media, server-assisted setup, relay as a fallback'.
go deeper
Name the four roles and one job for each: signalling exchanges offers and candidates, STUN reveals your public address, TURN relays, media servers handle groups or recording.
Explain that the standards leave signalling to the application, that STUN carries no media, and that a TURN relay forwards encrypted packets it cannot read.
Show which servers sit on the critical path of every call, where the bandwidth cost lives, and why adding recording or group calls turns a media server into a party to the call.
Frame the build-versus-operate choice: a self-run signalling and TURN estate against managed relays, and how relay share, regions and recording needs drive cost and privacy commitments.
## What "peer-to-peer" actually covers WebRTC is often described as browser-to-browser, and for the **media path** that is true: once a call is up, audio, video and data can flow directly between the two endpoints. RFC 8825, the WebRTC overview, draws this as a **trapezoid**: the media path ("low path") runs between the browsers, while the **signalling path** ("high path") runs through web servers that the application operates. So a "serverless" pitch is right about where the media usually goes and wrong about everything that has to happen before and around it. Four server roles exist, and each answers a different question: - **Signalling** answers "how do the two peers find each other and agree on a session?" - **STUN** answers "what address does the outside world see for me?" - **TURN** answers "how do we talk when no direct path works?" - **Media servers** answer "what if the call is more than two people talking?" ## Signalling: the role the standards leave to you Two browsers cannot open a connection to each other out of nowhere: neither knows the other's address, codecs, ICE credentials or DTLS certificate fingerprint. They must exchange **session descriptions** (an offer and an answer) and **ICE candidates** first. JSEP (RFC 9429) is explicit that it "does not specify a particular signaling model": it creates and applies descriptions, and how they travel — addressing, retransmission, forking, glare handling — is left to the application. The W3C WebRTC specification likewise says the signalling channel is "provided by unspecified means", typically a script talking to a server over WebSocket or HTTP. In practice the signalling service also carries everything around the call: who is online, who may call whom, ringing, and a hang-up message. It is always needed, even when both peers sit on the same desk. ## STUN and TURN: getting the packets through Most devices sit behind NATs and firewalls, so their own interface addresses are not reachable from outside. WebRTC uses ICE to gather candidate addresses and test pairs of them; two kinds of server feed it: 1. A **STUN** server answers a binding request with the address and port the request arrived from, so a peer learns its **server-reflexive** address and can offer it as a candidate. STUN carries no media. 2. A **TURN** server allocates a **relayed** address and forwards packets between the peers when no direct pair succeeds. RFC 8835 makes TURN support mandatory for WebRTC endpoints, and requires the TCP and TLS-over-TCP modes so a call can survive a network that blocks UDP. A relay costs bandwidth and adds latency, but it does not weaken encryption: the DTLS handshake runs between the two peers through it, so the relay forwards packets whose keys it never holds. RFC 8825 describes such relays as entities that "handle the data but do not modify it". ## Media servers: when the call stops being one-to-one A plain one-to-one call needs no media server. One appears when the product needs something two endpoints cannot do alone: - **group calls**, where forwarding or mixing streams centrally beats every participant uploading to every other; - **server-side recording** or transcription; - **gateways** to the telephone network, or to SIP equipment that lacks WebRTC's ICE and security mechanisms; - **broadcast** to large audiences. RFC 8825 notes that nothing restricts the protocols to browser-to-browser use: any endpoint that implements them faithfully interoperates. A media server is exactly that — it terminates each participant's peer connection as a WebRTC endpoint itself, which also means it is a party to the media rather than a pass-through. ## Who sees what | Server role | Needed when | Carries | Sees decrypted media? | |---|---|---|---| | Signalling | always | offers, answers, candidates, call control | no | | STUN | almost always (any NAT) | binding requests and responses | no media at all | | TURN | when no direct pair works | relayed DTLS and SRTP packets | no | | Media server | groups, recording, gateways | the media, as a call endpoint | yes | ## Taking the pitch apart A fair rewrite of "serverless video calling" is: **peer-to-peer media, server-assisted setup, relay as a fallback**. The operational consequences follow from the table: - the signalling service is on the critical path of every call, so it needs the availability of any login-gated API; - STUN is cheap, because it answers a few small requests per call; - TURN is where the bandwidth bill lives, and its share of calls depends on users' networks, not on the code; - adding recording or group calls changes the architecture, because a media server becomes a party to the call.
- Can two WebRTC peers on the same office network connect with no STUN or TURN server configured?Usually yes. With an empty `iceServers` list the ICE agent still gathers **host** candidates, the device's own interface addresses, and two peers on one network can often reach each other on those. Signalling is still required to exchange descriptions and candidates. The setup breaks as soon as a NAT or a firewall sits between them, which is why deployments configure STUN and TURN.
- Can the operator of a TURN relay listen to a relayed WebRTC call?Not from the relayed packets. The DTLS handshake runs between the two peers through the relay, so the relay forwards DTLS and SRTP packets whose keys it never holds. It does learn metadata: both peers' addresses, timing and traffic volume. A media server is different: it terminates each participant's connection, so it does see the media.
- Why does WebRTC not standardise a signalling protocol?JSEP (RFC 9429) deliberately decouples creating and applying descriptions from how they travel, so an application can reuse its own HTTPS or WebSocket API, or bridge to SIP or XMPP as RFC 8825's trapezoid shows. The cost is that every deployment builds and secures its own rendezvous, presence and authorisation, and two separately built applications cannot call each other without agreeing on one.
Two pen-pals who know only each other's names ask a mutual friend to pass along their addresses (signalling); each first asks the post office what its return address looks like from outside (STUN); if one building refuses unknown mail, they use a forwarding box at the post office (TURN). Once letters flow, the friend steps out.
saying these in an interview costs you the question
- WebRTC is fully peer-to-peer, so no server is involved at all
- The STUN server relays the media when a direct path fails
- Every browser speaks one standard WebRTC signalling protocol
- A TURN relay decrypts the media, so it can read the call
- Every WebRTC call, even one-to-one, has to pass through a media server