WebRTC & Real-Time Communication

The core WebRTC API for establishing a peer-to-peer audio/video/data connection between two browsers. Manages ICE gathering, SDP negotiation, DTLS handshake, and SRTP media streams. One RTCPeerConnection per peer.

"Creating a video call: const pc = new RTCPeerConnection(iceServers); localStream.getTracks().forEach(t => pc.addTrack(t, localStream)); const offer = await pc.createOffer(); await pc.setLocalDescription(offer); // send offer to remote via signalling server. The remote peer calls setRemoteDescription(offer), creates an answer, and sends it back. ICE candidates are exchanged in parallel."

A format describing a multimedia session: supported codecs, IP addresses, ports, and stream attributes. In WebRTC, the offer/answer model uses SDP: the initiator creates an SDP offer (what it can send/receive), the remote peer creates an SDP answer (what it accepts).

"An SDP offer contains sections for each media type: audio (a=sendrecv, supported codecs: opus/48000), video (a=sendrecv, codecs: VP8/90000, H264/90000), data channel. The answer mirrors the offer, selecting compatible codecs. SDP is verbose text — developers rarely parse it directly, but understanding its structure helps debug codec negotiation failures."

The WebRTC framework for finding the best network path between peers. Gathers candidates: host (local network), server-reflexive (public IP via STUN), relayed (TURN server). Runs connectivity checks, selects the best working pair.

"ICE gathering discovers three candidate types: host candidate (192.168.1.5:50000 — local LAN), server-reflexive candidate (203.0.113.45:50000 — public IP via STUN), relay candidate (via TURN server). If peers are on the same LAN, they connect via host candidates. If behind symmetric NAT (common in corporate networks), the TURN relay is the only option."

STUN (Session Traversal Utilities for NAT): tells a client its public IP and port as seen from the internet — cheap, stateless. TURN (Traversal Using Relays around NAT): a relay server that forwards traffic when direct P2P is impossible (symmetric NAT). TURN is expensive (all media flows through it).

"Our WebRTC deployment uses Google's public STUN server for IP discovery and our own Coturn TURN server for relay fallback. 70% of calls use direct P2P (STUN sufficient). 30% require TURN (corporate networks with strict firewalls). TURN bandwidth cost is our biggest WebRTC infrastructure expense — we scale TURN servers in regions close to our user base."

Sending multiple quality layers of the same video stream simultaneously from the sender. An SFU (Selective Forwarding Unit) forwards the appropriate quality layer to each receiver based on their bandwidth. Replaces per-receiver encoding on the sender.

"In our video conferencing app, each participant sends three simulcast layers: 1080p, 720p, 360p. The SFU forwards 1080p to participants on fast connections and 360p to mobile users on cellular. Without simulcast, the sender would need to encode separately for each receiver — CPU-prohibitive for the browser. Simulcast shifts layer selection to the SFU."

SFU: a media server that forwards incoming streams to all receivers without decoding/encoding. Scalable, low latency, but each receiver downloads multiple streams. MCU (Multipoint Control Unit): mixes all streams into one before forwarding. Lower receiver bandwidth but high server compute.

"We chose SFU architecture (mediasoup) for our video meetings. With 10 participants, each browser receives 9 streams — the SFU is just a packet forwarder. MCU would mix 10 streams into 1 on the server, reducing client bandwidth significantly but requiring server-side video transcoding for every participant. At scale, SFU server costs are lower; MCU has lower client requirements."

A data structure that enables multiple concurrent writers to modify shared state without coordination and always converge to a consistent state. Used in real-time collaborative editors (Yjs, Automerge) as an alternative to operational transformation.

"Our collaborative code editor uses Yjs CRDT. Two users can simultaneously edit the same line — their changes are represented as CRDT operations. When the operations are exchanged, they merge deterministically without conflict: no server round trip needed for conflict resolution. Offline edits merge correctly when the user reconnects. The CRDT guarantees eventual consistency."