Rheinisch-Westfälische Technische Hochschule Aachen

Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol

PROSEMINAR KOMMUNIKATIONSPROTOKOLLE SS 2003

Real – Time Transport Protocol RTP / RTCP

von Ilia Gurevich

Matrikelnummer : 234097

Betreuung : Dipl.-Inform. Imed Bouazizi

2

3

Inhaltsverzeichnis

1. Einleitung…………………………………………………………………....... 4

2. Struktur eines RTP-Pakets…………………...……………………….……… 6

2.1. Experimentelle RTP-Header Erweiterung……………………….…... 8

3. Anwendungsspezifische Erweiterung des RTP-Headers (Profile)…… 8

3.1. Beispiel eines MPEG Profils……………………………………........... 9

4. RTCP…………………………………………………………………………… 9

4.1. RTCP Pakettypen………………………………………………………. 10

4.2. Funktionen von RTCP………………………………………………….. 10

4.3. Sender- und Empfängerberichte…………………………………… 11

4.4. Beispiel eines Receiver Reports………………………………………. 13

4.5. SDES Pakete……………………………………………………………… 13

4.6. Beispiel eines SDES Pakets…………….………………………........... 15

4.7. Berechnung der Sendeperiode für RTCP Pakete ………………...15

5. Jitter……………………………………………………………………………. 16

6. Round-Trip Time……………………………………………………………… 17

7. Mixer und Translator………………………………………………………… 18

8. Zusammenfassung……………………………………………………………20

9. Literatur………...……………………………………………………………….21

4

1. Einleitung

Das Real -Time Transport Protocol (RTP) ist ein Internet - Protokoll, das für die Übertragung von audiovisuellen Daten in Echtzeit benutzt wird. Es wird beispielsweise fürs Telefonieren übers Internet mittels einer Eins- zu- Eins Verbindung (Unicast) eingesetzt oder für Videokonferenzen zwischen mehreren Teilnehmern, wobei Videodaten an mehrere Empfänger gleichzeitig geschickt werden (Multicast). Dadurch dass RTP so genannten Profils (Erweiterungen) unterstützt, können unterschiedliche Anwendungen dieses Transportprotokoll verwenden. Das RTP-Protokoll gliedert sich in zwei Teilprotokolle, die unabhängig voneinander funktionieren. Das RTP Data Transfer Protocol transportiert Nutzdaten in Echtzeit. Das RTP Control Protocol (RTCP) stellt Informationen über Qualität der Übertragung dar und gibt Auskunft über alle Teilnehmer einer Sitzung (Session). Die RTCP Daten werden über eine von RTP unabhängige Leitung transportiert. Der am weitesten verbreitete Transportprotokoll TCP ist für die Übertragung von RTP nicht geeignet, da TCP die verlorenen Datenblöcke erneut an den Empfänger sendet, was bei einer Echtzeitübertragung unpassend ist. Außerdem erlaubt TCP kein Multicasting. Deshalb setzt RTP auf UDP auf, der Multicasting unterstützt.

Abbildung 1: Schematische Darstellung einer Datenübertragung mittel s RTP

5

