cloudparts

WebRTC

A browser API and protocol suite for live audio, video and data sent straight between two endpoints: ICE finds a path through NATs, DTLS sets up the keys, SRTP carries the media and SCTP carries data channels.

What it is
Network protocols (transport protocols)
Type
Open source
Made by
W3C and IETF
License
Open standard (W3C Recommendation and IETF RFCs); Google’s reference implementation, libwebrtc, is BSD 3-Clause with a patent grant
Facts checked
13 October 2026
Website Source code

What it is

WebRTC is two standards that work together: the W3C’s JavaScript API (RTCPeerConnection, RTCDataChannel) and a suite of IETF protocols that every endpoint must implement, which RFC 8825 lists without defining a protocol of its own. Signaling is deliberately left out. Each application exchanges SDP offers and answers (the JSEP model of RFC 8829) and network candidates with the other side over a channel it chooses, typically HTTPS or WebSockets to its own server. Only the media path runs directly between the two endpoints, and it must follow the WebRTC protocols exactly so that any compliant browser, app or server can join.

Finding that path is the job of ICE (RFC 8445). Each side gathers candidates: host addresses from its own interfaces, server-reflexive addresses that a STUN server sees on the public side of a NAT, and relayed addresses allocated on a TURN server. ICE then tries the pairs in a sorted order until one works. Endpoints must support TURN, because two peers behind NATs with endpoint-dependent mapping can’t reach each other directly, and TURN over TCP or TLS to get through firewalls that block all UDP. On the chosen path the two sides run one DTLS handshake, checked against certificate fingerprints sent during signaling. Its exported keys protect the audio and video, sent as SRTP, and the data channels run SCTP inside the same DTLS association, all on one port pair.

Each data channel is an SCTP stream that is reliable by default, or limited by maxRetransmits or maxPacketLifeTime; zero retransmissions with unordered delivery gives a UDP-like service. Browsers must implement VP8 and H.264 Constrained Baseline video, and every endpoint Opus and G.711 audio. The IETF published the protocol cluster, more than 40 RFCs, in January 2021, and the W3C made the API a Recommendation on 26 January 2021, with an updated Recommendation on 13 March 2025.

Why teams pick it

  • Built into all major browsers as a royalty-free JavaScript API, with a library offering the same features to native Android and iOS apps, so a call needs no plugin or download
  • Encryption is mandatory: media keys come from a DTLS handshake between the endpoints, so a signaling server that only relays messages can’t passively read the call
  • NAT traversal is built in: ICE tries direct, STUN-discovered and TURN-relayed paths, and can fall back to TURN over TCP or TLS where UDP is blocked
  • Data channels let each channel choose reliable and ordered delivery or a UDP-like mode, and are congestion-controlled so they don’t swamp the audio and video

Watch out for

  • No signaling protocol: you must design or choose one, run a server for it, and operate STUN and TURN servers; when only a TURN relay works, all the media flows through your relay
  • Peer to peer doesn’t scale to big calls: in a mesh each participant sends its streams to every other participant, so larger groups need a selective forwarding middlebox (SFU) that receives each stream once
  • Connection attempts can reveal a user’s local and public IP addresses to the web application, more than plain HTTP does; RFC 8828 sets rules for how much browsers expose
  • Without SCTP message interleaving, data channel senders should keep messages to 16 KB, and TCP paths used where UDP is blocked can suffer head-of-line blocking

Alternatives

What all transport protocols have in common →Compare side by side →
QUICOpen sourceA secure, multiplexed transport over UDP: TLS 1.3 is built into its handshake, many streams share one connection without blocking each other, and a connection can survive a change of network.TCPOpen sourceThe Transmission Control Protocol: a handshake opens a connection between two ports, then bytes arrive complete and in order, resent when lost and paced to what the path can carry.UDPOpen sourceThe User Datagram Protocol: ports and a checksum on top of IP, and nothing else. Each datagram is sent on its own, with no connection, no retransmission and no ordering.

How it fits with other technologies

Open a peer connection with an unreliable data channel (signaling is your own code) · js

