4. Retransmission-Nutzlastformat
Das Format eines Retransmission-Pakets ist unten dargestellt:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSN | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Original RTP Packet Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Die Verwendung des RTP-Headers ist wie folgt:
Im Fall von Session-Multiplexing MUST derselbe SSRC-Wert für den Originalstrom und den Retransmission-Strom verwendet werden. Im Fall einer SSRC-Kollision in der Original- oder der Retransmission-Session verlangt die RTP-Spezifikation, dass ein RTCP-BYE-Paket in der Session gesendet wird, in der die Kollision auftrat. Zusätzlich MUST auch ein RTCP-BYE-Paket für den zugehörigen Strom in dessen eigener Session gesendet werden. Nach Erhalt eines neuen SSRC-Identifiers MUST der SSRC beider Ströme auf diesen Wert gesetzt werden.
Im Fall von SSRC-Multiplexing MUST zwei unterschiedliche SSRC-Werte für den Originalstrom und den Retransmission-Strom verwendet werden, wie von RTP gefordert. Wird für den Original- oder den Retransmission-Strom eine SSRC-Kollision erkannt, verlangt die RTP-Spezifikation, dass ein RTCP-BYE-Paket für diesen Strom gesendet wird. Ein RTCP-BYE-Paket MUST NOT für den zugehörigen Strom gesendet werden. Daher MUST nur der Strom, bei dem die SSRC-Kollision auftrat, einen neuen SSRC-Wert wählen. Auswirkungen auf die SSRC-Zuordnung von Original- und Retransmission-Strom am Empfänger siehe Abschnitt 5.3.
Für beide Multiplexing-Schemata gilt die Sequenznummer in der üblichen Definition; d. h. sie MUST um eins höher sein als die Sequenznummer des vorhergehenden im Retransmission-Strom gesendeten Pakets.
Der Zeitstempel des Retransmission-Pakets MUST auf den Originalzeitstempel gesetzt werden, d. h. auf den Zeitstempel des Originalpakets. Folglich ist der anfängliche RTP-Zeitstempel für das erste Paket des Retransmission-Stroms nicht zufällig, sondern gleich dem Originalzeitstempel des ersten retransmittierten Pakets. Sicherheitsaspekte siehe den Abschnitt Security Considerations in diesem Dokument.
Implementierer müssen wissen, dass der RTCP-Jitter-Wert für den Retransmission-Strom nicht den tatsächlichen Netz-Jitter widerspiegelt, da zwischen dem Zeitpunkt der Retransmission und dem Originalzeitstempel wenig Korrelation bestehen kann.
Der Payload-Typ ist dynamisch. Sind im Originalstrom mehrere Payload-Typen mit Retransmission vorhanden, MUST für jeden davon ein dynamischer Payload-Typ auf das Retransmission-Nutzlastformat abgebildet werden. Die Festlegung der Abbildung zwischen Original- und Retransmission-Payload-Typen mit Session Description Protocol (SDP) siehe Abschnitt 8.1.
Da der Zeitstempel des Retransmission-Pakets den ursprünglichen Medienzeitstempel trägt, MUST die vom Retransmission-Payload-Typ verwendete Zeitstempel-Taktrate dieselbe sein wie die des zugehörigen Original-Payload-Typs. Trägt ein RTP-Stream daher Payload-Typen mit unterschiedlichen Taktraten, gilt das auch für den zugehörigen Retransmission-Strom. Ein RTP-Stream trägt üblicherweise keine Payload-Typen mit unterschiedlichen Taktraten.
Die Nutzlast des RTP-Retransmission-Pakets besteht aus dem Retransmission-Payload-Header gefolgt von der Nutzlast des Original-RTP-Pakets. Die Länge des Retransmission-Payload-Headers beträgt 2 Oktette. Dieser Payload-Header enthält nur ein Feld, OSN (original sequence number), das MUST auf die Sequenznummer des zugehörigen Original-RTP-Pakets gesetzt werden. Die Nutzlast des Original-RTP-Pakets einschließlich etwaiger nutzlasttypspezifischer Header MUST unmittelbar hinter dem Retransmission-Payload-Header platziert werden.
Bei Nutzlastformaten, die Kodierung mit mehreren Raten unterstützen, MAY der Sender anstelle derselben Nutzlast wie im Original-RTP-Paket dieselben Daten mit niedrigerer Rate kodieren und retransmitieren. Ziel ist es, die Bandbreitennutzung des Retransmission-Stroms zu begrenzen. Dabei MUST der Sender sicherstellen, dass der Empfänger die Nutzlast der bereits gesendeten Originalpakete, die möglicherweise auf der Nutzlast des verlorenen Originalpakets basierten, weiterhin dekodieren kann. Wählt der Sender Retransmission mit niedrigerer Rate, gelten die Werte im Payload-Header des Original-RTP-Pakets für das Retransmission-Paket unter Umständen nicht mehr und müssen im Retransmission-Paket angepasst werden, um die geänderte Rate widerzuspiegeln. Der Sender SHOULD Bandbreitenersparnis und Qualitätsverlust durch erneutes Senden mit niedrigerer Rate gegeneinander abwägen.
Trug der Original-RTP-Header profilspezifische Erweiterungen, SHOULD das Retransmission-Paket dieselben Erweiterungen unmittelbar nach dem festen RTP-Header enthalten, wie von Anwendungen unter diesem Profil erwartet. In diesem Fall MUST der Retransmission-Payload-Header nach den profilspezifischen Erweiterungen stehen.
Trug der Original-RTP-Header eine RTP-Header-Erweiterung, SHOULD das Retransmission-Paket dieselbe Header-Erweiterung tragen. Diese Header-Erweiterung MUST unmittelbar nach dem festen RTP-Header stehen, wie in RTP [3] spezifiziert. In diesem Fall MUST der Retransmission-Payload-Header nach der Header-Erweiterung stehen.
Enthielt das Original-RTP-Paket RTP-Padding, MUST dieses vor dem Aufbau des Retransmission-Pakets entfernt werden. Ist Padding für das Retransmission-Paket nötig, MUST es wie bei jedem RTP-Paket durchgeführt werden und das Padding-Bit MUST gesetzt sein.
Das Marker-Bit (M), die CSRC-Anzahl (CC) und die CSRC-Liste des Original-RTP-Headers MUST unverändert („as is“) in den RTP-Header des Retransmission-Pakets kopiert werden.