Abbildung 1 stellt anhand einer Audioübertragung schematisch dar, auf welche Weise Daten zwischen einem Sender und einem Empfänger bei der Benutzung von RTP transportiert werden. Da Multicasting möglich ist, können diese Audiodaten auch an mehrere Teilnehmer geschickt werden. Jeder Teilnehmer der Sitzung braucht dafür einen UDP- Port mit separaten RTP und RTCP – Anschlüssen und eine IP-Adresse. Im Falle einer audiovisuellen Übertragung müssten sie noch über ein zusätzliches Paar von UDP-Anschlüssen verfügen, weil Audio und Video getrennt transportiert werden und RTCP- Pakete für beide Ströme unabhängig gesendet werden. Am Anfang werden Audiosignale des Senders zuerst in seine Kommunikationssoftware übertragen, deren Algorithmus aus diesen Signalen Audiodaten in einer bestimmten Kodierung erstellt und in Blöcke fester Größe kapselt. Jedem Datenblock wird ein Header mit Informationen über die Daten und ihrer Wiedergabe angebracht. Ein Datenblock mit Header bezeichnet man dann als ein RTP- Paket. [3] Anschließend wird jedes Paket in einen UDP-Segment verkapselt und an den Empfänger in gleichen Zeitintervallen abgeschickt. Alle Pakete, die von demselben Sender stammen, tragen gleiche Nummer in ihrem Header, genannt SSRC Nummer. Sie ist notwendig damit der Empfänger den Sender identifizieren kann. Eine Netzverbindung ist bei der Übertragung von Daten oft überlastet. Falls dies der Fall ist, kommen Pakete mit unterschiedlichen Zeitintervallen an den Empfänger an. Der Algorithmus in der Anwendung des Empfängers erwartet aber einen synchronisierten Datenstrom. Um dies zu erreichen müssen die ankommenden Pakete zuerst gepuffert werden. Um dabei die ursprüngliche Synchronisation zu erzeugen, braucht der Empfänger eine Zeitmarke(Timestamp), die im Paket -Header jedes Paketes vorhanden ist. Dieses Problem von unterschiedlichen Paketlaufzeiten bezeichnet man als Jitter, das man in Abbildung 1 an unterschiedlichen Abständen zwischen den RTP-Paketen erkennen kann. Das Vertauschen der ursprünglichen Paketreihenfolge und Paketverluste ist ein weiteres Problem bei der Übertragung von Daten. Um dieses Problem zu erkennen, enthält RTP-Header eine Sequenz Nummer, mit der alle Pakete nummeriert sind und die mit jedem gesendetem Paket um eins erhöht wird. Ein anderes Problem in einer Sitzung mit vielen Teilnehmern ist, dass manche Teilnehmer über eine weniger leistungsfähige Verbindung mit den anderen verbunden sind. In diesem Fall kann man Mixer oder Translator benutzen. Man setzt diese Systeme vor dem Bereich mit schwächerer Verbindung ein und führt eine Verringerung der Datenqualität durch, um eine schnellere Datenübertragung zu gewährleisten. Mixer erlaubt außerdem das Bündeln von verschiedenen Datenströmen gleichen Formats in einen Gesamtstrom mit dem Ziel einer Übertragungsbeschleunigung. Zusätzlich zu dem RTP-Datenstrom wird ein separater RTCP- Strom zwischen dem Sender und dem Empfänger aufgestellt, um Informationen über Datenübertragung und über Teilnehmer zwischen allen Teilnehmern auszutauschen. Es gibt verschiedene Typen von RTCP Paketen. Sender Reports sendet jeder Teilnehmer, der Daten seit dem letzten Report

6

abgeschickt hat. Er enthält Statistik über die Anzahl der gesendeten Pakete und ihre Gesamtgröße, SSRC Nummer, die Uhrzeit des letzten Paketerzeugnisses und Angaben zum Jitter. Der Empfänger sendet Receiver Reports an den Sender um einen Feedback (Rückkopplung) über die Qualität der Übertragung zu geben. Andere Pakete geben Informationen wie z.B. E–Mail Adresse, Name, Telefonnummer der Teilnehmer an alle anderen weiter .Dritte Identifizieren die Teilnehmer mit einem Canonical Name (CNAME), der im Unterschied zu SSRC Nummer konstant für jeden Teilnehmer im Laufe der Sitzung bleibt. Bye-Pakete zählen zu dem weiteren Typ von RTCP Paketen. Sie werden von denjenigen Teilnehmern verschickt, die die Sitzung verlassen wollen. APP Pakete benutzt man für experimentelle Anwendungen. Im folgenden Abschnitt wird das RTP-Paket detailliert beschrieben.

2. Struktur eines RTP-Pakets

In der Abbildung 2 ist ein RTP-Paket dargestellt, in dem der RTP-Header durch eine dickere Umrahmung gekennzeichnet ist. Wie in der Einleitung bereits erwähnt, enthält jedes RTP-Paket Nutzdaten und einen RTP-Header, dessen Struktur nun beschrieben wird.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Abbildung 2: RTP-Paket

Das Feld Version (V, 2 bit) gibt die Version des aktuellen RTP- Protokolls an (Abbildung 2). Im nächsten Feld muss ein Padding( Füllungs)- bit (P) gesetzt werden wenn Blöcke der Nutzdaten(Payload) mit einigen Oktetten zusätzlich gefüllt werden sollen. Diese tragen keine Informationen und werden fürs Erreichen einer bestimmten Blockgröße gebraucht, die einige Verschlüsselungsalgorithmen benötigen. Das letzte Oktett gibt die Anzahl dieser füllenden Oktette an. Wenn das X–bit ( Extension) im folgendem Feld gesetzt wird, dann folgt eine Erweiterung des Headers, die für experimentelle Zwecke benutzt wird. Das Feld SSRC(Synchronization Source Identifier) ist 32 bit lang. Diese Nummer dient zur eindeutigen Identifikation eines Senders .Jedes Paket von gleichem Sender trägt dieselbe Nummer im Header damit der Empfänger Pakete, die zu einem Datenstrom

V =2 | P | X | CC | M | PT | SEQUENCE NUMBER

TIMESTAMP

SYNCHRONISATION SOURCE (SSRC) IDENTIFIER

CONTRIBUTING SOURCE (CSRC) IDENTIFIERS …………………………

