RTP et RTCP

EFORT http://www.efort.com
Pour transporter la voix ou la vido sur IP, le protocole IP (Internet Protocol) au niveau 3 et le protocole UDP (User Datagram Protocol) au niveau 4 sont utiliss. En effet, si TCP (Transmission Control Protocol) prsente l'avantage de grer un transfert fiable (renvoi des paquets IP en cas d'erreur), il est malheureusement incompatible avec un flux temps-rel dans la mesure ou les mcanismes de TCP prvoient une rduction automatique du dbit accord l'metteur en cas de congestion du rseau et une remonte lente vers le dbit nominal (ceci afin de protger le rseau de soubresauts d'metteurs qui chercheraient tous en mme temps tirer parti de la bande passante disponible). Mais ces deux protocoles UDP et IP ne suffisent pas assurer le transport de la voix. De fait, UDP est un protocole sans correction d'erreur, et aucun moment l'arrive des paquets dans leur ordre dmission est assure. Pour le transport de donnes temps rel telles que la voix ou la vido, il est ncessaire dutiliser deux protocoles supplmentaires : RTP (RealTime transport Protocol) et RTCP (RTP Control Protocol). RTP et RTCP sont des protocoles qui se situent au niveau de l'application et sappuient sur le protocole de transport UDP. RTP et RTCP peuvent utiliser aussi bien le mode Unicast (point point) que le mode Multicast (multipoint). RTP et RTCP utilisent des ports diffrents. RTP utilise un numro de port pair, et RTCP le numro de port impair qui suit directement. Lorsquune session RTP est ouverte, alors une session RTCP est aussi ouverte de manire implicite. Les numros de port utiliss par RTP et RTCP sont compris entre 1025 et 65535. Les ports RTP et RTCP par dfaut sont respectivement 5004 et 5005. Le paragraphe 1 introduit le protocole RTP. Le paragraphe 2 prsente les entits Mixer et Translator pouvant tre utilises lors dchanges de paquets RTP. Le paragraphe 3 dcrit la structure des paquets RTP. Enfin le paragraphe 4 dtaille le protocole RTCP, son fonctionnement et les paquets RTCP.

1. RTP (Real-Time Transport Protocol)

Le but de RTP et de fournir un moyen uniforme de transmettre sur IP des donnes soumises des contraintes de temps rel (audio, vido, etc.). RTP permet : d'identifier le type de l'information transporte, d'ajouter des marqueurs temporels permettant dindiquer linstant dmission du paquet. Lapplication destinataire peut alors synchroniser les flux et mesurer les dlais et la gigue. dinclure des numros de squence l'information transporte afin de dtecter loccurrence de paquets perdus et de dlivrer les paquets en squence lapplication destinataire. De plus, RTP peut tre vhicul par des paquets multicast afin d'acheminer des conversations vers des destinataires multiples. Mais, RTP n'a pas t conu pour effectuer des rservations de ressources ou contrler la qualit de service et ne garantit pas la livraison du paquet larrive.

2. Mixer et Translator
Le mixer (mixeur) est une application qui reoit des flux de donnes de plusieurs sources quon appelle SSRCs (Synchronization Sources), en modifie ventuellement le format et

Copyright EFORT 2008

renvoie un seul flux de donnes agrg. L encore, dans une application de confrence, il est probablement conomique de regrouper ds que possible les flots sonores provenant de plusieurs sources, puisque, de toutes faons, ils seront mlangs chez les destinataires. En faisant ce travail, le mixer se comporte comme une source particulire (SSRC) qui regroupe les donnes de plusieurs autres sources qui taient des SSRCs et qui deviennent des CSRC (Contributing Source). Les paquets mis par une quelconque source (terminal, mixer) contiennent une information didentification de la SSRC qui les met. Ces paquets peuvent contenir galement lidentification des CSRC qui sont les sources relles des informations lorsquil sagit dun paquet construit par transformation. Dans lexemple reprsent la figure 1, un mixer reoit des paquets de trois sources (SSRC). Il peut raliser des conversions de format, mixe le contenu en fonction de lapplication et produit un nouveau paquet RTP quil relaye la destination. Le mixer fournit la synchronisation pour le nouveau flux et sidentifie comme la nouvelle source SSRC. Les trois sources origines sont dclares comme CSRC dans le paquet RTP compos.
T1 SSRC = 1 T2 SSRC = 2 T3 SSRC = 3 SSRC = M CSRC = 1 CSRC = 2 CSRC = 3 Mixer M T4

