Comment Ca Marche l'informatique ?
Accueil
Forum
Aide
bordure
Page d'accueil
Ajouter aux favoris
Signalez une erreur
Ecrire à Jean-Francois Pillou
Présentation
Protocole
Adresses IP
Noms de domaines
Notion de port
Les URLs
Avancé:TCP/IP
Avancé:Protocole IP
Avancé:Protocole ARP
Avancé:Protocole ICMP
Avancé:Protocole TCP
Avancé:Protocole UDP
Avancé:Routage
Avancé:PPP et SLIP
Avancé:Protocole HTTP
Avancé:Protocole LDAP
Avancé:Protocole DHCP
Avancé:Protocole SNMP
Avancé:Protocole RTCP
Avancé:Protocole IPv6
Avancé:NAT
Avancé:VLAN
Avancé:POP, SMTP, IMAP
Avancé:Protocole FTP
Avancé:Protocole Telnet
Avancé:Les RFC
Version 2.0.3
Les protocoles RTP/RTCP Page précédente Page suivante Retour à la page d'accueil

Document écrit par Nico VanHaute, Julien Barascud et Jean-Roland Conca de l'IUT de Béziers

Introduction : Qu'est ce que RTP et RTCP ?

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.

RTP (Real-time Transfert Protocole)

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.

RTCP (Real-time Transfert Control Protocole)

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

Utilisation prévue de RTP et RTCP

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.

Format des en-têtes et leurs contenus

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'en-tête RTCP

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)

Comment est utilisé RTCP vis à vis de RTP ?

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.

Au-dessus de quels protocoles fonctionnent RTP et RTCP

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.

Comment le type de flux est-il véhiculé ?

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


Page précédente Page suivante

Ce document issu de CommentCaMarche.net est soumis à la licence GNU FDL. Vous pouvez copier, modifier des copies de cette page tant que cette note apparaît clairement.