RTP PAYLOAD …………………………

7

gehören, bestimmen kann. Dieser Wert wird beim Erzeugen eines neuen Stroms zufällig generiert und soll für jeden Datenstrom einmalig sein. Das Feld CSRC(contributing source) wird benötigt wenn Pakete von verschiedenen Sendern in einen Gesamtdatenstrom gebündelt bilden. Ein spezielles System, genannt Mixer, kann unter anderem diese Funktion erfüllen. (Abbildung 3)

Abbildung 3: Darstellung eines gebündelten Datenstromes

Damit der Empfänger einzelne Sender bestimmen kann trägt der Mixer die SSRC Nummer jedes zum Gesamtstrom beitragenden Senders in die CSRC Liste jedes Paketes ein, (in Abbildung 3 ist (1,17) die CSRC Liste, wobei 1 und 17 die SSRC Nummer von Sender S1 und Sender S2 sind). Da Sender Pakete mit verschiedener Synchronisation geschickt haben konnten, synchronisiert Mixer den Gesamtstrom selber, deshalb tragen alle Pakete des Gesamtstromes die SSRC des Mixers( Nummer 48 im Bild). Weitere Funktionen des Mixers werden unten erläutert. CC( CSRC count,4 bit) gibt die Anzahl der Quellen an , aus denen der gebündelte Datenstrom besteht. Das Feld M (Marker,1 bit) wird benötigt um die Grenzen eines Datenflusses zu zeigen. Bei einer Videoübertragung markiert er das Ende eines Bildes, im Falle dar Audioübertragung zeigt er den Anfang einer Rede nach der Ruhepause. Im Feld PT(Packet Typ,7bit ) wird der Typ der Nutzdaten identifiziert, die das Paket transportiert, z.B. bezeichnet PT= 33 einen Mpeg2 Video Format. Der Sender kann auch während der Übertragung das Format ändern und in diesem Feld ein neues Format bekannt geben. Eine Änderung des Formats kann z.B. bei einer Netzwerküberlastung von Vorteil sein, damit die Daten schneller übertragen werden. Das Feld Sequence Number( 16 bit) benötigt man um jedes Paket eines Senders zu nummerieren. Das erste Paket ist mit einer zufälligen Nummer markiert, die dann mit jedem gesendeten Paket um eins erhöht wird. Die ursprüngliche Paketreihenfolge beim Absenden kann sich während der Übertragung im Netz ändern .Mit Sequenz Nummer kann der Empfänger die ursprüngliche Reihenfolge der Pakete bestimmen. Außerdem kann er die Paketverluste an den fehlenden Nummern

8

erkennen. Das Feld Timestamp ( 32 bit ) enthält den Zeitpunkt, zu dem das erste Oktett der Nutzdaten erzeugt wurde. Mit Hilfe von Timestamp kann der Empfänger Pakete synchronisieren und unterschiedlichen Paketlaufzeiten (Jitter) mit Hilfe dieses Wertes berechnen. Die eigentlichen Nutzdaten folgen dem

2.1.Experimentelle RTP-Header Erweiterung

Das RTP Protokoll unterstützt eine Erweiterung des Headers genannt Header Extension (Abbildung 4). Einige vom Nutzdatenformat unabhängige Funktionen benötigen eine zusätzliche Information, die dann in dieser Erweiterung getragen wird. Dies wird durch einen gesetzten X bit angekündigt. Die Erweiterung folgt direkt nach der CSRC Liste. In zwei Oktette langem Feld „Length“ wird die Anzahl der 32 bit Wörter angegeben, die das Paket als Nutzdaten überträgt. Die Definition des Feldes „defined by profile“ wird der Applikation überlassen.

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

DEFINED BY PROFILE | LENGTH

HEADER EXTENSION ………………..

Abbildung 4: Header Extension

3. Anwendungsspezifische Erweiterung des RTP-Headers

RTP ist ein Transport Protokoll, das von unterschiedlichen Anwendungen benutzt werden kann. Dies wird dadurch möglich, dass RTP anwendungsspezifische Erweiterungen (Profils) unterstützt . Das bedeutet, dass jede Anwendung einen zusätzlichen Header mit spezifischen Feldern an den RTP-Header anhängen kann um ihre besonderen Anforderungen zu erfüllen. Aus diesem Grund enthält RTP-Header nur allgemeine Angaben, wie zum Beispiel Marker bit oder Paket Typ, die von jeder Anwendung benutzt werden können. Die Unterstützung von Profilen hat außerdem einen anderen Vorteil: Der RTP-Header wird für eine längere Zeitperiode aktuell bleiben, weil neue Funktionen in die Profils eingetragen werden können. Wenn man zum Beispiel Daten im Mpeg Format mittels RTP übertragen will, so finden in diesem Fall die Profils eine breite Anwendung, denn der Kodierungsalgorithmus von Mpeg ist sehr variabel und verfügt über komplizierte Funktionen für die Darstellung der audiovisuellen Daten.