Figure 1 : Mixer RTP Le translator (traducteur) est une application qui transmet les paquets RTP quelle reoit sans changer lidentificateur de SSRC ( linverse de ce que fait le mixeur). Un traducteur permet par exemple de changer le codage dune donne ou le dbit, ou encore de traiter les problmes de scurit (firewalls) la frontire dun rseau priv. Si un terminal utilisant un codage PCM -law 64 kbit/s souhaite tablir une session avec un terminal supportant un codage G.726 ADPCM 32 kbit/s, alors il est ncessaire dinterfacer les deux terminaux travers un translator. Les fonctions Mixer et Translator sont gnralement mises en uvre dans un Gateway.

3. Les donnes RTP

RTP transporte les signaux audio ou vido encods laide de paquets RTP contenant un header RTP (en-tte) suivi de ces signaux audio ou vido. Un paquet RTP est soumis la couche UDP qui y rajoute un en-tte UDP. Lensemble est soumis la couche IP qui y agrge un en-tte IP. Le datagramme IP est alors rout la destination. A la rception, le paquet est dlivr la bonne application.

3.1.

Codage des signaux

Il est essentiel compte tenu du nombre important de normes de codage de signaux audio ou vido dinclure un mcanisme RTP afin de permettre au destinataire de connatre le codage utilis et ainsi pouvoir dcoder correctement. RTP ralise cette fonction grce au numro de type de contenu (payload type number) dans le header (en-tte) RTP. Les

Copyright EFORT 2008

numros de type de contenu sont spcifis dans le RFC 3551 (RTP Profile for Audio and Video Conferences with Minimal Control) et sont lists dans le tableau 1.
Type Codec Frquence Description Payload (Hz) 0 PCMU 8000 ITU G.711 PCM -Law audio 64 kbit/s 1 1016 8000 CELP Audi 4.8 kbit/s 2 G721 8000 ITU G.721 ADPCM Audio 32 kbit/s 3 GSM 8000 European GSM Audio 13 kbit/s 5 DVI4 8000 DVI ADPCM Audio 32kbit/s 6 DVI4 16000 DVI ADPCM Audio 64kbit/s 7 LPC 8000 Experimental LPC Audio 8 PCMA 8000 ITU G.711 PCM A-Law audio 64 kbit/s 9 G722 8000 ITU G.722 Audio 10 L16 44100 Linear 16 bit Audio 705,6 kbit/s 11 L16 44100 Linear 16 bit Stereo Audio 1411.2 kbit/s 14 MPA 90000 MPEG-I ou MPEG-II Audio 15 G728 8000 ITU G.728 Audio 16kbit/s 25 CELB 90000 CelB Video 26 JBEG 90000 JBEG Video 28 NV 90000 Nv Video 31 H261 90000 ITU H.261 Video 32 MPV 90000 MPEG-I et MPEG-II Video 33 MP2T 90000 MPEG-II transport stream Video

Tableau 1 : Les types de payload pour lencodage de signaux audio et vido

3.2. Encodage PCM

Le code du son avec une qualit de type tlphonique est bas sur le PCM -law ou parfois a-law. La norme -law tait celle en vigueur sur le rseau tlphonique amricain, la norme a-law celle en vigueur sur le rseau tlphonique europen. Dans cette norme, le son est cod sur 14 bits avec une frquence de 8000 Hertz, puis chaque chantillon est ramen une largeur de 8 bits laide dune table de translation. Cest la diffrence entre ces tables de translation qui spare les deux codages -law et a-law. Cette frquence dchantillonnage fournit une frquence audible couvrant la place de 300 Hertz 3500 Hertz. Avec des chantillons de 8 bits, le flux gnr atteint un dbit de 64 kbit/s.

