Chapitre 2

Les protocoles de transport dans la Téléphonie sur IP

II.1 Le protocole UDP

UDP signifie User Datagram Protocol, et il s'agit d'un protocole de commu-
nication sans connexion. Le protocole UDP est une alternative au protocole
TCP. Lorsque le protocole UDP est utilisé pour transporter les données, il va
envoyer les données d'un hôte source vers un hôte de destination, sans
chercher à savoir si l'hôte de destination a bien reçu l'ensemble des don-
nées. Autrement dit, il n'y a pas de vérification des erreurs : si l'on envoie
un fichier via UDP, on ne sait pas si l'hôte distant a reçu entièrement ce
fichier ou s'il l'a reçu partiellement. Puisque l'on ne vérifie pas que l'hôte
distant a bien reçu les données, on économise des ressources, mais aussi
du temps, donc le protocole UDP est plus rapide que le protocole TCP.
En utilisant UDP, une application peut donc envoyer très rapidement des
informations, étant donné qu’aucune connexion au destinataire n’est établie
et qu’aucune réponse ne doit être attendue. En revanche, il n’y a aucune
garantie que les paquets arrivent entiers et dans le même ordre que celui
dans lequel ils ont été envoyés.

Les caractéristiques de UDP

1. UDP est sans connexion : Aucune connexion existante entre l’expéditeur
et le destinataire. Les paquets concernés sont envoyés en indiquant le port
de destination, sans que l’ordinateur auquel cette adresse est attribuée n’ait
à envoyer une réponse.
2. Ports utilisés par UDP : Comme TCP, UDP a recours à des ports afin de
remettre les paquets aux applications souhaitées sur le système de desti-
nation. Les ports sont définis à l’aide d’une numérotation.
3. UDP permet une communication rapide : ce protocole de transport est
adapté à une transmission rapide des données, car il n’établit pas de con-
nexion.
4. UDP n’offre aucune garantie quant à la sécurité et à l’authenticité des
données : le fait de renoncer à l’authentification mutuelle de l’expéditeur et
du destinataire permet au protocole UDP d’assurer une vitesse de transmis-
sion exceptionnelle. Toutefois, le protocole ne peut garantir l’intégrité et la
sécurité des paquets de données.

II.2 Le protocole TCP

TCP signifie Transmission Control Protocol, et il s'agit d'un protocole orienté

connexion. Le protocole TCP est très utilisé lorsque l'on utilise des proto-
coles IP, c'est pour cela que l'on parle aussi de TCP/IP. Avec le protocole
TCP, avant que des données soient échangées entre les deux hôtes, l'hôte
source va créer une session de connexion avec l'hôte distant afin de le pré-
venir qu'il va recevoir des données. Pour cela, un premier échange aura lieu
entre les deux hôtes
Une fois que la connexion est établie, l'échange de données peut commen-
cer. Pendant cet échange de données, les paquets sont envoyés, et le pro-
tocole TCP va s'assurer que tous les paquets sont bien transmis, et si ce
n'est pas le cas, il est capable de renvoyer les paquets manquants. C'est
l'un des avantages du protocole TCP. Cette connexion sera maintenue jus-
qu'à ce qu'elle soit fermée, ce qui signifie qu'elle sera active jusqu'à la fin
de l'échange de données entre les deux hôtes.
En complément du contrôle des flux et de la gestion des erreurs, le proto-
cole TCP est capable de contrôler la congestion du réseau sur lequel les
paquets sont échangés. Un algorithme de contrôle de congestion est utilisé
et en cas de surcharge du réseau. Il faut retenir que TCP permet d'établir
une connexion fiable entre les deux hôtes pour s'assurer que les données
sont correctement reçues par l'hôte distant.
Pour établir une connexion TCP, trois étapes sont nécessaires, on parle alors
d'un processus "three-way handshake". Ces trois étapes correspondent à
trois paquets TCP : SYN, SYN-ACK et ACK. Ces termes correspondent à des
flags (des marqueurs) que l'on peut retrouver dans l’entête TCP. Le paquet
SYN correspond à une demande d'initialisation de connexion envoyée par
un client à un serveur. Ensuite, le serveur répond avec un paquet SYN-ACK
pour initier la connexion dans l'autre sens et indiquer au client qu'il a bien
reçu la demande de connexion (ACK pour Acknowledge).
Enfin, le client répond au serveur avec un paquet ACK pour accuser la ré-
ception de la demande de connexion (Acknowledge). La connexion TCP est
établie en mode full-duplex, c'est-à-dire dans les deux sens.
Pourquoi avons-nous besoin de RTP et RTCP dans la TIP ?

 Tout d’abord, dans la téléphonie, la rapidité est plus prioritaire que la

fiabilité (ça ne sert à rien de retransmettre les paquets de voix perdus,
et les conversations doivent se passer en temps réel)
 TCP est trop lent (doit attendre les ACK) et sa fonction de retransmis-
sion est inutile ici
 UDP est donc mieux adapté
 Sauf que UDP manque de fiabilité
 RTP vient donc rajouter des options de fiabilité pour compléter UDP
 RTP s’occupe de transmettre les données de la voix en elle-même
 RTCP s’occupe de transmettre des données de contrôle de qualité
