WebRTC

WebRTC (Web Real-Time Communication) is a W3C and IETF co-standardised open framework that enables peer-to-peer exchange of audio, video, and arbitrary data between web browsers and native applications using a JavaScript API (getUserMedia, RTCPeerConnection, RTCDataChannel), combining

Semantic Classification

Content

WebRTC originated from a joint initiative between Google, Mozilla, and Opera in 2011, driven by Google’s acquisition of Global IP Solutions (GIPS) and its codec intellectual property (VP8, iSAC). Google open-sourced the libwebrtc implementation and worked with the W3C and IETF to standardise the browser API and underlying protocols respectively. The W3C WebRTC 1.0 specification reached Recommendation status in January 2021, by which point WebRTC had already powered billions of video calls through Google Meet, Zoom’s browser client, and hundreds of other platforms.

Key Characteristics

• Peer-to-Peer Architecture: WebRTC establishes direct connections between peers wherever possible, routing media without traversing central servers. This reduces latency (typically 40–80 ms peer-to-peer), lowers server infrastructure costs, and provides privacy by keeping media off third-party servers.

• Three Core APIs: getUserMedia captures camera and microphone streams; RTCPeerConnection negotiates and maintains encrypted peer connections for media; RTCDataChannel provides a bidirectional, ordered or unordered, reliable or unreliable byte-stream channel for arbitrary data.

• ICE/STUN/TURN NAT Traversal: Interactive Connectivity Establishment tests multiple connection candidates (direct, server-reflexive via STUN, relayed via TURN) and selects the optimal path. Approximately 60 % of WebRTC connections use STUN-discovered paths; 8 % require TURN relay as fallback.

• Mandatory Encryption: DTLS (Datagram TLS) for key exchange and SRTP (Secure Real-Time Protocol) for media encryption are mandatory in all WebRTC implementations. There is no plaintext WebRTC mode, ensuring all peer communication is encrypted in transit.

• Adaptive Bitrate: The REMB (Receiver Estimated Maximum Bitrate) and Transport-CC feedback mechanisms allow senders to adapt video quality and bitrate dynamically based on network conditions, preventing buffer bloat and maintaining call quality under constrained network paths.

• Insertable Streams / Encoded Transform: A newer API allowing JavaScript (or WebAssembly modules) to intercept and transform encoded media frames before encryption and transmission, enabling end-to-end encrypted group calls, custom codecs, real-time AI processing (noise suppression, background replacement), and watermarking.

  How It Works

  WebRTC connection establishment follows the offer-answer model. Peer A calls createOffer() to generate an SDP (Session Description Protocol) document listing its media capabilities (supported codecs, ICE candidates). This SDP is sent to Peer B via an out-of-band signalling channel (typically a WebSocket server, though Nostr Protocol relay-based signalling is also possible). Peer B calls createAnswer() with a matching SDP and sends it back. Both peers set local and remote descriptions, which triggers ICE candidate gathering (querying STUN servers to discover public addresses) and exchange via the signalling channel. ICE then performs connectivity checks — sending STUN binding requests from each candidate pair — and promotes the first successful pair to the active connection path. Media flows immediately once the DTLS handshake completes (sub-second from ICE completion).

  For group calls beyond 4–6 participants, a Selective Forwarding Unit (SFU) architecture is used: each peer maintains a single WebRTC connection to the SFU server, which receives all streams and selectively forwards them to each subscriber based on available bandwidth. Popular open-source SFUs include mediasoup, Janus, Pion (Go), and LiveKit.

  Current Landscape

  WebRTC in 2025–2026 is ubiquitous: 98.7 % of browsers support it natively, and 4.2 billion monthly active users communicate via WebRTC-powered platforms. Key developments include AV1 codec standardisation (30 % better compression than VP9), WebCodecs API maturation enabling custom codec pipelines, and WebTransport (QUIC-based) partially displacing WebRTC data channels for low-latency application data. In the telecollaboration domain, WebRTC underpins all major platforms: Google Meet, Microsoft Teams browser client, Zoom, Jitsi Meet, and spatial audio platforms (Gather, Spatial). The NHS uses WebRTC for GP telehealth consultations across multiple provider platforms. The UK’s BBC uses WebRTC for remote broadcast contribution and audience interaction.

  Cross-Domain Applications

  In the Metaverse Domain, WebRTC carries both the spatial audio streams and binary avatar state updates in OpenXR collaborative environments, enabling multi-user XR experiences without dedicated game servers for the transport layer. In the Blockchain Domain, WebRTC data channels paired with Nostr Protocol signalling create a fully decentralised communication stack with no central server dependency. In the Robotics Domain, WebRTC carries tele-operation video feeds from Robot Operating System camera nodes to operator browsers, with RTCDataChannel carrying control commands in the reverse direction. In the NGM Domain, WebAssembly insertable streams process media frames on-device — running AutoML-trained noise suppression models — before encryption, without any server-side media access.

  Standards and References

• W3C. (2021). WebRTC 1.0: Real-Time Communication Between Browsers. W3C Recommendation. https://www.w3.org/TR/webrtc/

• IETF RTCWEB Working Group. (2014). Overview: Real-Time Protocols for Browser-Based Applications (RFC 7478). https://tools.ietf.org/html/rfc7478

• Loreto, S., & Romano, S. P. (2014). Real-Time Communication with WebRTC: Peer-to-Peer in the Browser. O’Reilly Media.

• Fette, I., & Melnikov, A. (2011). The WebSocket Protocol (RFC 6455). IETF.

• Rescorla, E. (2012). WebRTC Security Architecture (draft-ietf-rtcweb-security-arch). IETF RTCWEB.

Provenance