Zusammenfassung

  • Die SDP-Zeile o= verbindet ein stabiles Identitätstupel mit einer getrennten sess-version; eine neue Beschreibung kann zur selben Sitzung gehören.
  • Allgemeines SDP verlangt eine höhere Version bei Änderungen. Offer/Answer ist enger: Ein geändertes Angebot behält den Origin bis auf +1 bei, eine wiederholte Version muss identische SDP-Bytes tragen.
  • Die größere Zahl hilft gegen veraltete Beschreibungen. Sie authentisiert niemanden, nimmt kein Angebot an und beweist weder Zustimmung noch Medienfluss.

Eine Sitzung brauchte zwei Arten von Kontinuität

Multimedia-Sitzungen überleben einzelne Beschreibungen. Ein Termin verschiebt sich, Video kommt hinzu, Audio wird gehalten oder eine Empfangsadresse ändert sich. Würde jede Bearbeitung eine neue Identität erhalten, ginge der Zusammenhang verloren. Bliebe nur eine feste Identität ohne Revision, könnte eine alte Ankündigung eine neuere verdrängen.

SDP setzte beide Antworten in die Origin-Zeile:

o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>

Username, Sitzungs-ID, Netz- und Adresstyp sowie Origin-Adresse bilden die Sitzungslinie. sess-version ordnet Beschreibungen innerhalb dieser Linie. Erst wenn das vollständige Tupel übereinstimmt, ist der Versionsvergleich sinnvoll. Gleiche IDs unter verschiedenen Origins erzeugen keine gemeinsame Geschichte.

Origin war kein Ausweis

Der Username kann ein Login sein, aber auch . Die heutige Spezifikation erlaubt aus Datenschutzgründen einen beliebigen Namen und eine private Origin-Adresse, solange das Gesamttupel eindeutig bleibt.

Die Zeile ist deshalb Namespace, nicht Beglaubigung einer Person, Organisation oder Maschine. Die Origin-Adresse muss nicht das Medienziel sein. Ein NTP-ähnlicher Timestamp für sess-id ist eine Empfehlung gegen Kollisionen, kein Beweis für richtige Uhrzeit, Erstellungszeit oder Adressbesitz.

Wer gesendet hat, ob die Nachricht unverändert ankam und ob die Quelle Änderungen vorschlagen darf, muss die umgebende Signalisierung entscheiden.

Revision blieb eine lokale Auswertung

Ändert sich die Beschreibung, erhöht der Ersteller sess-version. Ein Empfänger kann Tupel, Version und Fingerprint der akzeptierten Fassung speichern und verhindern, dass eine verspätete ältere Kopie sie ersetzt.

Dafür braucht es keinen weltweiten Revisionsdienst. Die Aussage bleibt relativ: Allgemeines SDP verlangt Erhöhung, nicht überall genau +1; ein timestampförmiger Wert ist keine Zivilzeit; Versionen verschiedener Origins besitzen keine gemeinsame Ordnung.

Auditierbar ist nicht „Version 42 gesehen“, sondern: In diesem Signalisierungskontext wurden für dieses Origin-Tupel genau diese Bytes als Version 42 empfangen und lokal so behandelt.

Offer/Answer verschärfte den Vertrag

SDP begann als Beschreibungsformat. Offer/Answer definierte, wie zwei Agents eine gemeinsame Sicht herstellen, und überließ Transport, Kontext, Reihenfolge, Ablehnung und gleichzeitige Angebote einem höheren Protokoll wie SIP.

Ändert ein Agent sein früheres Angebot, bleibt die neue o=-Zeile bis auf die um eins erhöhte Version identisch. Die stabilen Felder erhalten die Linie; der einzelne Schritt bezeichnet die nächste Revision dieses Agents.

Bleibt die Version gleich, muss das SDP identisch mit dem Text dieser Version sein. Ein unverändertes Angebot darf als No-op wiederholt werden und verlangt weiterhin eine gültige Antwort. Neue Bytes unter alter Version sind hingegen unzulässig.

Zwei unterschiedliche Texte mit demselben (Origin, Version) sind daher widersprüchliche Belege, keine gleichwertigen Varianten. Die Ankunftsreihenfolge behebt den Konflikt nicht.

Offer/Answer begrenzt ID und Version außerdem auf darstellbare signed 64-bit integers und hält die Anfangsversion unter 2^62 - 1, um Rollover zu vermeiden. Das ist eine Grenze dieses Modells, keine universelle SDP-Ringarithmetik.

Die nächste Revision blieb ein Vorschlag

Die Zahl nimmt die Änderung nicht an. Der Answerer kann kompatible Streams auswählen, andere ablehnen oder das gesamte Angebot über die Signalisierung zurückweisen. Bei Ablehnung gilt wieder der frühere Beschreibungszustand.

Auch Konkurrenz wird nicht durch den höchsten Wert entschieden. Ein Agent darf kein neues Angebot senden, solange er auf eine Antwort wartet oder dem Peer eine Antwort schuldet. Gleichzeitige Angebote erzeugen Glare; das höhere Protokoll löst ihn. sess-version ist kein distributed lock.

Eine gültige Antwort belegt nur beschreibende Einigung. Sie beweist nicht, dass Pakete ankamen, der Codec lief, eine Firewall öffnete, ein Mensch zustimmte, eine Aufnahme rechtmäßig oder ein Dienst abgeschlossen war.

Frische erzeugte kein Vertrauen

Auch ein Angreifer kann eine riesige Zahl wählen. Deshalb stützt sich Offer/Answer auf End-to-End-Authentisierung und Integrität des Signalisierungsprotokolls. Der Empfänger behält Admission und Zustimmung als lokale Entscheidungen.

Authentisierung nennt die anerkannte Quelle, Integrität schützt den Transport, Origin behauptet die Linie, Version behauptet die Revision, Offer/Answer hält Vorschlag und Entscheidung fest, Medientelemetrie misst Wirkung. Kein Beleg ersetzt einen anderen.

SDPs dauerhafte Leistung war somit keine souveräne Zahl. Die Trennung von Identität und Änderung erlaubte jedem Ende, alte Beschreibungen ohne zentrale Behörde zu erkennen und dennoch selbst zu entscheiden, ob eine neue Beschreibung gelten darf.

Quellen und Beweisgrenzen

Die normative Kette bilden RFC 2327, RFC 4566, RFC 8866 und RFC 3264. Sie belegen Grammatik und Offer/Answer-Regeln, nicht heutige Produktkonformität, die Identität eines Live-Senders oder erfolgreiche Medienzustellung.