Zusammenfassung

  • Das 24-Bit-Ident in RFC 5215 ordnet Vorbis-Nutzdaten einer Decodier-Configuration zu. Der Index belegt die Auswahl des Senders, aber weder Empfang noch Prüfung oder Installation der referenzierten Codebooks.
  • Ändert sich das Ident und fehlt die richtige Configuration, darf der Client die zugehörigen Rohdaten nicht decodieren. Null Paketverlust kann deshalb mit korrektem Schweigen des Decoders zusammenfallen.

Zwei grüne Anzeigen, kein Ton

Der Netzbericht war sorgfältig erstellt. Nach dem Programmwechsel fehlte keine RTP-Sequenznummer, die Laufzeiten blieben stabil, sämtliche Audionutzdaten erreichten den Empfänger. Auch der Player-Bericht war korrekt: Im selben Zeitraum entstand kein einziges abspielbares Sample.

Zwischen beiden Befunden lag ein Objekt, das in der üblichen Paketquote kaum Gewicht hatte. Mit dem Programm war das Ident gewechselt. Die dafür benötigte Configuration wurde fragmentiert übertragen; ein Fragment fehlte. Die nachfolgenden Rohpakete kamen lückenlos an, doch ihr Decodiermodell blieb unvollständig.

RFC 5215 verlangt in diesem Fall Zurückhaltung. Erkennt ein Client ein neues Ident und besitzt die passende Configuration nicht, darf er die verbundenen Vorbis-Daten erst nach deren Beschaffung decodieren. Das Schweigen war kein Widerspruch zur erfolgreichen Übertragung, sondern die normative Folge einer nicht erfüllten Vorbedingung.

Die Adresse eines Modells ist nicht das Modell

Vorbis verwendet kein statisch vorkonfiguriertes Wahrscheinlichkeitsmodell. Entropiedecodierung, Vektorquantisierung und Huffman-Modelle werden in einem stromspezifischen Block übermittelt. Hinzu kommen Informationen wie Kanalzahl und weitere Parameter, die den Decoder auf den konkreten Strom einstellen.

Identification und Setup müssen vor den Audioframes vorhanden sein. Der Comment-Header gehört zur Vorbis-Struktur, ist für die Frame-Decodierung jedoch entbehrlich und darf in der gepackten Darstellung durch eine Attrappe ersetzt werden. Damit trennt die Norm sichtbare Metadaten von der unscheinbaren Konfiguration, die den Betrieb tatsächlich ermöglicht.

Das Ident macht die Zuordnung effizient. Statt die umfangreichen Daten in jedem Paket zu wiederholen, trägt die Nutzlast einen 24-Bit-Verweis. Eine Sitzung kann dadurch auch auf neue Codebooks oder verkettete Inhalte wechseln.

Der Verweis übernimmt aber nicht die Eigenschaften seines Ziels. Sein Empfang beweist nicht, dass alle Konfigurationsfragmente eingetroffen sind, die Header erfolgreich geparst wurden oder im Decoder dieselben Bytes unter diesem Ident liegen. Ein Monitoring, das Ident, payload type, Taktrate, Kanäle und Paketquote zu einem Gesamtstatus verdichtet, verdeckt genau diese Grenze.

SDP beschreibt die Absicht, nicht den installierten Zustand

Über rtpmap kann SDP Vorbis, Taktrate und Kanalzahl ankündigen. RFC 5215 bezeichnet diese Angaben als Hinweise, denn die exakten Informationen liefert die Configuration. Der Parameter configuration ist in fmtp vorgeschrieben; für einen nicht verketteten Strom wird die Packed Configuration im anfänglichen SDP empfohlen.

Während einer Sitzung kann sich der Zustand ändern. Neue Codebooks lassen sich im RTP-Strom, mit einer neuen Sitzungsbeschreibung oder über einen externen Bezug übertragen. In-Band-Aktualisierung muss unterstützt werden, Out-of-Band-Aktualisierung sollte unterstützt werden. Der RTP-Zeitstempel der Configuration markiert das erste Datenpaket, für das sie gilt.

