verfasst von Nico VanHaute, Julien Barascud et Jean-Roland Conca

Einführung : Was sind RTP und RTCP ?

Die Rechnerverbreitung, die Verfügbarkeit von preisgünstigen Informatik Geräte des Audiovisuellen Bereich, sowie die zuletzt verfügbaren Verbindungen mit immer höheren Durchsatzvermögen, lassen die Tendenz auftauchen, das Internet als Träger zu verwenden für Audio/Video Belange, Datentypen die traditionellerweise den Sondernetze reserviert waren; so das seit einigen Jahren Audio- sowie Videokonferenzen nun mehr dem Alltag angehören. Aus der Natur selbst von Internet, wird ersichtlich dass dieses Netz nicht gerade für Echtzeitübertragung angepasst wurde; Dies hat zur Folge, die Güte der Audioübertrangungen im Internet lassen weitgehend zu Wünschen übrig. Diese Arbeit ist gewidmet der Analyse und Problemlösungen, mit dem Ziel einer Internet-Applikation zu audiovisuellen bzw VoIP Eigenschaften zu verhelfen und zu reelen Anpassungsfähigkeiten für eine akzeptable Audiogüte, selbst in Fällen von Neztstauungen. Diese Lösungen, in Form von Kontrollschemata, wurden implementiert und getestet mit der, von uns selbst entwickelte Audiokonferenz und VoIP Software Free Phone. Eine Verhaltensstudie über diese Schemata zum Einbetten des Dienst Fair Queueing in einem sich immer mehr entwickelnden Internet, zeigte das diese Verfahren noch bessere Leistungen in diese Netzumgebung.

RTP (Real-time Transfert Protocole)

Das Ziel von RTP ist das stetige Übertragen über IP, von Daten deren Realzeit-Verhalten sehr relevant ist (Audio, Video, …) Die allerwichtigste Rolle von RTP besteht aus dem Erzeugen für IP Pakete mit Sprach- oder VideoInformationen, von Sequenznummern und sie mit Fähigkeiten zu versehen, in der nächst tiefer liegenden Ebene, die Ordnung der Pakete zu verändern.

Allgemeiner betrachtet, erlaubt RTP :

• das Identifizieren der übertragenen Information,
• das Eingliedern von Zeitmarken und Sequenznummern in die transportierte Information
• das Überwachen der Ankunft der Pakete.

RTCP (Real-time Transfert Control Protocole)

Das RTCP Protokoll ruht auf die Zeitsequentielle Übertragung von Kontrollpakete von sämtlichen Teilnehmer einer Sitzung

Dies ist ein RTP Stromkontrollprotokoll, mit dem Grundinformationen auf den Teilnehmer einer Sitzung und die Dienstgüte, verteilt werden.

Die vorgesehen Verwendung von RTP und RTCP

RTP dient der Verwaltung von Multimedia Ströme (Sprache, Video) über IP. RTP laüft mit dem UDP Protokoll. Der RTP Header enthält Informationen über synchronisation sowie Nummerierung. Die Datenkodierung hängt vom Typ der Datenkompression ab. Das RFCxxxx erklärt RTP, dagegen ist die Anpassung einer Kompressionmethode an RTP, Stand eines Sonder-RFC, z.B. H261 auf RTP steht im RFCxxxx. Je Stromtyp wird ein RTP Kanal eingesetzt : eins für Audio und eins für Video. Das Feld xxx dient der Synchronisierung. RTP bietet ein Dienst von Anfang bis zum Ende. Er setzt einen Header zu mit Informationen über notwendiges Timing der Synchronisierung des Realzeit Strom vom Typ Ton und Bild. RTP (Realtime Transport Protocol) und sein Geselle RTCP (Realtime Transport Control Protocol) erlauben jedes für sich, den Transport und die Kontrolle von Datenflüsse mit Realtime Eigenschaften. RTP und RTCP sind Protokolle auf Applikationsebene und nutzen die Protokolle der niedrigeren Schicht TCP oder UDP. Aber es im Allgemeinen UDP vorgezogen. RTP und RTCP können genauso gut den Modus Unicast (point-to-point) wie den Modus Multicast (Multipoint). Sie nutzen jeder für sich einen separaten Port getrennt durch ein Portenpaar. RTP nutzt den geraden Port und RTCP den ungeraden unmittelbar darüber liegenden Port.

Header- und Daten-Formate

Der RTP Header beinhaltet folgende Informationen :

<--------------------------- 32 bits --------------------------->

Hier die Erläteruing der einzelnen Felder im Header :

