Zum Hauptinhalt springen

7. RTP Translators and Mixers (RTP-Übersetzer und Mischer)

Zusätzlich zu Endsystemen unterstützt RTP das Konzept von „Übersetzern" (Translators) und „Mischern" (Mixers), die als „Zwischensysteme" auf RTP-Ebene betrachtet werden könnten. Obwohl diese Unterstützung dem Protokoll einige Komplexität hinzufügt, wurde der Bedarf für diese Funktionen durch Experimente mit Multicast-Audio- und -Videoanwendungen im Internet klar etabliert. Die in Abschnitt 2.3 genannten Beispiele für die Verwendung von Übersetzern und Mischern resultieren aus dem Vorhandensein von Firewalls und Verbindungen mit geringer Bandbreite, die beide voraussichtlich bestehen bleiben werden.

7.1 General Description (Allgemeine Beschreibung)​

Ein RTP-Übersetzer/Mischer verbindet zwei oder mehr Transport-Ebene-„Wolken" (Clouds). Typischerweise wird jede Wolke durch ein gemeinsames Netzwerk- und Transportprotokoll (z. B. IP/UDP) plus eine Multicast-Adresse und einen Transport-Ebene-Zielport oder ein Paar von Unicast-Adressen und -Ports definiert. (Netzwerk-Ebene-Protokollübersetzer, wie IP Version 4 zu IP Version 6, können innerhalb einer Wolke für RTP unsichtbar vorhanden sein.) Ein System kann als Übersetzer oder Mischer für eine Reihe von RTP-Sitzungen dienen, aber jedes wird als logisch separate Entität betrachtet.

Um die Erzeugung einer Schleife bei der Installation eines Übersetzers oder Mischers zu vermeiden, MÜSSEN die folgenden Regeln beachtet werden:

  • Jede der durch Übersetzer und Mischer verbundenen Wolken, die an einer RTP-Sitzung teilnehmen, MUSS entweder in mindestens einem dieser Parameter (Protokoll, Adresse, Port) von allen anderen verschieden sein oder MUSS auf Netzwerkebene von den anderen isoliert sein.

  • Eine Ableitung der ersten Regel ist, dass es NICHT mehrere Übersetzer oder Mischer geben darf, die parallel verbunden sind, außer durch eine Vereinbarung, bei der sie die Menge der weiterzuleitenden Quellen partitionieren.

Ebenso teilen alle RTP-Endsysteme, die durch einen oder mehrere RTP-Übersetzer oder Mischer kommunizieren können, denselben SSRC-Raum, das heißt, die SSRC-Identifikatoren MÜSSEN unter allen diesen Endsystemen eindeutig sein. Abschnitt 8.2 beschreibt den Kollisionsauflösungsalgorithmus, durch den SSRC-Identifikatoren eindeutig gehalten und Schleifen erkannt werden.

Es kann viele Arten von Übersetzern und Mischern geben, die für unterschiedliche Zwecke und Anwendungen entworfen sind. Einige Beispiele sind das Hinzufügen oder Entfernen von Verschlüsselung, das Ändern der Kodierung der Daten oder der zugrunde liegenden Protokolle oder die Replikation zwischen einer Multicast-Adresse und einer oder mehreren Unicast-Adressen. Der Unterschied zwischen Übersetzern und Mischern besteht darin, dass ein Übersetzer die Datenströme verschiedener Quellen getrennt durchlässt, während ein Mischer sie zu einem neuen Strom kombiniert:

  • Übersetzer (Translator) : Leitet RTP-Pakete mit unverändertem SSRC-Identifikator weiter; dies ermöglicht es Empfängern, einzelne Quellen zu identifizieren, selbst wenn Pakete aller Quellen durch denselben Übersetzer gehen und die Netzwerkquelladresse des Übersetzers tragen. Einige Arten von Übersetzern leiten die Daten unverändert durch, aber andere DÜRFEN die Kodierung der Daten und damit den RTP-Nutzlasttyp und Zeitstempel ändern. Falls mehrere Datenpakete in eines neu kodiert werden oder umgekehrt, MUSS ein Übersetzer den ausgehenden Paketen neue Sequenznummern zuweisen. Verluste im eingehenden Paketstrom können entsprechende Lücken in den ausgehenden Sequenznummern verursachen. Empfänger können das Vorhandensein eines Übersetzers nicht erkennen, es sei denn, sie wissen durch andere Mittel, welcher Nutzlasttyp oder welche Transportadresse von der ursprünglichen Quelle verwendet wurde.

  • Mischer (Mixer) : Empfängt RTP-Datenpaketströme von einer oder mehreren Quellen, ändert möglicherweise das Datenformat, kombiniert die Ströme auf eine Weise und leitet dann den kombinierten Strom weiter. Da die Zeitstruktur zwischen mehreren Eingangsquellen im Allgemeinen nicht synchronisiert sein wird, nimmt der Mischer Zeitkorrekturen zwischen den Strömen vor und erzeugt seine eigene Zeitstruktur für den kombinierten Strom, sodass er die Synchronisationsquelle ist. Daher MÜSSEN alle von einem Mischer weitergeleiteten Datenpakete mit dem eigenen SSRC-Identifikator des Mischers markiert sein. Um die Identität der ursprünglichen zum gemischten Paket beitragenden Quellen zu bewahren, SOLLTE der Mischer deren SSRC-Identifikatoren in die CSRC-Identifikatorliste nach dem festen RTP-Header des Pakets einfügen. Ein Mischer, der selbst eine Beitragende Quelle für ein Paket ist, SOLLTE seinen eigenen SSRC-Identifikator explizit in die CSRC-Liste für dieses Paket aufnehmen.

    Für einige Anwendungen kann es akzeptabel sein, dass ein Mischer Quellen in der CSRC-Liste nicht identifiziert. Dies führt jedoch die Gefahr ein, dass Schleifen, die diese Quellen betreffen, nicht erkannt werden können.

