2- Comment ça marche ?

A- Le protocole RTP (Real time Transport Protocol)

Le protocole de couche 4, TCP, sert de mécanisme de transport de données pour les réseaux (incluant l'Internet), il a été développé pour garantir la livraison fiable d'information dans l'ordre approprié d'un expéditeur à un récepteur (unicast). Cependant, TCP et ses mécanismes de contrôle de flux peut aboutir à des retards indéterminés et la livraison de données erronées. Cette approche est inadéquate pour le transport des données multimédia en temps réel, qui exige par sa nature un retard minime et l'aide d’un protocole utilisant le multicast. De plus, le logiciel de réception peut compenser le fait que certaines données soient perdues pour qu'ils ne puissent pas être décelé par l'oeil ou l'oreille humaine ; cela garantie une livraison d’un maximum de paquet dans un délai réduit.

Une première tentative de transport de données multimédias à travers des réseaux IP a abouti au développement par l’IETF du protocole ST-II. Conçu pour remplacer IP pour les données multimédias, incorporant le transport multicast et le QoS (Qualité de Service) dans la couche réseau de ce protocole. Mais ST-II, n’était pas assez adaptable aux grands groupes ou aux groupes dynamiques. L'IETF, reconnaissant le besoin d'une approche plus évolutive qui prendrait en compte l’existence de données erronées avec de nouvelles données multimédias sur un réseau IP courant, a conçu un nouveau protocole basé sur trois points :

· Le Multicast sur le protocole IP

· Le QoS via un nouveau protocole qui fonctionne avec IP (le Protocole de Réservation de Ressource [RSVP])

· Un nouveau protocole de transport qui supporte les exigences du multicast et du délai minime pour les données multimédia, RTP.

RTP a déjà été mis en oeuvre sur le MBONE. La dernière version, RTP la Version 2, a été approuvée pour la publication RFC et est proposée comme une norme.

RTP, avec son adjonction RTCP (Real-time Transport Control Protocol), travaille au côté de TCP pour le transport des données multimédias sur le réseau. RTP emploie des en-têtes de paquet qui contiennent des informations sur le séquençage, le délai exigés afin de daté la sortie (par exemple, pour l’affichage des trames), sur la synchronisation des flux de données multimédias (par exemple, l’audio et la vidéo) et l'information sur "payload" du paquet (par exemple, le codage MPEG contre le H.261). Ce descripteur permet à RTP de prendre en charge plusieurs types de compression.

RTCP fournit des feedbacks sur les conditions actuelles de réseau et la qualité de réception, permettant aux applications de s’adapter automatiquement à ces conditions. Par exemple, un ralentissement étant éprouvé par beaucoup de destinataires est probablement du à un ou des problèmes réseau et pas à un ordinateur individuel (par exemple, une ligne T1 défectueuse remplacée par une ligne de 56 Ko/s plus lente). Dans ce cas, l’application source pourrait vouloir changer de son type de codage, et éliminer temporairement la partie vidéo d'une transmission, ou passer de la couleur au monochrome pour améliorer le flux de transfert. Le fait que RTCP envoie des feedbacks non seulement à l'expéditeur, mais à tous les autres destinataires du flux multicast, permet aux utilisateurs de déterminer si c’est un problème est spécifique au noeud local ou attribuable à des problèmes système. Le mécanisme de feedback multicast de RTCP facilite aussi dans la mise en oeuvre de moniteurs de surveillance du réseau qui aident les administrateurs réseau a contrôlé la qualité de la distribution multicast.

RTCP fournit aussi des feedback a l’utilisateur qui a souscrit à un groupe donné à tout moment. Pour une application de formation à distance, par exemple, cela peut être employé pour déterminer qui suit la session de formation.

Une approche alternative de RTP/RTCP à été d’employer le MSS (MPEG System Streams) avec le protocole UDP. Initialement utilisé pour les essais de TV interactifs, MSS a certaines limitations dans la finalité des systèmes. D'abord, c'est spécifique au MPEG et ne peut pas être employé avec d'autres techniques de compression (par exemple, H.261 ou Indeo d'Intel) ou profiter de technologies plus puissantes des futures codecs. Deuxièmement, parce qu'aucun feedback n'est fournit, les applications ne peuvent pas réagir aux changements d’état du réseau. Troisièmement, parce que l'information de synchronisation est incorporée dans le flux, c'est difficile de synchroniser des flux de sources différentes. RTP/RTCP traite la session entière comme un processus distribué, contrôlable, s'adaptant aux circonstances changeantes en fournissant une information sur la qualité de réception et l'adhésion. RTP peut être utilisé avec les applications employant la compression de MPEG, MSS ou des flux élémentaires.