Practise vocabulary for WebRTC architecture: peer-to-peer vs. SFU vs. MCU, ICE framework, TURN/STUN servers, signaling channel, and NAT traversal.
0 / 5 completed
1 / 5
A team is building a video call for 2 participants. They choose a peer-to-peer (P2P) topology. What is the defining characteristic of P2P WebRTC?
In P2P WebRTC, media travels directly browser-to-browser once the ICE connection is established. For 2 participants this is optimal — no server cost, low latency. For N participants, each peer must upload N-1 streams, making P2P impractical beyond 4–6 participants. For larger calls, an SFU (Selective Forwarding Unit) is used instead.
2 / 5
What does an SFU (Selective Forwarding Unit) do in a WebRTC architecture?
An SFU (e.g., Mediasoup, Janus, LiveKit) forwards RTP packets without touching the payload — no decode/re-encode, so CPU cost is low. Each participant uploads once to the SFU; the SFU selectively forwards streams to each subscriber. This scales to dozens of participants. Contrast with MCU (Multipoint Control Unit), which mixes streams server-side — heavier CPU, but clients receive a single mixed stream.
3 / 5
What is the ICE (Interactive Connectivity Establishment) framework in WebRTC?
ICE is WebRTC's connection establishment engine. It gathers candidate types: host candidates (local IPs), server-reflexive candidates (public IP/port discovered via STUN), and relayed candidates (via TURN). ICE then performs connectivity checks on candidate pairs — both peers test all combinations — and selects the highest-priority working pair. This handles NAT, firewalls, and complex network topologies automatically.
4 / 5
What is the difference between STUN and TURN servers in WebRTC?
STUN (Session Traversal Utilities for NAT) is a lightweight server that simply tells the peer 'your public IP:port is X' — the peer includes this as a server-reflexive ICE candidate. No media flows through STUN. TURN (Traversal Using Relays around NAT) is used when direct connectivity fails: both peers connect to TURN, which relays all media. TURN is expensive (bandwidth cost) but guarantees connectivity — a production WebRTC app always configures TURN as a fallback.
5 / 5
What is the distinction between the 'media plane' and the 'signaling plane' in WebRTC architecture?
Signaling plane: SDP offer/answer exchange, ICE candidate trickling — all via the app's signaling server (typically WebSocket). This is how two peers negotiate what to connect and how. Media plane: once ICE succeeds and DTLS handshake completes, encrypted RTP/RTCP flows directly P2P (or via SFU/TURN) — the signaling server is completely out of the media path. This separation is fundamental to WebRTC's architecture and why signaling is not specified by the standard.