• Das Feld Version V in 2 bit Länge zeigt die Protokoll version (V=2)
• Das Feld Padding P : 1 bit, wenn P=1, das Paket enthält die zusätzliche FüllBytes (padding) zum Füllen des letztenPaket.
• Das Feld extension X : 1 bit, wenn X=1 kommt dem Header ein erweiterungspaket nach
• Das Felder CSRC count CC : 4 bit, enthält die Zahl der CSRC die nach dem Header kommen
• Das Feld marker M : 1 bit, seine bedeutung hängt vom Applikationsprofile (profile)
• Das Feld payload type PT : 7 bit, zeigt die Art von Payload an (audio, video,bild,text,html,etc…)
• Das Feld Sequenz number : 16 bit, sein erster Wert ist willkürrlichdann wird es um 1 inkrementiert mit jedem gesendeten Paket; er kann dazu dienen die verlorenen Paket ausfindig zu machen.
• Das Feld Timestamp : 32 bit, spiegelt den Zeitpunkt an dem das erste Byte im RTP Paket ausgemustert wurde. Dieser Zeitpunkt stammt von einem monoton-stetigen Timer damit das Synchronisationsprozess und die Berechnung des jitter für die Ziel Station
• Das Feld SSRC : 32 bit, identifiziert eindeutig die Quelle, ihr Wert wird von der Applikation willkürlich gewählt . Das Feld SSRC identifiziert die Synchronisierungsquelle (oder einfacher die "die Quelle"). Dieser Identifier ist willkürlich mit dem Vorzug der Eindeutigkeit zwischen allen Quellen einer Sitzung. Die Liste der CSRC identifiziert die Quellen (SSRC) die beitrugen bei der Erzeugung der Paketdaten mit den Identifikatoren. Le Zahl der Identifikatoren steht im Feld CC.
• Das Feld CSRC : 32 bit, identifiziert die beitragenden Quellen

Der Header RTCP

Das Ziel von RTCP sei die Lieferung von verschiedene Informationstypen und eine Rückmeldund der Empfangsgüte betreffend.

Der Header beinhaltet folgende Informationen :

• Das Feld Version (2bit)
• Das Feld Padding (1 bit) zeigt eine Füllung deren Grösse im letzten Byte steht
• Das Feld reception report count (5 bit) : die anzahl der Meldungen im Paket
• Das Feld paket Type (8 bit) 200 für SR
• Das Feld length (16 bit) Länge des Pakets in 32 bit Worte
• Das Feld SSRC 32 bit) : Identifizierung des mit der Quelle verbundenen Empfänger
• Das Feld NTP timestamp 64 bit)
• Das Feld RTP timestamp (32 bit)
• Das Feld sender's packet count (32 bit)
• Das Feld sender's octet count (32 bi) Statistik
• Das Feld SSRC-n (32 bit) QuellNummer der analysierten Daten
• Dazs feld fraction lost (8 bit)
• Das Feld cumulative number of packets lost (24 bit)
• Das Feld extended highest sequence number received (32 bit)
• Das Feld interarrival jitter ( 32 bit). Dies ist eine Abschätzung des Zeitintervals eines RTP Datenpaket gemessen am Timestamp in Form einer ganzen Zahl. Das ist, in der Tat, die relative Durchquerzeit zwischen zwei Datenpakete
  Die Formel dafür ist :  J=J+(|D(i-1,i)|-J)/16
  Der interarrival jitter wird berechnet bei jedem Datenpaket aus der Quelle SSRC_n
  i --> erstes Paket
  i-1 --> vorriges Paket
  D --> Differenz
  J --> Zweites Paket
• Das Feld last SR timestamp (32 bits)
• Das Feld delay since last SR (32 bits)

Wie wirkt RTCP vs. RTP ?

RTCP ist ein an RTP assoziiertes Protokoll, er misst Leistungen, aber liefert dafür keine Garantien. Dafür müsste man ein reservation protocole der Art RSVP oder sich vergewissern das die benuzten Kommunikationsknoten richtig dimensioniert wurden in Bezug auf ihre Einsatzverwendung.

Oberhalb welcher Protokolle laufen RTP undRTCP ?

RTP/RTCP liegt oberhalb des UDP/TCP Transport, und praktisch oberhalb von UDP
RTP ist ein Sitzungprotokoll, es sitzt aber innerhalb der Applikation. Das Integrieren obliegt dem Software-Entwickler.

Wie wird der Datenstrom transportiert ?

RTP hat nichts mit dem Stromtyp zu tun, es liegt über UDP das selbst über IP steht. Der Stromtyp ist theoretisch in IP benutzt.
RTP bringt eine Sequenznummer, ein time Stamp und einen eindeutigen Identifier für die Quelle (SSRC).

verfasst von Nico VanHaute, Julien Barascud et Jean-Roland Conca