Zusammenfassung

  • RFC 3016 machte die RTP-Paketgrenze zu einer Ausfallgrenze: Ein Paket musste nicht nur unter die Path MTU passen, sondern syntaktische Einstiegspunkte und unabhängig wiederherstellbare Einheiten sinnvoll bewahren.
  • Sequenznummer, Zeitstempel und Marker belegten die Transportstruktur. Sie belegten weder vorhandene Konfiguration noch erfolgreiche Decodierung, Darstellung oder Wahrnehmung.

Die übliche Größenprüfung endete an der Path MTU. War das RTP-Paket klein genug, drohte keine IP-Fragmentierung; die Aufgabe schien erledigt. RFC 3016 stellte daneben eine zweite, weniger sichtbare Größe: Wie viele logisch unabhängige Dinge würden mit diesem einen Paket verschwinden?

Der im November 2000 veröffentlichte Standard beschrieb den direkten Transport von MPEG-4 Audio und MPEG-4 Visual über RTP, ohne Synchronisations- und Stream-Management-Funktionen von MPEG-4 Systems. H.323 konnte H.245 verwenden, SIP und RTSP konnten MIME und SDP einsetzen. Das vereinheitlichte die Behandlung mit anderen RTP-Codecs.

Direktabbildung bedeutete jedoch, dass der Packetizer die Grenze zwischen Codecsyntax und Netzwerk festlegte. Er entschied über MTU, Headerplatzierung, Aggregation und Konfigurationswiederholung — also über den Ausfallumfang.

Syntaktische Hierarchie war Teil der Fehlerisolierung

MPEG-4 Visual verfügte über eigene Resilienzwerkzeuge. RFC 3016 fügte deshalb keinen medienspezifischen RTP-Zusatzheader hinzu. Der Bytestrom wurde byte-aligned und ohne Entfernung von Syntaxelementen in den Payload geschrieben.

Die Platzierung blieb geregelt. Konfiguration und Group_of_VideoObjectPlane mussten am Payloadanfang oder unmittelbar nach dem syntaktisch übergeordneten Header stehen. Enthielt der Payload Header, musste er mit dem höchsten beginnen. Ein Header durfte niemals über mehrere RTP-Pakete geteilt werden.

Der Grund war funktional. Ein vollständiger Header bildet einen erneuten Interpretationseinstieg. Zwei Hälften in zwei Datagrammen machen beide voneinander abhängig. Der Verlust einer Hälfte kann die angekommenen Folgedaten semantisch unbrauchbar machen.

RFC 3016 empfahl ein video packet pro RTP packet und eine Größe unter der Path MTU. Bei hoher Verlustrate konnten andere Einheiten mit ihrem Header Extension Code decodierbar bleiben, selbst wenn das Paket mit dem VOP-Header fehlte.

Kleine Einheiten erzeugten dagegen hohen RTP/IP-Anteil. Mehrere video packets durften zusammengefasst werden. Der Standard nannte die Konsequenz: Ein einziger RTP-Verlust verwarf alle zusammengefassten Einheiten.

MTU-Konformität verhinderte damit nur eine Art Fragmentierung. Sie garantierte keine kleine semantische Schadenszone.

Gleiche Paketanzahl, ungleiche Wiederherstellung

Ein verbotenes Beispiel ordnete zwei logische video packets auf zwei RTP packets an. Bei der sauberen Anordnung entfernte der Verlust des zweiten RTP nur die zweite Einheit. Bei der anderen verlief die erste Einheit über die Grenze, der Header der zweiten folgte dahinter, und derselbe Verlust machte beide unbrauchbar.

Zwei Pakete wurden gesendet, eines ging verloren — in beiden Fällen. Nur die Abhängigkeitsposition unterschied sich.

Deshalb beschreibt die Verlustrate nicht allein die Medienwirkung. Eine Sequenzlücke verrät nicht, ob ein isoliertes Fragment, mehrere aggregierte Einheiten, ein Wiedereinstiegsheader oder eine Konfiguration fehlte.

Wenn der Encoder video packets deaktivierte, durfte ein VOP an beliebigen Bytepositionen geteilt werden. Unter einer fehlerfreien Netzannahme konnten feste Stücke funktionieren. In einer verlustbehafteten Umgebung boten sie laut RFC schlechte Resilienz. Eine legale Codereinstellung ersetzte keine Prüfung der Pfadannahme.

Der Marker schloss die Sendereinheit

Bei Visual kennzeichnete das Marker-Bit das letzte oder einzige RTP-Paket eines VOP. Mehrere VOPs in einem Payload führten ebenfalls zu gesetztem Marker; der Zeitstempel gehörte zum frühesten VOP, weitere Zeiten kamen aus internen Headern.

Das half beim Depacketizing. Es war keine Empfangsquittung. Das markierte Paket konnte fehlen, nach einem verlorenen Vorgänger eintreffen, eine vom Decoder verworfene Einheit schließen oder ein Bild erzeugen, das die Anwendung nie zeigte.

