5. RTP Data Transfer Protocol (RTP-Datenübertragungsprotokoll)

5.1 RTP Fixed Header Fields (Feste RTP-Header-Felder)

Der RTP-Header hat folgendes Format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           synchronization source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            contributing source (CSRC) identifiers             |
|                             ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Die ersten zwölf Oktette sind in jedem RTP-Paket vorhanden, während die Liste der CSRC-Identifikatoren nur dann vorhanden ist, wenn sie von einem Mischer eingefügt wird. Die Felder haben folgende Bedeutung:

• Version (V) : 2 Bits. Dieses Feld identifiziert die RTP-Version. Die durch diese Spezifikation definierte Version ist zwei (2). (Der Wert 1 wird von der ersten Entwurfsversion von RTP verwendet und der Wert 0 von dem ursprünglich im Audio-Werkzeug „vat" implementierten Protokoll.)

• Füllung (P, Padding) : 1 Bit. Falls das Füllbit gesetzt ist, enthält das Paket ein oder mehrere zusätzliche Fülloktette am Ende, die nicht zum Nutzlastinhalt gehören. Das letzte Fülloktett enthält eine Zählung der zu ignorierenden Fülloktett-Anzahl, einschließlich seiner selbst. Füllung kann für einige Algorithmen mit festen Blockgrößen zur Verschlüsselung oder zum Transport mehrerer RTP-Pakete in einer Einheit der unteren Protokollebene erforderlich sein.

• Erweiterung (X) : 1 Bit. Falls das Erweiterungsbit gesetzt ist, muss dem festen Header genau eine Header-Erweiterung folgen, deren Format in Abschnitt 5.3.1 definiert ist.

• CSRC-Zähler (CC) : 4 Bits. Der CSRC-Zähler enthält die Anzahl der CSRC-Identifikatoren, die dem festen Header folgen.

• Marker (M) : 1 Bit. Die Interpretation des Markers ist durch ein Profil definiert. Er dient dazu, signifikante Ereignisse wie Rahmengrenzen im Paketstrom zu markieren. Ein Profil kann zusätzliche Marker-Bits definieren oder festlegen, dass kein Marker-Bit vorhanden ist, indem es die Anzahl der Bits im Nutzlasttypfeld ändert (siehe Abschnitt 5.3).

• Nutzlasttyp (PT, Payload Type) : 7 Bits. Dieses Feld identifiziert das Format der RTP-Nutzlast und bestimmt dessen Interpretation durch die Anwendung. Ein Profil kann eine statische Standardzuordnung von Nutzlasttypcodes zu Nutzlastformaten festlegen. Zusätzliche Nutzlasttypcodes können dynamisch durch Nicht-RTP-Mittel definiert werden (siehe Abschnitt 3). Ein Satz von Standardzuordnungen für Audio und Video ist im Begleitdokument RFC 3551 [1] angegeben. Eine RTP-Quelle kann den Nutzlasttyp im Laufe einer Sitzung ändern, aber dieses Feld sollte nicht verwendet werden, um separate Medienströme zu multiplexen (siehe Abschnitt 5.2).

  Ein Empfänger MUSS Pakete mit einem ihm unverständlichen Nutzlasttyp ignorieren.

• Sequenznummer (Sequence Number) : 16 Bits. Die Sequenznummer wird für jedes gesendete RTP-Datenpaket um eins erhöht und kann vom Empfänger verwendet werden, um Paketverluste zu erkennen und die Paketreihenfolge wiederherzustellen. Der Anfangswert der Sequenznummer sollte zufällig (unvorhersehbar) gewählt werden, um Known-Plaintext-Angriffe auf die Verschlüsselung zu erschweren, selbst wenn die Quelle selbst nicht gemäß der Methode in Abschnitt 9.1 verschlüsselt, da Pakete über einen Übersetzer gehen können, der dies tut. Techniken zur Wahl unvorhersehbarer Zahlen werden in [17] diskutiert.

• Zeitstempel (Timestamp) : 32 Bits. Der Zeitstempel spiegelt den Abtastzeitpunkt des ersten Oktetts im RTP-Datenpaket wider. Der Abtastzeitpunkt MUSS von einer Uhr abgeleitet sein, die im Laufe der Zeit monoton und linear zunimmt, um Zeit- und Jitterberechnungen zu ermöglichen (siehe Abschnitt 6.4.1). Die Auflösung der Uhr MUSS für die gewünschte Synchronisierungsgenauigkeit und zur Messung des Ankunftsjitter der Pakete ausreichen (ein Tick pro Videoframe ist typischerweise unzureichend). Die Frequenz der Uhr hängt vom Format der als Nutzlast transportierten Daten ab und wird statisch im Profil oder der Nutzlastformatspezifikation, die das Format definiert, festgelegt, oder kann dynamisch für durch Nicht-RTP-Mittel definierte Nutzlastformate angegeben werden. Falls RTP-Pakete periodisch erzeugt werden, sollte der nominale Abtastzeitpunkt, wie er aus der Abtastuhr bestimmt wird, verwendet werden, nicht eine Systemuhr-Lesung. Beispielsweise würde die Zeitstempeluhr für Audio mit fester Rate vermutlich für jede Abtastperiode um eins erhöht. Wenn eine Audioanwendung Blöcke liest, die 160 Abtastperioden abdecken, würde der Zeitstempel für jeden solchen Block um 160 erhöht, unabhängig davon, ob der Block in einem Paket übertragen oder als Stille verworfen wird.

  Der Anfangswert des Zeitstempels sollte zufällig sein, ebenso wie bei der Sequenznummer. Mehrere aufeinanderfolgende RTP-Pakete haben gleiche Zeitstempel, falls sie (logisch) zur gleichen Zeit erzeugt wurden, beispielsweise falls sie zum selben Videoframe gehören. Aufeinanderfolgende RTP-Pakete dürfen nicht monotone Zeitstempel enthalten, falls die Daten nicht in der Reihenfolge ihrer Abtastung übertragen werden, wie im Fall von MPEG-Interpolations-Videoframes. (Die Paketsequenznummern selbst sind stets monoton.)

  RTP-Zeitstempel verschiedener Medienströme können mit unterschiedlichen Raten fortschreiten und haben im Allgemeinen unabhängige zufällige Versätze. Daher ist ein direkter Vergleich der RTP-Zeitstempel verschiedener Medien für die Synchronisation nicht zielführend. Stattdessen wird für jedes Medium der RTP-Zeitstempel mit dem Abtastzeitpunkt verknüpft, indem er mit einem Zeitstempel einer Referenzuhr (Wallclock) gepaart wird, die den Zeitpunkt darstellt, zu dem die dem RTP-Zeitstempel entsprechenden Daten abgetastet wurden. Die Referenzuhr wird von allen zu synchronisierenden Medien geteilt. Die Zeitstempelpaare werden nicht in jedem Datenpaket, sondern mit geringerer Rate in den RTCP-SR-Paketen wie in Abschnitt 6.4 beschrieben übertragen.

  Der Abtastzeitpunkt wird als Bezugspunkt für den RTP-Zeitstempel gewählt, weil er dem sendenden Endpunkt bekannt ist und eine gemeinsame Definition für alle Medien unabhängig von Codierungs- oder anderen Verarbeitungsverzögerungen hat. Der Zweck ist es, eine synchronisierte Präsentation aller zum selben Zeitpunkt abgetasteten Medien zu ermöglichen.

  Anwendungen, die gespeicherte Daten statt in Echtzeit abgetasteter Daten übertragen, verwenden typischerweise eine aus der Uhrzeit abgeleitete virtuelle Präsentationschronologie, um zu bestimmen, wann das nächste Frame oder eine andere Einheit der gespeicherten Daten präsentiert werden soll. In diesem Fall spiegelt der RTP-Zeitstempel die Präsentationszeit für jede Einheit wider. Das heißt, der RTP-Zeitstempel jeder Einheit würde mit der Uhrzeit verknüpft, zu der die Einheit auf der virtuellen Präsentationschronologie aktuell wird. Die tatsächliche Präsentation erfolgt später, wie vom Empfänger bestimmt.

  Ein Beispiel, das die Live-Audionarration einer voraufgezeichneten Videoillustration beschreibt, veranschaulicht die Bedeutung der Wahl des Abtastzeitpunkts als Bezugspunkt. In diesem Szenario würde das Video lokal präsentiert, damit der Erzähler es sieht, und gleichzeitig über RTP übertragen. Der „Abtastzeitpunkt" eines übertragenen Videoframes würde durch Bezugnahme seines Zeitstempels auf die Uhrzeit etabliert, zu der dieser Videoframe dem Erzähler präsentiert wurde. Der Abtastzeitpunkt für die RTP-Audiopakete mit der Sprache des Erzählers würde durch Bezugnahme auf dieselbe Uhrzeit etabliert, zu der das Audio abgetastet wurde. Audio und Video können sogar von verschiedenen Hosts übertragen werden, falls deren Referenzuhren durch ein Mittel wie NTP synchronisiert sind. Ein Empfänger kann dann die Präsentation der Audio- und Videopakete synchronisieren, indem er deren RTP-Zeitstempel mithilfe der Zeitstempelpaare in den RTCP-SR-Paketen verknüpft.

• SSRC : 32 Bits. Das SSRC-Feld identifiziert die Synchronisationsquelle. Dieser Identifikator sollte zufällig gewählt werden, in der Absicht, dass keine der Synchronisationsquellen innerhalb derselben RTP-Sitzung denselben SSRC-Identifikator hat. Ein Beispielalgorithmus zur Erzeugung eines Zufallsidentifikators ist in Anhang A.6 angegeben. Obwohl die Wahrscheinlichkeit, dass mehrere Quellen denselben Identifikator wählen, gering ist, müssen alle RTP-Implementierungen bereit sein, Kollisionen zu erkennen und aufzulösen. Abschnitt 8 beschreibt die Kollisionswahrscheinlichkeit sowie einen Mechanismus zur Auflösung von Kollisionen und zur Erkennung von Übertragungsschleifen auf RTP-Ebene basierend auf der Eindeutigkeit des SSRC-Identifikators. Falls eine Quelle ihre Quell-Transportadresse ändert, muss sie auch einen neuen SSRC-Identifikator wählen, um nicht als Schleifenquelle interpretiert zu werden (siehe Abschnitt 8.2).

• CSRC-Liste : 0 bis 15 Elemente, je 32 Bits. Die CSRC-Liste identifiziert die Beitragendenquellen für die in diesem Paket enthaltene Nutzlast. Die Anzahl der Identifikatoren wird durch das CC-Feld gegeben. Gibt es mehr als 15 Beitragendequellen, können nur 15 identifiziert werden. Die CSRC-Identifikatoren werden von den Mischern (siehe Abschnitt 7.1) unter Verwendung der SSRC-Identifikatoren der Beitragendenquellen eingefügt. Beispielsweise werden für Audiopakete die SSRC-Identifikatoren aller Quellen aufgelistet, die zum Erzeugen eines Pakets zusammengemischt wurden, was eine korrekte Sprecheranzeige beim Empfänger ermöglicht.

5.2 Multiplexing RTP Sessions (Multiplexen von RTP-Sitzungen)

Für eine effiziente Protokollverarbeitung sollte die Anzahl der Multiplexpunkte minimiert werden, wie im Entwurfsprinzip der Integrierten Schichtverarbeitung [10] beschrieben. In RTP wird das Multiplexen durch die Ziel-Transportadresse (Netzwerkadresse und Portnummer) bereitgestellt, die für jede RTP-Sitzung unterschiedlich ist. Beispielsweise sollte in einer Videokonferenz, die aus separat kodierten Audio- und Videomedien besteht, jedes Medium in einer separaten RTP-Sitzung mit eigener Ziel-Transportadresse transportiert werden.

Separate Audio- und Videoströme sollten NICHT in einer einzigen RTP-Sitzung transportiert und anhand des Nutzlasttyps oder der SSRC-Felder demultiplext werden. Das Verschachteln von Paketen mit verschiedenen RTP-Medientypen, aber derselben SSRC, würde mehrere Probleme aufwerfen:

1. Wenn beispielsweise zwei Audioströme dieselbe RTP-Sitzung und denselben SSRC-Wert teilten und einer die Kodierung änderte und damit einen anderen RTP-Nutzlasttyp erhielte, gäbe es keine allgemeine Möglichkeit zu identifizieren, welcher Strom die Kodierung geändert hat.

2. Ein SSRC ist definiert, um einen einzigen Zeit- und Sequenznummernraum zu identifizieren. Das Verschachteln verschiedener Nutzlasttypen würde unterschiedliche Zeiträume erfordern, falls die Medienuhr-Frequenzen differieren, und unterschiedliche Sequenznummernräume, um zu sagen, welcher Nutzlasttyp Paketverluste erlitten hat.

3. Die RTCP-Sender- und Empfangsberichte (siehe Abschnitt 6.4) können pro SSRC nur einen einzigen Zeit- und Sequenznummernraum beschreiben und tragen kein Nutzlasttypfeld.

4. Ein RTP-Mischer wäre nicht in der Lage, verschachtelte inkompatible Medienströme zu einem einzigen Strom zu mischen.

5. Der Transport mehrerer Medien in einer einzigen RTP-Sitzung verhindert: die Verwendung unterschiedlicher Netzwerkpfade oder Ressourcenzuteilungen falls angemessen; den Empfang einer Untermenge der Medien falls gewünscht, beispielsweise nur Audio, wenn Video die verfügbare Bandbreite überschreiten würde; und Implementierungen von Empfängern, die separate Prozesse für die verschiedenen Medien verwenden, während die Verwendung separater RTP-Sitzungen Einzel- oder Multiprozessimplementierungen erlaubt.

Die Verwendung eines anderen SSRC für jedes Medium, aber deren Sendung in derselben RTP-Sitzung würde die ersten drei Probleme vermeiden, aber nicht die letzten beiden.

Andererseits ist das Multiplexen mehrerer verwandter Quellen desselben Mediums in einer RTP-Sitzung unter Verwendung verschiedener SSRC-Werte der Standard für Multicast-Sitzungen. Die oben aufgeführten Probleme treffen nicht zu: ein RTP-Mischer kann mehrere Audioquellen kombinieren, und dieselbe Verarbeitung ist für alle anwendbar. Es kann auch angemessen sein, Ströme desselben Mediums unter Verwendung verschiedener SSRC-Werte in anderen Szenarien zu multiplexen, wo die beiden letzten Probleme nicht zutreffen.

5.3 Profile-Specific Modifications to the RTP Header (Profilspezifische Änderungen am RTP-Header)

Es wird angenommen, dass der vorhandene RTP-Datenpaket-Header für den gesamten Satz der Funktionen vollständig ist, die gemeinsam über alle Klassen von Anwendungen erforderlich sind, die RTP unterstützen könnte. Gemäß dem ALF-Entwurfsprinzip kann der Header jedoch durch in einer Profilspezifikation definierte Änderungen oder Ergänzungen angepasst werden, während unabhängige profilunabhängige Überwachungs- und Aufzeichnungswerkzeuge funktionsfähig bleiben.

• Das Marker-Bit und das Nutzlasttypfeld tragen profilspezifische Informationen, werden aber im festen Header platziert, da viele Anwendungen sie benötigen und andernfalls ein weiteres 32-Bit-Wort nur zu deren Aufnahme hinzufügen müssten. Das Byte, das diese Felder enthält, KANN durch ein Profil neu definiert werden, um unterschiedlichen Anforderungen zu entsprechen, beispielsweise mit mehr oder weniger Marker-Bits. Falls Marker-Bits vorhanden sind, sollte eines im höchstwertigen Bit des Bytes liegen, da profilunabhängige Überwacher eine Korrelation zwischen Verlustmustern und dem Marker-Bit beobachten können.

• Zusätzliche Informationen, die für ein bestimmtes Nutzlastformat wie eine Videokodierung erforderlich sind, SOLLTEN im Nutzlastbereich des Pakets transportiert werden. Dies kann in einem Header am Anfang des Nutzlastbereichs oder durch einen reservierten Wert im Datenmuster angezeigt werden.

• Falls eine bestimmte Klasse von Anwendungen eine zusätzliche, vom Nutzlastformat unabhängige Funktion benötigt, SOLLTE das Profil, unter dem diese Anwendungen arbeiten, zusätzliche feste Felder direkt nach dem SSRC-Feld des vorhandenen festen Headers definieren. Diese Anwendungen können dann schnell und direkt auf die zusätzlichen Felder zugreifen, während profilunabhängige Überwacher oder Recorder RTP-Pakete weiterhin nur unter Interpretation der ersten zwölf Oktette verarbeiten können.

Sollte sich herausstellen, dass eine zusätzliche Funktion über alle Profile hinweg gemeinsam benötigt wird, sollte eine neue RTP-Version definiert werden, um eine dauerhafte Änderung am festen Header vorzunehmen.

5.3.1 RTP Header Extension (RTP-Header-Erweiterung)

Ein Erweiterungsmechanismus wird bereitgestellt, um einzelnen Implementierungen zu ermöglichen, mit neuen, vom Nutzlastformat unabhängigen Funktionen zu experimentieren, die zusätzliche Informationen im Header des Datenpakets transportiert werden müssen. Dieser Mechanismus ist so gestaltet, dass die Header-Erweiterung von anderen interoperablen Implementierungen, die nicht erweitert wurden, ignoriert werden kann.

Beachten Sie, dass diese Header-Erweiterung nur für einen begrenzten Gebrauch gedacht ist. Die meisten potenziellen Verwendungen dieses Mechanismus wären besser auf andere Weise mit den im vorigen Abschnitt beschriebenen Methoden auszuführen. Beispielsweise ist eine profilspezifische Erweiterung des festen Headers günstiger zu verarbeiten, da sie nicht bedingt oder an variabler Position ist. Zusätzliche Informationen, die für ein bestimmtes Nutzlastformat erforderlich sind, SOLLTEN diese Header-Erweiterung NICHT verwenden, sondern im Nutzlastbereich des Pakets transportiert werden.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      defined by profile       |           length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        header extension                       |
|                             ....                              |

Falls das X-Bit im RTP-Header auf eins gesetzt ist, MUSS dem RTP-Header eine Header-Erweiterung variabler Länge hinzugefügt werden, gegebenenfalls nach der CSRC-Liste. Die Header-Erweiterung enthält ein 16-Bit-Längenfeld, das die Anzahl der 32-Bit-Worte in der Erweiterung zählt, ausschließlich des vier Oktette umfassenden Erweiterungsheaders (sodass Null eine gültige Länge ist). An den RTP-Datenheader kann nur eine Erweiterung angefügt werden. Um mehreren interoperablen Implementierungen zu ermöglichen, jeweils unabhängig mit verschiedenen Header-Erweiterungen zu experimentieren, oder einer bestimmten Implementierung, mit mehr als einem Typ von Header-Erweiterung zu experimentieren, sind die ersten 16 Bits der Header-Erweiterung für Unterscheidungskennungen oder -parameter offen gelassen. Das Format dieser 16 Bits wird durch die Profilspezifikation definiert, unter der die Implementierungen arbeiten. Diese RTP-Spezifikation definiert selbst keine Header-Erweiterung.