Real-time Transport Protocol
Pour les articles homonymes, voir RTP.
Cet article est une ébauche concernant l’informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
Consultez la liste des tâches à accomplir en page de discussion.
Real-Time Transport Protocol (RTP) est un protocole de communication informatique permettant le transport de données[1] soumises à des contraintes de temps réel, tels que des flux média audio ou vidéo[2].
Utilisation[modifier | modifier le code]
RTP est à l'heure actuelle principalement utilisé comme transport de média pour les services de la voix sur IP ou de vidéo conférence, voire de streaming. En mode unidirectionnel, il est toujours associé avec un autre protocole de signalisation qui gère l'établissement de session et permet l'échange du numéro de port utilisé par les deux extrémités. On peut citer :
- le protocole SIP pour les services de VoIP et de visioconférences ;
- le protocole H.323 pour les mêmes services (ancienne génération) ;
- le protocole RTSP pour le streaming bien que ce dernier possède un mode d'encapsulation TCP.
Le protocole ajoute un en-tête spécifique aux paquets UDP pour
- spécifier le type et le format (codec) du média transporté ;
- numéroter les paquets afin de pouvoir gérer les pertes et les dé-séquencements ;
- fournir une indication d'horloge pour gérer la gigue.
RTP sera utilisé avantageusement sur un réseau temps réel (par exemple un réseau ATM à bande passante garantie, un canal optique, une radiodiffusion ou un canal satellite).
RTP est unidirectionnel mais peut être utilisé en mode diffusion (multicast) via satellite. Il est alors extrêmement économique en termes de ressources réseau pour servir un grand nombre de récepteurs, ce qui permet d'augmenter considérablement le débit utile et la qualité de codage du contenu.
Caractéristiques techniques[modifier | modifier le code]
Canal de retour[modifier | modifier le code]
Bien qu'unidirectionnel, RTP peut toutefois être utilisé conjointement avec un canal de retour (feedback) sur la qualité de service (QoS) via RTCP (Real-Time Transport Control Protocol), négocié indépendamment (voir RTSP). Ce feedback peut par exemple informer l'émetteur sur les propriétés temps-réel du canal, l'état du tampon du récepteur, ainsi que demander des changements de compression/débit pour les applications multimédia par exemple (dans ce cas, les données manquantes pourront être transmises via Unicast).
Pour la diffusion en masse cependant (flux en direct, radiodiffusé), cette voie de retour n'est généralement pas utilisée, mais le contenu est transmis plusieurs fois en parallèle avec un décalage temporel suffisant pour pallier les interruptions temporaires de qualité de réception, mais n'excèdent pas les limites des tampons des récepteurs (normalement pas plus d'une quinzaine de secondes d'écart). Le récepteur peut alors reconstituer et réordonner la séquence complète afin d'obtenir un flux continu sans perte.
Mode multicast[modifier | modifier le code]
La mise en œuvre de RTP en mode multicast requiert la configuration préalable de routage au niveau du récepteur, qui doit faire lui-même la demande de routage à ses routeurs hôtes, entre l'émetteur et le récepteur. L'émetteur quant à lui informe séparément les routeurs de diffusion auxquels il est directement connecté.
Pour les contenus protégés à valeur ajoutée, l'absence de voie de retour implique l'utilisation de clé de déchiffrement du contenu, que le récepteur doit négocier séparément avec l'émetteur (chacun peut recevoir facilement le contenu chiffré simplement en se connectant au routeur de diffusion). Mais RTP lui-même ne s'occupe pas du chiffrement et transporte le contenu de façon transparente.
Références RFC[modifier | modifier le code]
- RFC 4175, RTP Payload Format for Uncompressed Video
- RFC 4103, RTP Payload Format for Text Conversation
- RFC 6184, RTP Payload Format for H.264 Video
- RFC 3640, RTP Payload Format for Transport of MPEG-4 Elementary Streams
- RFC 3016, RTP Payload Format for MPEG-4 Audio/Visual Streams
- RFC 2435, RTP Payload Format for JPEG-compressed Video
- RFC 3551, Standard 65, RTP Profile for Audio and Video Conferences with Minimal Control
- RFC 3550, Standard 64, RTP: A Transport Protocol for Real-Time Applications
- RFC 2250, Proposed Standard, RTP Payload Format for MPEG1/MPEG2 Video
Notes et références[modifier | modifier le code]
- Ce protocole utilise l'UDP. Il n'est pas vraiment temps-réel par lui-même (les réseaux actuels comme l'Ethernet n'étant pas temps-réel puisqu'il n'y a pas de délai maximum garanti).[réf. nécessaire]. Certains auteurs placent ce protocole au niveau de la couche n°5 du modèle OSI.
- RFC 3550 indique " This memorandum specifies the real-time transport protocol (RTP), which provides end-to-end delivery services for data with real-time characteristics, such as interactive audio and video."
Voir aussi[modifier | modifier le code]
- RTP est la version normalisée internationale de l'ancien protocole propriétaire RDP (initialement créé pour Real Player), en voie d'obsolescence.
- Le protocole SRTP (acronyme de Secure Real-time Transport Protocol) est le pendant sécurisé (chiffré) de RTP.