3.3. Encodage ADPCM

Une compression ADPCM par codage diffrentiel a t propose afin de rduire le dbit gnr. Celui-ci passe 32 kbit/s. Cette compression altre trs faiblement la qualit sonore, tout au plus, limite-t-elle la dynamique dans les aigus.

3.4. Format du paquet RTP

L'en-tte d'un paquet RTP (RTP header) est obligatoirement constitu de 12 octets, ventuellement suivi d'une liste d'identificateurs de sources contributives CSRCs dans le cas d'un mixer. Cet en-tte prcde le "payload" qui reprsente les donnes utiles (Figure 2).
RTP Header (12 octets) Payload

Figure 2 : Format du paquet RTP Version (V) (2 bits) : Ce champ indique le numro de version RTP utilise. La version actuelle est la version 2.

Copyright EFORT 2008

 Padding (P) (1 bit) : Si positionn 1, ce champ signifie que le champ des donnes (payload) a une partie de bourrage. Rappelons que la longueur des donnes doit tre un multiple de 4 octets, do la ncessit doctets de bourrage, notamment pour le dernier paquet. Le dernier octet de cette partie de bourrage indique le nombre doctets de bourrage ignorer. Extension (X) (1 bit) : Si positionn 1, ce champ indique que len-tte fixe a une partie den-tte supplmentaire. CSRC Count (CC) (4 bits) : Ce champ contient le nombre didentifiants CSRC qui suivent len-tte fixe, cest dire le nombre de sources contributives lies ce paquet. Marker (M) (1 bit) : Il sagit dun bit de signalisation. Sa signification dpend des donnes transportes. Payload type (PT) (7 bits) : Ce champ identifie le type de contenu (audio, vido, etc.) qui reprsente le type de codage dinformation vhicul dans le paquet. La liste est prsente au tableau 8.1. Sequence Number (16 bits) : La valeur de ce champ est incrmente de 1 chaque paquet RTP envoy alors que sa valeur initiale est alatoire. Ce champ permet de dtecter des paquets RTP perdus. TimeStamp (32 bits) : Un protocole comme RTP utilise des estampilles temporelles pour dater les paquets mis. Ces informations sont la base de calculs permettant dvaluer le dlai et la gigue introduits par un systme de communication. La pertinence de ces informations dpend toute entire de la prcision et de la synchronisation des horloges utilises dans les machines qui vont appuyer leurs calculs sur ces valeurs. Synchronization Source (SSRC) (32 bits) : Ce champ identifie la source ayant produit le paquet. Au dbut dune session, chaque participant choisit un numro de SSRC. On parle ici de synchronisation car lchelle de temps installe par la source dans ses paquets va servir de repre aux rcepteurs pour restituer linformation correctement. Contributing source (CSRC) : 0 15 instances de ce champ peuvent tre prsentes dans len-tte du paquet RTP. Le nombre est indiqu par le champ CC. Lorsquun flux RTP est le rsultat dune agrgation par un mixeur RTP de plusieurs flux RTP, la liste des SSRCs ayant apport leur contribution est rajoute dans len-tte des paquets RTP du flux rsultant (Figure 3).
1 2 3 0 01234567 89012345 67890123 45678901 V=2 P X CC M PT Sequence number Timestamp Synchronization Source (SSRC) Identifier Contributing Source (CSRC) Identifiers (0-15 Entres)

Figure 3 : En-tte RTP

4. RTCP (RTP Control Protocol)

Le protocole RTCP est bas sur des transmissions priodiques de paquets de contrle par tous les participants dans la session. C'est un protocole de contrle des flux RTP, permettant de vhiculer des informations basiques sur les participants d'une session, et sur la qualit de service. Il existe cinq types diffrents de paquets RTCP pour chaque type d'information : SR (Sender Report) contient des statistiques de transmission et de rception pour les participants qui sont des metteurs actifs. RR (Receiver Report) contient des statistiques de rception pour les participants qui ne sont pas des metteurs actifs mais rcepteurs dune session. SDES (Source Description) dcrit la source : nom, email, tl, etc. BYE permet une station dindiquer la fin de sa participation une session. APP est un paquet de signalisation spcifique une application.

