2. RTP Use Scenarios (RTP-Anwendungsszenarien)
Die folgenden Abschnitte beschreiben einige Aspekte der RTP-Verwendung. Die Beispiele wurden gewählt, um die Grundlagen der Funktionsweise von Anwendungen zu veranschaulichen, die RTP nutzen, und nicht, um die möglichen Verwendungen von RTP einzuschränken. In diesen Beispielen wird RTP über IP und UDP transportiert und den im Begleitdokument RFC 3551 festgelegten Konventionen für das Audio-/Video-Profil gefolgt.
2.1 Simple Multicast Audio Conference (Einfache Multicast-Audiokonferenz)
Eine IETF-Arbeitsgruppe trifft sich, um das neueste Protokolldokument zu erörtern, und nutzt die IP-Multicast-Dienste des Internets für die Sprachkommunikation. Durch einen Zuweisungsmechanismus erhält der Vorsitzende der Arbeitsgruppe eine Multicast-Gruppenadresse und ein Paar von Ports. Ein Port wird für Audio-Daten verwendet, der andere für Steuerpakete (RTCP). Diese Adress- und Portinformation wird an die vorgesehenen Teilnehmer verteilt. Falls Vertraulichkeit gewünscht wird, können Daten- und Steuerpakete gemäß Abschnitt 9.1 verschlüsselt werden, woraufhin auch ein Verschlüsselungsschlüssel erzeugt und verteilt werden muss. Die genauen Einzelheiten dieser Zuweisungs- und Verteidungsmechanismen liegen außerhalb von RTP.
Die von jedem Teilnehmer verwendete Audio-Konferenzanwendung sendet die Audiodaten in kleinen Blöcken, sagen wir von 20 ms Dauer. Jeder Audiodatenblock wird von einem RTP-Header vorangestellt; RTP-Header und Daten sind wiederum in einem UDP-Paket enthalten. Der RTP-Header gibt an, welche Art von Audiokodierung (wie PCM, ADPCM oder LPC) in jedem Paket enthalten ist, sodass die Sender die Kodierung im Laufe einer Konferenz wechseln können, beispielsweise um einen neu beitretenden Teilnehmer über eine Verbindung mit geringer Bandbreite aufzunehmen oder um auf Anzeichen für Netzwerküberlastung zu reagieren.
Das Internet wie auch andere Paketnetze verlieren gelegentlich Pakete und ordnen sie neu an sowie verzögern sie um unterschiedliche Zeiträume. Um diesen Verfälschungen zu begegnen, enthält der RTP-Header Zeitstempel- und Sequenznummerninformationen, die es den Empfängern ermöglichen, die vom Sender erzeugte Zeitstruktur zu rekonstruieren, sodass in diesem Beispiel die Audioblöcke vom Lautsprecher alle 20 ms zusammenhängend wiedergegeben werden. Diese zeitliche Rekonstruktion erfolgt separat für jede Paketquelle der Konferenz. Die Sequenznummer kann vom Empfänger auch zur Schätzung der Anzahl verlorener Pakete verwendet werden.
Da die Mitglieder der Arbeitsgruppe im Laufe der Zeit der Konferenz beitreten und sie verlassen, ist es nützlich zu wissen, wer zu einem bestimmten Zeitpunkt teilnimmt und mit welcher Qualität sie die Audiodaten empfangen. Zu diesem Zweck sendet jede Instanz der Audioanwendung in der Konferenz in regelmäßigen Abständen einen Empfangsbericht (Reception Report) sowie den Namen ihres Benutzers über den RTCP-Port (Steuerung). Der Empfangsbericht gibt an, wie gut der aktuelle Sprecher empfangen wird, und kann zur Steuerung adaptiver Kodierungen verwendet werden. Zusätzlich zum Benutzernamen können weitere Identifikationsinformationen im Rahmen der verfügbaren Steuerbandbreite eingefügt werden. Ein Standort sendet das RTCP-BYE-Paket (Abschnitt 6.6), wenn er die Konferenz verlässt.
2.2 Audio and Video Conference (Audio- und Videokonferenz)
Falls in einer Konferenz sowohl Audio- als auch Videomedien 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 verschiedenen Multicast-Adressen übertragen. Es gibt auf RTP-Ebene keine direkte Kopplung zwischen den Audio- und Videositzungen, außer dass ein Teilnehmer, der an beiden Sitzungen teilnimmt, in den RTCP-Paketen beider den gleichen kanonischen Namen (CNAME) verwenden muss, damit die Sitzungen zugeordnet werden können.
Ein Grund für diese Trennung ist es, einigen Konferenzteilnehmern zu ermöglichen, nur ein Medium zu empfangen, wenn sie dies wünschen. Eine ergänzende Erklärung hierzu findet sich in Abschnitt 5.2. Trotz dieser Trennung kann eine synchronisierte Wiedergabe von Audio und Video einer Quelle erreicht werden, indem die in den RTCP-Paketen beider Sitzungen transportierten Zeitinformationen genutzt werden.
2.3 Mixers and Translators (Mischer und Übersetzer)
Bis hierher haben wir angenommen, dass alle Standorte die Medien-Daten im gleichen Format empfangen möchten. Dies ist jedoch nicht immer angemessen. Betrachten wir den Fall, dass einige Teilnehmer einer Zone über eine Verbindung mit geringer Bandbreite mit der Mehrheit der Konferenzteilnehmer verbunden sind, die über breitbandigen Netzzugang verfügen. Anstatt alle zur Verwendung eines Audio-Kodierungsverfahrens mit reduzierter Bandbreite und geringerer Qualität zu zwingen, kann ein RTP-Ebene-Relais namens Mischer (Mixer) in der Nähe der Zone mit geringer Bandbreite platziert werden. Dieser Mischer resynchronisiert die eingehenden Audiopakete, um die vom Sender erzeugte konstante 20-ms-Abfolge wiederherzustellen, mischt diese rekonstruierten Audioströme zu einem einzigen Strom, übersetzt die Audiokodierung in eine Kodierung mit geringerer Bandbreite und überträgt den Strom mit reduzierter Paketbandbreite über die Verbindung mit geringer Bandbreite. Diese Pakete können unicast an einen einzelnen Empfänger oder multicast an eine andere Adresse an mehrere Empfänger gesendet werden. Der RTP-Header enthält eine Möglichkeit, mit der Mischer die Quellen kennzeichnen können, die zu einem gemischten Paket beigetragen haben, damit den Empfängern eine korrekte Sprecheranzeige gegeben werden kann.
Einige der vorgesehenen Teilnehmer der Audiokonferenz sind möglicherweise über Verbindungen mit hoher Bandbreite angeschlossen, sind jedoch nicht direkt über IP-Multicast erreichbar. Beispielsweise können sie sich hinter einer Application-Level-Firewall befinden, die keine IP-Pakete durchlässt. Für diese Standorte ist ein Mischer möglicherweise nicht erforderlich; stattdessen kann ein anderer Typ eines RTP-Ebene-Relais namens Übersetzer (Translator) verwendet werden. Es werden zwei Übersetzer installiert, jeweils einer auf jeder Seite der Firewall; der äußere empfängt alle Multicast-Pakete und leitet sie über eine sichere Verbindung an den inneren Übersetzer weiter. Der innere Übersetzer sendet sie wiederum als Multicast-Pakete an eine Multicast-Gruppe, die auf das interne Netz des Standorts beschränkt ist.
Mischer und Übersetzer können für verschiedene Zwecke konzipiert sein. Ein Beispiel ist ein Video-Mischer, der die Bilder einzelner Personen aus separaten Videoströmen skaliert und zu einem einzigen Videostrom für eine Gruppenszene zusammensetzt. Weitere Beispiele für Übersetzung umfassen die Verbindung einer Gruppe von nur IP/UDP sprechenden Hosts mit einer Gruppe von nur ST-II sprechenden Hosts oder die paketweise Übersetzung der Kodierung von Videoströmen einzelner Quellen ohne Resynchronisation oder Mischung. Einzelheiten zur Funktionsweise von Mischern und Übersetzern sind in Abschnitt 7 angegeben.
2.4 Layered Encodings (Geschichtete Kodierungen)
Multimedia-Anwendungen müssen in der Lage sein, die Senderate an die Kapazität des Empfängers anzupassen oder sich an Netzwerküberlastungen anzupassen. Viele Implementierungen legen die Verantwortung für die Ratene Adaptivität (Rate-Adaptivity) bei der Quelle. Dies funktioniert bei Multicast-Übertragung schlecht wegen der widersprüchlichen Bandbreitenanforderungen heterogener Empfänger. Das Ergebnis ist oft ein Szenario des kleinsten gemeinsamen Nenners (Least-Common Denominator), bei dem das kleinste Rohr des Netzgeflechts die Qualität und Treue der globalen „Live"-Multimediaübertragung diktiert.
Stattdessen kann die Verantwortung für die Ratene Adaptivität auf die Empfänger verlagert werden, indem eine geschichtete Kodierung (Layered Encoding) mit einem System zur geschichteten Übertragung kombiniert wird. Im Kontext von RTP über IP-Multicast kann die Quelle die progressiven Schichten eines hierarchisch dargestellten Signals auf mehrere RTP-Sitzungen aufteilen (Striping), von denen jede über ihre eigene Multicast-Gruppe transportiert wird. Die Empfänger können sich dann an die Heterogenität des Netzwerks anpassen und ihre Empfangsbandbreite steuern, indem sie nur die entsprechende Untermenge der Multicast-Gruppen beitreten.
Einzelheiten zur Verwendung von RTP mit geschichteten Kodierungen sind in den Abschnitten 6.3.9, 8.3 und 11 angegeben.