2.4.2 RTP-Protokollelemente

Jedem zu sendenden Datenpaket wird ein Kopf vorangestellt. Der Kopf besitzt einen festen Teil, der eine Größe von 12 Byte hat. Diesem festen Teil kann eine Liste sogenannter "Beitragsquellen" (Contributing SouRCe - CSRC) folgen. Im Anschluß daran ist noch eine Kopf-Erweiterung möglich. Da im Zusammenhang mit RTP noch kaum deutschsprachige Begriffe etabliert sind, haben wir in diesem Abschnitt die Bilder mit den englischen Originalbegriffen beschriftet:

Die Felder haben folgende Bedeutung:

Es mag Sie etwas verwundern, daß hier von zwei unterschiedlichen Quellen die Rede war ("Synchronization Source" - "Contributing Source"), weil Sie bisher gewohnt waren, daß Transportprotokolle nur in Endsystemen eingesetzt werden und es folglich nur eine Sorte von Quellen geben sollte. Bei RTP wurden nun zwei Ausnahmefälle von "Zwischensystemen" eingeführt, die eine Anpassung an sehr heterogene Verbindungsqualitäten, Umkodierungen usw. ermöglichen: Ein Mixer empfängt Datenpakete von einem oder mehreren Sendern. Die Daten werden auf eine bestimmte Art verarbeitet, neu synchronisiert und möglicherweise umkodiert. Alle RTP-Pakete haben einen SSRC-Identifikator, der ihren Sender bestimmt. Der Mixer erzeugt neue Datenpakete und ist deshalb auch ein Sender. Aus diesem Grund trägt er einen eigenen SSRC-Identifikator in die durch ihn generierten Pakete ein.

Die SSRC-Identifikatoren der Pakete, die der Mixer empfangen hat, um aus ihnen neue Pakete herzustellen, gehen nicht automatisch verloren, sondern werden in der Regel nach Möglichkeit in die max. 15 Elemente umfassende Liste der CSRC-Identifikatoren eingetragen, die Bestandteil jedes neu entstandenen Pakets ist.

Als Anwendungsbeispiel für einen Mixer nehmen wir folgenden Fall an:

In einer Audiokonferenz sind die Teilnehmer A und B durch ein Hochgeschwindigkeitsnetz miteinander verbunden, während die Datenübertragungsrate zu anderen Teilnehmern (E und F) nur gering ist. Anstatt nun alle Teilnehmer mit einer schlechten Audio-Qualität abzuspeisen oder einen Teil der Empfänger von der Konferenz auszuschließen, existiert auch noch ein dritter Weg. Dabei empfängt ein Mixer M die Pakete der Sender (A und B) , mischt diese und konvertiert sie in ein Format, das eine geringere Datenübertragungsrate als zuvor benötigt.

Zum Beispiel kann der Dynamikbereich der Audiodaten verringert werden (8-Bit-Samples statt 16-Bit ...). Auch die Verringerung der Abtastfrequenz oder eine Datenkompression sind Möglichkeiten, die Datenrate zu senken. Diese Daten werden dann durch den Mixer zu den Teilnehmern geschickt, die eine schlechte Anbindung an die Konferenz haben (in unserem konkreten Fall sind E und F nur passiv, d.h. zuhörend an der Konferenz beteiligt).

Damit ein Konferenzteilnehmer entscheiden kann, in welcher Qualität er die Audiodaten empfangen möchte, werden jetzt zwei Multicast-Gruppen benötigt. Zu der einen Gruppe schicken alle Sender ihre Daten. Konferenzteilnehmer, die Mitglied in dieser Gruppe sind, erhalten die Audiodaten direkt von den Sendern (ohne Qualitätseinbuße). Die anderen Konferenzteilnehmer werden Mitglied in der anderen Multicast-Gruppe, an die der Mixer seine Audiodaten sendet.

An dieser Stelle sollte auch ein wichtiger Grund dafür klar werden, warum ein Mixer eine Liste der "Beitragsquellen" in den von ihm generierten RTP-Paketen mitschickt. Nur so sind Schleifen zwischen mehreren Mixern erkennbar, die durch Fehlkonfigurationen entstanden sein könnten.

Eine andere Art von Zwischensystemen sind die Übersetzer (Translator). Sie leiten die ankommenden RTP-Pakete weiter, ohne deren SSRC-Identifikator zu verändern. Ein Übersetzer führt nur eine Umkodierung der RTP-Nutzdaten durch. Es erfolgt im Gegensatz zum Mixer keine Zusammenfassung von Datenpaketen. Deshalb ist auch keine Resynchronisation des Paketstroms notwendig.

Eine Anwendung für Übersetzer ist der Übergang von der Multicast- zur Unicast-Kommunikation. Dieser Fall tritt dann ein, wenn Hosts an einer MBONE-Konferenz teilnehmen möchten, aber nicht direkt an das MBONE angeschlossen sind. Der Übersetzer verschickt dann den Inhalt der Multicast-Pakete mit Hilfe von Unicast-Paketen an die einzelnen Empfänger außerhalb des MBone:

Der Multicast-Bereich (MBONE) umfaßt hier A, B und T. Teilnehmer E ist nur durch eine bidirektionale Unicast-Kommunikation erreichbar. Er kann über den Übersetzer (Translator) T an der Konferenz teilnehmen. Weitere Anwendungsfälle für Übersetzer gibt es im Zusammenhang mit Firewalls.


© Patrick Voigt, Uwe Hübner 31.5.1998