Module 4 — The Browser Gets a Dial Tone

The Module 4 Examination

The thinking behind WebRTC call setup has been to fully specify and control the media plane, but to leave the signaling plane up to the application as much as possible.— Uberti, Jennings & Rescorla, RFC 8829 (JSEP), 2021

Plan on 90 minutes. Part A is code, graded by the harness with hints disabled and partial credit per assertion; its centerpiece runs your negotiation logic against three adversarial schedules. Part B is forensic scenario work on canned artifacts. Part C covers concepts and history, and — as every exam from Module 2 onward does — closes with two spaced-review questions, this time reaching back to Modules 3 and 1. The pass mark is 80 percent; retakes draw variants of these problems, so understanding beats memorizing the answer key.

AThe state machine and the glare storm

Every RTCPeerConnection walks the signaling state machine that JSEP grafted onto RFC 3264's offer/answer algebra. Problem 1 asks you to write that machine down: a transition function over stable, have-local-offer, and have-remote-offer that accepts what JSEP accepts and returns null for everything else. The assertions probe the classic wounds — answering your own offer, applying a second answer in stable, a crossing offer arriving in have-local-offer, rollback attempted from stable — and two subtleties that separate reading the spec from guessing: a re-offer legally replaces a pending offer of the same direction, and rollback is legal from both offer-pending states via either set method.

Problem 2 is the module's summit. You implement perfect negotiation — the polite/impolite pattern distilled into the W3C specification's own example code by Mozilla's Jan-Ivar Bruaroey — and the grader runs it on live loopback connections under three schedules: an uncontested round to prove the plumbing, a deterministically crossed pair of offers where the impolite peer must ignore exactly one, and a rude scripted peer that discards every offer you send, forcing your polite side to roll back and answer. A coda swaps in a fresh canvas track with replaceTrack() and asserts that no new description crosses the wire — the no-renegotiation superpower from § 4.3, verified on the wire rather than asserted from memory.

Part A — CodingHints disabled · partial credit per assertion

Write the JSEP state machine, then survive glare against a live adversarial signaler.

A′The trust anchor

Module 4 ended with the reason your calls cannot be wiretapped from the signaling room: keys never ride the SDP. What rides the SDP instead is a certificate fingerprint, and the DTLS handshake — run over the ICE-established path — must present a certificate whose hash matches it. Problem 3 makes you touch every link in that chain. You parse a=fingerprint lines, you derive the DTLS client/server roles from a=setup, and then the harness negotiates a real loopback call and checks your extracted fingerprint against the remoteCertificateId chain in getStats() — the actual security property, tested for real. The final assertion plays attacker: it munges the fingerprint in flight and demands that the connection never reach connected.

Part A, continued — FingerprintsLive verification with a tamper case

Extract the trust anchor, assign the handshake roles, and catch the forgery.

BScenario diagnostics

Two artifacts anchor this part. The first is a 2008-vintage session description of the kind SDES-era VoIP exchanged — read the a=crypto line and remember that every signaling server, session border controller, and lawful-intercept tap on the path could read it too. The second is a Plan B video section: one m=video, two tracks, distinguishable only by their a=ssrc clusters — the layout Chrome spoke between 2013 and 2018 and the source of a generation of interop bugs.

Artifact 1 — an SDES-keyed offer, as logged by a signaling server.

Artifact 2 — a Plan B video section carrying a camera and a screen share.

Part B — ForensicsScenario triage on canned artifacts

Five incidents. Read the artifact before choosing the diagnosis.

CConcepts, history, and spaced review

Part C tests the ideas that make the API's strange shapes make sense: which of the four state machines to believe when they disagree, why replaceTrack() is free while addTrack() costs a negotiation round, what Google actually bought in 2010, and what rollback may and may not undo. The last two questions reach back deliberately: to Module 3, where STUN taught a socket its public name, and to Module 1, where PCM fixed the 64 kbit/s channel that the whole circuit-switched telephone network was built around.

Part C — ConceptsIncluding two spaced-review questions

Seven questions; every explanation cites its source.