Zusammenfassung

  • RFC 3119 verlangte in SDP den Namen mp3, obwohl der registrierte Medientyp und das benachbarte rtpmap-Beispiel mpa-robust verwendeten; RFC 5219 vereinheitlichte den Encodierungsnamen.
  • Der Nachfolger behielt das ADU-basierte RTP-Payload-Design bei und bezeichnete die Pseudocode-Änderungen als kleinere, nicht normative Klarstellungen. Aus dem Standardisierungsprotokoll geht nicht hervor, ob eingesetzte Software den widersprüchlichen Namen verwendete oder eine Sitzung scheiterte.

Zwei Namen im selben Abschnitt

Der Widerspruch lässt sich leicht übersehen. RFC 3119 aus dem Jahr 2001 registriert mpa-robust als Medientyp für sein MP3-Format über RTP. Im Abschnitt zur SDP-Nutzung schreibt das Dokument jedoch den Encodierungsnamen mp3 vor. Direkt darunter weist das Beispiel den dynamischen Payload-Typ 121 zu und enthält a=rtpmap:121 mpa-robust/90000.

Die Zeilen beschreiben dasselbe Format an unterschiedlichen Stellen. RTP überträgt Payload-Typnummern. Bei einer dynamischen Nummer teilt das SDP-Attribut rtpmap dem Gegenüber mit, welcher Encodierung und welcher Taktfrequenz sie entspricht. RFC 4566 definiert diese Zuordnung. RFC 3119 lieferte somit zwei unvereinbare Namen für die Sitzungsbeschreibung, obwohl Medientyp und Zuordnungsbeispiel übereinstimmten.

Das ist mehr als ein Schreibfehler. Eine dynamische Nummer erklärt nicht von selbst, was die Pakete enthalten. Beide Endpunkte benötigen dieselbe Zuordnung zwischen der RTP-Payload-Nummer und dem vom Empfänger erwarteten Format. Der Paketaufbau kann in sich stimmig sein, während die Beschreibung an der Aushandlungsgrenze widersprüchlich bleibt. Das Dokument belegt einen Spezifikationsfehler, nicht das Verhalten eines realen Geräts.

Warum ein anderes RTP-Format entstand

Das ursprüngliche Design reagierte auf eine besondere Eigenschaft von MP3 Layer III. Ein Frame kann auf codierte Daten in früheren Frames zurückverweisen und ist deshalb nicht immer eine unabhängig decodierbare Einheit. RFC 3119 erklärte, dass an Frame-Grenzen ausgerichtete RTP-Pakete beim Verlust eines Pakets auch Daten in anderen, unbeschädigt empfangenen Frames unbrauchbar machen können.

Die Alternative ordnete den Datenstrom in Application Data Units (ADUs) um. Jeder ADU war ein Deskriptor vorangestellt, der Größe und mögliche Fortsetzung aus einem anderen Paket angab. Sender konnten die ADUs zusätzlich verschachteln, sodass aufeinanderfolgende Einheiten in nicht aufeinanderfolgenden Paketen ankamen. Das war nicht einfach zusätzliche Redundanz: Die Paketgrenzen wurden zu den Einheiten verschoben, die der Decoder verarbeitet, während die codierten Daten erhalten blieben.

RFC 5219 vom Februar 2008 behielt diesen Grundansatz bei. Die Einleitung erläutert erneut Rückverweise, ADUs, Deskriptoren und die optionale Verschachtelung. Laut Abstract löst der Text RFC 3119 ab, um Druckfehler im SDP-Abschnitt und in den Pseudocode-Anhängen zu korrigieren. Appendix C präzisiert: Die wichtigste Änderung ist der SDP-Encodierungsname; Appendix A und B enthalten kleinere Korrekturen und Klarstellungen für nicht normativen Pseudocode.

Die Korrektur ist eindeutig. RFC 5219 verlangt mpa-robust passend zum registrierten Medientyp; das Beispiel ordnet den dynamischen Payload-Typ 121 weiterhin mpa-robust/90000 zu. Ein vom RFC Editor bestätigtes Erratum zu RFC 3119 dokumentiert auch den ursprünglichen Widerspruch und mehrere Reparaturen der Beispiele: Ein Backpointer ist ein Wert, keine Größe; eine Variable muss prevADU statt curADU heißen; zwei Arraygrenzen in B.2 ändern sich von 32 auf 256. Diese Änderungen präzisieren die schriftliche Anleitung. Sie belegen nicht, dass sich eingesetzte Payloads 2008 änderten.

Eine RFC-Nummer ist kein Störungsbericht

RFC 5219 zeigt, dass Standards auf mehreren Ebenen nachgebessert werden können. Der SDP-Name gehört zur normativen Anleitung für Sitzungsbeschreibungen: Die Neufassung korrigiert, wie Teilnehmer die Encodierung benennen sollen. Die Änderungen in den Anhängen betreffen dagegen Pseudocode, den RFC 5219 selbst als nicht normativ einordnet. Keiner dieser Befunde misst allein das Ausmaß eines Betriebsproblems.

Die Dokumente enthalten weder eine Implementierungsübersicht noch Paketmitschnitte, Aufzeichnungen fehlgeschlagener Sitzungen, Herstellerhinweise oder Vorher-Nachher-Tests. Sie sagen nicht, dass ein Gerät tatsächlich mp3 ankündigte, dass ein anderes es ablehnte oder dass die korrigierte Schreibweise die Interoperabilität in gemessenen Einsätzen verbesserte. Ein vom RFC Editor bestätigtes Erratum belegt einen Fehler im Dokument, nicht wie oft Software ihn reproduzierte.

Diese historische Grenze muss bestehen bleiben. RFC 5219 ersetzte seinen Vorgänger, weil die Anweisung zur Sitzungsbeschreibung korrigiert und Teile der Implementierungshinweise präzisiert werden mussten. Das ADU-Payload-Modell blieb erhalten. Die Standardisierungsunterlagen zeigen, was die Autoren korrigierten; für Aussagen über reale Systeme wären separate Belege aus Implementierungen und Sitzungen nötig.

Quellen

  1. https://www.rfc-editor.org/rfc/rfc3119.html
  2. https://www.rfc-editor.org/info/rfc3119/
  3. https://www.rfc-editor.org/rfc/rfc5219.html
  4. https://www.rfc-editor.org/info/rfc5219/
  5. https://datatracker.ietf.org/doc/rfc5219/
  6. https://www.rfc-editor.org/errata/eid331
  7. https://www.rfc-editor.org/rfc/rfc4566.html
  8. https://www.rfc-editor.org/rfc/rfc2250.html
  9. https://www.rfc-editor.org/rfc/rfc3550.html
  10. https://www.rfc-editor.org/rfc/rfc3551.html
  11. https://www.rfc-editor.org/rfc/rfc2736.html