(RTCP « surveille » RTP pour voir si ce dernier fournit un service sa-
tisfaisant)
II.3 Le protocole RTP
Le but de RTP (Real-time Transport Protocol) et de fournir un moyen uni-
forme de transmettre sur IP des données soumises à des contraintes de
temps réel (audio, vidéo). Le rôle principal de RTP consiste à mettre en
œuvre des numéros de séquence de paquets IP pour reconstituer les infor-
mations de voix ou vidéo même si le réseau sous-jacent change l'ordre des
paquets. Le protocole RTP a été proposé pour compléter UDP en lui
ajoutant des fonctionnalités d’ordonnancement lui permettant la reconsti-
tution de l’ordre du flux.
Les principales taches du protocole RTP sont donc :

1. Synchronisation des flux :

Si l’audio et la vidéo sont transmis séparément, le destinataire doit jouer la

séquence audio de façon que cette dernière coïncide avec la séquence vi-
déo. Pour cela, RTP ajoute aux paquets émis une estampille de date, appe-
lée horodatage, ou timestamp. Cette estampille indique le moment
où le paquet a été émis, ce qui permet de reproduire les mêmes délais inter-
paquet et de jouer les paquets audio et vidéo de manière synchronisée.

2. Reconstitution de l’ordre des paquets émis et détection des

pertes de paquets :
Les paquets IP sont transmis indépendamment les uns des autres. En con-
séquence, leur ordre d’arrivée chez le destinataire n’est pas forcément con-
forme à leur ordre d’émission. Pour cela, un numéro de séquence qui s’in-
crémente progressivement est affecté à chaque paquet. Ce numéro
permet de déterminer un ordre de précédence des paquets.
Champs de l’entête RTP

• V pour version (sur 2 bits) : indique la version du protocole RTP utili-

sée. Actuellement, c’est la 2 qui est exploitée.

• P pour padding (sur 1 bit) : Si P=1, le paquet contient des octets

additionnels de bourrage (padding) pour compléter les champs optionnels
en multiple de 32.

• X pour extension (sur 1 bit) : Si X=1 l'en-tête est suivie d'un paquet
d'extension (qui complète un autre paquet)

• CC pour CSRC Count (sur 4 bits) : nombre de sources ayant contribué

à la génération du paquet. (Conférences)
• PT pour Payload Type (sur 7 bits) : décrit le format de données (pour
qu’il puisse être compris par le destinataire).

• Sequence number (sur 16 bits) : Numéro de séquence ou compteur

incrémenté d’une unité entre chaque paquet.

• Timestamp (sur 32 bits) : estampille temporelle permettant la synchro-

nisation des flux.

• CSRC pour contributing source (optionnel, sur n fois 32 bits) : iden-

tifie les contributeurs à la génération du paquet.

II.4 Le protocole RTCP

RTCP est un protocole de contrôle et de supervision du réseau. Il opère
comme un radar qui décrit les performances dont la communication en
cours bénéficie. Son objectif est d’offrir aux participants d’une session une
vision sur l’état du réseau. Il fournit pour cela un rapport sur la qualité de
la transmission, incluant le délai de bout en bout, la gigue et le taux de
pertes. Ce rapport est envoyé de façon périodique pour que les intervenants
disposent d’une mise à jour fréquente de l’état du réseau.
Exemple : un participant d’une conférence a une mauvaise connexion, le
serveur baisse alors la qualité de la vidéo pour lui permettre de participer.

Les catégories de paquets RTCP

RTCP distingue plusieurs types de paquets : rapport de l'expéditeur (RS),
le rapport du récepteur (RR), la description des sources (SDES), et la fin
d'une session (BYE).

a. Rapport de l'expéditeur (SR Sender Report)

Le rapport expéditeur est envoyé périodiquement par les expéditeurs actifs
d'une conférence pour présenter les statistiques de transmission et de ré-
ception pour tous les paquets RTP envoyés pendant l'intervalle. Le rapport
d'un expéditeur inclut un timestamp (horodatage) absolu, qui est le nombre
de secondes écoulées depuis minuit le 1er janvier 1900. L'horodatage absolu
permet au récepteur de synchroniser les messages RTP. Il est particulière-
ment important lorsque les deux flux audio et vidéo sont transmis simulta-
nément, parce que les flux audio et vidéo utilisent chacun leur propre ho-
rodatage relatif.

b. Rapport du receveur (RR Receiver Report)

Le rapport du récepteur est pour les participants passifs, ceux qui
n'ont pas envoyé de paquets RTP. Le rapport informe l'expéditeur et
les autres récepteurs de la qualité de service.

c. Description de la source (SDES Source Description)

Le message Description Source est utilisé pour fournir des informa-
tions supplémentaires telles que le nom, l'adresse e-mail, numéro de
téléphone et l'adresse du propriétaire ou de contrôleur de la source.

d. Fin de la participation (BYE)

Une source envoie un message BYE pour arrêter un flux. Il permet à
un terminal d'annoncer qu'il quitte la conférence. Bien que d'autres
sources peuvent détecter l'absence d'une source, ce message est une
annonce directe.