const signaling = new SignalingChannel(); // yours: WebSocket, HTTPS, anything
const pc = new RTCPeerConnection({
  iceServers: [
    { urls: 'stun:stun.example.org' },
    { urls: 'turn:turn.example.org', username: 'user', credential: 'secret' },
  ],
});

// UDP-like: unordered, never retransmitted
const telemetry = pc.createDataChannel('telemetry', { ordered: false, maxRetransmits: 0 });
telemetry.onopen = () => telemetry.send(JSON.stringify({ speed: 1.2 }));

pc.onicecandidate = ({ candidate }) => signaling.send({ candidate });
pc.onnegotiationneeded = async () => {
  await pc.setLocalDescription(); // creates the SDP offer
  signaling.send({ description: pc.localDescription });
};

signaling.onmessage = async ({ data: { description, candidate } }) => {
  if (description) {
    await pc.setRemoteDescription(description);
    if (description.type === 'offer') {
      await pc.setLocalDescription(); // creates the answer
      signaling.send({ description: pc.localDescription });
    }
  } else if (candidate) {
    await pc.addIceCandidate(candidate);
  }
};

See it in a real stack

No architecture uses WebRTC yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2011–2025

Voice and video calls on the web used to mean installing a plugin or a separate application. In 2010 Google bought Global IP Solutions (GIPS), developer of the iSAC voice codec, for $68.2 million, and on 31 May 2011 Harald Alvestrand announced on the W3C’s public WebRTC list that Google had released WebRTC, an open-source package for real-time voice and video on the web that it would integrate into Chrome. It was published under a BSD license with a patent grant and included GIPS’s iSAC voice codec, VP8 video, echo cancellation and noise suppression.

Standardization split the work in two. The W3C WebRTC Working Group wrote the JavaScript API, publishing its first Working Draft on 27 October 2011, while the IETF’s RTCWEB working group defined the protocols between endpoints, built from existing pieces: ICE, STUN and TURN, DTLS, SRTP and SCTP. The resulting cluster of more than 40 interrelated RFCs came out together in January 2021, and on 26 January 2021 the W3C and IETF jointly announced WebRTC as an official standard, crediting it with carrying video calls through the COVID-19 pandemic.

Work continued on the edges. The W3C published an updated Recommendation with amendments in March 2025, and the IETF standardized WHIP (RFC 9725, March 2025), a simple HTTP-based signaling protocol for one-way ingest: pushing a WebRTC stream from a broadcasting tool into a streaming service or CDN.

Why it’s built this way

Leave signaling to the application
RFC 8825 puts the choice of signaling protocols outside the WebRTC suite, and JSEP hands the offer/answer state machine to JavaScript, so applications can use SIP, XMPP or their own protocol and interwork with legacy SIP devices through a signaling gateway, without a media gateway.
Mandatory DTLS-SRTP encryption
Once ICE checks pass, the endpoints run a DTLS handshake and key SRTP from it, so the channel’s keys aren’t known to any third party and the signaling service can’t mount a passive attack on the media (RFC 8827).
Full ICE with TURN required
Browsers sit behind NATs and firewalls. RFC 8835 requires a full ICE implementation, TURN for NATs that block direct paths, and TURN over TCP and TLS for networks that block UDP, so calls can connect through NATs and UDP-blocking firewalls.
Two mandatory video codecs
To guarantee that any two browsers can talk, RFC 7742 requires both VP8 and H.264 Constrained Baseline, with a note that the working group wants to promote royalty-free codecs.

Timeline

  1. 2011

    Google open-sources WebRTC, built on technology from its purchase of Global IP Solutions

  2. 2011

    First W3C Working Draft of the WebRTC API (27 October)

  3. 2018

    ICE revised as RFC 8445, the NAT traversal protocol WebRTC requires

  4. 2021

    More than 40 RFCs published together and the API becomes a W3C Recommendation (26 January)

  5. 2025

    Updated W3C Recommendation (13 March) and WHIP ingest signaling as RFC 9725

Sources17 · facts checked 13 October 2026

Improve this page on GitHub