Copyright EFORT 2008

Le contrle de flux RTP est ralis en gardant une valuation du nombre de participants une session (sources et rcepteurs). A partir de cette valuation on calcule un intervalle de temps qui sert de priode de rcurrence la diffusion des informations SR ou RR suivant le cas. Globalement, les algorithmes de contrle limitent le volume des informations de contrle transmises (les donnes RTCP donc) 5% du volume global des changes de la session. Dans ce volume, 25% sont rserves aux informations des sources (messages SR). On garantit ainsi une possibilit de grer des groupes de grande taille du point de vue du volume dinformation chang. Plus le nombre de participants est lev, moins prcise est la vision qua chaque participant de ltat du rseau. Si lon considre une session audio avec deux participants, des paquets RTCP peuvent tre mis toutes les 5 secondes alors que pour quatre participants, ils sont mis toutes les 10 secondes. Les paquets qui sont le plus frquemment transmis sont SR et RR.

4.1. Paquet RTCP Sender Report (SR)

Les participants une session qui la fois mettent et reoivent des paquets RTP utilisent les paquets RTCP SR. Le format de ce paquet est prsent la figure 4. Le paquet SR contient un header (en-tte), des informations sur lmetteur, un certain nombre de blocs de rapports de rception et optionnellement une extension spcifique au profil. La structure est similaire celle dun paquet RTP. Len-tte contient les champs suivants : Version (V) (2 bits) : Ce champ indique le numro de version RTCP. La valeur de la version courante du protocole RTCP est 2 (10). Padding (P) (1 bit) : Positionn la valeur 1, ce champ indique qu'il y a un bourrage dont la taille est indique dans le dernier octet. Reception report count (RC) (5 bits) : Ce champ prcise le nombre de rapports de rception contenus dans le paquet SR, en considrant un rapport pour chaque source. Un maximum de 31 rapports peut donc tre inclus dans le paquet SR. Packet type (PT) (8 bits) : Ce champ indique le type de paquet ; il sagit dun paquet SR, reprsent par la valeur 200. Length (16 bits) : Ce champ indique la longueur totale du paquet en mots de 32 bits (entte et bourrage compris). Les informations sur lmetteur consistent en les champs suivants : SSRC of sender (32 bits) : Ce champ prcise lidentification de la source spcifique l'metteur. NTP timestamp (64 bits) : La reprsentation du temps utilise par NTP (Network Time Protocol) est assez simple : une date est code sur 64 bits et mesure en secondes depuis 0h le premier janvier 1900. La partie entire de cette date exprime en secondes est code sur les 32 bits de poids fort (most significant word), la partie fractionnaire (fraction de seconde) sur les 32 bits de poids faible (least significant word). Cette reprsentation garantit une prcision d peu prs 200 pico-secondes, ce qui est probablement suffisant pour la plupart des applications. Le problme du bouclage zro de cette reprsentation interviendra en 2036. Il sera donc ncessaire de dfinir une nouvelle version du protocole avant cette date. RTP timestamp (32 bits): Ce champ indique le mme temps que celui prsent le champ NTP Timestamp prcdent, mais en utilisant les mmes units que celles utilises pour spcifier la valeur timestamp dans les paquets RTP. Senders packet count (32 bits) : Ce champ indique le nombre total de paquets RTP transmis par lmetteur depuis le dbut de la session. Il est rinitialis dans le contexte dune session si lmetteur change didentificateur SSRC.

Copyright EFORT 2008

 Senders octet count (32 bits) : Ce champ indique le nombre total doctets RTP (ne sont considrs que les octets de donnes utilisateur et non les octets den-tte ou de bourrage) transmis par lmetteur depuis le dbut de la session. Il est aussi rinitialis si lmetteur change didentificateur de SSRC.
