RTP/RTCP - Informatik 4

Rheinisch-Westfälische Technische Hochschule AachenLehrstuhl für Informatik IVProf. Dr. rer. nat. Otto SpaniolPROSEMINARKOMMUNIKATIONSPROTOKOLLE SS 2003Real – Time Transport ProtocolRTP / RTCPvon Ilia GurevichMatrikelnummer : 234097Betreuung : Dipl.-Inform. Imed Bouazizi

3Inhaltsverzeichnis1. Einleitung…………………………………………………………………....... 42. Struktur eines RTP-Pakets…………………...……………………….……… 62.1. Experimentelle RTP-Header Erweiterung……………………….…... 83. Anwendungsspezifische Erweiterung des RTP-Headers (Profile)…… 83.1. Beispiel eines MPEG Profils……………………………………........... 94. RTCP…………………………………………………………………………… 94.1. RTCP Pakettypen………………………………………………………. 104.2. Funktionen von RTCP………………………………………………….. 104.3. Sender- und Empfängerberichte…………………………………… 114.4. Beispiel eines Receiver Reports………………………………………. 134.5. SDES Pakete……………………………………………………………… 134.6. Beispiel eines SDES Pakets…………….………………………........... 154.7. Berechnung der Sendeperiode für RTCP Pakete ………………...155. Jitter……………………………………………………………………………. 166. Round-Trip Time……………………………………………………………… 177. Mixer und Translator………………………………………………………… 188. Zusammenfassung……………………………………………………………209. Literatur………...……………………………………………………………….21

41. EinleitungDas Real -Time Transport Protocol (RTP) ist ein Internet - Protokoll, das für dieÜbertragung von audiovisuellen Daten in Echtzeit benutzt wird. Es wirdbeispielsweise fürs Telefonieren übers Internet mittels einer Eins- zu- EinsVerbindung (Unicast) eingesetzt oder für Videokonferenzen zwischenmehreren Teilnehmern, wobei Videodaten an mehrere Empfängergleichzeitig geschickt werden (Multicast). Dadurch dass RTP so genanntenProfils (Erweiterungen) unterstützt, können unterschiedliche Anwendungendieses Transportprotokoll verwenden.Das RTP-Protokoll gliedert sich in zwei Teilprotokolle, die unabhängigvoneinander funktionieren. Das RTP Data Transfer Protocol transportiertNutzdaten in Echtzeit. Das RTP Control Protocol (RTCP) stellt Informationenüber Qualität der Übertragung dar und gibt Auskunft über alle Teilnehmereiner Sitzung (Session).Die RTCP Daten werden über eine von RTP unabhängige Leitungtransportiert. Der am weitesten verbreitete Transportprotokoll TCP ist für dieÜbertragung von RTP nicht geeignet, da TCP die verlorenen Datenblöckeerneut an den Empfänger sendet, was bei einer Echtzeitübertragungunpassend ist. Außerdem erlaubt TCP kein Multicasting. Deshalb setzt RTP aufUDP auf, der Multicasting unterstützt.Abbildung 1: Schematische Darstellung einer Datenübertragung mittel s RTP

