How Browsers Video Call Without Servers – WebRTC Explained

Real-time media streaming, high-frequency video conferencing, and instantaneous peer-to-peer data channels require specialized networking models that avoid the heavy latency introduced by intermediary application servers. While traditional protocols like HTTP and WebSockets excel at request-response or server-mediated chat interactions, high-bandwidth applications like voice over IP (VoIP), live video, and browser-based screen sharing demand direct client-to-client communication. This chapter explores WebRTC (Web Real-Time Communication), analyzing how browsers negotiate, establish, and maintain direct peer connections using UDP transport, signaling servers, and session description protocols.

1. Why Do We Need WebRTC? (The WebSocket Limitation)

To understand why WebRTC was invented, we must first review how WebSockets handle real-time data and where they fall short for modern multimedia applications.

The WebSocket Model

WebSockets were designed to overcome the stateless, short-lived nature of HTTP by establishing a single, long-lived TCP connection through an initial handshake. Once established, both the client and server can push bidirectional messages instantaneously without repeating HTTP connection overhead.

Why WebSockets Fail for Video Calls

• High Latency / Round-Trip Overhead: In a video call routed through WebSockets, Client A's video frames must travel all the way to the server, get processed by the server application, and then get forwarded to Client B. This "double-hop" adds perceptible delay (lag).
• Server Bandwidth Bottleneck: The relay server must ingest and re-transmit massive amounts of high-bitrate video and audio streams for every active participant, causing immense server-side network and CPU loads.
• TCP Head-of-Line Blocking: WebSockets operate over TCP. If a single TCP packet is dropped due to packet loss on a wireless network, the entire connection stalls while waiting for retransmission, causing video stuttering and freezing.

2. Core Mental Model: The Direct Phone Call Analogy

Real-Life Analogy

Think of WebSockets like communicating through a central telephone switchboard operator. Every time you want to tell your friend something, you must speak your message to the operator, the operator records it, and then turns around and reads it to your friend. It works well for passing notes back and forth (chat), but it becomes extremely slow and bottlenecked if you both try to sing a duet simultaneously (video calling).

In contrast, WebRTC is like dialing your friend's direct phone number using a directory assistance lookup once at the very beginning. Once the call connects, you talk directly to each other peer-to-peer. The telephone company's routing equipment helped set up the call initially, but your actual voice travels directly between your phones without stopping at an operator's desk.

3. WebSockets vs. WebRTC: Comparative Synthesis

When architecting modern web applications, developers frequently combine both technologies rather than choosing just one. For instance, an online tutoring platform uses WebRTC for the live video classroom, while utilizing WebSockets for the live text chat sidebar.

4. What is WebRTC?

WebRTC stands for Web Real-Time Communication. It is an open-source framework and set of browser APIs that enables web browsers and mobile applications to perform peer-to-peer audio, video, and arbitrary data sharing without requiring intermediate plugins or third-party server relays.

Key Capabilities

• Browser-Native Voice & Video: Direct, high-definition audio and video conferencing directly inside the browser engine.
• Live Screen Sharing: High-framerate desktop or tab sharing for collaborative tools (e.g., Figma, Google Meet, Zoom).
• Peer-to-Peer Data Channels: Arbitrary binary or string data transfer over UDP data channels for gaming state synchronization or collaborative canvas editing.
• UDP Foundation: Built on top of User Datagram Protocol (UDP), allowing it to drop hopelessly delayed packets in favor of immediate, real-time frame delivery—ideal for audio/video streams.

5. The Architecture of WebRTC Connection Establishment

Although WebRTC communicates directly peer-to-peer, browsers cannot magically discover each other across the public internet without help. Devices live behind Network Address Translators (NATs) and firewalls. Therefore, WebRTC requires external helper servers initially to bootstrap the connection.

The Role of the Signaling Server

The Signaling Server is an intermediary broker (often implemented using WebSockets) whose sole job is to help two peers exchange connection metadata (descriptions of themselves) so they can discover each other. Once this exchange completes, the signaling server steps out of the way, and media flows directly between the peers.

6. SDP: Session Description Protocol

To establish a connection, browsers must exchange configuration parameters detailing what kind of media they want to transmit and how they are willing to communicate. This metadata is structured using SDP (Session Description Protocol).

What is Contained in an SDP Payload?

• Connection Information: Network endpoints, IP addresses, and port candidates.
• Media Types: Declarations of whether the session includes audio, video, or data channels.
• Codecs Supported: Negotiated compression formats (e.g., VP8, H.264 for video; Opus for audio).
• Encryption Keys: Cryptographic parameters required to secure the peer-to-peer media stream (Secure Real-time Transport Protocol - SRTP).

7. Step-by-Step Flow Walkthrough: Alice and Bob Connect

To visualize how a WebRTC session goes live between two users (Alice and Bob), let's trace the exact sequence of events:

1. Session Initialization: Alice decides to call Bob. Her browser creates an SDP Offer describing her media capabilities, supported codecs, and cryptographic keys.
2. Signaling Exchange (Offer): Alice sends her SDP Offer to the Signaling Server, which immediately routes it to Bob's browser.
3. Processing and Response: Bob's browser receives Alice's offer, reads her capabilities, and generates an SDP Answer confirming compatible codecs and media streams.
4. Signaling Exchange (Answer): Bob sends his SDP Answer back through the Signaling Server to Alice.
5. Direct Connection Established: With the SDP exchange complete, both browsers possess all necessary configuration metadata. They open direct peer-to-peer UDP channels.
6. Streaming Phase: The signaling server is no longer needed. Audio, video, and data flow directly between Alice and Bob with minimal latency.

8. Summary and Key Takeaways

• The WebSocket Bottleneck: While WebSockets enable real-time bidirectional communication via servers, routing heavy video and audio through a server adds latency, bandwidth bottlenecks, and high operational costs.
• WebRTC Definition: WebRTC (Web Real-Time Communication) enables direct peer-to-peer audio, video, and data streaming natively within modern web browsers.
• Server-less Data Path: Once connected, WebRTC removes servers from the data path, routing media directly between clients for optimal streaming performance.
• UDP Underpinnings: WebRTC relies on UDP rather than TCP, sacrificing absolute packet delivery reliability for ultra-low latency, which is essential for real-time media.
• Initial Signaling Requirement: Although communication is peer-to-peer, a temporary Signaling Server is required at startup to help clients exchange discovery metadata.
• SDP Metadata Exchange: Browsers use SDP (Session Description Protocol) to negotiate media types, codecs, network addresses, and cryptographic keys during the handshake.
• Hybrid Architectures: Real-world applications often combine WebSockets and WebRTC—using WebSockets for chat signaling/messaging and WebRTC for the heavy video conference streams.