WikiDer > Echtzeit-Transportprotokoll

Realtime Transport Protocol

Echtzeit-Transportprotokoll, abgekürzt RTP, ist ein Protokoll, das ein standardisiertes Paketformat definiert, um Audio- und Video über die Internet senden. Es wurde ursprünglich als ein Multicast-Protokoll ist aber auch in vielen Unicast-Anwendungen angewendet. RTP wird oft verwendet für Streaming-Media-Systeme (zusammen mit RTSP) und für Videokonferenzsysteme (zusammen mit H.323 oder SCHLUCK). RTP ist der technische Gründer der Voice over IP-Industrie. Das Echtzeit-Transportkontrollprotokoll (RTCP), die zusammen mit RTP definiert ist in RFC 3550, verarbeitet Feedback, Synchronisation und die Benutzeroberfläche.[1]

Geschichte

UDP wird häufig für Client-Server-RPC verwendet. UDP wird auch häufig für Echtzeit-Multimedia-Anwendungen verwendet. Aufgrund der zunehmenden Popularität von Internettelefon, Videokonferenzen, Video auf Nachfrage und anderen Multimedia-Anwendungen kamen Anwendungsdesigner zu dem Schluss, dass sie eigentlich alle versuchten, mehr oder weniger das gleiche Echtzeit-Transportprotokoll zu erfinden. Es entstand der Eindruck, dass ein generisches Echtzeit-Transportprotokoll für verschiedene Anwendungen sinnvoll sein könnte. Damals entstand RTP, das Echtzeit-Transportprotokoll. Es ist beschrieben in RFC 3550[1] und wird jetzt weithin für Multimediaanwendungen verwendet.

RTP wurde von der Audio-Video Transport Working Group der . entwickelt IETF und wurde 1996 als RFC 1889.[2] RTP wird auch von der . veröffentlicht ITU-T als H.225.0. Das Protokoll existiert als Internet Draft Standard, definiert in den Texten RFC 3550[3] (in letzter Zeit RFC 1889), die das Protokoll spezifiziert und in RFC3551[4] (in letzter Zeit RFC 1890), das ein spezifisches Profil für Audio- und Videokonferenzen definiert.

Echtzeit-Transportprotokoll

Bild, das die Position von RTP im Protokollstapel und die Paketverschachtelung zeigt.
(a) Die Position von RTP im Protokollstapel. (b) Verschachtelung von Paketen.

Wir beschreiben zwei Aspekte des Echtzeitverkehrs. Das erste ist das RTP-Protokoll zum Transportieren von Audio- und Videodaten in Paketen. Der zweite Aspekt wird durch das RTCP-Protokoll bereitgestellt. Dies ist die Verarbeitung, die hauptsächlich beim Empfänger stattfindet, um Audio und Video zum richtigen Zeitpunkt abzuspielen. Diese Funktionen passen in die Protokollstack wie in Abbildung 1 gezeigt. RTP läuft normalerweise im Userspace über UDP (im Betriebssystem). Es geht so. Die Multimedia-Anwendung besteht aus verschiedenen Audio-, Video-, Text- und ggf. weiteren Streams und verpackt diese in RTP-Pakete, die dann über einen Socket gesendet werden. Auf der Betriebssystemseite des Sockets werden UDP-Pakete generiert, um RTP-Pakete zu umhüllen und an IP zur Übertragung über eine Verbindung wie . übergeben Ethernet. Der umgekehrte Vorgang findet beim Empfänger statt. Die Multimediaanwendung empfängt schließlich Multimediadaten von der RTP-Bibliothek. Dieser ist für das Abspielen der Medien zuständig.

Die Grundfunktion von RTP besteht darin, verschiedene Echtzeit-Datenströme zu übertragen Multiplexen zu einem Stream von UDP-Paketen. Der UDP-Stream kann an ein Ziel gesendet werden (Unicasting) oder zu verschiedenen Zielen (Multicasting). Da RTP nur normales UDP verwendet, werden die Pakete in den Routern keiner spezifischen Behandlung unterzogen, es sei denn, es gibt eine Servicequalität (QoS) Funktionalität ist möglich. In jedem Fall gibt es keine Garantien für die Lieferung und Pakete können verloren gehen, verspätet oder beschädigt werden. Das RTP-Format enthält mehrere Funktionen, die Empfängern bei der Arbeit mit Multimedia-Informationen helfen.

Sequenznummer

Jedem Paket in einem RTP-Datenstrom wird eine Nummer höher als die des vorherigen Pakets zugewiesen. Anhand dieser Nummerierung kann das Ziel feststellen, ob Pakete fehlen. Wenn ein Paket fehlt, hängt die beste Zielaktion von der Anwendung ab. Die Aktion kann beispielsweise ein Videobild überspringen (für Video) oder einen fehlenden Wert um . ausfüllen Interpolation (mit Ton). Ein erneutes Versenden ist nicht praktikabel, da das erneut gesendete Paket viel zu spät ankommen würde. Daher hat RTP keine Bestätigungen und keinen Mechanismus, um das erneute Senden von Paketen anzufordern.

Datenfeld