9

Ein Mpeg Video Header wird nun als Beispiel eines Profils dargestellt und allgemein beschrieben.(Tabelle 3) Dieser Profil muss in jedem RTP- Paket nach dem RTP – Header angehängt werden. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Tabelle 3: RTP Profile für MPEG Video

Die Zahl 32 im Payload-Feld (siehe Beispiel 3.1) besagt, dass dieses Paket MPEG1 Daten transportiert. B (Beginning-of-slice) und E (End-of-slice) Felder benutzt man um zu zeigen, dass ein Element eines Bildes in diesem Paket zum letzten oder zum ersten Mal übertragen wird. Verschiedene Motion Vektoren (FBV, BFC, FFV, FFC) [2] zur Beschreibung des Bildes werden dann von den eigentlichen Nutzdaten gefolgt.

3.1. Beispiel eines MPEG Profils

Feld Vers. Padding Extens. CSRC Marker Payload Type

Seq. Numb.

Timestamp SSRC

Eintrag 2 False False 0 False 32:MPEG 3969 207037442 1919871431 Einträge im RTP-Standard Header

Feld MBZ T TR

AN N S B E P FBV BFZ FVV FFC Stream

Eintrag 0 0 7 0 0 False True False 3 0 3 0 3 0101...

Einträge im MPEG-Profile

4. RTCP

Das RTP Data Transfer Protocol ermöglicht also einen Datenaustausch zwischen den Teilnehmern einer Sitzung. Das RTCP Protokoll, andererseits, wird fürs Versenden von Kontrollinformationen über die Lieferung von Daten an den Empfänger eingesetzt, indem dem Sender regelmäßig eine Rückkopplung ( QoS-Feedback, Quality of Service) über die Qualität der Übertragung gesendet wird .Außerdem dient RTCP zur Identifikation der

MBZ | T | TR | |N| S |B |E| P | | BFZ | | FFC AN FBV FVV

10

Teilnehmer und ihrer Beschreibung. Bei der Benutzung von Multicasting ist es auch möglich, dass Netzwerk Provider den Verlauf der Session verfolgt und Probleme bei der Übertragung analysiert. RTCP benutzt denselben Transportprotokoll wie RTP, d.h. meistens UDP, aber einen anderen Port.

4.1. RTCP Pakettypen RTCP Pakete haben verschiedene Typen, die in der Tabelle 1 dargestellt sind. Die Werte von 200 bis 204 werden ins PT Feld der RTCP Pakete eingetragen, um den Typ des aktuellen Paketes zu bezeichnen. Es gibt zum einen Sender Report (SR) Pakete und Receiver Report (RR) Pakete, die Statistik über Daten und ihrer Übertragung enthalten. Außer diesen zwei Typen gibt es quellenbeschreibende Pakete (SDES „Source Description Items“), die unterschiedliche Items (Notizen) mit der Beschreibung des Teilnehmers enthalten und vor allem seine identifizierende Nummer angeben, die im CNAME Item steht und an alle Teilnehmer gesendet werden muss. Eine Quelle sendet ein Bye Paket wenn der Teilnehmer die Sitzung verlässt. APP Pakete sind experimentelle RTCP-Pakete.

Tabelle 1: Pakettypen des RTCP- Protokolls

4.2. Funktionen von RTCP

1. Die Hauptfunktion von RTCP ist eine Rückkopplung (Feedback) über die Qualität der Datenübertragung. Mit Hilfe von Sender –und Receiver Reports, die weiter unten genau erläutert werden, kann der Sender Statistik über Datenverluste und Netzbelastung bekommen und entsprechende Veränderungen durchführen, z.B. Änderung des Datenformats, um eine optimale Übertragung zu erzielen. Wenn für die Übertragung von Daten IP Multicast benutzt wird, so kann auch der Netzwerk Provider die Übertragung analysieren.

Abkürzung EINTRAG IM FELD Wert SR sender report 200 RR receiver report 201 SDES Beschreibung der Quelle 202 BYE Bye –Paket 203 APP definiert durch Anwendung 204

11

2. Die zweite wichtige Funktion von RTCP ist die eindeutige Identifikation des Senders über Canonical Name( CNAME). Im Unterschied zur SSRC Nummer, die sich im Laufe der Session wegen eines Fehlers oder eines neuen Starts des Programms ändern kann, bleibt der Sender durch CNAME eindeutig bestimmt. Außerdem kann der Empfänger bei einer audiovisuellen Übertragung mittels CNAME bestimmen, welche zwei Datenströme für Audio –und Videoübertragung zu einem Sender gehören, da SSRC Nummer dieser Ströme unterschiedlich sein können.

