3. Anforderungen und Entwurfsbegründung für ein Retransmissionsschema

Der Einsatz von Retransmissionen in RTP als Reparaturmethode für Streaming-Medien ist in Szenarien mit gelockerten Verzögerungsgrenzen angemessen, in denen keine vollständige Zuverlässigkeit erforderlich ist. Konkret ermöglicht RTP-Retransmission einen Kompromiss zwischen Zuverlässigkeit und Verzögerung; d. h. die Endpunkte können aufgeben, ein verlorenes Paket nach Ablauf einer gegebenen Pufferzeit erneut zu senden. Im Gegensatz zu TCP entsteht durch RTP-Retransmissionen also kein Head-of-Line-Blocking. Implementierer sollten sich bewusst sein, dass in Fällen, in denen vollständige Zuverlässigkeit erforderlich ist oder höhere Verzögerung und Jitter toleriert werden können, TCP oder andere Transportoptionen in Betracht gezogen werden sollten.

Das in diesem Dokument definierte RTP-Retransmissionsschema soll die folgenden Anforderungen erfüllen:

1. Es darf allgemeine RTP- und RTCP-Mechanismen nicht brechen.

2. Es muss für Unicast und kleine Multicast-Gruppen geeignet sein.

3. Es muss mit Mixern und Translators funktionieren.

4. Es muss mit allen bekannten Payload-Typen funktionieren.

5. Es darf die Verwendung mehrerer Payload-Typen in einer Session nicht verhindern.

6. Um die größtmögliche Vielfalt von Nutzlastformaten zu unterstützen, muss der RTP-Empfänger aus einer Lücke in den empfangenen RTP-Sequenznummern ableiten können, wie viele und welche RTP-Pakete verloren gingen. Diese Anforderung wird als Erhalt der Sequenznummernzuordnung (sequence number preservation) bezeichnet. Ohne sie wäre Retransmission mit Nutzlastformaten unmöglich, die die RTP-Sequenznummer zum Erkennen verlorener Pakete nutzen, etwa konversationeller Text [9] oder die meisten Audio-/Video-Streaming-Anwendungen.

Beim Entwurf einer Lösung für RTP-Retransmission können mehrere Ansätze für das Multiplexen der Original-RTP-Pakete und der retransmittierten RTP-Pakete in Betracht gezogen werden.

Ein Ansatz könnte sein, das RTP-Paket mit seiner ursprünglichen Sequenznummer erneut zu senden und Original- und Retransmission-Pakete im selben RTP-Strom zu übertragen. Das Retransmission-Paket wäre dann identisch mit dem Original-RTP-Paket, d. h. derselbe Header (und damit dieselbe Sequenznummer) und dieselbe Nutzlast. Ein solcher Ansatz ist jedoch nicht akzeptabel, weil er die RTCP-Statistiken verfälschen würde. Folglich würde Anforderung 1 nicht erfüllt. Korrekte RTCP-Statistiken erfordern, dass die Sequenznummer für jedes RTP-Paket im RTP-Strom um eins erhöht wird.

Ein anderer Ansatz könnte sein, Original-RTP-Pakete und Retransmission-Pakete im selben RTP-Strom mit unterschiedlichen Payload-Type-Werten zu multiplexen. Dann würden Original- und Retransmission-Pakete denselben Sequenznummernraum teilen. Der RTP-Empfänger könnte daraus nicht ableiten, wie viele und welche Originalpakete (welche Sequenznummern) verloren gingen.

Mit anderen Worten: Dieser Ansatz erfüllt nicht die Anforderung zur Erhalt der Sequenznummernzuordnung (Anforderung 6). Daraus folgt, dass Anforderung 4 nicht erfüllt wäre. Die Interoperabilität mit Mixern und Translators wäre ebenfalls schwieriger, wenn sie diesen neuen Retransmission-Payload-Typ im Sender-RTP-Strom nicht verstünden. Aus diesen Gründen wird eine Lösung auf Basis von Payload-Type-Multiplexing von Original- und Retransmission-Paketen im selben RTP-Strom ausgeschlossen.

Schließlich können Original- und Retransmission-Pakete in zwei getrennten Strömen gesendet werden. Diese beiden Ströme können entweder multiplext werden, indem sie in zwei verschiedenen Sessions gesendet werden, d. h. Session-Multiplexing, oder in derselben Session mit unterschiedlichen SSRC-Werten, d. h. SSRC-Multiplexing. Da Original- und Retransmission-Pakete Medien desselben Typs tragen, gelten in diesem Fall die in Abschnitt 5.2 von RTP [3] genannten Bedenken gegen RTP-Multiplexing nicht.

Mixer und Translators können den Originalstrom verarbeiten und den Retransmission-Strom einfach verwerfen, wenn sie ihn nicht nutzen können.

Andererseits erfüllt das Senden von Original- und Retransmission-Paketen in zwei getrennten Strömen allein die Anforderungen 1 und 6 nicht. Zu diesem Zweck nimmt dieses Dokument die ursprüngliche Sequenznummer in die retransmittierten Pakete auf.

Auf diese Weise erfüllt die Verwendung zweier getrennter Ströme alle in diesem Abschnitt genannten Anforderungen.