On WebRTC

In 2010, Google acquired Global IP Solutions (GIPS) for $68.2 million specifically to open-source its proprietary voice and video engines. This acquisition formed the foundation of the WebRTC standard.

It's an open source project that provides real-time communication (RTC) capabilities to Web browsers.

WebRTC shifts the paradigm from a traditional Client-Server model to a Peer-to-Peer (P2P) model for media transfer. The core system design challenge is connecting two or more browsers, often hidden behind Network Address Translation (NAT) and strict firewalls, to stream data with millisecond latency.

WebRTC architecture relies on three distinct pillars: the Control Plane, the Traversal Framework, and the Data Plane.

When the W3C and IETF were standardizing WebRTC, a debate erupted over how to handle call setup. Telecom veterans pushed hard to bake in SIP (Session Initiation Protocol). Web developers balked at the rigid, legacy baggage of telecom standards. The result was a deliberate, pragmatic architectural compromise: WebRTC standardizes the media transport but intentionally provides zero signaling protocol. It is strictly "Bring Your Own Signaling." This forces developers to build a custom infrastructure just to negotiate a connection, but it also allows WebRTC to integrate cleanly with anything from legacy VoIP bridges to modern IoT backends.

Before raw media packets can bypass firewalls and travel directly over the internet, clients must discover each other and agree on communication parameters. Here is how that control plane is constructed from scratch.

Since WebRTC lacks built-in discovery, a central Signaling Server must track who is online and how to reach them. Registration typically follows this pattern:

• Authentication: A client authenticates with the backend (e.g., via standard OAuth or JWT over a REST API).

• Connection: The client opens a persistent, bi-directional connection—almost always a WebSocket—to a specific signaling server node.

• State Mapping: The signaling node writes a record to an in-memory datastore (like Redis), mapping the user's ID to the specific server node maintaining their socket.

With both clients registered and online, they must exchange a Session Description Protocol (SDP) payload. SDP is a string-based blob that acts as a digital contract. It outlines exact media capabilities (like supporting VP8 or H.264 video codecs), encryption keys, and network routing candidates.

The actual negotiation is an asynchronous ping-pong match brokered entirely by the signaling infrastructure:

• The Offer: Client A generates an SDP Offer and transmits it over their WebSocket to the signaling server.

• The Routing: The signaling server queries the state datastore, locates Client B's active WebSocket node, and routes the Offer payload to them.

• The Answer: Client B evaluates the Offer, determines if its hardware can support the requested codecs, generates an SDP Answer, and fires it back through the signaling server to Client A.

• The Handshake: Once the Answer is received, the WebRTC peer connection transitions to the networking phase (ICE) to establish the direct media pipeline.

WebSockets are the industry standard for the signaling transport layer. Legacy HTTP polling introduces unacceptable latency; SDP exchanges must happen in milliseconds to avoid noticeable call setup delays.

However, scaling WebSocket servers introduces massive state management challenges. A single server cannot hold millions of concurrent, stateful TCP connections. Handling global scale requires distributing the load across a cluster:

• State Management (The Registry): A highly available, low-latency datastore (Redis) acts as the single source of truth for user presence and socket mapping.

• Message Brokering (The Router): A Pub/Sub architecture (like Kafka or Redis Pub/Sub) connects the cluster. If Client A (on Node 1) calls Client B (on Node 5), Node 1 publishes the SDP Offer to the message broker, which immediately pushes it to Node 5 for final delivery.

Client devices typically sit behind NAT routers, operating on local IP addresses invisible to the public internet. The Interactive Connectivity Establishment (ICE) protocol acts as the mapping framework to discover usable public routes.

A STUN server operates as a cheap, lightweight network mirror. A client pings the STUN server, which simply replies with the client’s public-facing IP address and port. This resolves the majority of basic NAT traversal issues without processing actual media.

Symmetric NATs, frequently deployed in corporate environments and 5G networks, actively block direct P2P traffic. In these scenarios, the system falls back to a TURN server. TURN acts as a heavy-duty relay, proxying every single media packet between clients. It requires significant bandwidth and computational resources.

Optimization via Trickle ICE

Waiting for STUN to resolve all public IPs before sending an SDP Offer creates noticeable connection delays. Trickle ICE optimizes this by dispatching the initial SDP immediately using only local IPs. As public IPs are discovered via STUN, they stream to the remote peer asynchronously as "ICE Candidates," drastically reducing the time to first frame.

Direct P2P connectivity works flawlessly for two participants. Scaling to multi-party group calls requires architectural shifts.

In a pure mesh, every participant connects directly to every other participant.

• Advantage: Zero media server costs and strict end-to-end encryption.

• Drawback: The model collapses past a handful of users. Client devices quickly exhaust available CPU and upload bandwidth encoding and transmitting identical video streams to multiple peers.

An MCU centralizes the workload, acting as a massive video mixer.

• Advantage: Clients upload once and download a single composite stream, minimizing local bandwidth.

• Drawback: Server-side CPU costs skyrocket due to decoding and re-encoding composite grids. Clients also lose the ability to manipulate individual participant layouts.

The SFU represents the modern standard for platforms handling massive concurrency. It operates as a highly optimized media router.

• Advantage: Clients upload a single stream. The SFU forwards discrete copies of that stream to downstream participants. This preserves UI flexibility on the client side without exponentially increasing upload bandwidth requirements.

Notes: Expanding the Architecture

A complete system design requires addressing edge cases and massive scale.

We will dive deeper into network resilience, global distribution, transport mechanics and more in the upcoming posts and build a simple DB-less, P2P planning poker app using WebRTC and PeerJs.

🚢 Keep Shipping!