3. Jeder Teilnehmer einer Session schickt an alle anderen Teilnehmer periodisch RTCP Pakete ab, deshalb muss die Senderate reguliert werden, um die Netzüberlastung zu verhindern.

4. Optional können Teilnehmer einer Session zusätzliche Informationen übereinander austauschen, z.B. E-Mail Adresse, Name, Telefonnummer

4.3. Sender -und Empfängerberichte.

Sowohl der Sender Report (SR) als auch Receiver Report (RR) enthalten einen 8 Oktett langen Header, nach dem nur bei den Sender Reports ein 20 -byte langer Feld kommt(Sender Info). Die weiteren Blöcke , die bei beiden Pakettypen vorhanden sind , heißen Reception Report Blocks und enthalten Informationen zu jedem Sender , von dem Daten seit dem letzten Report empfangen worden sind(Abbildung 5).

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Abbildung 5: RTCP Sender Report (SR)

V V=2 | P | RC | PT= SR= 200 | length

SSRC of sender

NTP timestamp, most significant word NTP timestamp,least significant word

RTP timestamp

sender’s packet count sender’octet count

SSRC_1 ( SSRC of first source) fraction lost | cumulative number of packets lost

extended highest sequence number received

interrival jitter last SR (LSR)

delay since last SR ( DLSR) SSRC_2 ( SSRC of second source)

……………….

profile specific extensions

12

Die Felder V und P stehen für Version und Padding . Sie haben die gleiche Bedeutung wie die gleichnamigen Felder in RTP –Paketen. Das RC Feld (Reception Report Count, 5 bit) gibt an, wie viele Reception Report Blöcke im Paket vorhanden sind, wobei auch die Null erlaubt ist. Reception Report enthält Statistik zu dem Sender, von dem die Daten seit dem letzten Report angekommen sind. Da es sich um einen Sender Report handelt, muss im Feld PT( 8 bit) die Zahl 200 stehen. Die Länge des SR Paketes wird durch das Feld Length( 16 bit) angegeben und gibt Auskunft über die Anzahl der 32-bit Wörter in diesem Paket. Der Absender dieses Paketes wird durch die SSRC Nummer identifiziert.

Die zweite Sektion des Paketes ist 20 Oktett lang und bildet den einzigen Unterschied zwischen RR und SR Paketen.

Im ersten Feld dieser Sektion wird die Zeit des Absendens des aktuellen Reports angegeben, gemessen in NTP timestamp(64 bits).RTP timestamp(32bit) entspricht der NTP timestamp aber in anderer Zeiteinheit. Die Gesamtzahl der von Sender seit Anfang der Session gesendeter RTP- Pakete mit gleichem SSRC wird im Feld sender’s packet count ( 32 bit) angegeben. Die Gesamtzahl der von Sender übertragenen Nutzdaten (gemessen in Bytes)seit dem Anfang der Session bis zum aktuellen Zeitpunkt steht im Feld sender’s octet count( 32bit).

Im dritten Teil des Pakets werden die Reception Reports übertragen. Ihre Anzahl ist gleich der Anzahl der Sender, von denen der aktuelle Sender Pakete seit dem letzten Report erhalten hat. Reception Report Block besteht aus 6 Feldern a 32 bit .Jeder SR enthält SSRC des Senders, zu dem sich Reception Report bezieht, dies wird im Feld SSRC_n (32bit) angegeben. Die Anzahl der verlorenen RTP-Pakete von dem Sender SSRC_n seit dem letzten SR oder RR geteilt durch die Anzahl der erwarteten Pakete wird im Feld fraction lost ( 8 bit) angegeben. Im Feld steht dann der Integer Teil, nachdem man diesen Bruch mit 256 multipliziert hat.

Cumulative Number of packets lost (24 bit) ist Gesamtzahl verlorener RTP Pakete von der Quelle SSRC_n seit dem Anfang der Übertragung. Mit Hilfe von Cumulative Number of packets lost kann man die Anzahl verlorener Paketen zwischen Reception Reports berechnen, in dem man die Differenz von Cumulative Numbers bildet. Extended highest sequence number received( 32 bit) enthält die größte Sequence Nummer eines RTP Paketes, die von der Quelle SSRC_n empfangen worden ist. Die Differenz zwischen extended highest sequence number received gibt die Anzahl der Pakete, die man im Laufe der Übertragung zu bekommen erwartet . Die Bedeutung und Berechnung der Beträge für die restlichen Felder wird in Kapitel 6 detailliert beschrieben.

13

4.4 Beispiel eines Receiver Reports