Der Vorteil eines Mischers gegenüber einem Übersetzer für Anwendungen wie Audio besteht darin, dass die Ausgangsbandbreite auf die eines einzigen Senders begrenzt ist, selbst wenn auf der Eingangsseite mehrere Quellen aktiv sind. Dies kann für Verbindungen mit geringer Bandbreite wichtig sein. Der Nachteil ist, dass Empfänger auf der Ausgangsseite keine Kontrolle darüber haben, welche Quellen durchgelassen oder stummgeschaltet werden, es sei denn, es wird ein Mechanismus zur Fernsteuerung des Mischers implementiert. Die Regenerierung von Synchronisationsinformationen durch Mischer bedeutet auch, dass Empfänger keine inter-mediale Synchronisation der ursprünglichen Ströme durchführen können. Ein Multi-Media-Mischer könnte dies tun.

       [E1]                                    [E6]
        |                                       |
 E1:17 |                                 E6:15 |
        |                                       |   E6:15
        V  M1:48 (1,17)         M1:48 (1,17)    V   M1:48 (1,17)
       (M1)-------------><T1>-----------------><T2>-------------->[E7]
        ^                 ^     E4:47           ^   E4:47
 E2:1 |           E4:47 |                     |   M3:89 (64,45)
        |                 |                     |
       [E2]              [E4]     M3:89 (64,45) |
                                                  |        legend:
[E3] --------->(M2)----------->(M3)------------|        [End system]
        E3:64        M2:12 (64)  ^                       (Mixer)
                                 | E5:45                 <Translator>
                                 |
                                [E5]          source: SSRC (CSRCs)
                                              ------------------->

Abbildung 3: Beispielnetz RTP mit Endsystemen, Mischern und Übersetzern

Eine Ansammlung von Mischern und Übersetzern ist in Abb. 3 gezeigt, um ihre Wirkung auf SSRC- und CSRC-Identifikatoren zu veranschaulichen. In der Abbildung sind Endsysteme als Rechtecke (benannt E), Übersetzer als Dreiecke (benannt T) und Mischer als Ovale (benannt M) dargestellt. Die Notation „M1:48(1,17)" bezeichnet ein Paket, das von einem Mischer M1 stammt, identifiziert durch M1s (zufälligen) SSRC-Wert 48 und zwei CSRC-Identifikatoren, 1 und 17, kopiert von den SSRC-Identifikatoren der Pakete von E1 und E2.

7.2 RTCP Processing in Translators (RTCP-Verarbeitung in Übersetzern)​

Zusätzlich zum Weiterleiten von (vielleicht modifizierten) Datenpaketen MÜSSEN Übersetzer und Mischer auch RTCP-Pakete verarbeiten. In vielen Fällen werden sie die von Endsystemen empfangenen zusammengesetzten RTCP-Pakete zerlegen, um SDES-Informationen zu aggregieren und die SR- oder RR-Pakete zu modifizieren. Die Retransmission dieser Information kann durch die Paketankunft oder durch den RTCP-Intervallzeitgeber des Übersetzers oder Mischers selbst ausgelöst werden.

