Papers
Papers
Home > Papers > RSVP/RTP
RSVP | Funktionsprinzip | Reservierungsmechanismus | Fazit: RSVP | RTP | Anwendungsfälle | RTCP | Fazit: RTP/RTCP | Literatur | Folien

Resource Reservation Protocol / Realtime Transport Protocol
Anwendungsfälle

Betrachten wir nun die Funktionsweise von RTP anhand verschiedener Anwendungsfälle. Ausgehend von einer einfachen Konferenz steigern wir dabei die Komplexität der Szenarien.

Einfache Audiokonferenz

Einfache Audiokonferenz Um eine Audiokonferenz aufzubauen, müssen die Teilnehmer sich zunächst auf eine Multicast-Adresse und zwei Port-Nummern für die RTP- und RTCP-Pakete einigen.

Während der Konferenz verpackt jeder Teilnehmer den von ihm erzeugten Audio-Datenstrom in RTP-Pakete fester Größe. Die RTP-Pakete werden an die Multicast-Adresse geschickt und vom Netz an alle Teilnehmer weitergeleitet. Anhand der Zusatzinformationen, die jedes RTP-Paket neben den Nutzdaten enthält, bringt der Empfänger die Pakete in die richtige Reihenfolge, synchronisiert sie, identifiziert das gekapselte Datenformat und baut daraus die Nutzdatenströme für die Wiedergabe zusammen. Jede Datenquelle wird dazu im RTP-Paket über eine eindeutige Kennung (Synchronization Source, SSRC) identifiziert.

Da während der Konferenz die für bestimmte Teilnehmer zur Verfügung stehende Bandbreite schwanken kann, verschickt jede Station periodisch RTCP-Pakete mit Statistiken über ihre Empfangsqualität.

Jeder Teilnehmer sendet außerdem in zeitlichen Abständen Meta-Informationen über sich (eindeutige Teilnehmer-Kennung, Realname, e-Mail-Adresse, Standort, Anwendungsprogramm etc.). Dies dient zum einen der Verknüpfung von Datenquellen und Teilnehmern, zum anderen erkennen auf diese Weise alle Teilnehmer, wenn ein neuer Teilnehmer der Konferenz beitritt oder ein anderer sie verläßt.

Multiplexen mehrerer Medien

Multiplexen mehrerer Medien Wenn jeder Teilnehmer Datenströme verschiedener Medien generiert (in einer Videokonferenz z.B. Audio- und Videosignal), so werden diese in getrennten RTP-Sessions übertragen. Die Ströme werden nicht über ein Feld im RTP-Header wie "Nutzdatentyp" oder "Synchronisation Source" gemultiplext, sondern über ihre Zieladresse (IP-Adresse und Port). Für den zweiten Strom wird folglich ein neues Port-Paar (einer für RTP und einer für RTCP) benötigt.

Dies hat zum einen technische Gründe - die Implementierung des Protokolls würde aufwändiger, wenn es einen eigenen Multiplex-Mechanismus bereitstellen müsste. Zum anderen ermöglicht es die Übertragung in getrennten Sessions, beim Transport verschiedene Netzwerkpfade und Ressourcen zu verwenden sowie beim Teilnehmer die Verarbeitung in getrennten Prozessen zu implementieren. Zudem kann ein Teilnehmer, der nur über geringe Bandbreite verfügt, sich entscheiden, vollständig auf ein Medium zu verzichten und z.B. nur Audio übertragen.

Obwohl in unserem Beispiel Video- und Audiosignal eines Teilnehmers in getrennten Sessions übertragen werden, müssen sie für die Wiedergabe natürlich verknüft werden. Die Zuordnung zu einem bestimmten Teilnehmer geschieht über die eindeutige Teilnehmerkennung, die regelmäßig via RTCP übertragen wird; die Synchronisation erfolgt über die Zeitstempel in jedem RTP-Paket.

Mixer

Mixer In einigen Fällen kann es sinnvoll sein, Datenströme von mehreren Teilnehmern zu kombinieren und als einzelnen Datentrom weiterzuleiten. Diese Aufgabe wird von einem sog. Mixer übernommen.

Ist ein Teilnehmer einer Audiokonferenz z.B. mit geringerer Bandbreite angebunden, so kann ein Mixer an den Anfang des betreffenden Netzabschnitts gesetzt werden. Er kombiniert die bei ihm eintreffenden Ströme, indem er die Audiosignale decodiert, zusammenmischt und das Ergebnis mit einem stärker komprimierenden Verfahren wieder codiert, um es als neuen Strom weiterzuleiten. Der Empfänger des neuen Stroms kann entweder ein einzelner Teilnehmer oder eine weitere Multicast-Gruppe sein.

Da der Mixer somit selbst zur Datenquelle wird, trägt er sich selbst als Synchronisation Source im RTP-Header jedes Pakets ein. Die ursprünglichen Pakete gehen verloren, um den Empfängern dennoch mitzuteilen, von welchen Sendern die zusammengemischten Daten stammen, ergänzt er jedes Paket um eine Liste von Contributing Sources (CSRC).

Translator

Translator Ein weiteres Element, das in RTP-Netzen eingesetzt werden kann, ist der Translator: Er kann RTP-Pakete auf verschiedene Arten verändern, bewahrt dabei jedoch im Unterschied zum Mixer ihre Identität.

Translatoren können z.B. das Nutzdatenformat von Strömen paketweise ändern, ohne sie zusammenzumischen, um Verbindungen mit geringerer Bandbreite oder Teilnehmer mit anderer Technologie zu bedienen.

Ein anderes Anwendungsgebiet ist die Überbrückung von Firewalls: Läßt eine Firewall z.B. keine Multicast-Pakete durch, so kann ein Translator auf der Außenseite die eingehenden Pakete per Unicast an einen Translator auf der Innenseite übertragen, der sie per Multicast an die inneren Teilnehmer weiterleitet.

RTP | RTCP >

© 2000 Matthias Book