Understanding WebRTC: Architecture, Core Components, and Protocol Stack

Introduction

WebRTC (Web Real‑Time Communications) enables browsers to create peer‑to‑peer (P2P) connections for audio, video, or arbitrary data without plugins or intermediate servers. It consists of a set of standards covering media codecs, encryption, transport, and a JavaScript API that applications use to control the connection. Signaling is left to the developer, allowing integration with SIP, WebSocket, or other signalling mechanisms.

Supported browsers and platforms

Internal architecture

Color legend of the diagram:

Purple – API layer exposed to web developers

Solid blue – API implemented by browser vendors

Dashed blue – optional vendor‑specific extensions

WebRTC is divided into three functional modules:

Voice engine

NetEQ – jitter buffer and packet‑loss concealment for audio

Echo canceller and noise‑reduction

Video engine

VP8 (and optionally VP9/H.264) codec

Video jitter buffer

Image‑enhancement filters

Transport

SRTP – secure media transport

Multiplexing of media and data streams

STUN, TURN and ICE for NAT/firewall traversal

DTLS for key exchange and encryption of all traffic

All traffic runs over UDP

Core components

Audio/video codecs: OPUS, VP8/VP9, H.264

Transport protocol: UDP

Media protection: SRTP / SRTCP

Data transport: DTLS / SCTP

NAT traversal: STUN / TURN / ICE (including Trickle ICE)

Signalling & SDP negotiation: HTTP, WebSocket, SIP, Offer‑Answer model

Audio and video engine stack

Hardware layer provides raw audio capture and video capture devices.

C++ engine layer performs capture, encoding, jitter mitigation, echo cancellation (audio) and codec optimisation, jitter buffering (video).

The C++ engine is wrapped by a JavaScript API exposed as RTCPeerConnection, MediaStream, etc.

Protocol stack

All protocols are built on top of UDP.

ICE (RFC 5245) coordinates candidate gathering; STUN (RFC 5389) discovers public addresses; TURN (RFC 5766) relays traffic when direct paths fail.

DTLS (RFC 6347) provides encryption and key exchange; it is mandatory for all WebRTC connections, which must be served over HTTPS or localhost.

SRTP / SRTCP (RFC 3711) protect media streams.

SCTP (RFC 4960) runs over DTLS to deliver reliable, ordered or unordered data channels (RTCDataChannel). RTCPeerConnection manages the end‑to‑end media path; RTCDataChannel enables arbitrary binary data exchange.