Das Datenfeld eines RTP-Pakets kann unterschiedlich sein Proben und sie können beliebig codiert werden, wie es die Anwendung wünscht. Um mit den unterschiedlichen Netzwerken zu arbeiten, definiert RTP unterschiedliche Profile und für jedes Profil können unterschiedliche Verschlüsselungsformate zugelassen werden. Beispielsweise kann ein Audiostream als 8-Bit kodiert werden PCM bei 8kHz. RTP enthält ein Header-Feld, in dem die Quelle die Verschlüsselung angeben kann, aber ansonsten nicht in die Durchführung der Verschlüsselung eingreift.

Zeitstempel

Eine weitere Möglichkeit, die in Echtzeitanwendungen dringend benötigt wird, ist die Zeitstempelung. Die Idee ist, dass die Quelle dem ersten Sample in jedem Paket einen Zeitstempel angibt. Die Zeitstempel sind relativ zum Anfang des Streams, daher ist nur der Unterschied zwischen den Zeitstempeln wichtig. Die absoluten Werte haben keine Bedeutung. Wie wir gleich beschreiben werden, ermöglicht dies dem Ziel, in begrenztem Umfang zu puffern und jeden Abtastwert mit der entsprechenden Anzahl von Millisekunden nach dem Start des Streams zu rendern, unabhängig davon, wann das Paket mit diesem Abtastwert angekommen ist. Der Zeitstempel reduziert nicht nur die Auswirkungen der Variation der Netzwerkverzögerung, sondern ermöglicht auch die Synchronisierung verschiedener Streams miteinander. Beispielsweise kann ein digitales Fernsehprogramm einen Videostream und zwei Audiostreams aufweisen. Diese beiden Audiostreams können Stereotonsignal oder zwei Soundtracks in verschiedenen Sprachen für den Zuschauer zum Anhören. Jeder Stream stammt von einem anderen physischen Gerät, aber wenn sie einen Zeitstempel verwenden, der von einem Zähler stammt, ist es möglich, sie synchron anzuzeigen, auch wenn die Streams diskontinuierlich gesendet und/oder empfangen wurden.

RTP-Header

Der RTP-Header
Der RTP-Header

Der RTP-Header besteht aus drei 32-Bit-Wörtern und möglicherweise einigen Erweiterungen. Das erste Wort enthält das Versionsfeld, das bereits den Wert 2 hat. Es ist zu hoffen, dass diese Version bereits nahe an der ultimativen Version ist, da nur noch eine Versionsnummer übrig ist (obwohl 3 durch die tatsächliche Version im Erweiterungswort definiert werden könnte).

Das P-Bit zeigt an, dass das Paket auf ein Vielfaches von 4 Byte aufgefüllt wird. Das letzte Padding-Byte gibt an, wie viele Bytes zum Padding verwendet wurden. Das X-Bit zeigt an, dass ein Erweiterungsheader vorhanden ist. Format und Bedeutung des Extension-Headers sind nicht definiert. Definiert ist lediglich, dass das erste Wort der Erweiterung seine Länge enthält. Dies ist eine Notfalleinrichtung für die Zukunft.

Das CC-Feld zeigt an, wie viele Ressourcen verwendet werden und kann einen Wert zwischen 0 und 15 haben. Das M-Bit ist ein anwendungsspezifisches Flag-Bit. Es kann verwendet werden, um den Anfang eines Videoframes, den Anfang eines Wortes in einem Audiokanal oder alles andere zu markieren, was die Anwendung versteht. Das Datenfeld zeigt an, welcher Verschlüsselungsalgorithmus verwendet wurde. Da jedes Paket dieses Feld enthält, ist es möglich, während des Versands auf eine andere Verschlüsselungsmethode umzuschalten. Die Sequenznummer ist ein Zähler, der nach jedem gesendeten RTP-Paket um eins erhöht wird. Ermöglicht die Erkennung verlorener Pakete.

Der Zeitstempel wird von der Streamquelle generiert, um anzugeben, wann das erste Beispiel im Paket erstellt wurde. Dieser Wert kann dazu beitragen, die Variation des Timings, den Jitter, beim Empfänger zu reduzieren, indem die Rendering-Zeit vom Zeitpunkt des Paketankommens entkoppelt wird. Die Synchronisationsquellenkennung gibt den Stream an, zu dem das Paket gehört. Es verwendet das gleiche Verfahren wie das Multiplexen und Demultiplexen verschiedener Datenströme in einen Strom von UDP-Paketen. Schließlich werden die beitragenden Quellenkennungen verwendet, wenn Mischpulte im Studio verwendet werden. In diesem Fall ist der Mischer die Synchronquelle und die zu mischenden Ströme werden aufsummiert.

Sicheres RTP

Es gibt auch eine „sichere“ oder sichere Version von RTP, nämlich SRTP. Diese sichere Version wird beschrieben in RFC 3711[5].

Verweise

  • Tanenbaum, A. (2003). Computernetzwerke. Oberer Saddle River: Prentice Hall.
  • Schulzrinne, H. (2003). RTP: Ein Transportprotokoll für Echtzeitanwendungen. Universität von Columbia. Abgerufen am 3. Dezember 2013. (RFC 3550)
  • Lazzaro, J. (2006). RFC4571: Framing Real-time Transport Protocol (RTP) und RTP Control Protocol (RTCP) Pakete über verbindungsorientierten Transport. UC Berkeley. Abgerufen am 3. Dezember 2013. (RFC 4571)
  • Perkins, C. (2003). RTP: Audio und Video für das Internet. Boston: Addison Wesley.

Externe Links