RTP allgemein definiert die Sequenznummer zur Lückenerkennung und Reihenfolgewiederherstellung. Der Timestamp bildet den Abtastzeitpunkt und unterstützt Synchronisation; die tatsächliche Präsentation erfolgt später. Der Marker erhält seine Bedeutung vom Payloadformat. Keines dieser Felder bedeutet „erfolgreich angesehen“.

Audio machte Konfiguration zu zeitlichem Zustand

MPEG-4 Audio verwendete LATM. Ein vollständiges oder teilweises audioMuxElement lag direkt im RTP-Payload, sein erstes Byte an dessen Anfang. Ein Element pro Paket war empfohlen; zu große Elemente konnten über mehrere Pakete verteilt werden.

Im In-Band-Modus konnte useSameStreamMux auf die StreamMuxConfig des vorherigen Frames verweisen. Das sparte Wiederholung. Ging der vorherige Frame verloren, konnte der aktuelle trotz vollständiger Ankunft undecodierbar sein. RFC 3016 empfahl daher, die Konfiguration abhängig von den Netzbedingungen zu wiederholen.

Das Wiederholungsintervall war eine Zustands-Haftungsdauer. Je länger es war, desto mehr zukünftige Medien hingen von einem früheren Paket ab. Out-of-Band-Konfiguration über SDP verlagerte die Haftung auf Signalisierung und korrekte Stream-Zuordnung.

Capability und Configuration hatten unterschiedliche Beweislast

profile-level-id konnte bei Visual die unterstützte Profile/Level-Kombination ausdrücken. config beschrieb die konkrete Bitstream-Konfiguration und durfte ausdrücklich nicht als Capability-Angabe dienen.

Ein Decoder konnte die Werkzeugmenge unterstützen und dennoch den aktuellen Zustand nicht besitzen. Gleiches Profile/Level bedeutete nicht identische Konfiguration. Eine gültige SDP-Beschreibung war eine Beschreibung, keine Messung des Pfads oder der Decodierung.

FEC übernahm eine bereits geformte Einheit

RFC 3016 erlaubte Generic FEC nach RFC 2733 und redundante Audiodaten nach RFC 2198. Wenn FEC begann, war aber bereits entschieden, welche logischen Einheiten ein Source-Paket enthielt.

Das trennt die These vom veröffentlichten RFC-2733-Artikel. Dort geht es um Parität, Wiederherstellungsbedingungen, Overhead und Verzögerung. Hier geht es um die vorgelagerte Frage, wie groß das geschützte oder ungeschützte Los überhaupt war.

RFC 2429 zeigt eine andere Codecstrategie: H.263+ verwendete einen Zusatzheader und konnte Picture-Header-Information kopieren, damit ein Paket trotz Verlust des Originals decodierbar blieb. RFC 3016 verließ sich auf MPEG-4-Visual-Werkzeuge. RTP vereinheitlichte das Transportgerüst, nicht den Wiederherstellungsvertrag.

RFC 6416 machte die Versionsgrenze binär

RFC 6416 löste RFC 3016 im Jahr 2011 ab. Es korrigierte vor allem die Abweichung zwischen MPEG-4 Audio und 3GPP PSS. Die nun verlangte LATM-Version war binär inkompatibel mit der von RFC 3016 referenzierten. StreamMuxConfig, SBR, Parametric Stereo, Rate, Kanalzahl und skalierbare Abhängigkeiten wurden überarbeitet.

Einige als RFC-3016-Implementierung bezeichnete Produkte verwendeten bereits neueres LATM und konnten dadurch eher RFC 6416 entsprechen als dem Wortlaut von RFC 3016. Die Protokollnummer war kein Binärfingerabdruck.

Der visuelle Grundsatz blieb: Isolation kostete Header und begrenzte Verlust; Aggregation sparte Header und vergrößerte Verlust.

Kryptographische Echtheit änderte die Ausfallgröße nicht

RFC 3016 übernahm RTP-Sicherheitsfragen und erlaubte Verschlüsselung nach der Kompression. Der auf Audio und Video begrenzte Payload konnte keine MPEG-J-Applets oder Skripte des vollständigen MPEG-4 Systems transportieren.

Vertraulichkeit, Integrität und Quellauthentizität schützen Bytes und Herkunft. Sie ändern keine Path MTU, wiederholen keine verlorene Konfiguration und zerlegen keine aggregierten Einheiten. Ein authentisches Paket kann weiterhin ein zu großer Ausfallbereich sein.

Die historische Stärke des RFC lag darin, keine universelle Paketgröße vorzugeben. Bitrate, Verlust, MTU und Codecwerkzeuge unterschieden sich. Es definierte stattdessen Mindestgrenzen, an denen Interpretation und Wiederherstellung nicht sinnlos beschädigt werden sollten.

Ein Paket konnte alle MTU-Regeln erfüllen. Ob es im Fehlerfall zu groß war, entschied seine innere Abhängigkeit.

Quellen