Ein Übersetzer, der die Datenpakete nicht modifiziert, beispielsweise einer, der nur zwischen einer Multicast-Adresse und einer Unicast-Adresse repliziert, KANN RTCP-Pakete ebenfalls unverändert weiterleiten. Ein Übersetzer, der die Nutzlast irgendwie transformiert, MUSS entsprechende Transformationen in den SR- und RR-Informationen vornehmen, damit sie weiterhin die Eigenschaften der Daten und die Empfangsqualität widerspiegeln. Diese Übersetzer DÜRFEN RTCP-Pakete nicht einfach weiterleiten. Im Allgemeinen SOLLTE ein Übersetzer SR- und RR-Pakete verschiedener Quellen nicht zu einem Paket aggregieren, da dies die Genauigkeit der auf den Feldern LSR und DLSR basierenden Ausbreitungsverzögerungsmessungen verringern würde.

  • SR-Senderinformation : Ein Übersetzer erzeugt keine eigenen Senderinformationen, sondern leitet die von einer Wolke empfangenen SR-Pakete an die anderen weiter. Der SSRC bleibt unverändert, aber die Senderinformation MUSS modifiziert werden, falls die Übersetzung es erfordert. Wenn ein Übersetzer die Datenkodierung ändert, MUSS er das Feld „Sender's Byte Count" (Byte-Zähler des Senders) ändern. Wenn er auch mehrere Datenpakete zu einem Ausgangspaket kombiniert, MUSS er das Feld „Sender's Packet Count" (Paketzähler des Senders) ändern. Wenn er die Zeitstempelfrequenz ändert, MUSS er das Feld „RTP Timestamp" im SR-Paket ändern.

  • SR/RR-Empfangsberichtsblöcke : Ein Übersetzer leitet die von einer Wolke empfangenen Empfangsberichte an die anderen weiter. Beachten Sie, dass diese in die der Daten entgegengesetzte Richtung fließen. Der SSRC bleibt unverändert. Wenn ein Übersetzer mehrere Datenpakete zu einem Ausgangspaket kombiniert und damit die Sequenznummern ändert, MUSS er die inverse Manipulation für die Paketverlustfelder und das Feld „Extended Last Sequence Number" (Erweiterte letzte Sequenznummer) vornehmen. Dies kann komplex sein. Im Extremfall gibt es möglicherweise keine sinnvolle Möglichkeit, die Empfangsberichte zu übersetzen, sodass der Übersetzer keinen Empfangsbericht oder einen synthetischen Bericht basierend auf seinem eigenen Empfang weitergeben MAG. Die allgemeine Regel ist, das zu tun, was für eine bestimmte Übersetzung sinnvoll ist.

    Ein Übersetzer benötigt keinen eigenen SSRC-Identifikator, kann aber einen zuweisen, um Berichte über das von ihm Empfangene zu senden. Diese würden an alle verbundenen Wolken gesendet, jeweils entsprechend der Übersetzung des an diese Wolke gesendeten Datenstroms, da Empfangsberichte normalerweise an alle Teilnehmer multicastet werden.

  • SDES : Übersetzer leiten typischerweise die SDES-Informationen, die sie von einer Wolke empfangen, unverändert an die anderen weiter, KÖNNEN aber beispielsweise beschließen, Nicht-CNAME-SDES-Informationen herauszufiltern, falls die Bandbreite begrenzt ist. Die CNAMEs MÜSSEN weitergeleitet werden, damit die Erkennung von SSRC-Identifikatorkollisionen funktioniert. Ein Übersetzer, der eigene RR-Pakete erzeugt, MUSS SDES-CNAME-Informationen über sich selbst an dieselben Wolken senden, an die er diese RR-Pakete sendet.

  • BYE : Übersetzer leiten BYE-Pakete unverändert weiter. Ein Übersetzer, der kurz davor steht, das Weiterleiten von Paketen einzustellen, SOLLTE ein BYE-Paket an jede verbundene Wolke senden, das alle SSRC-Identifikatoren enthält, die zuvor an diese Wolke weitergeleitet wurden, einschließlich des eigenen SSRC-Identifikators des Übersetzers, falls er eigene Berichte gesendet hat.

  • APP : Übersetzer leiten APP-Pakete unverändert weiter.

7.3 RTCP Processing in Mixers (RTCP-Verarbeitung in Mischern)​

