1. Einleitung
Zum Zeitpunkt, als das Real-Time Transport Protocol (RTP) [RFC3550] ursprünglich entworfen wurde, und für eine ganze Weile danach, übertrugen Endpunkte in RTP-Sitzungen typischerweise nur eine einzige Medienquelle und verwendeten daher einen einzigen RTP-Strom und eine einzige Synchronisationsquelle (SSRC) pro RTP-Sitzung, wobei separate RTP-Sitzungen typischerweise für jeden unterschiedlichen Medientyp verwendet wurden. In jüngster Zeit sind jedoch eine Reihe von Szenarien entstanden, in denen Endpunkte mehrere RTP-Ströme, die durch unterschiedliche RTP-Synchronisationsquellen-Kennungen (SSRC) unterschieden werden, in einer einzigen RTP-Sitzung senden möchten. Obwohl der ursprüngliche Entwurf von RTP solche Szenarien berücksichtigte, wurde die Spezifikation nicht konsequent unter Berücksichtigung solcher Anwendungsfälle geschrieben; daher ist die Spezifikation an einigen Stellen etwas unklar.
Dieses Memorandum aktualisiert [RFC3550], um das Verhalten in Anwendungsfällen zu klären, in denen Endpunkte mehrere SSRCs verwenden. Es aktualisiert auch [RFC4585], um Probleme im Hinblick auf den Timeout inaktiver SSRCs zu lösen und das Verhalten im Zusammenhang mit der Einbeziehung von Feedback-Nachrichten zu klären.
2. Terminologie
Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind wie in RFC 2119 [RFC2119] beschrieben zu interpretieren und geben Anforderungsstufen für konforme Implementierungen an.
3. Anwendungsfälle für Mehrstrom-Endpunkte
In diesem Abschnitt werden verschiedene Anwendungsfälle erörtert, die die Entwicklung von Endpunkten motiviert haben, die RTP-Daten mit mehreren SSRCs in einer einzigen RTP-Sitzung senden.
3.1. Endpunkte mit mehreren Erfassungsgeräten
Die naheliegendste Motivation für einen Endpunkt, mehrere gleichzeitige RTP-Ströme in einer einzigen RTP-Sitzung zu senden, ist, wenn ein Endpunkt über mehrere Erfassungsgeräte verfügt und somit mehrere Medienquellen desselben Medientyps und derselben Charakteristik erzeugen kann. Beispielsweise verfügen Telepresence-Systeme des im CLUE Telepresence Framework [CLUE-FRAME] beschriebenen Typs oft ü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
Jüngste Arbeiten haben RTP [MULTI-RTP] und das Session Description Protocol (SDP) [SDP-BUNDLE] aktualisiert, um die historische Annahme in RTP zu entfernen, dass Medienquellen unterschiedlicher Medientypen immer über verschiedene RTP-Sitzungen gesendet würden. In dieser Arbeit werden stattdessen beispielsweise die Audio- und Video-RTP-Ströme eines einzelnen Endpunkts in einer einzigen RTP-Sitzung gesendet, um die Anzahl der verwendeten Transportschicht-Flows zu reduzieren.
3.3. Mehrstrom-Mischer
Es gibt verschiedene RTP-Topologien, an denen ein zentrales Gerät beteiligt sein kann, das selbst mehrere RTP-Ströme in einer Sitzung erzeugt. Ein Beispiel ist ein Mischer, der ein zentralisiertes Compositing für ein Mehrfach-Erfassungsszenario bereitstellt, wie es in Abschnitt 3.1 beschrieben ist. In diesem Fall verhält sich der zentralisierte Knoten ähnlich wie ein Mehrfach-Erfassungs-Endpunkt und erzeugt mehrere ähnliche und miteinander verbundene Quellen.
3.4. Mehrere SSRCs für eine einzelne Medienquelle
Es gibt verschiedene Fälle, in denen mehrere SSRCs verwendet werden, um Daten von einer einzelnen Medienquelle innerhalb einer Sitzung zu senden. Dazu gehören:
- Schichtweise oder Codecs mit mehrfacher Beschreibung: Wo verschiedene Schichten oder Beschreibungen mit verschiedenen SSRCs gesendet werden
- Mechanismen zur Transportrobustheit: Wie RTP-Retransmission [RFC4588] oder Vorwärtsfehlerkorrektur [RFC5109]
- Simulcast: Senden mehrerer Kodierungen derselben Quelle in unterschiedlichen Qualitäten oder Auflösungen