1. Introduction

Echtzeit-Mediendatenströme, die RTP verwenden, sind bis zu einem gewissen Grad widerstandsfähig gegen Paketverluste. RTP [1] stellt alle notwendigen Mechanismen bereit, um die beim Sender vorliegende Reihenfolge und Zeitgebung beim Empfänger wiederherzustellen und einen Mediendatenstrom korrekt wiederzugeben. RTP liefert außerdem kontinuierliches Feedback zur gesamten Empfangsqualität aller Empfänger und ermöglicht es den Sender(n), mittelfristig (in der Größenordnung von Sekunden bis Minuten) Codierschema und Übertragungsverhalten an die beobachtete Netzwerk-Quality-of-Service (QoS) anzupassen. Außer bei wenigen payload-spezifischen Mechanismen [6] sieht RTP jedoch kein zeitnahes Feedback vor, das einem Sender erlauben würde, den Mediendatenstrom sofort zu reparieren: durch Retransmissionen, retroaktive Forward-Error-Correction-(FEC-)Steuerung oder medienspezifische Mechanismen für einige Videocodecs, etwa Referenzbildauswahl.

Derzeit mit RTP verfügbare Mechanismen zur Verbesserung der Fehlerresilienz umfassen Audio-Redundanzcodierung [13], Video-Redundanzcodierung [14], FEC auf RTP-Ebene [11] und allgemeine Überlegungen zur robusteren Übertragung von Mediendatenströmen [12]. Diese Mechanismen können proaktiv angewendet werden (wodurch die Bandbreite eines gegebenen Mediendatenstroms steigt). Alternativ können in hinreichend kleinen Gruppen mit kleinen Round-Trip-Zeiten (RTTs) die Sender Reparaturen bei Bedarf durchführen, unter Verwendung der genannten Mechanismen und/oder mediencodierungsspezifischer Ansätze. „Kleine Gruppe“ und „hinreichend kleine RTT“ sind beides stark anwendungsabhängig.

Dieses Dokument spezifiziert ein modifiziertes RTP-Profil für Audio- und Videokonferenzen mit minimalem Steuerungsaufwand auf Grundlage von [1] und [2] mittels zweier Änderungen/Ergänzungen: Erstens werden zur Erreichung zeitnahen Feedbacks das Konzept von Early-RTCP-Nachrichten sowie Algorithmen eingeführt, die in kleinen Multicast-Gruppen Feedback mit geringer Verzögerung ermöglichen (und in großen Gruppen eine Feedback-Implosion verhindern). Punkt-zu-Punkt-Szenarien werden besonders berücksichtigt. Zweitens werden eine kleine Zahl allgemeiner Feedback-Nachrichten sowie ein Format für codec- und anwendungsspezifische Feedback-Informationen für die Übertragung in RTCP-Payloads definiert.