§ 4.4  Module 4 — The Browser Gets a Dial Tone

Plan B, Unified Plan, and the ORTC Rebellion

The nice thing about standards is that you have so many to choose from.— Andrew S. Tanenbaum, Computer Networks, 1981

4.4.1The multi-stream trigger

SDP was designed in the 1990s (RFC 2327, 1998, Mark Handley and Van Jacobson) to announce multicast conference sessions, and its unit of description is the media section: a block beginning with an m= line that names a media type, a port, and a codec list. The offer/answer model (RFC 3264, June 2002, Rosenberg and Schulzrinne) layered negotiation on top: an answer must contain exactly as many m= sections as the offer, in the same order, accepting or rejecting each. For a 2011-era WebRTC call — one audio track, one video track — the mapping was trivial: one m=audio, one m=video, done.

Two use cases broke the mapping at once. First, screen sharing: a second video track in the same call. Second, and more forcefully, the SFU. As services like Google Hangouts (2013) and Jitsi Videobridge (2013) moved from mixing MCUs to forwarding SFUs — a shift Module 7 treats in depth under media topologies — each receiver suddenly needed to accept N remote video tracks, one per visible participant, and the set changed every time someone joined. SDP now had to describe a dynamic, many-track session, and RFC 3264's rigid section-matching made every track change a renegotiation. The question of where tracks live in SDP stopped being aesthetic and became the load-bearing wall of the standard.

Every RTP stream already carried a 32-bit synchronization source identifier — the SSRC, defined in RTP itself (RFC 3550, 2003) — that distinguished it from other streams on the same socket. The dispute was whether SSRCs or m= sections should be the unit that carries a track.

4.4.2Plan B: many SSRCs, one m-section

Uberti's Plan B kept exactly one m= section per media type and enumerated tracks as a=ssrc attribute lines inside it. Each SSRC line carried an msid value naming the MediaStream and track the SSRC belonged to. Two video tracks looked like this:

m=video 9 UDP/TLS/RTP/SAVPF 96 97
a=mid:video
a=ssrc:11111 cname:host4User
a=ssrc:11111 msid:camStream camTrack
a=ssrc:22222 cname:host4User
a=ssrc:22222 msid:screenStream screenTrack

Listing 4.7 — A Plan B video section: two tracks multiplexed as two SSRCs in a single m=video block.

The virtues were real. SDP stayed small: an SFU conference with forty video tracks still produced one m=video section, and adding or removing a participant changed only a=ssrc lines, which Chrome could process without a full renegotiation round trip. For Google, whose Hangouts SFU was the largest WebRTC deployment on earth, this was the point.

The costs were structural. Everything SDP can only say per m= section — codec choice, bandwidth caps, direction (a=sendonly, a=recvonly), header extensions — became impossible to say per track. You could not send the camera in VP8 and the screen share in a codec tuned for text, could not pause one track at the SDP level, could not give the screen share its own bandwidth budget. And Plan B was unreadable to the installed base: a SIP video phone or gateway parsing RFC 3264-style SDP sees one m=video section, picks one SSRC, and silently discards the rest.

4.4.3Unified Plan: one m-section per track

Unified Plan made the opposite trade: every track gets its own m= section, identified by a mid and labeled with a media-level a=msid line. The same two tracks become two sections:

m=video 9 UDP/TLS/RTP/SAVPF 96 97
a=mid:1
a=msid:camStream camTrack
a=sendrecv

m=video 9 UDP/TLS/RTP/SAVPF 98
a=mid:2
a=msid:screenStream screenTrack
a=sendonly

Listing 4.8 — The Unified Plan equivalent: one m=video section per track, each with its own mid, codecs, and direction.

Per-track expressiveness returns immediately — the screen share above negotiates its own codec list and its own a=sendonly direction — and legacy SIP equipment can parse the result, because one-section-per-source is how pre-WebRTC SDP already worked. The obvious objection, that N tracks would demand N ports and N ICE negotiations, was answered by BUNDLE (eventually RFC 8843): all m= sections share a single transport — one ICE agent, one DTLS-SRTP session — and the mid, carried in an RTP header extension, routes packets to sections. The m= line's port number becomes ceremonial. The price is bulk: SDP for a large conference runs to hundreds of kilobytes of text, and every added track is a new section, which is why the working group's answer to scale ultimately routed around SDP growth with simulcast and SVC rather than more sections. Unified Plan was folded into JSEP, the specification of how browsers generate and consume SDP, and Mozilla shipped it first: Firefox 38 (May 2015) did multi-stream Unified Plan against Jitsi Videobridge while Chrome was still Plan B–only.

4.4.4The ORTC rebellion