4.5. SDES : Source Description RTCP Paket. Die SDES Pakete (Abbildung 6) dienen zur Beschreibung der Teilnehmer einer Session und enthalten deshalb solche Items (Notizen) wie zum Beispiel E-mail , Name und Telefonnummer. Es müssen nicht alle Items in jedem SDES Paket jedes Mal übertragen werden um den Netz nicht zu überlasten, aber CNAME Item ist sehr wichtig für die eindeutige Identifikation des Teilnehmers, deshalb ist er in jedem SDES Paket enthalten. Die SSRC Nummer reicht nicht immer aus, denn wenn eine Quelle sowohl Audio als auch Videodaten sendet, kann jeder von diesen Strömen eine andere SSRC Nummer haben. Durch CNAME kann man aber diese Ströme einer Quelle eindeutig zuordnen.

Feld

Eintrag

Version 2

Padding False

Reception report count 1

Packet type 201 Length 7

Sender SSRC 1921800069

Source 1 Identifier 1919871431

Fraction lost 255 / 256 Cumulative number of packets lost 11862016

Extended highest sequence number

received 280367285

Sequence number cycles count

4278

Highest sequence number received 4277

Interarrival jitter 1076 Last SR timestamp 1049894200

Delay since last SR timestamp

7274

14

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

Abbildung 6: SDES Paket

Jedes SDES Paket besteht aus einem 32 Bit Header. Die Bedeutung der Felder Version, Padding und Length ist dieselbe wie in den SR oder RR Paketen .Im Feld Source Count (SC) wird die Anzahl der Blöcke angegeben, die zu jedem Datenstrom der Quelle Informat ionen enthalten. Die Konstante 202 im Feld Packet Type(PT) bezeichnet den SDES Paket. Nach dem Header folgen Blöcke mit den SSRC/CSRC_n Nummern der Sender. In der Tabelle 2 sind alle Typen der SDES Items dargestellt. Jedes Item besteht aus einem 8 bit Feld( SDES Wert in der Tabelle), in dem der Typ des Items angegeben wird und einem 8 bit length Feld, das die Länge des folgenden beschreibenden Textes angibt, deren Länge maximal 255 Oktetten betragen darf.

Tabelle 2: SDES items

V =2 | P | SC | PT= SR= 202 | length

SSRC/CSRC_1 SDES items

SSRC/CSRC_2 SDES items

SDES WERT EINTRAG IM FELD BEDEUTUNG 0 END Ende der SDES Liste 1 CNAME Canonical Name 2 NAME Name des Teilnehmers 3 E-MAIL E-Mail des Teilnehmers 4 PHONE Telefonnummer des Teilnehmers 5 LOC geografischer Standort des Teilnehmers 6 TOOL Name der Software für Kommunikation 7 NOTE Information über dem Zustand des

Teilnehmers 8 PRIV experimentelle Erweiterung

15

4.6. Beispiel eines SDES Pakets :

Feld Eintrag Version 2

Padding False source count 1 Packet type 202

length 15 Chunk1,SSRC/CSRC 1921800069

CNAME 1 length 13

text ilia@gurevich EMAIL 3 length 16 text

jmf-user@sun.com

TOOL

6

length 16

text JMF RTP PLAYER v2.0

4.7. Berechnung der Sendeperiode für RTCP - Pakete

An einer Audiokonferenz können mittels RTP mehrere hundert Menschen teilnehmen, ohne dabei den RTP-Datenstrom zu überlasten, denn zu einem Zeitpunkt nur ein Paar von ihnen gleichzeitig sprechen werden. Anders sieht es im RTCP Datenstrom aus. Hier werden unterschiedliche Reports gegenseitig und regelmäßig mittels Multicasting verschickt, was schnell zu einer Netzüberlastung führen kann, denn die Anzahl der gesendeten Reports mit der wachsender Teilnehmerzahl linear ansteigt. Um die Überlastung zu verhindern, muss die Senderate von RTCP- Paketen in Abhängigkeit von der Teilnehmeranzahl und der Bandbreite berechnet werden. Da alle Teilnehmer ihre Reports aneinander senden, ist die Gesamtanzahl der Teilnehmer dadurch leicht bestimmbar. Jeder Teilnehmer führt eine Tabelle, in der die Gesamtanzahl der Teilnehmer eingetragen ist. Die Quellen werden aus der Tabelle entfernt, wenn von ihnen im Laufe eines Zeitintervalls keine Pakete gesendet wurden oder wenn diese Sender Bye Pakete gesendet haben um zu zeigen, dass sie die Konferenz verlassen. Die SDES Pakete mit Canonical Name , RR und SR Pakete müssen bevorzugt werden, weil ihr periodisches Austauschen unter allen Teilnehmern einen

16

