# Video Call Service Low-Level Design: WebRTC Signaling, Media Relay, and Quality Adaptation

Source: https://www.techinterview.org/post/3233469739/lld-video-call/
Updated: 2026-06-30 · techinterview.org

## WebRTC Overview

WebRTC (Web Real-Time Communication) is a browser and native SDK standard for peer-to-peer audio and video. It handles media capture, codec negotiation, NAT traversal, encryption, and congestion control — all without requiring a media server for 1:1 calls. The application is responsible only for signaling: exchanging the session descriptions and network candidates that WebRTC needs to establish the peer connection.

## WebRTC Peer Connection Internals

A WebRTC peer connection involves several protocol layers:

- **ICE (Interactive Connectivity Establishment):** discovers network paths between peers, selecting the best available route

- **DTLS (Datagram TLS):** establishes encrypted channel over UDP for key exchange

- **SRTP (Secure Real-time Transport Protocol):** encrypts media streams using keys negotiated via DTLS

- **SDP (Session Description Protocol):** describes media capabilities — codecs, bitrates, directions, and network candidates

## Signaling Server

WebRTC does not define a signaling protocol — applications implement their own. A WebSocket-based signaling server relays SDP offers/answers and ICE candidates between peers:

- Caller creates an SDP offer describing its media capabilities

- Offer sent to signaling server → forwarded to callee

- Callee creates SDP answer → sent back via signaling server

- Both peers exchange ICE candidates (network addresses) through signaling

- WebRTC selects the best ICE candidate pair and establishes the peer connection

The signaling server is only in the control plane — it carries no media after connection establishment.

## STUN Server

Most clients are behind NAT — their internal IP (192.168.x.x) is not reachable by peers. STUN (RFC 5389) solves this:

- Client sends a request to the STUN server from behind NAT

- STUN server responds with the client's public IP:port as observed at the server

- Client includes this reflexive candidate in its ICE candidate list

STUN is cheap to operate — requests are tiny and stateless. Google's public STUN servers (`stun.l.google.com:19302`) are commonly used in development.

## TURN Relay

Symmetric NATs block STUN-discovered candidates — roughly 8% of real-world connections require a relay. TURN (RFC 5766) allocates a public relay address on the server and forwards all media through it:

- Client authenticates with TURN server and requests an allocation

- TURN server assigns a relay IP:port

- All media packets flow through the TURN server — significant bandwidth cost

- TURN is used only as a fallback after STUN and direct P2P attempts fail

Coturn is the standard open-source TURN server. Plan for ~1.5x the call's media bandwidth in TURN infrastructure costs for the fraction of calls that need it.

## P2P vs SFU for Group Calls

1:1 calls work well P2P. Group calls do not scale with pure P2P:

- **P2P mesh (N participants):** each participant sends N-1 streams and receives N-1 streams. Upload bandwidth scales as O(N). At 5 participants with 1Mbps video each, every participant uploads 4Mbps — unsustainable on typical home connections.

- **SFU (Selective Forwarding Unit):** each participant sends one stream to the SFU. The SFU forwards each participant's stream to all other participants. Upload per participant stays constant at 1 stream regardless of group size.

## SFU Architecture

The SFU operates at the RTP packet level — it forwards video/audio packets without decoding:

- **Simulcast:** senders transmit 3 quality layers simultaneously (e.g., 720p/1080p/360p). The SFU selects which layer to forward to each recipient based on their available downlink bandwidth.

- **Spatial and temporal scalability:** SVC (Scalable Video Coding) with VP9/AV1 allows the SFU to drop packet layers without requiring re-encoding.

Open-source SFU implementations: Mediasoup (Node.js), Janus (C), Livekit (Go).

## Adaptive Bitrate

WebRTC has built-in congestion control. The receiver measures packet loss, jitter, and inter-packet delay, then sends bandwidth estimates back to the sender via RTCP:

- **REMB (Receiver Estimated Maximum Bitrate):** receiver estimates available downlink and signals it to the sender

- **TWCC (Transport-Wide Congestion Control):** sender receives per-packet arrival time reports and runs its own bandwidth estimation (GCC algorithm)

The sender responds by adjusting bitrate — reducing resolution or framerate to fit the available bandwidth. This happens in real time, continuously.

## Quality Metrics and Recording

**Quality metrics** available via the WebRTC Stats API and RTCP reports:

- Packet loss percentage — above 2% is noticeable, above 10% causes freezes

- Jitter — variation in packet arrival times; large jitter degrades audio

- Round-trip time — above 300ms creates perceptible conversational delay

Expose these to the UI as a call quality indicator (good/fair/poor).

**Recording:** the SFU writes each participant's incoming RTP stream to disk. Post-call, a compositor process combines individual tracks into a mixed recording, transcodes to MP4, and stores in S3. Alternatively, record the mixed stream in real time using GStreamer or FFmpeg connected to the SFU's RTP output.

## Screen Sharing and Background Effects

**Screen sharing:** `getDisplayMedia()` captures a screen or window as a MediaStream. This is added as a separate video track in the WebRTC peer connection — recipients receive both the camera track and the screen share track simultaneously.

**Virtual background / blur:** applied client-side before the video track enters WebRTC. Two approaches: WebGL shader for real-time blur of a fixed background region, or MediaPipe Selfie Segmentation for accurate person/background separation. The processed frames replace the raw camera track, so no server-side changes are needed.

See also: [Netflix Interview Guide 2026: Streaming Architecture, Recommendation Systems, and Engineering Excellence](https://www.techinterview.org/post/3233460274/netflix-interview-guide-2026-streaming-architecture-recommendation-systems-and-engineering-excellence/)

See also: [Meta Interview Guide 2026: Facebook, Instagram, WhatsApp Engineering](https://www.techinterview.org/post/3233460272/meta-interview-guide-2026-facebook-instagram-whatsapp-engineering/)

See also: [Scale AI Interview Guide 2026: Data Infrastructure, RLHF Pipelines, and ML Engineering](https://www.techinterview.org/post/3233460275/scale-ai-interview-guide-2026-data-infrastructure-rlhf-pipelines-and-ml-engineering/)