0 1 2 3 01234567 89012345 67890123 45678901 V=2 P RC PT=SR=200 Length Header SSRC of sender NTP Timestamp (most significant word) Sender NTP Timestamp (least significant word) Info RTP Timestamp Senders packet count Senders octet count SSRC_1 (SSRC of first source) Report Fraction lost Cumulative number of packets lost block1 Extended highest sequence number received Interarrival jitter Last SR (LSR) Delay since last SR (DLSR) SSRC_2 (SSRC of second source) Report ... block2, etc. Profile-specific extensions

Figure 4 : Paquet RTCP Sender Report Un ou plusieurs blocs de rapports de rception (RR, Receiver Report) suivent linformation de lmetteur. Ils fournissent aux autres participants de la session linformation concernant le nombre de paquets RTP quils ont mis et qui ont t reus avec succs par lmetteur du paquet SR. Les champs suivants sont inclus dans chaque bloc RR (Figure 5): SSRC_n (32 bits): Ce champ prcise lidentification de la source dans la session, qui est concerne par les donnes incluses dans le bloc RR. Fraction lost (8 bits): Ce champ indique la fraction de paquets RTP perdus depuis le dernier rapport mis par ce participant. La fraction reprsente le rapport entre le nombre de paquets perdus et le nombre de paquets attendus. Le nombre de paquets perdus peut tre dduit partir de lanalyse du numro de squence (Sequence Number) de chaque paquet RTP reu. Cumulative number of packets lost (24 bits): Ce champ indique le nombre total de paquets RTP de la source en question qui ont t perdus depuis le dbut de la session RTP. Extended highest sequence number received (32 bits): Ce champ prcise le numro de squence du dernier paquet RTP reu depuis cette source SSRC_n. Interarrival jitter (32 bits) : Ce champ renseigne sur la variation du dlai de transmission des paquets RTP. Last SR Timestamp (LSR) (32 bits) : Ce champ reprsente les 32 bits du milieu du champ NTP Timestamp utilis dans le dernier paquet SR reu depuis la source en question. Il considre donc les 16 bits de poids faible de la partie entire de cette date (secondes) et les 16 bits de poids fort de la partie fractionnaire (fractions de seconde). Si aucun paquet RTCP SR na encore t reu, alors la valeur de ce champ est gale 0. Delay Since Last SR (DLSR) (32 bits) : Ce champ reprsente le dlai exprim en units de 1/65536 secondes entre linstant de rception du dernier paquet SR de la source SSRC_n et linstant dmission de ce bloc RR. Si aucun paquet SR na encore t reu de la source SSRC_n, la valeur du champ DLSR est positionne 0.

Copyright EFORT 2008

4.2. Paquet RTCP Receiver Report (RR)

Le paquet RCTP RR (Receiver Report) est mis par un participant une session qui reoit des paquets RTP mais nen met pas. Le format du paquet est prsent la figure 5. Il a une structure similaire au paquet RTCP SR, mais indique la valeur 201 pour le champ payload type et ninclut pas dinformation spcifique lmetteur.
0 1 2 3 01234567 89012345 67890123 45678901 V=2 P RC PT=RR=201 Length Header SSRC of packet sender SSRC_1 (SSRC of first source) Report Fraction lost Cumulative number of packets lost block1 Extended highest sequence number received Interarrival jitter Last SR (LSR) Delay since last SR (DLSR) SSRC_2 (SSRC of second source) Report ... block2, etc. Profile-specific extensions

Figure 5 : Paquet RTCP Receiver Report

4.3. Paquet Source Description (SDES)

Le paquet RTCP SDES (Source Description) permet didentifier les participants une session et de fournir des informations sur ces participants. La structure du paquet SDES est compose dun header (en-tte) et de zro, un ou plusieurs chunks, chacun dcrivant la source identifie dans ce chunk (Figure 6). Len-tte comprend : Les champs Version Padding et Length qui ont la mme signification que ceux du paquet RTCP SR. Le champ Packet Type (PT) sur 8 bits qui indique un paquet SDES, reprsent par la valeur 202. Le champ Source Count (SC) sur 5 bits qui indique le nombre de chunks SSRC/CSRC contenus dans le paquet SDES. Chaque Chunk contient une valeur de SSRC ou de CSRC suivie par un ou plusieurs identificateurs et par des informations dcrivant ce SSRC ou CSRC. Ces informations sont dnommes SDES items et peuvent inclure des donnes telles que le nom, ladresse Email, le numro de tlphone, la localisation de lutilisateur, etc. Les terminaux doivent envoyer un paquet SDES au dbut de la session afin que chaque particpant soit explicitement identifi. Le mixer combine les paquets SDES de diffrents participants et produit un paquet compos dautant de Chunks que de paquets SDES origine.

