Real-time transport protocol
Un article de Wikipédia, l'encyclopédie libre.
 |
Cet article est une ébauche à compléter concernant l'informatique, vous pouvez partager vos connaissances en le modifiant. |
| 7 | Application |
|---|---|
| 6 | Présentation |
| 5 | Session |
| 4 | Transport |
| 3 | Réseau |
| 2 | Liaison de données |
| 1 | Physique |
| Modèle OSI | |
RTP (Real-Time Transport Protocol) est un protocole de communication informatique.
Ce n'est pas un réel protocole de transfert, puisqu'il utilise l'UDP, le TCP n'étant pas multicast et ne permettant pas un envoi immédiat de flots de données. Il n'est pas non plus 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), mais 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).
Il accorde des fonctions temporelles en tant que service pour des applications multimedia, comme Voice over IP pour la téléphonie sur Internet ou la diffusion de contenus vidéo en direct. Il ajoute un entête spécifique aux paquets UDP pour informer sur le type de media transporté, le séquencement et la synchronisation des datagrammes, afin que le récepteur puisse détecter les datagrammes perdus sur le réseau ou incorrectement reçus, et puisse éventuellement reconstituer un flux continu.
RTP est unidirectionnel et peut être utilisé pour la diffusion (multicast) via satellite. Il est alors extrêmement économique en terme 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.
Il peut éventuellement être utilisé conjointement avec un canal de retour (feedback) sur la qualité de service (QoS) via RTCP (Real Time 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é ou via satellite), 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.
La mise en œuvre de RTP en mode Multicast demande 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 auxquel 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). RTP lui-même ne s'occupe pas du chiffrement et transporte le contenu de façon transparente.
RTP est la version normalisée internationale de l'ancien protocole propriétaire RDP (initialement créé pour Real Player) en voie d'obsolescence.
