Real-time Transport Protocol

Aujourd'hui, Real-time Transport Protocol est un sujet qui suscite un grand intérêt et un grand débat dans la société. Depuis longtemps, Real-time Transport Protocol fait l'objet d'études et d'analyses, générant différentes perspectives et opinions sur le sujet. Dans cet article, nous allons approfondir le sujet de Real-time Transport Protocol, en abordant ses aspects les plus pertinents et en en proposant une vision large et enrichissante. Real-time Transport Protocol est un sujet qui impacte considérablement la vie des gens, et c'est pourquoi il est essentiel de l'aborder sous différents angles pour le comprendre dans sa globalité. Dans cette optique, nous explorerons les différentes facettes de Real-time Transport Protocol, en essayant d'offrir une vision objective et complète qui invite à la réflexion et à l'analyse de la part de nos lecteurs.

Page d’aide sur l’homonymie

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) joue le rôle d'un transport par excellence des médias pour les services de la voix sur IP.

Real-Time Transport Protocol (RTP) est un protocole de communication informatique permettant le transport de données soumises à des contraintes de temps réel, tels que des flux média audio ou vidéo.

Utilisation

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

Canal de retour

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

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

  • 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

  1. ↑ 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.
  2. ↑ 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

v · m
7. Application
6. Présentation
5. Session
4. Transport
3. Réseau
2. Liaison
1. Physique