Part 1 showed how a call connects. This part opens the box, as of 30 Oct 2026: what encrypts the media, which codecs you get, how bandwidth adapts, and which server shape a group call needs.
TL;DR
- Encryption is mandatory: DTLS-SRTP for media, DTLS for data. Plain RTP is forbidden.
- Every browser must ship VP8, H.264, Opus and G.711. VP9, AV1 and HEVC are extras.
- Congestion control is a de-facto Google algorithm described in expired IETF drafts, not an RFC.
- Group calls: mesh needs no media server, an SFU forwards, an MCU mixes and re-encodes.
- Media security
- DTLS-SRTPRFC 8827: MUST
- Data channels
- SCTP/DTLSRFC 8831
- Video codecs
- VP8 + H.264RFC 7742: MUST
- Audio codecs
- Opus + G.711RFC 7874: MUST
Encryption is mandatory
RFC 8827: "Implementations MUST support DTLS … and DTLS-SRTP", "All media channels MUST be secured via SRTP" and "Media traffic MUST NOT be sent over plain (unencrypted) RTP". Implementations "MUST NOT offer SDP security descriptions" (SDES), the older scheme that put keys in signaling; Chrome removed SDES in M98.
Data channels
RFC 8831 runs data channels as SCTP over DTLS over ICE/UDP. Each channel can be reliable or partially reliable, ordered or unordered; DCEP (RFC 8832) opens them. Chrome removed its old non-standard RTP data channels in M90.
Codecs: the mandatory set and the newer ones
RFC 7742: "WebRTC Browsers MUST implement the VP8 video codec … and H.264 Constrained Baseline". RFC 7874 requires Opus plus G.711 (PCMA/PCMU) for audio.
| Codec | Status |
|---|---|
| VP8 | Mandatory (RFC 7742) |
| H.264 Constrained Baseline | Mandatory (RFC 7742); Chrome since M52 |
| Opus, G.711 | Mandatory audio (RFC 7874) |
| VP9 | Chrome 48+, Firefox (MDN) |
| AV1 | Chrome desktop shipped an AV1 encoder for WebRTC in Chrome 90 |
| HEVC (H.265) | Chrome 136, hardware-only; Safari 18.0 added the RFC 7789 payload format |
Chrome's HEVC note: "we will not provide a software implementation", so it depends on the device. Chrome added a Codec Selection API in M119.
Congestion control and simulcast
WebRTC adapts its bitrate to the network. Google Congestion Control (GCC), combining delay-based and loss-based control, is described in draft-ietf-rmcat-gcc, an expired draft. Its feedback companion, transport-wide congestion control, is also an expired draft, built on "keeping the receiver dumb".
Simulcast (RFC 8853) is "the act of simultaneously sending multiple different encoded streams of the same media source", tagged with a=simulcast and RIDs. SVC layers one stream instead: the W3C WebRTC-SVC Working Draft defines scalabilityMode values such as L1T3 and L3T3, and Chrome shipped SVC in M111. Both let a server send each viewer a fitting quality.
SFU vs MCU vs mesh
Group call
Pick a topology
Mesh
Every peer sends to every other; no media server. By our reading, each sender uploads N−1 copies.
SFU
Selective Forwarding Middlebox: forwards streams, adds little delay, no signal processing. Leans on simulcast/SVC.
MCU
Media-Mixing Mixer: decodes, mixes, re-encodes. Costs quality and latency; each endpoint gets one stream.
No source we trust gives a participant count where mesh breaks; measure your users' uplinks. Discord's 2018 write-up describes a homegrown C++ SFU serving "more than 2.6 million concurrent voice users" on "more than 850 voice servers in 13 regions" (Discord's 2018 figures).
Open-source WebRTC servers
| Project | Describes itself as | License |
|---|---|---|
| mediasoup | "Cutting Edge WebRTC Video Conferencing" | ISC |
| Janus | "Janus WebRTC Server" | GPL-3.0 |
| LiveKit | "End-to-end realtime stack for connecting humans and AI" | Apache-2.0 |
| Jitsi Videobridge | "WebRTC compatible video router or SFU" | Apache-2.0 |
| Pion | "Pure Go implementation of the WebRTC API" | MIT |
| coturn | TURN server | Check the repo |
Vendor claims, not benchmarks: Jitsi says "up to hundreds of conferences per server"; coturn says it "can handle thousands simultaneous calls per CPU (when TURN protocol is used)" and load-balances for scale. Licenses matter as much as features: GPL-3.0 and Apache-2.0 carry different obligations. We wire these servers into products as part of real-time web development. Part 3 covers WHIP, end-to-end encryption and security.
The whole series
- Part 1: What WebRTC is and how a call connects
- Part 2: Encryption, codecs, and SFU vs MCU vs mesh (this post)
- Part 3: WHIP, E2EE, MoQ, security and debugging