To one faction the Plan fight proved a deeper point: the mistake was not how to write tracks into SDP but that a text blob designed in 1998 was the API surface at all. ORTC — Object Real-Time Communications, organized as a W3C Community Group in August 2013 by Robin Raymond of Hookflash with Bernard Aboba of Microsoft as a driving editor — proposed a WebRTC with no SDP and no offer/answer state machine. Every layer the SDP blob smuggled past you became a constructible JavaScript object: an RTCIceGatherer collects candidates, an RTCIceTransport runs connectivity checks, an RTCDtlsTransport rides on it, and RTCRtpSender and RTCRtpReceiver objects are told what to send with plain dictionaries — sender.send({ encodings: [...], codecs: [...] }) — rather than by munging text. Nothing forced two ends to negotiate in lockstep; you exchanged whatever parameters you liked, however you liked. Microsoft, which had never shipped WebRTC in Internet Explorer, made ORTC its bet: Edge shipped the ORTC API in September 2015, and for several years the interoperability story between Edge and Chrome ran through adapter.js shims translating objects to SDP and back.

ORTC failed as a standalone standard — no other browser implemented it, and the network effect of a Chrome- and Firefox-compatible API was decisive — but it won as an influence, and the W3C working group absorbed its object model into WebRTC 1.0 during the 2016 restructuring of the spec. The absorption is visible every time you touch the modern API. RTCRtpSender and RTCRtpReceiver are ORTC objects, grafted onto RTCPeerConnection. The RTCRtpTransceiver you met in §4.3 is the bridge artifact itself: an ORTC-style object whose one job is to correspond to an m= section, pairing a sender and receiver under a shared mid. sender.getParameters() and setParameters() — the sanctioned way to change encodings, set bitrate caps, and control simulcast layers without renegotiating — are ORTC's parameter dictionaries verbatim. Even the transports surfaced: sender.transport is an RTCDtlsTransport, its iceTransport attribute an RTCIceTransport, and the datachannel stack exposes an RTCSctpTransport, objects you can inspect for state even though the browser, not your code, still constructs them. WebRTC 1.0, published as a W3C Recommendation on January 26, 2021, is therefore a hybrid: JSEP's SDP offer/answer engine on the outside, ORTC's object skeleton on the inside.

4.4.5The migration era: sdpSemantics

Standards choose; shipped code lingers. Chrome had carried Plan B since 2013, and thousands of applications had parsed, munged, and stored Plan B SDP. Google's migration ran on a constructor flag: Chrome 69 (September 2018) added sdpSemantics so applications could opt in early, and Chrome 72 (January 2019) flipped the default.

// The migration-era escape hatches, now historical:
new RTCPeerConnection({ sdpSemantics: 'plan-b' });       // Chrome-only, removed 2021
new RTCPeerConnection({ sdpSemantics: 'unified-plan' }); // the default since Chrome 72

Listing 4.9 — The sdpSemantics flag that governed Chrome's 2018–2021 transition. It never existed in Firefox or Safari, which were Unified Plan from the start.

Plan B was removed outright in Chrome 93 (September 2021), with a temporary deprecation trial for stragglers that expired at the end of that year. The legacy pair addStream()/onaddstream — stream-oriented APIs that made sense when a stream mapped to SSRC lines — gave way to addTrack(), addTransceiver(), and the track-oriented ontrack event, which hands you the transceiver and therefore the mid.

For the engineer, the era's lasting deliverable is a diagnostic reflex, because plan-mismatch bugs had a signature unlike anything else: silent partial success. A Plan B endpoint offering two video tracks to a Unified Plan endpoint produced one m=video section; the receiver fired ontrack once and the second participant's video simply never existed — no exception, no failed state, connectionState happily connected. In the reverse direction, a Unified Plan multi-video offer hit a Plan B answerer that expected at most one video section and either rejected the extras or threw setRemoteDescription errors about the m= line count. The debugging heuristics are textual and mechanical, which is exactly why Exercise 1 has you build the detector: multiple distinct msid values inside one m= section is positive proof of Plan B; one section per track with media-level a=msid lines is Unified Plan; and a single-track-per-type call is indistinguishable — both dialects emit the same SDP, which is why simple calls interoperated for years while multiparty calls burned. One trap: multiple a=ssrc lines alone prove nothing, because Unified Plan sections legitimately carry two SSRCs for one track — the retransmission (RTX) pair declared by a=ssrc-group:FID. Count distinct tracks, not SSRCs.

4.4.6What the fossil record teaches

Read as a whole, the 2013–2021 arc explains most of the API's apparent redundancy. Why do addTrack and addTransceiver both exist? Because one is the legacy stream-era verb and one is the ORTC-shaped section-era verb. Why does ontrack deliver streams arrays and a transceiver? Because msid keeps MediaStream grouping alive inside a per-track world. Why is there both renegotiation and setParameters? Because the working group kept JSEP's offer/answer for anything that changes the section structure, and adopted ORTC's dictionaries for anything that does not. The lesson that follows takes the remaining sharp edge of that compromise — two sides renegotiating at once, the glare problem — and shows the pattern that finally tamed it.

Checkpoint for § 4.4.5Spot the symptom

Three quick scenario reads before the anchor problems — each describes a real migration-era failure.

Problems for § 4.4Check your understanding

Build the forensic tool this lesson kept promising, then face the standards history head-on.

¶Field quirks

What the specifications say, and what the browsers actually do, are two different documents. These are the divergences that cost production teams their weekends.