Document écrit par Nico VanHaute, Julien Barascud et Jean-Roland Conca de l'IUT de Béziers
La diffusion des ordinateurs, ajouté à la disponibilité de matériel informatique audio/vidéo bon marché, ainsi qu'à la disponibilité de liaisons à plus haut débit, ont fait surgir l'intérêt d'utiliser le réseau Internet pour envoyer de l'audio et de la vidéo, types de données qui traditionnellement étaient réservés aux réseaux spécialisés à cet effet, et depuis déjà quelques années l'audio et la vidéoconférence sont devenus une pratique courante. Mais la nature même de l'Internet, fait que ce réseau ne soit pas adapté pour la transmission des données temps réel, ceci a comme conséquence que la qualité de l'audio envoyé à travers l'Internet a en moyen une qualité médiocre. Cette thèse s'adresse précisément à l'analyse et solution de ces problèmes pour permettre à une application d'audioconférence ou téléphone sur Internet, d'adapter son comportement pour maintenir une qualité auditive acceptable même dans des cas où le réseau est assez congestionné. Ces solutions, sous la forme de mécanismes de contrôle, ont été implémentées et testées sur le logiciel d'audioconférence et téléphone sur Internet Free Phone que nous avons développé. Une étude sur le comportement qui auraient ces mécanismes dans un Internet qui évoluait pour intégrer la discipline de service Fair Queueing a montré que ces mécanismes, qui seraient encore nécessaires, auraient même une meilleure performance dans ce type de réseau.
Le but de RTP et de fournir un moyen uniforme de transmettre sur IP des données soumises à des contraintes de temps réel (audio, vidéo, ... ).
Le rôle principal de RTP consiste à mettre en oeuvre des numéros de séquence de paquets IP pour reconstituer les informations de voix ou vidéo même si le réseau sous-jacent change l'ordre des paquets.
Plus généralement, RTP permet :
- d'identifier le type de l'information transportée,
- d'ajouter des marqueurs temporels et des numéros de séquence l'information transporte
- de contrôler l'arrivée à destination des paquets.
De plus, RTP peut être vehiculé par des paquets multicast afin d'acheminer des conversations vers des destinataires multiples.
Le protocole RTCP est base sur des transmissions périodiques de paquets de contrôle par tous les participants dans la session.
C'est un protocole de contrôle des flux RTP, permettant de véhiculer des informations basiques sur les participants d'une session, et sur la qualité de service
RTP permet une gestion des flux multimédias (voix, vidéo) sur IP. RTP fonctionne sur UDP. L'en-tête RTP comporte des informations de synchronisation, de numérotation. Le codage des données dépendra du type de compression. Le RFCxxxx spécifie RTP, par contre l'adaptation d'une méthode de compression à RTP sera décrite dans un RFC spécifique, par exemple H261 sur RTP est décrit dans le RFCxxxx.
Un canal RTP est employé par type de flux: un pour l'audio, un pour la vidéo. Le champ xxx est employé pour la synchronisation. RTP offre un service de bout en bout. Il ajoute un en-tête qui fournit les informations de timing nécessaires à la synchronisation de flux temps réel du type son et vidéo.
RTP (Realtime Transport Protocol) et son compagnon RTCP (Realtime Transport Control Protocol) permettent respectivement de transporter et de contrôler des flots de données qui ont des propriétés temps-réel. RTP et RTCP sont des protocoles qui se situent au niveau de l'application et utilisent les protocoles sous-jacents de transport TCP ou UDP. Mais l'utilisation de RTP/RTCP se fait généralement au-dessus de UDP.
RTP et RTCP peuvent utiliser aussi bien le mode Unicast (point à point) que le mode Multicast (multipoint).
Chacun d'eux utilise un port séparé d'une paire de ports. RTP utilise le port pair et RTCP le port impair immédiatement supérieur.
L'en-tête RTP comportera les informations suivantes:
<--------------------------- 32 bits --------------------------->
V=2 |
P |
X |
CC |
M |
Sequence number
|
Timestamp |
Identifiant de la source de synchronisation (SSRC) |
Identifiants de la source de contribution (CSRC) |
Voici la signification des différents champs de l'en-tête:
- Le champ Version V de 2 bits de longueur indique la version du protocole (V=2)
- Le champ padding P : 1 bit, si P est égal à 1, le paquet contient des octets additionnels de bourrage (padding) pour finir le dernier paquet.
- Le champ extension X : 1 bit, si X=1 l'en-tête est suivie d'un paquet d'extension
- Le champ CSRC count CC : 4 bits, contient le nombre de CSRC qui suivent l'entête
- Le champ marker M: 1 bit, son interprétation est définie par un profil d'application (profile)
- Le champ payload type PT : 7 bits, ce champ identifie le type du payload (audio, vidéo, image, texte, html, etc.)
- Le champ séquence number : 16 bits, sa valeur initiale est aléatoire et il s'incrémente de 1 à chaque paquet envoyé, il peut servir à détecter des paquets perdus
- Le champ timestamp : 32 bits, reflète l'instant où le premier octet du paquet RTP à été échantillonné. Cet instant doit être dérivé d'une horloge qui augmente de façon monotone et linéaire dans le temps pour permettre la synchronisation et le calcul de la gigue à la destination
- Le champ SSRC : 32 bits, identifie de manière unique la source, sa valeur est choisie de manière aléatoire par l'application.
Le champ SSRC identifie la source de synchronisation (ou dit simplement "la source"). Cet identificateur est choisi de manière aléatoire avec l'intérêt qu'il soit unique parmi toutes les sources d'une même session
La liste des CSRC identifie les sources (SSRC) qui ont contribué à l'obtention des données contenues dans le paquet qui contient ces identificateurs. Le nombre d'identificateurs est donné dans le champ CC
- Le champ CSRC : 32 bits, identifie les sources contribuant.
L'objectif de RTCP est de fournir différents types d'informations
et un retour quant à la qualité de réception.
L'en-tête RTCP comportera les informations suivantes:
- Le champ version (2 bits)
- Le champ padding (1 bits) indique qu'il y a du bourrage dont la taille est indiquée dans le dernier octet
- Le champ reception report count (5 bits): nombre de compte-rendus dans le paquet
- Le champ packet type (8 bits) 200 pour SR
- Le champ length (16 bits) longueur du paquet en mots de 32 bits
- Le champ SSRC (32 bits): identification de la source spécifique à l'émetteur
- Le champ NTP timestamp (64 bits)
- Le champ RTP timestamp (32 bits)
- Le champ sender's packet count (32 bits)
- Le champ sender's octet count (32 bits) statistiques
- Le champ SSRC-n (32 bits) numéro de la source dont le flux est analysé
- Le champ fraction lost (8 bits)
- Le champ cumulative number of packets lost (24 bits)
- Le champ extended highest sequence number received (32 bits)
- Le champ interarrival jitter (32 bits).
C'est une estimation de l'intervalle de temps d'un packet de donnés RTP qui est
mesuré avec le timestamp et qui est sous forme d'un entier.
C'est en fait le temps relatif de transit entre deux paquets de donnés.
La formule pour le calculer est : J=J+(|D(i-1,i)|-J)/16
L'interarrival jitter est calculé à chaque packet de donnée reçu par la source SSRC_n
i --> Premier paquet
i-1 --> paquet précédent
D --> différence
J --> Second paquet
- Le champ last SR timestamp (32 bits)
- Le champ delay since last SR (32 bits)
RTCP est un protocole de contrôle associé à RTP, il mesure les performances, par contre il n'offre pas de garantie. Pour cela il faut, employer un protocole de réservation du type RSVP ou bien s'assurer que les liens de communications utilisés sont correctement dimensionnés par rapport à l'utilisation qui en est faite.
RTP/RTCP est au-dessus du transport UDP/TCP, mais pratiquement au-dessus de UDP.
RTP est un protocole de session, mais il est placé dans l'application.
C'est au développeur de l'intégrer.
RTP n'a rien a voir avec le type de flux, il est au-dessus de UDP lui-même au-dessus de IP. Le type de flux est théoriquement utilise dans IP.
RTP apporte un numéro de séquence, un timestamp et un identificateur unique de la source (SSRC).
Article écrit par Nico VanHaute, Julien Barascud et Jean-Roland Conca
|