Zusammenfassung

  • SDP kennt zwei verschiedene Versionen: v=0 bezeichnet die Protokollfassung, während sess-version in o= steigt, sobald sich eine identifizierte Session-Beschreibung ändert.
  • Die Zahl gilt nur innerhalb des Origin-Tupels. Ein Vergleich zwischen Origins oder die Deutung einer zeitstempelähnlichen Zahl als beglaubigte Zeit vernichtet den Herkunftsnachweis.

Der größte Wert war nur lokal der größte

Bei einem Failover kann ein Ersatzcontroller mit einer höheren oder niedrigeren Zahl beginnen als sein Vorgänger. Jedes Erzeugungswerkzeug verwaltet seine eigene Folge. Der RFC verteilt keinen globalen Zähler an alle SDP-Autoren, und ein anderer Host verändert einen Teil der Identität, bevor die Version verglichen werden darf.

Die Datenbankformel session_id + max(version) wirkt elegant. Sie verschmilzt jedoch Erzeugerreihenfolge, Empfangszeit und Berechtigung zur Nachfolge. Später empfangen heißt nicht später revidiert. Höher nummeriert heißt nicht autorisiert. Autorisiert heißt noch nicht vom Gegenüber angenommen.

v=0 ist nicht Revision null des Gesprächs

RFC 8866 beginnt jede Beschreibung mit v=0. Das Feld nennt die Version des Session Description Protocol; eine Minor-Version gibt es nicht. Ein neuer Videostrom, ein anderer Codec oder eine neue Medienadresse machen daraus kein v=1.

Die Pflichtzeile o= enthält Username, Session-ID, Session-Version, Netztyp, Adresstyp und Unicast-Adresse. sess-version gehört zur Revision der Beschreibung. Das erzeugende Werkzeug muss sie bei Änderungen erhöhen; ein Zeitstempel wird als Zuteilungsverfahren empfohlen.

Wer die Felder verwechselt, kann in beide Richtungen irren. Ein erhöhtes v= behauptet ein neues Protokollformat. Geänderte Bytes bei unveränderter sess-version behaupten dieselbe Revision für verschiedene Zustände. Beide Werte gehören ins Inventar, aber nicht in dieselbe Semantik.

Fünf Werte benennen, der sechste ordnet

Nach RFC 8866 bilden Username, Session-ID, Netztyp, Adresstyp und Unicast-Adresse gemeinsam den weltweit eindeutigen Session-Identifier. Kein Einzelwert genügt. Dieselbe Session-ID auf einem anderen Host übernimmt keine Historie. Ein Username authentifiziert keine Person. Eine geänderte Adresse ist nicht automatisch eine Fortsetzung.

RFC 2327 erklärte die ursprüngliche Aufgabe präzise. Handley und Van Jacobson schrieben, die Version helfe Proxy-Ankündigungen, unter mehreren Ankündigungen derselben Session die jüngste zu erkennen. „Derselben Session“ begrenzt den Vergleich. Erst Identität, dann Reihenfolge.

Ändert ein geplanter Controllerwechsel das Tupel, braucht er einen eigenen Migrationsbeleg: alte und neue Origin, genehmigende Stelle, Wirksamkeitszeit, übernommener Zustand und Rückweg. Eine größere Ganzzahl autorisiert den Übergang nicht.

Bei Offer/Answer bindet dieselbe Version denselben Inhalt

RFC 3264 verschärft die Regel für eine ändernde Offer. Die neue o=-Zeile bleibt gegenüber dem vorherigen SDP identisch, nur die Version steigt um eins. Steigt sie nicht, muss der SDP-Inhalt mit dem bisherigen Inhalt dieser Version identisch sein. Eine unveränderte Wiederholung ist effektiv ein No-op, verlangt aber weiterhin eine gültige Answer.

Daraus folgt eine harte Konsistenzprüfung. Gleiche Origin, gleiche Version und andere Bytes sind keine harmlose Wiederholung. Beide Originale und Hashes müssen erhalten, die Linie als widersprüchlich markiert und die lokale Fehlerpolitik angewendet werden. „Letzter Eingang gewinnt“ würde den Beweis löschen.

Eine höhere Version beweist umgekehrt nur, dass der Erzeuger eine Änderung erklärt hat. Sie beweist weder Annahme noch RTP-Verkehr noch nutzbare Medien.

Ein Zeitstempelformat beglaubigt keine Uhr

RFC 8866 empfiehlt für die Session-ID Sekunden seit dem 1. Januar 1900 UTC und auch für sess-version einen Zeitstempel. Das hilft einem Erzeuger, unterscheidbare und steigende Dezimalwerte zu bilden. Es belegt keine Uhrensynchronisation, Empfangszeit oder organisatorische Befugnis.

Die Sicherheitsanforderung steht an anderer Stelle: Eine Beschreibung ist nur vertrauenswürdig, wenn sie von einer bekannten, vertrauenswürdigen Quelle über einen authentifizierten und integritätsgeschützten Transport erlangt wurde. Ein belastbarer Beleg verbindet daher das deklarierte Origin-Tupel mit Transport-Principal und Integritätsergebnis.

SAP setzt ein anderes Änderungszeichen

RFC 2974 gibt dem Session Announcement Protocol eigene Felder für originating source und message identifier hash. Ändert sich der Hash, soll der Empfänger geänderten Ankündigungsinhalt erneut auswerten. Das eingebettete SDP behält Origin und Session-Version. Ein Signal der Verteilungsschicht ist keine Dokumentenlinie.

SDP ist ausdrücklich ein Beschreibungsformat, kein Transportprotokoll, und führt allein keine Aushandlung von Inhalt oder Kodierung durch. SIP Offer/Answer kann es begrenzt dafür einsetzen; SAP, HTTP oder E-Mail können es transportieren. Empfang, Identität, Aushandlung und Medienergebnis bleiben verknüpfbar, aber getrennt.

Mark Handley steht in einer gemeinsamen Autorenlinie

RFC 2327 nennt Mark Handley und Van Jacobson. RFC 4566 nennt Handley, Jacobson und Colin Perkins. Der aktuelle RFC 8866 stammt von Ali Begen, Paul Kyzivat, Perkins und Handley. SDP ist gemeinschaftlich fortgeschriebene Standardisierung und kein Solowerk.

Die Royal Society führt Handley als Professor of Networked Systems am UCL, Autor zahlreicher Internetstandards und früheres Mitglied des Internet Architecture Board. ACM SIGCOMM würdigte ihn 2019 für Beiträge zu Internet-Multimedia, Multicast, Congestion Control, Multipath-Netzen und Protokollstandardisierung.

Welche Aussage die Version trägt

Mit vollständiger Identität, exakten SDP-Bytes und vertrauenswürdigem Erwerbsbeleg stützt sess-version eine begrenzte Aussage: Dieser Erzeuger kennzeichnete die Beschreibung als spätere Revision derselben Session. Im RFC-3264-Kontext deckt sie auch unterschiedlichen Inhalt unter derselben Version oder eine Änderung ohne Erhöhung auf.

Sie belegt keine berechtigte Nachfolge, korrekte Uhr, Senderautorität, Annahme, Paketzustellung oder Servicequalität. Dafür braucht es Migration, Transportauthentisierung, Offer/Answer-Belege, Netzbeobachtung und Ergebnisprüfung.

Quellen