großen Einfluss auf die technische Qualität der Sitzung hat. So werden die E-Mail Adresse und weitere beschreibende Items nicht in jedem SDES Paket gesendet. Es wird auch vereinbart, dass aktive Sender mehr Ressourcen zur Verfügung bekommen. Außerdem wird die Bandbreite des RTCP Verkehrs auf 5 % der RTP Bandbreite begrenzt. Der folgende Beispiel demonstriert, in welchen Zeitabständen T ( Periode ) der Empfänger und der Sender ihre RTCP -Pakete schicken sollen, um Netztüberlastung zu vermeiden. Wenn z.B. ein Sender Video in einer Rate von 2 Mbps überträgt und die Bandbreite des RTCP -Stromes maximal 5% betragen darf, so dürfen nur 0,05*2Mbps= 100Kbps übertragen werden. Der Sender bekommt in diesem Fall ¼ der Rate ( 25 Kbps) und der Empfänger 75 Kbps. Wenn es R Empfänger gibt, so müssen 75 Kbps auf R Empfänger aufgeteilt werden. In der Formel für den Sender muss man also die Periode ( T ) in Abhängigkeit von der Anzahl der Sender (N), durchschnittlicher RTCP - Paketgröße ( D ) und Sitzungsbandbreite ( s ) darstellen [3]:

×=

× ×( )

( 0 , 2 5 0 , 0 5 )N D

TS

Wenn also die Anzahl der Sender ansteigt muss die Periode T größer werden. Für den Empfänger gilt folgende Formel:

×=× ×

( )( 0 , 7 5 0 , 0 5 )

N DTS

5. Jitter

Abbildung 7: Darstellung eines Jitters

Jitter bedeutet, dass Pakete eine unterschiedliche Laufzeit bei der Übertragung zwischen dem Sender und Empfänger haben. Obwohl sie in

17

gleichen Zeitabständen gesendet wurden kommen sie ungleichmäßig an den Empfänger an. (Abbildung 7). Wenn ein Packet mit sehr großen

Verzögerung an den Empfänger ankommt, muss die Anwendung entscheiden ob dieses Packet verwendet oder ausgelassen wird. Unter Verwendung von Sequenznummer und Timestamp kann man die Pakete in ursprünglicher Reihenfolge anordnen und im Puffer speichern damit sie richtig synchronisiert werden können. Jeder Sender -und Receiver Report enthält einen 32 bit Feld mit dem aktuellen Betrag des Jitters zwischen zwei aufeinander folgenden Paketen. Dieser Wert gibt die geschätzte statistische Varianz der Zwischenankunftszeit der RTP Packete an und wird mit J bezeichnet. Für Berechnung von J muss man zuerst die „ relative transit time“ für zwei Pakete berechnen, die mit D bezeichnet wird. Für jeweils zwei aufeinander folgende Pakete berechnet man dabei die Zeit, die jeder von beiden Paketen zwischen dem Sender und Empfänger unterwegs ist. Dann wird die Paketlaufzeit eines Paketes von der des anderen Paketes subtrahiert. Diese Zeit wird in RTP Timestamp gemessen und mit D bezeichnet:

j j i iD(i, j) = (R - S ) - (R - S )

Interarrival Jitter ist nun folgendermaßen rekursiv definiert:

( | D( i-1,i ) | - J) | D( i-1,i) |15

16 16 16J =J + ( ) J+= ⋅

Das Parameter 1/16 dient zur “ noice reduction”, d.h. eine starke Abweichung des Wertes D kann keine große Auswirkung auf den Wert J haben, weil D durch 16 geteilt wird.

6. Round –Trip Time Die Zeit, die zwischen dem Absenden eines Sender Reports an den Empfänger und dem Empfang seines Receiver Reports verläuft, nennt man Round –Trip time. Um sie zu berechnen, braucht man zwei neue Größen: LSR und DLSR. last SR timestamp (LSR) , 32 bits: Das sind die mittlere 32 bits des NTP - Timestamps des letzten Sender Reports von dem Sender SSRC_n. LSR ist gleich 0 falls kein SR bislang angekommen ist.

Delay since last SR ( DLSR) (32bit): Zeitintervall gemessen in 1/65536 Sec. zwischen dem Empfang des letzten SR von SSRC_n und dem Abschicken des aktuellen RR Paketes. DLSR ist gleich 0 falls kein SR von SSRC_n angekommen ist. Der Sender kann nun die Round- Trip Time folgendermaßen berechnen ( Abbildung 8 ): Er subtrahiert zuerst den Zeitpunkt LSR von dem Zeitpunkt,

18

an dem der Receiver Report zu ihm zurückkehrt. Diese Differenz ist ( F ).Die Verzögerungszeit zwischen dem Empfang des Sender Reports und dem Abschicken des Receiver Reports wird als DLSR bezeichnet. Diese muss man schließlich von ( F ) subtrahieren, um dann die Round Trip Time ( RRT) zu bekommen.

