3. Anwendungsfälle für Endpunkte mit mehreren Strömen
Dieser Abschnitt erörtert mehrere Anwendungsfälle, die die Entwicklung von Endpunkten motiviert haben, die RTP-Daten unter Verwendung mehrerer SSRCs in einer einzigen RTP-Sitzung senden.
3.1. Endpunkte mit mehreren Aufnahmegeräten
Die naheliegendste Motivation für einen Endpunkt, mehrere gleichzeitige RTP-Ströme in einer einzigen RTP-Sitzung zu senden, ist der Fall, dass ein Endpunkt über mehrere Aufnahmegeräte verfügt und somit mehrere Medienquellen desselben Medientyps und mit denselben Eigenschaften erzeugen kann. Beispielsweise verfügen Telepräsenzsysteme der vom CLUE Telepresence Framework [CLUE-FRAME] beschriebenen Art häufig über mehrere Kameras oder Mikrofone, die verschiedene Bereiche eines Raums abdecken, und senden daher mehrere RTP-Ströme jedes Typs innerhalb einer einzigen RTP-Sitzung.
3.2. Mehrere Medientypen in einer einzigen RTP-Sitzung
Neuere Arbeiten haben RTP [MULTI-RTP] und das Session Description Protocol (SDP) [SDP-BUNDLE] aktualisiert, um die historische Annahme in RTP zu beseitigen, dass Medienquellen unterschiedlicher Medientypen stets in verschiedenen RTP-Sitzungen gesendet würden. In diesen Arbeiten werden die Audio- und Video-RTP-Ströme eines einzelnen Endpunkts (zum Beispiel) stattdessen in einer einzigen RTP-Sitzung gesendet, um die Anzahl der verwendeten Transportschicht-Flüsse zu verringern.
3.3. Mehrere Strom-Mixer
Es gibt mehrere RTP-Topologien, die ein zentrales Gerät umfassen können, das selbst mehrere RTP-Ströme in einer Sitzung erzeugt. Ein Beispiel ist ein Mixer, der eine zentrale Zusammenstellung (Compositing) für ein Multi-Capture-Szenario wie das in Abschnitt 3.1 beschriebene bereitstellt. In diesem Fall verhält sich der zentrale Knoten ganz ähnlich wie ein Endpunkt mit mehreren Aufnahmegeräten und erzeugt mehrere ähnliche und zusammengehörige Quellen.
Ein komplexeres Beispiel ist die selektiv weiterleitende Middlebox, die in Abschnitt 3.7 von [RFC7667] beschrieben wird. Dabei handelt es sich um eine Middlebox, die RTP-Ströme von mehreren Endpunkten empfängt und dann selektiv geänderte Versionen einiger RTP-Ströme an die anderen Endpunkte weiterleitet, mit denen sie verbunden ist. Für jeden verbundenen Endpunkt erscheint in der Sitzung eine separate Medienquelle für jede andere mit der Middlebox verbundene Quelle, die aus den ursprünglichen Strömen "projiziert" wird, doch zu jedem gegebenen Zeitpunkt können viele von ihnen inaktiv erscheinen (und sind somit in RTP Empfänger, nicht Sender). Diese Art von Gerät ist eher ein RTP-Mixer als ein RTP-Translator: Es beendet die RTCP-Berichterstattung über die gemischten Ströme; es kann SSRCs, Zeitstempel und Sequenznummern sowie den Inhalt der RTP-Nutzlasten neu schreiben; und es kann Quellen nach Belieben ein- und ausschalten, ohne dass Paketverluste zu entstehen scheinen. Jeder projizierte Strom behält typischerweise seine ursprünglichen RTCP-Source-Description-(SDES-)Informationen bei.
3.4. Mehrere SSRCs für eine einzige Medienquelle
Es gibt außerdem mehrere Fälle, in denen mehrere SSRCs verwendet werden können, um Daten aus einer einzigen Medienquelle innerhalb einer einzigen RTP-Sitzung zu senden. Dazu gehören unter anderem Werkzeuge zur Transportrobustheit, wie das RTP-Retransmissions-Nutzlastformat [RFC4588], bei dem eine SSRC für die Mediendaten und eine andere SSRC für die Reparaturdaten verwendet werden muss. In ähnlicher Weise können einige geschichtete Medienkodierungsverfahren, zum Beispiel H.264 Scalable Video Coding (SVC) [RFC6190], in einer Konfiguration verwendet werden, in der jede Schicht unter Verwendung einer anderen SSRC innerhalb einer einzigen RTP-Sitzung gesendet wird.