Da ein Mischer einen eigenen neuen Datenstrom erzeugt, lässt er SR- oder RR-Pakete überhaupt nicht durch, sondern erzeugt stattdessen neue Informationen für beide Seiten.

  • SR-Senderinformation : Ein Mischer lässt Senderinformationen der von ihm gemischten Quellen nicht durch, da die Eigenschaften der Quellströme im Mix verloren gehen. Als Synchronisationsquelle SOLLTE der Mischer eigene SR-Pakete mit Senderinformationen über den gemischten Datenstrom erzeugen und sie in dieselbe Richtung wie den gemischten Strom senden.

  • SR/RR-Empfangsberichtsblöcke : Ein Mischer erzeugt eigene Empfangsberichte für Quellen in jeder Wolke und sendet sie nur an dieselbe Wolke. Er DARF diese Empfangsberichte nicht an die anderen Wolken senden und DARF Empfangsberichte von einer Wolke nicht an die anderen weiterleiten, da die Quellen dort keine SSRCs (nur CSRCs) wären.

  • SDES : Mischer leiten typischerweise die SDES-Informationen, die sie von einer Wolke empfangen, unverändert an die anderen weiter, KÖNNEN aber beispielsweise beschließen, Nicht-CNAME-SDES-Informationen herauszufiltern, falls die Bandbreite begrenzt ist. Die CNAMEs MÜSSEN weitergeleitet werden, damit die Erkennung von SSRC-Identifikatorkollisionen funktioniert. (Ein Identifikator in einer von einem Mischer erzeugten CSRC-Liste könnte mit einem von einem Endsystem erzeugten SSRC-Identifikator kollidieren.) Ein Mischer MUSS SDES-CNAME-Informationen über sich selbst an dieselben Wolken senden, an die er SR- oder RR-Pakete sendet.

    Da Mischer keine SR- oder RR-Pakete weiterleiten, werden sie typischerweise SDES-Pakete aus einem zusammengesetzten RTCP-Paket extrahieren. Um den Overhead zu minimieren, KÖNNEN Blöcke aus den SDES-Paketen zu einem einzigen SDES-Paket aggregiert werden, das dann auf einem vom Mischer stammenden SR- oder RR-Paket gestapelt wird. Ein Mischer, der SDES-Pakete aggregiert, wird mehr RTCP-Bandbreite als eine einzelne Quelle verwenden, da die zusammengesetzten Pakete länger sind, aber das ist angemessen, da der Mischer mehrere Quellen repräsentiert. Ebenso wird ein Mischer, der SDES-Pakete wie empfangen durchleitet, RTCP-Pakete mit einer höheren als der Einzelquellenrate übertragen, aber auch das ist korrekt, da die Pakete von mehreren Quellen stammen. Die RTCP-Paketrate kann auf jeder Seite des Mischers unterschiedlich sein.

    Ein Mischer, der keine CSRC-Identifikatoren einfügt, KANN auch davon absehen, SDES-CNAMEs weiterzuleiten. In diesem Fall sind die SSRC-Identifikatorräume in den beiden Wolken unabhängig. Wie zuvor erwähnt, erzeugt dieser Betriebsmodus die Gefahr, dass Schleifen nicht erkannt werden können.

  • BYE : Mischer MÜSSEN BYE-Pakete weiterleiten. Ein Mischer, der kurz davor steht, das Weiterleiten von Paketen einzustellen, SOLLTE ein BYE-Paket an jede verbundene Wolke senden, das alle SSRC-Identifikatoren enthält, die zuvor an diese Wolke weitergeleitet wurden, einschließlich des eigenen SSRC-Identifikators des Mischers, falls er eigene Berichte gesendet hat.

  • APP : Die Behandlung von APP-Paketen durch Mischer ist anwendungsspezifisch.

7.4 Cascaded Mixers (Kaskadierte Mischer)​

Eine RTP-Sitzung kann eine Ansammlung von Mischern und Übersetzern wie in Abb. 3 umfassen. Wenn zwei Mischer kaskadiert sind, wie M2 und M3 in der Abbildung, können vom Mischer empfangene Pakete bereits gemischt worden sein und eine CSRC-Liste mit mehreren Identifikatoren enthalten. Der zweite Mischer SOLLTE die CSRC-Liste für das ausgehende Paket unter Verwendung der CSRC-Identifikatoren bereits gemischter Eingabepakete und der SSRC-Identifikatoren unmittelbarer Eingabepakete aufbauen. Dies ist im Ausgangsbogen des Mischers M3 mit der Bezeichnung M3:89(64,45) in der Abbildung gezeigt. Wie im Fall nicht kaskadierter Mischer kann, falls die resultierende CSRC-Liste mehr als 15 Identifikatoren hat, der Rest nicht aufgenommen werden.