2. RTP-Anwendungsszenarien (RTP Use Scenarios)
Die folgenden Abschnitte beschreiben einige Aspekte der Verwendung von RTP. Die Beispiele wurden ausgewählt, um die grundlegende Funktionsweise von Anwendungen zu veranschaulichen, die RTP verwenden, und nicht um einzuschränken, wofür RTP verwendet werden kann. In diesen Beispielen wird RTP über IP und UDP übertragen und folgt den Konventionen, die durch das Profil für Audio und Video im begleitenden RFC 3551 festgelegt wurden.
2.1 Einfache Multicast-Audiokonferenz (Simple Multicast Audio Conference)
Eine Arbeitsgruppe der IETF trifft sich, um das neueste Protokolldokument zu diskutieren, und verwendet die IP-Multicast-Dienste des Internets für die Sprachkommunikation. Durch einen Zuweisungsmechanismus erhält der Vorsitzende der Arbeitsgruppe eine Multicast-Gruppenadresse und ein Portpaar. Ein Port wird für Audiodaten verwendet, der andere für Kontrollpakete (RTCP). Diese Adress- und Portinformationen werden an die vorgesehenen Teilnehmer verteilt. Wenn Vertraulichkeit gewünscht wird, können die Daten- und Kontrollpakete wie in Abschnitt 9.1 angegeben verschlüsselt werden, wobei auch ein Verschlüsselungsschlüssel generiert und verteilt werden muss. Die genauen Details dieser Zuweisungs- und Verteilungsmechanismen liegen außerhalb des Geltungsbereichs von RTP.
Die von jedem Konferenzteilnehmer verwendete Audiokonferenzanwendung sendet Audiodaten in kleinen Blöcken von beispielsweise 20 ms Dauer. Jedem Audiodatenblock geht ein RTP-Header voraus; RTP-Header und Daten sind wiederum in einem UDP-Paket enthalten. Der RTP-Header gibt an, welche Art von Audiocodierung (wie PCM, ADPCM oder LPC) in jedem Paket enthalten ist, sodass Sender die Codierung während einer Konferenz ändern können, beispielsweise um einen neuen Teilnehmer zu berücksichtigen, der über eine Verbindung mit geringer Bandbreite verbunden ist, oder um auf Anzeichen von Netzwerküberlastung zu reagieren.
Das Internet verliert und ordnet wie andere Paketnetzwerke gelegentlich Pakete neu und verzögert sie um variable Zeitmengen. Um mit diesen Beeinträchtigungen umzugehen, enthält der RTP-Header Zeitinformationen und eine Sequenznummer, die es den Empfängern ermöglichen, das von der Quelle erzeugte Timing zu rekonstruieren, sodass in diesem Beispiel Audioblöcke alle 20 ms kontinuierlich über den Lautsprecher ausgegeben werden. Diese Zeitrekonstruktion wird für jede Quelle von RTP-Paketen in der Konferenz separat durchgeführt. Die Sequenznummer kann auch vom Empfänger verwendet werden, um abzuschätzen, wie viele Pakete verloren gehen.
Da Mitglieder der Arbeitsgruppe während der Konferenz beitreten und verlassen, ist es nützlich zu wissen, wer zu jedem Zeitpunkt teilnimmt und wie gut sie die Audiodaten empfangen. Zu diesem Zweck sendet jede Instanz der Audioanwendung in der Konferenz periodisch einen Empfangsbericht plus den Namen ihres Benutzers über den RTCP-Port (Kontrolle) per Multicast. Der Empfangsbericht zeigt an, wie gut der aktuelle Sprecher empfangen wird, und kann zur Steuerung adaptiver Codierungen verwendet werden. Zusätzlich zum Benutzernamen können auch andere identifizierende Informationen einbezogen werden, vorbehaltlich der Kontrollbandbreitengrenzen. Eine Site sendet das RTCP-BYE-Paket (Abschnitt 6.6), wenn sie die Konferenz verlässt.
2.2 Audio- und Videokonferenz (Audio and Video Conference)
Wenn sowohl Audio- als auch Videomedien in einer Konferenz verwendet werden, werden sie als separate RTP-Sitzungen übertragen. Das heißt, separate RTP- und RTCP-Pakete werden für jedes Medium unter Verwendung von zwei verschiedenen UDP-Portpaaren und/oder Multicast-Adressen übertragen. Es gibt keine direkte Kopplung auf RTP-Ebene zwischen den Audio- und Videositzungen, außer dass ein Benutzer, der an beiden Sitzungen teilnimmt, in den RTCP-Paketen für beide denselben ausgezeichneten (kanonischen) Namen verwenden sollte, damit die Sitzungen zugeordnet werden können.
Eine Motivation für diese Trennung besteht darin, einigen Teilnehmern der Konferenz zu ermöglichen, nur ein Medium zu empfangen, wenn sie dies wünschen. Eine weitere Erklärung findet sich in Abschnitt 5.2. Trotz der Trennung kann eine synchronisierte Wiedergabe von Audio und Video einer Quelle unter Verwendung der in den RTCP-Paketen für beide Sitzungen übertragenen Zeitinformationen erreicht werden.
2.3 Mixer und Übersetzer (Mixers and Translators)
Bisher haben wir angenommen, dass alle Sites Mediendaten im gleichen Format empfangen möchten. Dies ist jedoch möglicherweise nicht immer angemessen. Betrachten Sie den Fall, in dem Teilnehmer in einem Bereich über eine Verbindung mit niedriger Geschwindigkeit mit der Mehrheit der Konferenzteilnehmer verbunden sind, die über einen Hochgeschwindigkeitsnetzwerkzugang verfügen. Anstatt alle zu zwingen, eine Audiocodierung mit geringerer Bandbreite und reduzierter Qualität zu verwenden, kann ein RTP-Level-Relay namens Mixer in der Nähe des Bereichs mit geringer Bandbreite platziert werden. Dieser Mixer resynchronisiert eingehende Audiopakete, um den konstanten 20-ms-Abstand zu rekonstruieren, der vom Sender erzeugt wird, mischt diese rekonstruierten Audioströme zu einem einzigen Strom, übersetzt die Audiocodierung in eine mit geringerer Bandbreite und leitet den Paketstrom mit geringerer Bandbreite über die Verbindung mit niedriger Geschwindigkeit weiter. Diese Pakete können an einen einzelnen Empfänger unicast oder auf einer anderen Adresse an mehrere Empfänger multicast werden. Der RTP-Header enthält ein Mittel für Mixer, um die Quellen zu identifizieren, die zu einem gemischten Paket beigetragen haben, sodass eine korrekte Sprecheranzeige bei den Empfängern bereitgestellt werden kann.
Einige der vorgesehenen Teilnehmer an der Audiokonferenz können mit Hochbandbreitenverbindungen verbunden sein, sind jedoch möglicherweise nicht direkt über IP-Multicast erreichbar. Beispielsweise befinden sie sich möglicherweise hinter einer Firewall auf Anwendungsebene, die keine IP-Pakete durchlässt. Für diese Sites ist das Mischen möglicherweise nicht erforderlich, in diesem Fall kann ein anderer Typ von RTP-Level-Relay namens Übersetzer verwendet werden. Zwei Übersetzer werden installiert, einer auf jeder Seite der Firewall, wobei der äußere alle empfangenen Multicast-Pakete über eine sichere Verbindung zum Übersetzer innerhalb der Firewall leitet. Der Übersetzer innerhalb der Firewall sendet sie erneut als Multicast-Pakete an eine Multicast-Gruppe, die auf das interne Netzwerk der Site beschränkt ist.
Mixer und Übersetzer können für verschiedene Zwecke entwickelt werden. Ein Beispiel ist ein Videomixer, der die Bilder einzelner Personen in separaten Videoströmen skaliert und sie zu einem Videostrom zusammensetzt, um eine Gruppenszene zu simulieren. Weitere Beispiele für Übersetzung umfassen die Verbindung einer Gruppe von Hosts, die nur IP/UDP sprechen, mit einer Gruppe von Hosts, die nur ST-II verstehen, oder die paketweise Codierungsübersetzung von Videoströmen aus einzelnen Quellen ohne Resynchronisation oder Mischung. Details zum Betrieb von Mixern und Übersetzern finden sich in Abschnitt 7.
2.4 Schichtcodierungen (Layered Encodings)
Multimedia-Anwendungen sollten in der Lage sein, die Übertragungsrate anzupassen, um der Kapazität des Empfängers zu entsprechen oder sich an Netzwerküberlastung anzupassen. Viele Implementierungen legen die Verantwortung für die Ratenanpassung an die Quelle. Dies funktioniert bei Multicast-Übertragung aufgrund der widersprüchlichen Bandbreitenanforderungen heterogener Empfänger nicht gut. Das Ergebnis ist oft ein Szenario des kleinsten gemeinsamen Nenners, bei dem die kleinste Leitung im Netzwerknetz die Qualität und Wiedergabetreue der gesamten Live-Multimedia-„Übertragung" bestimmt.
Stattdessen kann die Verantwortung für die Ratenanpassung bei den Empfängern platziert werden, indem eine Schichtcodierung mit einem Schichtübertragungssystem kombiniert wird. Im Kontext von RTP über IP-Multicast kann die Quelle die progressiven Schichten eines hierarchisch dargestellten Signals über mehrere RTP-Sitzungen verteilen, die jeweils auf ihrer eigenen Multicast-Gruppe übertragen werden. Empfänger können sich dann an die Netzwerkheterogenität anpassen und ihre Empfangsbandbreite steuern, indem sie nur der entsprechenden Teilmenge der Multicast-Gruppen beitreten.
Details zur Verwendung von RTP mit Schichtcodierungen finden sich in den Abschnitten 6.3.9, 8.3 und 11.