1. Einführung

Paketverluste zwischen einem RTP-Sender und -Empfänger können die Qualität des empfangenen Mediums erheblich verschlechtern. Mehrere Techniken, etwa Forward Error Correction (FEC), Retransmissionen oder Interleaving, können erwogen werden, um die Robustheit gegen Paketverlust zu erhöhen. RFC 2354 [8] diskutiert die verschiedenen Optionen.

Bei der Wahl einer Reparaturtechnik für eine bestimmte Anwendung muss die tolerierbare Latenz der Anwendung berücksichtigt werden. Bei Multimedia-Konferenzen muss die Ende-zu-Ende-Verzögerung höchstens einige hundert Millisekunden betragen, um Interaktivität zu gewährleisten, was in der Regel den Einsatz von Retransmission ausschließt.

Mit ausreichender Latenz kann die Effizienz des Reparaturschemas erhöht werden. Der Sender kann das Empfänger-Feedback nutzen, um auf Verluste zu reagieren, bevor deren Wiedergabezeitpunkt am Empfänger erreicht ist.

Bei Multimedia-Streaming kann der Nutzer eine anfängliche Latenz im Rahmen der Session-Einrichtung tolerieren, sodass eine Ende-zu-Ende-Verzögerung von mehreren Sekunden akzeptabel sein kann. RTP-Retransmission, wie in diesem Dokument definiert, richtet sich an solche Anwendungen.

Darüber hinaus ist das hier definierte RTP-Retransmissionsverfahren für Unicast und (kleine) Multicast-Gruppen anwendbar. Das vorliegende Dokument definiert ein Nutzlastformat für retransmittierte RTP-Pakete und legt Protokollregeln für Sender und Empfänger im Zusammenhang mit Retransmissionen fest.

Dieses Retransmission-Nutzlastformat wurde für die Verwendung mit dem erweiterten RTP-Profil für RTCP-basierte Rückmeldung, AVPF [1], entworfen. Es kann auch mit anderen in Zukunft definierten RTP-Profilen verwendet werden.

Das AVPF-Profil ermöglicht häufigeres und früheres Feedback. Es definiert eine allgemeine Feedback-Nachricht, d. h. NACK, sowie codec- und anwendungsspezifische Feedback-Nachrichten. Einzelheiten siehe [1].