5Abbildung 1 stellt anhand einer Audioübertragung schematisch dar, aufwelche Weise Daten zwischen einem Sender und einem Empfänger bei derBenutzung 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 separatenRTP und RTCP – Anschlüssen und eine IP-Adresse. Im Falle eineraudiovisuellen Übertragung müssten sie noch über ein zusätzliches Paar vonUDP-Anschlüssen verfügen, weil Audio und Video getrennt transportiertwerden und RTCP- Pakete für beide Ströme unabhängig gesendet werden.Am Anfang werden Audiosignale des Senders zuerst in seineKommunikationssoftware übertragen, deren Algorithmus aus diesenSignalen Audiodaten in einer bestimmten Kodierung erstellt und in Blöckefester Größe kapselt. Jedem Datenblock wird ein Header mit Informationenüber die Daten und ihrer Wiedergabe angebracht. Ein Datenblock mitHeader bezeichnet man dann als ein RTP- Paket. [3] Anschließend wirdjedes Paket in einen UDP-Segment verkapselt und an den Empfänger ingleichen Zeitintervallen abgeschickt. Alle Pakete, die von demselbenSender stammen, tragen gleiche Nummer in ihrem Header, genannt SSRCNummer. Sie ist notwendig damit der Empfänger den Sender identifizierenkann.Eine Netzverbindung ist bei der Übertragung von Daten oft überlastet. Fallsdies der Fall ist, kommen Pakete mit unterschiedlichen Zeitintervallen an denEmpfänger an. Der Algorithmus in der Anwendung des Empfängers erwartetaber einen synchronisierten Datenstrom. Um dies zu erreichen müssen dieankommenden Pakete zuerst gepuffert werden. Um dabei die ursprünglicheSynchronisation zu erzeugen, braucht der Empfänger eineZeitmarke(Timestamp), die im Paket-Header jedes Paketes vorhanden ist.Dieses Problem von unterschiedlichen Paketlaufzeiten bezeichnet man alsJitter, das man in Abbildung 1 an unterschiedlichen Abständen zwischenden RTP-Paketen erkennen kann.Das Vertauschen der ursprünglichen Paketreihenfolge und Paketverluste istein weiteres Problem bei der Übertragung von Daten. Um dieses Problem zuerkennen, enthält RTP-Header eine Sequenz Nummer, mit der alle Paketenummeriert sind und die mit jedem gesendetem Paket um eins erhöht wird.Ein anderes Problem in einer Sitzung mit vielen Teilnehmern ist, dass mancheTeilnehmer über eine weniger leistungsfähige Verbindung mit den anderenverbunden sind. In diesem Fall kann man Mixer oder Translator benutzen.Man setzt diese Systeme vor dem Bereich mit schwächerer Verbindung einund führt eine Verringerung der Datenqualität durch, um eine schnellereDatenübertragung zu gewährleisten. Mixer erlaubt außerdem das Bündelnvon verschiedenen Datenströmen gleichen Formats in einen Gesamtstrommit dem Ziel einer Übertragungsbeschleunigung.Zusätzlich zu dem RTP-Datenstrom wird ein separater RTCP- Strom zwischendem Sender und dem Empfänger aufgestellt, um Informationen überDatenübertragung und über Teilnehmer zwischen allen Teilnehmernauszutauschen. Es gibt verschiedene Typen von RTCP Paketen. SenderReports sendet jeder Teilnehmer, der Daten seit dem letzten Report

abgeschickt hat. Er enthält Statistik über die Anzahl der gesendeten Paketeund ihre Gesamtgröße, SSRC Nummer, die Uhrzeit des letztenPaketerzeugnisses und Angaben zum Jitter. Der Empfänger sendet ReceiverReports an den Sender um einen Feedback (Rückkopplung) über dieQualität der Übertragung zu geben. Andere Pakete geben Informationenwie z.B. E–Mail Adresse, Name, Telefonnummer der Teilnehmer an alleanderen weiter .Dritte Identifizieren die Teilnehmer mit einem CanonicalName (CNAME), der im Unterschied zu SSRC Nummer konstant für jedenTeilnehmer im Laufe der Sitzung bleibt. Bye-Pakete zählen zu dem weiterenTyp von RTCP Paketen. Sie werden von denjenigen Teilnehmern verschickt,die die Sitzung verlassen wollen. APP Pakete benutzt man für experimentelleAnwendungen.Im folgenden Abschnitt wird das RTP-Paket detailliert beschrieben.62. Struktur eines RTP-PaketsIn der Abbildung 2 ist ein RTP-Paket dargestellt, in dem der RTP-Header durch einedickere Umrahmung gekennzeichnet ist. Wie in der Einleitung bereits erwähnt,enthält jedes RTP-Paket Nutzdaten und einen RTP-Header, dessen Struktur nunbeschrieben wird.0 1 2 30 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 1V =2 | P | X | CC | M | PT | SEQUENCE NUMBERTIMESTAMPSYNCHRONISATION SOURCE (SSRC) IDENTIFIERCONTRIBUTING SOURCE (CSRC) IDENTIFIERS…………………………RTP PAYLOAD…………………………Abbildung 2: RTP-PaketDas 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) gesetztwerden wenn Blöcke der Nutzdaten(Payload) mit einigen Oktettenzusätzlich gefüllt werden sollen. Diese tragen keine Informationen undwerden fürs Erreichen einer bestimmten Blockgröße gebraucht, die einigeVerschlüsselungsalgorithmen benötigen. Das letzte Oktett gibt die Anzahldieser füllenden Oktette an. Wenn das X–bit ( Extension) im folgendem Feldgesetzt wird, dann folgt eine Erweiterung des Headers, die fürexperimentelle Zwecke benutzt wird. Das Feld SSRC(Synchronization SourceIdentifier) ist 32 bit lang. Diese Nummer dient zur eindeutigen Identifikationeines Senders .Jedes Paket von gleichem Sender trägt dieselbe Nummerim Header damit der Empfänger Pakete, die zu einem Datenstrom

