If you have ever joined a video call in your browser without installing a plugin — Google Meet, Discord on web, Jitsi, Whereby, the millions of telehealth visits during the pandemic — RFC 7742 is one of the small documents that made it possible. It is short (twelve pages) and reads like a checklist, but behind it sits one of the nastiest political fights in the history of the IETF.

The problem. WebRTC, the browser-native real-time media stack, only works if any compliant endpoint can talk to any other compliant endpoint. That means every browser must agree on at least one common video codec. In the 2010s, the obvious candidate was H.264 — universally supported in hardware, beautifully tuned, and absolutely covered in patents. Cisco and Apple shipped it. Mozilla and Google preferred royalty-free VP8, which they had been building into the open web on principle. Neither side would budge. WebRTC nearly stalled.

The compromise. RFC 7742 declares — in the dryest possible language — that both codecs are mandatory to implement for any "WebRTC Browser." Non-browser endpoints (a SIP gateway, a security camera, a bot) only need one of the two. Cisco famously published a free, prebuilt H.264 binary (OpenH264) so that open-source browsers like Firefox could ship H.264 support without paying MPEG LA royalties; Cisco paid those royalties on everyone's behalf up to an annual cap. RFC 7742 is the document that bakes that political settlement into the protocol.

What it actually specifies. Beyond the codec mandate, the RFC lays out the boring-but-essential rules:

• Browsers must be able to decode any resolution up to what the negotiated codec profile allows, including unusual aspect ratios — no rejecting a stream because it's 720x480 instead of 16:9.
• Encoders must adapt rate, resolution, and frame rate dynamically in response to congestion signals (the googRemb and later transport-cc feedback). A WebRTC encoder is not a file encoder; it is a closed-loop control system.
• Orientation must be signalled out-of-band via the CVO RTP header extension (RFC 7741), so a phone rotated mid-call doesn't ship sideways pixels.
• Frame rate is "best effort" — a stalled encoder must not be considered a protocol violation, because real networks stall.

Why it still matters. Every browser-to-browser video call you make today negotiates codecs through SDP using exactly the rules in this RFC. When you open DevTools on a Meet call and see VP8 selected on one leg and H.264 on another, that is RFC 7742 in action: a peer offers both, the other side picks, and a transcoding SFU may bridge mismatched legs. AV1 and VP9 are now layered on top via later documents (RFC 9080 and friends), but the "mandatory two" rule has never been retired — backwards compatibility is forever in real-time media.

The history bit. The IETF debate over WebRTC's mandatory codec ran for roughly three years and produced more mailing-list traffic than almost any working-group fight of its era. The final vote in the RTCWEB WG was a hum, not a tally, and the chairs explicitly framed the outcome as "neither side won, and we are shipping." Adam Roach, then at Mozilla, wrote the document that codified that exhaustion into a standard.