Dieser Zeitpunkt grenzt Geltung ab. Er quittiert keinen Empfang. Der Sender kann den Wechsel ordnungsgemäß angekündigt haben, ohne zu wissen, ob jeder Empfänger die neue Configuration rechtzeitig installiert hat.

Der seltene Block entscheidet über die Masse

Konfigurationsdaten können mehrere Kilobyte groß sein und fragmentiert werden. Clients müssen Fragmente und periodische Wiederholung beherrschen. Geht ein Rohdatenpaket verloren, fehlt ein Stück Signal. Geht ein Configuration-Fragment verloren, kann der gesamte nachfolgende Strom unter diesem Ident undekodierbar werden.

Eine nach Paketmenge gewichtete Verfügbarkeit bewertet die Lage falsch herum. Tausende kleine erfolgreiche Übertragungen lassen das einzelne fehlende Objekt statistisch verschwinden. Funktional besitzt gerade dieses Objekt die Deutungshoheit über alle übrigen.

Der Empfänger kann erneut anfordern, eine externe Quelle verwenden, auf Wiederholung warten oder Rohdaten puffern. Als Grundreaktion kommen auch Reset oder Sitzungsende in Betracht. Jeder Weg hat eine andere Wirkung: Späte Wiederherstellung kann eine Aufzeichnung retten und zugleich das Echtzeitziel verfehlen. Ein Reset kann Ton zurückbringen und die Ursache aus dem flüchtigen Zustand löschen.

Eine Quittung für Decodierbefugnis

Ein belastbarer Nachweis verbindet die Offer/Answer-Generation, SSRC und payload type mit dem Hash der Packed Configuration. Er bindet das Ident an die Hashes von Identification und Setup sowie an den ersten geltenden RTP-Zeitstempel.

Danach muss er den Lieferweg, die Vollständigkeit aller Fragmente, Parsergebnis und Installationszeit beim Empfänger erfassen. Die tatsächlich verwendete Zuordnung von Ident zu Configuration-Hash ist wichtiger als die Ankündigung des Senders. Während des Mangels gehören gepufferte oder verworfene Pakete, Wiederholungsversuche und externe Abrufe ins Protokoll. Erstes decodiertes Frame, Samples an die Wiedergabe und beobachteter Ausgang schließen die Kette.

Diese „Quittung für Decodierbefugnis“ ist eine redaktionelle BTW-Empfehlung, keine Ergänzung zu RFC 5215. Sie hält die Zuständigkeit der Belege auseinander: RTP spricht für Transport, SDP für Verhandlung, Ident für Auswahl, der installierte Zustand für Decodierfähigkeit und der Ausgang für erbrachte Wirkung.

Heng Lus Prinzip des running code liefert den Maßstab. Eine sichtbare Erklärung wird erst dort operativ, wo die ausführende Komponente sie konsumiert. Ein Ident in jedem Paket kann keine fehlenden Codebooks vertreten. Transportdaten dürfen den Zustand eines Decoders nicht stellvertretend beschließen.

Die bessere Führungskennzahl lautet deshalb nicht nur „Wie viele Pakete kamen an?“, sondern „Welcher Beleg zeigt, dass der betreffende Decoder sie vor Ablauf der Wiedergabefrist interpretieren konnte?“

Quellen

  1. RFC 5215
  2. IETF Datatracker — RFC 5215
  3. RFC-5215-Information
  4. Dokumenthistorie
  5. RFC 3550 — RTP
  6. RFC 4566 — SDP
  7. RFC 3264 — Offer/Answer
  8. RFC 4588 — RTP-Wiederholung
  9. RFC 3611 — RTCP XR
  10. RFC 3533 — Ogg-Kapselung
  11. RFC 4648 — Base-Codierungen
  12. RFC 3986 — URI
  13. RFC 3551 — RTP-Profil
  14. RFC 1191 — Path MTU
  15. RFC 1981 — IPv6 Path MTU
  16. Vorbis-I-Spezifikation
  17. RFC 8088 — RTP-Schutzschalter
  18. RFC 8866 — SDP
  19. Heng Lu — Vorrang des running code