TP Protocole de transport RTP Exercice Réseau Protocole RTP

 Protocole de transport RTP  

Dans les vingt premières années de son existence le réseau Internet a été utilisé pour des applications de 

transmission de données informatiques en mode asynchrone comme l es transferts de fichiers, les transferts de courriers électroniques, l’accès à des documents. Ensuite, l’utilisation d’Internet a évolué progressivement vers des applications multimédia à flux continu. Des applications comme le téléphone,  la diffusion radio ou télévision sont considérées comme des applications Internet utilisant les quatre couches basses de cette architecture réseau. Dans cet ensemble, on distingue deux types de transmissions. Le cas le plus simple est celui des données à f lux continu pouvant être stockées avant d’être délivrées (plusieurs secondes à plusieurs dizaines de seconde comme dans le cas de la radio, de la télévision, on parle de ‘streaming’). Un cas plus difficile est celui des données multimédia à délivrance en ‘temps réel’ comme le téléphone ou la visio-conférence. 

Ce problème s’intéresse à la transmission des données au niveau transport pour des applications multimédia sur Internet et en particulier au protocole de transport RTP (Real -time Transport Protocol RFC 3550 Juillet 2003).

Question 1

Dans le domaine des données multimédia en flux continu on s’intéresse surtout à la transmission de données en mode synchrone. Rappelez la définition d’une transmission synchrone. Donnez quelques exemples de communication en mode synchrone au niveau physique.

Des applications Internet souhaitant échanger des flux continus peuvent envisager d’utiliser comme protocole de transport TCP (pour la transmission de données synchrones).

Question 2

Indiquez plusieurs problèmes liés aux caractéristiques de TCP. On examinera les caractéristiques habituelles des protocoles concernant, la livraison en séquence, les mécanismes de contrôle d’erreur, de contrôle de flux, de contrôle de congestion, et dans le cas précis la délivrance synchrone.

Le protocole de transport temps réel RTP a choisi de s’appuyer sur le service du protocole UDP pour la transmission de données synchrones. Donc dans une transmission avec RTP le niveau transport comprend les deux protocoles RTP et UDP selon l’architecture suivante. 

Question 3

Pourquoi avoir choisi le protocole UDP comme protocole sous jacent à RTP ?

L’entête d’un message de données RTP comprend cinq champs: 


- Le champ type (‘Payload Type’) décrit le type de la charge utile transportée (sur 7 bits).
- Le champ numéro de séquence (‘Sequence Number’) est le numéro de séquence du message RTP. Il est incrémenté à chaque nouvel envoi d’un message RTP (sur 16 bits).
- Le champ estampille (‘Timestamp’) sur 32 bits. Ce champ reflète l’instant d’échantillonnage du premier octet de la charge utile. Supposons par exemple que pour un certain type de codage du son, un
message RTP transporte 40 échantillons de son prélevés 44000 fois par seconde alors la valeur du champ estampille progresse de 40 à chaque nouveau message.
- Le champ identifiant de la source (‘Synchronization Source Identifier’) sur 32 bits. C’est un identifiant choisi aléatoirement qui identifie une source de données RTP. On peut en effet avoir sur le même
hôte plusieurs flots de données transmises en même temps vers le même destinataire. 
- Différents indicateurs (numéro de version, existence d’octets de bourrage, existence d’extension d’entête ….) sont également présents dans l’entête. Ils ne sont pas détaillés dans ce sujet.

Question 4

Selon la norme RTP, la zone type de charge utile de l'entête ayant pour valeur 0 est attribué au codage MIC avec la loi µ à 64 kb/s (PCM ,  µ law 64) du téléphone numérique. Rappelez les principes de base du MIC
(échantillonnage, quantification, codage)?

Question 5

L'utilisation du codage MIC suppose que codage et le décodage soient effectués par des horloges synchronisées (comme c'est le cas dans les réseaux RNIS). Dans le cas d'une transmission avec RTP/UDP/IP, l'application qui reçoit le flux MIC va utiliser un buffer pour amortir la gigue. Quelle sera alors l'influence de la dérive des horloges sur le buffer ?

Question 6
Est-on obligé de maintenir une latence constante durant toute la durée de la communication, pour chaque échantillon ?  Le codage de la voix nécessite-t-il donc une transmission complètement synchrone ? Comment dans ce cas gérer le simplement le problème de dérive d'horloge ? 

  Des techniques de détection de silences sont parfois introduites directement dans le format de codage du média, mais ce n'est pas le cas du MIC (codé en G.711). Ainsi, RTP propose d'introduire un
type de payload appelé Comfort Noise (RFC 3389) pour introduire un « Silence Insertion Descriptor ».

Les protocoles comme SIP (pour la signalisation dans la téléphonie sur IP, RFC 3261, Juin 2002) ou SAP (RFC 2974, Octobre 2000) pour annoncer des sessions Multimédia (conférence, diffusion, etc)
sont des protocoles servant à «  initialiser » une communication avec des flux multimédia. Ces protocoles utilisent SDP (Session Description Protocol, RFC 2327) pour présenter les informations nécessaires à
l'établissement de session RTP.

   Dans un paquet SDP, la description d'une session se fait au format texte et la description est la forme <type>=<value>. 
Voici un extrait de description de session :    

    
m=audio 49170 RTP/AVP    0    13
          m=video 51372 RTP/AVP    31
          m=application 32416 udp whiteboard

Pour les valeurs «  audio » et «  vidéo » :  m=<audio ou vidéo> <port utilisé> <protocole de transport>
<type de payload1> <type de payload 2> ... <type de payload n>
Pour « application », remplacer <type de payload> par le nom de l'application.

Question 7

Le payload numéro  « 0 » correspond au codage G.711 (MIC) et le 13 au « Comfort Noise » et le 31 au codage vidéo h.261. Quel sera alors le nombre de session RTP ouverte ?

Question 8

Donner des exemples d'applications dans lesquelles le « Comfort Noise » n'est pas applicable. 

Question 9

Comment un utilisateur du protocole RTP peut-il utiliser les informations dont il dispose pour  délivrer correctement (de manière synchrone) les unités d’informations transportées ? 

Question 10

On s'intéresse maintenant au traitement des erreurs de transmission dans le protocole RTP. On considère tout d'abord la pile des protocoles utilisés. 
Quels sont les mécanismes de traitement des erreurs mis en œuvre dans les différents protocoles Internet (aux niveaux physique, liaison,  réseau et transport avec UDP) ?

Question 11

Avec  l’ensemble des informations qui ont été données dans ce texte sur RTP (format de l’entête RTP, utilisation par RTP de UDP et des protocoles Internet) comment le destinataire d’un message peut-il détecter une erreur de transmission sur un message ? 

Question 12

Compte tenu des objectifs de transmission synchrone, quel mécanisme de traitement des erreurs de transmission (codes détecteurs d’erreur avec retransmission, codes correcteurs d’erreurs) doit être privilégié par un utilisateur d’un protocole de transport pour des données multimédia en  flux continu comme RTP?

L’une des solutions proposée pour traiter les erreurs dans des flux continus consiste à rajouter en émission le mécanisme suivant. Après avoir émis n messages (chaque message contient  k échantillons de
son ou d’image), un utilisateur RTP émet un message n+1 dont la valeur est le ou exclusif des n messages précédents (la parité longitudinale de k échantillons). 

Question 13

Comment utiliser cette parité dans le cadre du traitement des erreurs (examinez les possibilités offertes en détection comme en correction en prenant en compte les solutions des questions 5 et 6) ?