Module 2 — Naming the Session: SDP, SIP, and Offer/Answer

The Module 2 Examination

This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them.— J. Rosenberg & H. Schulzrinne, RFC 3264, 2002

Plan on 90 minutes. Part A is code, graded by the harness with hints disabled and partial credit per assertion. Part B is forensic scenario work. Part C is concepts and history, and — as every exam from this module onward does — it reaches back with two spaced-review questions from Module 1. The pass mark is 80 percent; retakes draw variants of these problems, so understanding beats memorizing the answer key.

AThe repair room

Three session descriptions arrived damaged, each broken in a different layer of the grammar. SDP A has legal lines in an illegal order — the o= line has sunk below s= and t=, which any conforming parser (including the browser's) rejects outright. SDP B has a healthy skeleton but a broken retransmission chain: its RTX payload type declares apt=98, and payload type 98 does not exist in the section. SDP C is an offer/answer pair in which the answer replies to a sendonly video offer with sendrecv — a direction RFC 3264 forbids the answerer to choose. Repair all three. Your repaired SDP A is additionally fed to a live setRemoteDescription() call on a real RTCPeerConnection; the a=ice-ufrag, a=ice-pwd, and a=fingerprint lines it carries are the pointers to ICE and DTLS that Modules 3 and 4 will open — for now, leave them exactly as found.

SDP A — session-level lines out of order.

SDP B — an orphaned RTX apt= reference.

SDP C — the offer (left intact) and the illegal answer.

The second problem is archaeology of a different kind: a loopback call script — the very pattern you built in § 2.5 — seeded with five sequencing bugs. The topology is correct, every API name is correct, and it still cannot connect, because offer/answer is a state machine and the script walks it in the wrong order. Fix the order, nothing else.

Part A — CodingHints disabled · partial credit per assertion

Repair the three descriptions above, then resurrect the loopback script.

A′Interrogate the SFU offer

The description below is the kind a selective forwarding unit sends a subscriber: one Opus-led audio section riding alongside RED and three static-table survivors, a camera video section with VP8, VP9, and two H.264 profiles each dragging an RTX shadow behind an apt= pointer, a second video section for a screen share, and a=ssrc-group:FID lines pairing every primary SSRC with its retransmission SSRC. Ten structured queries follow. Answer them by reading the artifact — a parser is optional; precision is not.

The canned SFU offer, verbatim as passed to your function.

Part A, continued — Forensic readingTen queries, one assertion each

Account for every claim with a specific line of the offer.

BScenario diagnostics

Module 2 gave you a diagnostic axis that will carry you through the rest of this course: the signaling plane (did the descriptions get where they were going?) is not the media plane (did packets flow once they agreed?). The scenarios below are triage. Classify first, then name the artifact you would open — and notice the glare condition at the end, the crossing-offers accident SIP met as crossing INVITEs and that perfect negotiation will later tame.

Part B — ForensicsScenario triage

Five incidents. Decide which plane failed before deciding anything else.

CConcepts, history, and spaced review

Part C closes with the ideas that make the syntax make sense — BUNDLE, msid, the curious port 9, the answerer's obligations — and with SDP's origin story, because knowing that the format predates negotiation explains most of its scar tissue. The final two questions deliberately reach back to Module 1: RTP's framing fields and the choice of UDP are the foundation everything in this module stands on.

Part C — ConceptsIncluding two Module 1 review questions

Seven questions; every explanation cites its source.