gehören, bestimmen kann. Dieser Wert wird beim Erzeugen eines neuenStroms zufällig generiert und soll für jeden Datenstrom einmalig sein. DasFeld CSRC(contributing source) wird benötigt wenn Pakete vonverschiedenen Sendern in einen Gesamtdatenstrom gebündelt bilden. Einspezielles System, genannt Mixer, kann unter anderem diese Funktionerfüllen. (Abbildung 3)7Abbildung 3: Darstellung eines gebündelten DatenstromesDamit der Empfänger einzelne Sender bestimmen kann trägt der Mixer dieSSRC Nummer jedes zum Gesamtstrom beitragenden Senders in die CSRCListe jedes Paketes ein, (in Abbildung 3 ist (1,17) die CSRC Liste, wobei 1 und17 die SSRC Nummer von Sender S1 und Sender S2 sind). Da Sender Paketemit verschiedener Synchronisation geschickt haben konnten, synchronisiertMixer den Gesamtstrom selber, deshalb tragen alle Pakete desGesamtstromes die SSRC des Mixers( Nummer 48 im Bild). Weitere Funktionendes Mixers werden unten erläutert. CC( CSRC count,4 bit) gibt die Anzahlder Quellen an , aus denen der gebündelte Datenstrom besteht. Das FeldM (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 darAudioübertragung zeigt er den Anfang einer Rede nach der Ruhepause. ImFeld PT(Packet Typ,7bit ) wird der Typ der Nutzdaten identifiziert, die dasPaket transportiert, z.B. bezeichnet PT= 33 einen Mpeg2 Video Format. DerSender kann auch während der Übertragung das Format ändern und indiesem Feld ein neues Format bekannt geben. Eine Änderung des Formatskann z.B. bei einer Netzwerküberlastung von Vorteil sein, damit die Datenschneller übertragen werden. Das Feld Sequence Number( 16 bit) benötigtman um jedes Paket eines Senders zu nummerieren. Das erste Paket ist miteiner zufälligen Nummer markiert, die dann mit jedem gesendeten Paket umeins erhöht wird. Die ursprüngliche Paketreihenfolge beim Absenden kannsich während der Übertragung im Netz ändern .Mit Sequenz Nummer kannder Empfänger die ursprüngliche Reihenfolge der Pakete bestimmen.Außerdem kann er die Paketverluste an den fehlenden Nummern

8erkennen. Das Feld Timestamp ( 32 bit ) enthält den Zeitpunkt, zu dem daserste Oktett der Nutzdaten erzeugt wurde. Mit Hilfe von Timestamp kannder Empfänger Pakete synchronisieren und unterschiedlichenPaketlaufzeiten (Jitter) mit Hilfe dieses Wertes berechnen. Dieeigentlichen Nutzdaten folgen dem2.1.Experimentelle RTP-Header ErweiterungDas RTP Protokoll unterstützt eine Erweiterung des Headers genannt HeaderExtension (Abbildung 4). Einige vom Nutzdatenformat unabhängigeFunktionen benötigen eine zusätzliche Information, die dann in dieserErweiterung getragen wird. Dies wird durch einen gesetzten X bitangekündigt. Die Erweiterung folgt direkt nach der CSRC Liste. In zweiOktette langem Feld „Length“ wird die Anzahl der 32 bit Wörter angegeben,die das Paket als Nutzdaten überträgt. Die Definition des Feldes „defined byprofile“ wird der Applikation überlassen.0 1 2 30 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 1DEFINED BY PROFILE | LENGTHHEADER EXTENSION………………..Abbildung 4: Header Extension3. Anwendungsspezifische Erweiterung des RTP-HeadersRTP ist ein Transport Protokoll, das von unterschiedlichen Anwendungenbenutzt werden kann. Dies wird dadurch möglich, dass RTPanwendungsspezifische Erweiterungen (Profils) unterstützt. Das bedeutet,dass jede Anwendung einen zusätzlichen Header mit spezifischen Feldernan den RTP-Header anhängen kann um ihre besonderen Anforderungen zuerfüllen. Aus diesem Grund enthält RTP-Header nur allgemeine Angaben,wie zum Beispiel Marker bit oder Paket Typ, die von jeder Anwendungbenutzt werden können. Die Unterstützung von Profilen hat außerdem einenanderen Vorteil: Der RTP-Header wird für eine längere Zeitperiode aktuellbleiben, 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 derKodierungsalgorithmus von Mpeg ist sehr variabel und verfügt überkomplizierte Funktionen für die Darstellung der audiovisuellen Daten.

Ein Mpeg Video Header wird nun als Beispiel eines Profils dargestellt undallgemein beschrieben.(Tabelle 3) Dieser Profil muss in jedem RTP- Paketnach dem RTP – Header angehängt werden.0 1 2 30 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 1MBZ | T | TR | |N| S |B |E| P | | BFZ | | FFCAN FBV FVV9Tabelle 3: RTP Profile für MPEG VideoDie Zahl 32 im Payload-Feld (siehe Beispiel 3.1) besagt, dass dieses PaketMPEG1 Daten transportiert. B (Beginning-of-slice) und E (End-of-slice) Felderbenutzt man um zu zeigen, dass ein Element eines Bildes in diesem Paketzum letzten oder zum ersten Mal übertragen wird. Verschiedene MotionVektoren (FBV, BFC, FFV, FFC) [2] zur Beschreibung des Bildes werden dannvon den eigentlichen Nutzdaten gefolgt.3.1. Beispiel eines MPEG ProfilsFeld Vers. Padding Extens. CSRC Marker Payload Seq. Timestamp SSRCType Numb.Eintrag 2 False False 0 False 32:MPEG 3969 207037442 1919871431Einträge im RTP-Standard HeaderFeld MBZ T TR AN N S B E P FBV BFZ FVV FFC StreamEintrag 0 0 7 0 0 False True False 3 0 3 0 3 0101...Einträge im MPEG-Profile4. RTCPDas RTP Data Transfer Protocol ermöglicht also einen Datenaustauschzwischen den Teilnehmern einer Sitzung. Das RTCP Protokoll, andererseits,wird fürs Versenden von Kontrollinformationen über die Lieferung von Datenan den Empfänger eingesetzt, indem dem Sender regelmäßig eineRückkopplung ( QoS-Feedback, Quality of Service) über die Qualität derÜbertragung gesendet wird .Außerdem dient RTCP zur Identifikation der

Teilnehmer und ihrer Beschreibung. Bei der Benutzung von Multicasting ist esauch möglich, dass Netzwerk Provider den Verlauf der Session verfolgt undProbleme bei der Übertragung analysiert. RTCP benutzt denselbenTransportprotokoll wie RTP, d.h. meistens UDP, aber einen anderen Port.104.1. RTCP PakettypenRTCP Pakete haben verschiedene Typen, die in der Tabelle 1 dargestelltsind. Die Werte von 200 bis 204 werden ins PT Feld der RTCP Paketeeingetragen, um den Typ des aktuellen Paketes zu bezeichnen. Es gibt zumeinen Sender Report (SR) Pakete und Receiver Report (RR) Pakete, dieStatistik über Daten und ihrer Übertragung enthalten. Außer diesen zweiTypen gibt es quellenbeschreibende Pakete (SDES „Source DescriptionItems“), die unterschiedliche Items (Notizen) mit der Beschreibung desTeilnehmers enthalten und vor allem seine identifizierende Nummerangeben, die im CNAME Item steht und an alle Teilnehmer gesendetwerden muss. Eine Quelle sendet ein Bye Paket wenn der Teilnehmer dieSitzung verlässt. APP Pakete sind experimentelle RTCP-Pakete.Abkürzung EINTRAG IM FELD WertSR sender report 200RR receiver report 201SDES Beschreibung der Quelle 202BYE Bye –Paket 203APP definiert durch Anwendung 204Tabelle 1: Pakettypen des RTCP- Protokolls4.2. Funktionen von RTCP1. Die Hauptfunktion von RTCP ist eine Rückkopplung (Feedback) über dieQualität der Datenübertragung. Mit Hilfe von Sender –und Receiver Reports,die weiter unten genau erläutert werden, kann der Sender Statistik überDatenverluste und Netzbelastung bekommen und entsprechendeVeränderungen durchführen, z.B. Änderung des Datenformats, um eineoptimale Übertragung zu erzielen. Wenn für die Übertragung von Daten IPMulticast benutzt wird, so kann auch der Netzwerk Provider die Übertragunganalysieren.

112. Die zweite wichtige Funktion von RTCP ist die eindeutige Identifikation desSenders über Canonical Name( CNAME). Im Unterschied zur SSRC Nummer,die sich im Laufe der Session wegen eines Fehlers oder eines neuen Startsdes Programms ändern kann, bleibt der Sender durch CNAME eindeutigbestimmt. 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 dieserStröme unterschiedlich sein können.3. Jeder Teilnehmer einer Session schickt an alle anderen Teilnehmerperiodisch 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, Telefonnummer4.3. Sender -und Empfängerberichte.Sowohl der Sender Report (SR) als auch Receiver Report (RR) enthalteneinen 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 beidenPakettypen vorhanden sind , heißen Reception Report Blocks und enthaltenInformationen zu jedem Sender , von dem Daten seit dem letzten Reportempfangen worden sind(Abbildung 5).0 1 2 30 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 1V V=2 | P | RC | PT= SR= 200 | lengthSSRC of senderNTP timestamp, most significant wordNTP timestamp,least significant wordRTP timestampsender’s packet countsender’octet countSSRC_1 ( SSRC of first source)fraction lost | cumulative number of packets lostextended highest sequence number receivedinterrival jitterlast SR (LSR)delay since last SR ( DLSR)SSRC_2 ( SSRC of second source)……………….profile specific extensionsAbbildung 5: RTCP Sender Report (SR)

Die Felder V und P stehen für Version und Padding . Sie haben die gleicheBedeutung wie die gleichnamigen Felder in RTP –Paketen. Das RC Feld(Reception Report Count, 5 bit) gibt an, wie viele Reception Report Blöckeim Paket vorhanden sind, wobei auch die Null erlaubt ist. Reception Reportenthält Statistik zu dem Sender, von dem die Daten seit dem letzten Reportangekommen sind. Da es sich um einen Sender Report handelt, muss imFeld PT( 8 bit) die Zahl 200 stehen. Die Länge des SR Paketes wird durch dasFeld Length( 16 bit) angegeben und gibt Auskunft über die Anzahl der 32-bitWörter in diesem Paket. Der Absender dieses Paketes wird durch die SSRCNummer identifiziert.Die zweite Sektion des Paketes ist 20 Oktett lang und bildet den einzigenUnterschied zwischen RR und SR Paketen.Im ersten Feld dieser Sektion wird die Zeit des Absendens des aktuellenReports angegeben, gemessen in NTP timestamp(64 bits).RTPtimestamp(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 Zeitpunktsteht im Feld sender’s octet count( 32bit).Im dritten Teil des Pakets werden die Reception Reports übertragen. IhreAnzahl ist gleich der Anzahl der Sender, von denen der aktuelle SenderPakete seit dem letzten Report erhalten hat. Reception Report Block bestehtaus 6 Feldern a 32 bit .Jeder SR enthält SSRC des Senders, zu dem sichReception Report bezieht, dies wird im Feld SSRC_n (32bit) angegeben. DieAnzahl der verlorenen RTP-Pakete von dem Sender SSRC_n seit dem letztenSR oder RR geteilt durch die Anzahl der erwarteten Pakete wird im Feldfraction 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 RTPPakete von der Quelle SSRC_n seit dem Anfang der Übertragung.Mit Hilfe von Cumulative Number of packets lost kann man die Anzahlverlorener Paketen zwischen Reception Reports berechnen, in dem man dieDifferenz von Cumulative Numbers bildet. Extended highest sequencenumber received( 32 bit) enthält die größte Sequence Nummer eines RTPPaketes, die von der Quelle SSRC_n empfangen worden ist. Die Differenzzwischen extended highest sequence number received gibt die Anzahl derPakete, die man im Laufe der Übertragung zu bekommen erwartet . DieBedeutung und Berechnung der Beträge für die restlichen Felder wird inKapitel 6 detailliert beschrieben.12

134.4 Beispiel eines Receiver ReportsFeldEintragVersion 2PaddingFalseReception reportcount1Packet type 201Length 7Sender SSRC1921800069Source 1Identifier1919871431Fraction lost 255 / 256Cumulative numberof packets lostExtended highestsequence numberreceivedSequence numbercycles countHighest sequencenumber received1186201628036728542784277Interarrival jitter 1076Last SR timestamp 1049894200Delay since last SRtimestamp 72744.5. SDES : Source Description RTCP Paket.Die SDES Pakete (Abbildung 6) dienen zur Beschreibung der Teilnehmereiner Session und enthalten deshalb solche Items (Notizen) wie zumBeispiel E-mail , Name und Telefonnummer. Es müssen nicht alle Items injedem SDES Paket jedes Mal übertragen werden um den Netz nicht zuüberlasten, aber CNAME Item ist sehr wichtig für die eindeutigeIdentifikation des Teilnehmers, deshalb ist er in jedem SDES Paketenthalten. Die SSRC Nummer reicht nicht immer aus, denn wenn eineQuelle sowohl Audio als auch Videodaten sendet, kann jeder von diesenStrömen eine andere SSRC Nummer haben.Durch CNAME kann man aber diese Ströme einer Quelle eindeutigzuordnen.

140 1 2 30 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 1V =2 | P | SC | PT= SR= 202 | lengthSSRC/CSRC_1SDES itemsSSRC/CSRC_2SDES itemsAbbildung 6: SDES PaketJedes SDES Paket besteht aus einem 32 Bit Header. Die Bedeutung derFelder Version, Padding und Length ist dieselbe wie in den SR oder RRPaketen .Im Feld Source Count (SC) wird die Anzahl der Blöcke angegeben,die zu jedem Datenstrom der Quelle Informat ionen enthalten. Die Konstante202 im Feld Packet Type(PT) bezeichnet den SDES Paket. Nach demHeader folgen Blöcke mit den SSRC/CSRC_n Nummern der Sender. In derTabelle 2 sind alle Typen der SDES Items dargestellt.Jedes Item besteht aus einem 8 bit Feld( SDES Wert in der Tabelle), in demder Typ des Items angegeben wird und einem 8 bit length Feld, das dieLänge des folgenden beschreibenden Textes angibt, deren Länge maximal255 Oktetten betragen darf.SDES WERT EINTRAG IM FELD BEDEUTUNG0 END Ende der SDES Liste1 CNAME Canonical Name2 NAME Name des Teilnehmers3 E-MAIL E-Mail des Teilnehmers4 PHONE Telefonnummer des Teilnehmers5 LOC geografischer Standort des Teilnehmers6 TOOL Name der Software für Kommunikation7 NOTE Information über dem Zustand desTeilnehmers8 PRIV experimentelle ErweiterungTabelle 2: SDES items

154.6. Beispiel eines SDES Pakets :FeldEintragVersion 2PaddingFalsesource count 1Packet type 202length 15Chunk1,SSRC/CSRC 1921800069CNAME 1length 13textilia@gurevichEMAIL 3length 16textjmf-user@sun.comTOOL6length 16textJMF RTP PLAYERv2.04.7. Berechnung der Sendeperiode für RTCP - PaketeAn einer Audiokonferenz können mittels RTP mehrere hundert Menschenteilnehmen, ohne dabei den RTP-Datenstrom zu überlasten, denn zu einemZeitpunkt nur ein Paar von ihnen gleichzeitig sprechen werden. Anders siehtes im RTCP Datenstrom aus. Hier werden unterschiedliche Reportsgegenseitig und regelmäßig mittels Multicasting verschickt, was schnell zueiner Netzüberlastung führen kann, denn die Anzahl der gesendeten Reportsmit der wachsender Teilnehmerzahl linear ansteigt. Um die Überlastung zuverhindern, muss die Senderate von RTCP- Paketen in Abhängigkeit von derTeilnehmeranzahl und der Bandbreite berechnet werden. Da alleTeilnehmer ihre Reports aneinander senden, ist die Gesamtanzahl derTeilnehmer dadurch leicht bestimmbar. Jeder Teilnehmer führt eine Tabelle,in der die Gesamtanzahl der Teilnehmer eingetragen ist. Die Quellenwerden aus der Tabelle entfernt, wenn von ihnen im Laufe einesZeitintervalls keine Pakete gesendet wurden oder wenn diese Sender ByePakete gesendet haben um zu zeigen, dass sie die Konferenz verlassen.Die SDES Pakete mit Canonical Name , RR und SR Pakete müssen bevorzugtwerden, weil ihr periodisches Austauschen unter allen Teilnehmern einen

großen Einfluss auf die technische Qualität der Sitzung hat. So werden dieE-Mail Adresse und weitere beschreibende Items nicht in jedem SDES Paketgesendet. Es wird auch vereinbart, dass aktive Sender mehr Ressourcen zurVerfügung bekommen. Außerdem wird die Bandbreite des RTCP Verkehrsauf 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, umNetztüberlastung zu vermeiden. Wenn z.B. ein Sender Video in einer Ratevon 2 Mbps überträgt und die Bandbreite des RTCP -Stromes maximal 5%betragen darf, so dürfen nur 0,05*2Mbps= 100Kbps übertragen werden. DerSender bekommt in diesem Fall ¼ der Rate ( 25 Kbps) und der Empfänger75 Kbps. Wenn es R Empfänger gibt, so müssen 75 Kbps auf R Empfängeraufgeteilt 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]:16T=( N × D )(0,25 × 0,05 × S )Wenn also die Anzahl der Sender ansteigt muss die Periode T größerwerden. Für den Empfänger gilt folgende Formel:T=( N × D )(0,75 × 0,05 × S )5. JitterAbbildung 7: Darstellung eines JittersJitter bedeutet, dass Pakete eine unterschiedliche Laufzeit bei derÜbertragung zwischen dem Sender und Empfänger haben. Obwohl sie in

gleichen Zeitabständen gesendet wurden kommen sie ungleichmäßig anden Empfänger an. (Abbildung 7). Wenn ein Packet mit sehr großenVerzögerung an den Empfänger ankommt, muss die Anwendungentscheiden ob dieses Packet verwendet oder ausgelassen wird. UnterVerwendung von Sequenznummer und Timestamp kann man die Pakete inursprünglicher Reihenfolge anordnen und im Puffer speichern damit sierichtig synchronisiert werden können. Jeder Sender -und Receiver Reportenthält einen 32 bit Feld mit dem aktuellen Betrag des Jitters zwischen zweiaufeinander folgenden Paketen. Dieser Wert gibt die geschätzte statistischeVarianz der Zwischenankunftszeit der RTP Packete an und wird mit Jbezeichnet. 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 zweiaufeinander folgende Pakete berechnet man dabei die Zeit, die jeder vonbeiden Paketen zwischen dem Sender und Empfänger unterwegs ist. Dannwird die Paketlaufzeit eines Paketes von der des anderen Paketessubtrahiert. Diese Zeit wird in RTP Timestamp gemessen und mit Dbezeichnet:D(i, j) = (Rj- Sj) - (Ri- S)iInterarrival Jitter ist nun folgendermaßen rekursiv definiert:17J =J + = ( ) ⋅J+( | D( i-1,i ) | - J) 15 | D( i-1,i) |16 16 16Das Parameter 1/16 dient zur “ noice reduction”, d.h. eine starkeAbweichung des Wertes D kann keine große Auswirkung auf den Wert Jhaben, weil D durch 16 geteilt wird.6. Round –Trip TimeDie Zeit, die zwischen dem Absenden eines Sender Reports an denEmpfänger und dem Empfang seines Receiver Reports verläuft, nennt manRound –Trip time. Um sie zu berechnen, braucht man zwei neue Größen: LSRund DLSR.last SR timestamp (LSR) , 32 bits:Das sind die mittlere 32 bits des NTP - Timestamps des letzten Sender Reportsvon dem Sender SSRC_n. LSR ist gleich 0 falls kein SR bislang angekommenist.Delay since last SR ( DLSR) (32bit):Zeitintervall gemessen in 1/65536 Sec. zwischen dem Empfang des letzten SRvon SSRC_n und dem Abschicken des aktuellen RR Paketes. DLSR ist gleich 0falls 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,

an dem der Receiver Report zu ihm zurückkehrt. Diese Differenz ist ( F ).DieVerzögerungszeit zwischen dem Empfang des Sender Reports und demAbschicken des Receiver Reports wird als DLSR bezeichnet. Diese muss manschließlich von ( F ) subtrahieren, um dann die Round Trip Time ( RRT) zubekommen.18Abbildung 8: Grafsche Darstellung der Round -Trip Time7. Mixer und Translator.In einer Audiokonferenz kann es vorkommen, dass einige Teilnehmer übereine geringere Bandbreite mit den anderen Teilnehmern verbunden sindund somit Daten mit einer Verzögerung bekommen, was den Verlauf einerKonferenz erschwert. Um dieses Problem zu lösen muss möglichst am Anfangzu der schwächeren Verbindung ein Mixer geschaltet werden. Mittels Mixerkann man nun Audiodaten von mehreren sprechenden Teilnehmernsynchronisieren, sie in einen Gesamtstrom bündeln und danach einestärkere Komprimierung der Daten durchführen. Der gebündelteAudiostrom wird dann an die Teilnehmer gesendet, die ein schwächeresNetzwerk haben und so wird auf diese Weise eine schnellere Übertragungvon Audiosignalen an sie ermöglicht. Da Mixer mehrere Audioströme selbstsynchronisiert hat, tragen die Pakete des gebündelten Datenstroms seineSSRC Nummer. Damit der Empfänger die Sender von Audioströmenidentifizieren kann, enthält jeder RTP -Header der Pakete des Gesamtstromes

eine CSRC Liste mit SSRC Nummern der beitragenden Sendern. Dies wird inder Abbildung 9 veranschaulicht. Hier tragen die Pakete des gebündeltenStromes eine CSRC Liste mit SCRC Nummern 17 und 39 der Sender sowie dieSSRC Nummer des Mixers (5). Eine Veränderung des Datenformats oder dasBilden eines neuen Datenstromes aus mehreren Strömen mittels eines Mixersbringt natürlich auch eine Veränderung in den RTCP –Strom. So generiertMixer die Sender Reports mit Informationen über dem gebündeltemGesamtdatenstrom selber.In Abbildung 9 erkennt man außer Mixers einen Translator. Im Unterschiedzum Mixer bleibt die SSRC Nummer der Sender erhalten, wenn Translatordas Datenformat verändert. Translator kann das Format von mehrerenStrömen simultan verändern ohne dabei ein gebündeltesGesamtdatenstrom zu bilden. Im Gegensatz zum Mixer müssen die in denTranslator eingehenden Ströme keine gleichen Formate haben. In derAbbildung 9 werden die PCMU – und MPA Formate in ein GSM Formatumkodiert. Des Weiteren benutzt man einen Translator, um Daten anTeilnehmer zu schicken, die durch eine Firewall geschützt sind. Um Firewallzu überbrücken, schaltet man einen äußeren Translator vor der Firewall , derDaten durch diese an den inneren Translator transportiert. Schließlich ist einTranslator in der Lage, Multicast –Pakete in Unicast –Pakete umzuwandeln.Da Translator kein Bündeln von Daten durchführt, wird der Sender Reportnicht verändert. Wenn der Translator aber beispielsweise die Komprimierungder Daten ändert, so muss der Eintrag „ sender’s byte count „ im SenderReport aktualisiert werden. [1]19Abbildung 9: Translator und Mixer

208. ZusammenfassungRTP ist ein etabliertes Internet -Protokoll für die Echtzeitübertragung vonaudiovisuellen Daten. Es gliedert sich in zwei Teilprotokolle: Das RTP DataTransfer Protocol , das die Daten transportiert und das RTP Control Protocol(RTCP), das Informationen über Qualität der Übertragung und über dieTeilnehmer bereitstellt. Für diese Zwecke gibt es in RTCP fünf verschiedenePakettypen.RTP verfügt über Mechanismen zum Umgang mit unterschiedlichenProblemen, die bei der Datenübertragung entstehen können, wie zumBeispiel Jitter, Paketverluste und Vertauschung der ursprünglichenPaketreihenfolge. Unterschiedliche Datenströme können bei der Benutzungvon RTP synchronisiert werden und je nach Bedarf mittels Translator in einanderes Format umkodiert oder mittels Mixer in einen Gesamtdatenstromgebündelt werden, falls diese Datenströme gleiches Format haben.Die zusätzliche Unterstützung von Profils macht RTP zu einemTransportprotokoll, das eine breite Verwendung unter zahlreichenAnwendungen findet und deshalb für eine längere Zeitperiode aktuellbleiben wird.

219. 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