Abbildung 8: Grafsche Darstellung der Round -Trip Time

7. Mixer und Translator.

In einer Audiokonferenz kann es vorkommen, dass einige Teilnehmer über eine geringere Bandbreite mit den anderen Teilnehmern verbunden sind und somit Daten mit einer Verzögerung bekommen, was den Verlauf einer Konferenz erschwert. Um dieses Problem zu lösen muss möglichst am Anfang zu der schwächeren Verbindung ein Mixer geschaltet werden. Mittels Mixer kann man nun Audiodaten von mehreren sprechenden Teilnehmern synchronisieren, sie in einen Gesamtstrom bündeln und danach eine stärkere Komprimierung der Daten durchführen. Der gebündelte Audiostrom wird dann an die Teilnehmer gesendet, die ein schwächeres Netzwerk haben und so wird auf diese Weise eine schnellere Übertragung von Audiosignalen an sie ermöglicht. Da Mixer mehrere Audioströme selbst synchronisiert hat, tragen die Pakete des gebündelten Datenstroms seine SSRC Nummer. Damit der Empfänger die Sender von Audioströmen identifizieren kann, enthält jeder RTP -Header der Pakete des Gesamtstromes

19

eine CSRC Liste mit SSRC Nummern der beitragenden Sendern. Dies wird in der Abbildung 9 veranschaulicht. Hier tragen die Pakete des gebündelten

Stromes eine CSRC Liste mit SCRC Nummern 17 und 39 der Sender sowie die SSRC Nummer des Mixers (5). Eine Veränderung des Datenformats oder das Bilden eines neuen Datenstromes aus mehreren Strömen mittels eines Mixers bringt natürlich auch eine Veränderung in den RTCP –Strom. So generiert Mixer die Sender Reports mit Informationen über dem gebündeltem Gesamtdatenstrom selber. In Abbildung 9 erkennt man außer Mixers einen Translator. Im Unterschied zum Mixer bleibt die SSRC Nummer der Sender erhalten, wenn Translator das Datenformat verändert. Translator kann das Format von mehreren Strömen simultan verändern ohne dabei ein gebündeltes Gesamtdatenstrom zu bilden. Im Gegensatz zum Mixer müssen die in den Translator eingehenden Ströme keine gleichen Formate haben. In der Abbildung 9 werden die PCMU – und MPA Formate in ein GSM Format umkodiert. Des Weiteren benutzt man einen Translator, um Daten an Teilnehmer zu schicken, die durch eine Firewall geschützt sind. Um Firewall zu überbrücken, schaltet man einen äußeren Translator vor der Firewall , der Daten durch diese an den inneren Translator transportiert. Schließlich ist ein Translator in der Lage, Multicast –Pakete in Unicast –Pakete umzuwandeln. Da Translator kein Bündeln von Daten durchführt, wird der Sender Report nicht verändert. Wenn der Translator aber beispielsweise die Komprimierung der Daten ändert, so muss der Eintrag „ sender’s byte count „ im Sender Report aktualisiert werden. [1]

Abbildung 9: Translator und Mixer

20

8. Zusammenfassung

RTP ist ein etabliertes Internet -Protokoll für die Echtzeitübertragung von audiovisuellen Daten. Es gliedert sich in zwei Teilprotokolle: Das RTP Data Transfer Protocol , das die Daten transportiert und das RTP Control Protocol (RTCP), das Informationen über Qualität der Übertragung und über die Teilnehmer bereitstellt. Für diese Zwecke gibt es in RTCP fünf verschiedene Pakettypen. RTP verfügt über Mechanismen zum Umgang mit unterschiedlichen Problemen, die bei der Datenübertragung entstehen können, wie zum Beispiel Jitter, Paketverluste und Vertauschung der ursprünglichen Paketreihenfolge. Unterschiedliche Datenströme können bei der Benutzung von RTP synchronisiert werden und je nach Bedarf mittels Translator in ein anderes Format umkodiert oder mittels Mixer in einen Gesamtdatenstrom gebündelt werden, falls diese Datenströme gleiches Format haben. Die zusätzliche Unterstützung von Profils macht RTP zu einem Transportprotokoll, das eine breite Verwendung unter zahlreichen Anwendungen findet und deshalb für eine längere Zeitperiode aktuell bleiben wird.

21

9. Literatur

[1] Schulzrinne, “RTP: A Transport Protocol for Real-Time Applications“, January 1996

[2] Hoffman, “RTP Payload Format for Mpeg1 / Mpeg2 Video”, January 1998

[3] Keith, Kurose, “Computer Networking“, S.510-517