Copyright EFORT 2008

0 1 2 3 01234567 89012345 67890123 45678901 V=2 P SC PT=SDES=202 Length Header SSRC/CSRC_1 Chunk 1 SDES Items SSRC/CSRC_2 Chunk 2 SDES Items

Figure 6 : Paquet RTCP Source Description

4.4. Paquet RTCP BYE

Le paquet RTCP BYE permet dindiquer quune source (un participant la session) nest plus active. Les champs Version, Padding et Length ont la mme signification que ceux du paquet RTCP SR. Le champ Packet Type (PT) indique le type de paquet RTCP. il sagit dun paquet BYE, reprsent par la valeur 203. Le champ Source Count (SC) indique le nombre didentificateurs SSRC/CSRC inclus dans ce paquet. Si un paquet BYE est reu par un mixer, il le relaye avec les identificateurs SSRC/CSRC inchangs. Si par contre le mixer doit arrter de fonctionner, il doit alors mettre un paquet BYE listant toutes les sources contributives quil prend en charge, ainsi que son propre identificateur SSRC. Enfin, le champ optionnel Reason for leaving indique, sous la forme dune chane de caractres, la raison de lenvoi du paquet BYE. Ce champ est prcd par sa longueur. A la diffrence du paquet SDES, il nest pas possible de mixer plusieurs paquets BYE en un seul paquet BYE compos.
1 2 3 0 01234567 89012345 67890123 45678901 V=2 P SC PT=BYE=203 Length Header SSRC/CSRC Length Reason for leaving ( optional)

Figure 7 : Paquet RTCP BYE

4.5. Paquet RTCP APP

Le paquet RTCP APP est un paquet de signalisation spcifique aux applications (Figure 8). Les champs Version, Padding et Length ont la mme signification que ceux du paquet RTCP SR. Le champ subtype (5 bits) peut tre utilis afin de dfinir un sous-type identifiant un ensemble de paquets APP. Le champ name affecte un nom unique (4 caractres) pour le sous-type. Les donnes dpendant de lapplication sont incluses dans le champ Applicationdependent data .
0 1 2 3 01234567 89012345 67890123 45678901 V=2 P Subtype PT=APP=204 Length SSRC/CSRC Name (ASCII) Application-dependent data

Figure 8 : Paquet RTCP APP

Copyright EFORT 2008

5. Conclusion
Les protocoles RTP et RTCP sont adapts pour la transmission de donnes temps rel. Cependant, ils fonctionnent en stratgie bout bout et donc ne peuvent contrler l'lment principal de la communication : le rseau. Pourtant, quelques soient les efforts d'adaptation des metteurs, ou les moyens mis en uvre par les rcepteurs, c'est au cur du rseau que les dysfonctionnements critiques sont gnrs. Le protocole Internet a t volontairement pens pour reporter l'intelligence vers les systmes d'extrmit. C'est cette simplicit qui a conduit au succs d'Internet. Le protocole RSVP (Resource Reservation Protocol) dfini par lIETF a t dvelopp afin de remdier ces dysfonctionnements et ainsi amliorer les transmissions temps rel. Les protocoles RTP et RTCP sont principalement utiliss en visioconfrence, o les participants sont tour tour, metteurs ou rcepteurs. Pour le transport de la voix, ils permettent une transmission correcte sur des rseaux bien cibls. C'est--dire, des rseaux qui implmentent une qualit de service adapte (ATM). Il est aussi possible de sappuyer sur des rseaux bien dimensionns (bande passante, dterminisme des couches sousjacentes, etc.), de type LAN d'entreprise.

Copyright EFORT 2008