CHAPITRE 2 les protocoles de la VOIP

II Les Protocoles utilisés par la VOIP

Il y a de nombreux protocoles de couches inférieures à celle qui contient l'information
voix parmi lesquels TCP (Transmission Control Protocol), UDP (User Datagramme
Protocol) et RTP (Real Time Protocol), RTCP (Real Time Control Protocol).

II.1 Le protocole UDP

Le protocole UDP (User Datagram Protocol) est un protocole non orienté connexion
de la couche transport du modèle TCP/IP. Ce protocole est très simple étant donné
qu'il ne fournit pas de contrôle d'erreurs (il n'est pas orienté connexion...). 

L'en-tête du segment UDP est donc très simple :

Port Source(16 bits) Port Destination(16 bits)
Longueur(16 bits) Somme de contrôle(16 bits)
Données(longueur variable) 

 Port Source: il s'agit du numéro de port correspondant à l'application

émettrice du segment UDP. Ce champ représente une adresse de réponse pour le
destinataire. ce champ peut être optionnel, c.-à-d. les 16 bits de ce champ seront
mis à zéro,(généralement pour des messages unidirectionnels).

 Port Destination: Ce champ contient le port correspondant à l'application de

la machine destinataire à laquelle on s'adresse.

 Longueur: Ce champ précise la longueur totale du segment, en-tête comprise,

or l'en-tête a une longueur de 4 x 16 bits (soient 8 x 8 bits) donc le champ longueur
est nécessairement supérieur ou égal à 8 octets.

 Somme de contrôle: Il s'agit d'une somme de contrôle réalisée de telle façon à

pouvoir contrôler l'intégrité du segment.

II.1.1 Utilisation

Il est utilisé quand il est nécessaire soit de transmettre des données très rapidement, et
où la perte d'une partie de ces données n'a pas une grande importance, soit de
transmettre des petites quantités de données, là où la connexion « 3-WAY » TCP serait
inutilement coûteuse en ressources. Par exemple, dans le cas de la transmission de
la voix sur IP, la perte occasionnelle d'un paquet est tolérable dans la mesure où il
existe des mécanismes de substitution des données manquantes, par contre la rapidité
de transmission est un critère primordial pour la qualité d'écoute.
Exemples d'utilisation :
 les protocoles DNS, SNMP;
 le streaming ;
 les jeux en réseau
 le programme traceroute.

1
 CHAPITRE 2 les protocoles de la VOIP

II.2 Le protocole TCP

TCP (qui signifie Transmission Control Protocol, soit en français: Protocole de
Contrôle de Transmission) est un des principaux protocoles de la couche transport du
modèle TCP/IP. Il permet
 de remettre en ordre les datagrammes en provenance du protocole IP
 de vérifier le flot de données afin d'éviter une saturation du réseau
 de formater les données en segments de longueur variable afin de les
"remettre" au protocole IP
 de multiplexer les données, c'est-à-dire de faire circuler simultanément des
informations provenant de sources (applications par exemple) distinctes sur une
même ligne
 l'initialisation et la fin d'une communication de manière courtoise

II.2 .1 Structure d'un segment

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Port Source 2 octets Port destination 2 octets
Numéro de sequence
Numéro d'acquittement
Taille
de l'en- Réservé ECN URG ACK PSH RST SYN FIN Fenêtre
tête
Somme de contrôle Pointeur de données urgentes
Options Remplissage
Données

Signification des champs :

 Port source : numéro du port source
 Port destination : numéro du port destination
 Numéro de séquence: numéro de séquence du premier octet de ce segment
 Numéro d'acquittement : numéro de séquence du prochain octet attendu
 Taille de l'en-tête : longueur de l'en-tête en mots de 32 bits (les options font
partie de l'en-tête)
 Drapeaux
 Réservé : réservé pour un usage futur
 ECN : signale la présence de congestion, voir RFC 3168
 URG : Signale la présence de données urgentes
 ACK : signale que le paquet est un accusé de réception
(acknowledgement)
 PSH : données à envoyer tout de suite (push)
 RST : rupture anormale de la connexion (reset)
 SYN : demande de synchronisation (SYN) ou établissement de
connexion
 FIN : demande la FIN de la connexion

2
CHAPITRE 2 les protocoles de la VOIP

 Fenêtre : taille de fenêtre demandée, c'est-à-dire le nombre d'octets que le

récepteur souhaite recevoir sans accusé de réception
 Somme de contrôle: somme de contrôle calculée sur l'ensemble de l'en-tête
TCP et des données, mais aussi sur un pseudo en-tête (extrait de l'en-tête IP)
 Pointeur de données urgentes : position relative des dernières données
urgentes
 Options : facultatives
 Remplissage : zéros ajoutés pour aligner les champs suivants du paquet sur 32
bits, si nécessaire
 Données : séquences d'octets transmis par l'application

II.2 .2 Fonctionnement
Une session TCP fonctionne en trois phases :
 l'établissement de la connexion ;
 les transferts de données ;
 la fin de la connexion.

a) L'établissement de la connexion se fait par un handshaking en trois

temps

Figure II.1

b) Transfert de données

3
CHAPITRE 2 les protocoles de la VOIP

Figure II.2

II.3 Les Protocoles de transport de la voix

II.3.1 Introduction
Pour transporter la voix ou la vidéo sur IP, le protocole IP (Internet Protocol) au
niveau 3 et le protocole UDP (U ser Datagram Protocol) au niveau 4 sont utilisés. En
effet, si TCP (Transmission Control Protocol) présente l'avantage de gérer un transfert
fiable (renvoi des paquets IP en cas d'erreur), il est malheureusement incompatible
avec un flux temps-réel, tel que la voix sur IP, les jeux sur le net,…etc, donc le
protocole de transport UDP, par son structure relativement légère, donc il s’adapte
bien avec les applications, soumises aux contraintes temps réel, néanmoins le
protocole UDP tous seul reste incapable d’assurer le transport de la voix sur IP. De ce
fait, UDP est un protocole sans correction d'erreur, et à aucun moment l'arrivée des
paquets dans leur ordre d’émission est assurée. Pour le transport de données temps
réel telles que la voix ou la vidéo, il est nécessaire d’utiliser deux protocoles
supplémentaires : RTP (Real-Time transport Protocol) et RTCP (RTP Control
Protocol).

4
CHAPITRE 2 les protocoles de la VOIP

II.3.2 RTP (Real-Time Transport Protocol)

Le protocole RTP assure la transmission des données soumises à des contraintes
temps réel (audio, vidéo, etc.), ce dernier sera greffé au-dessus du protocole UDP.
Donc le protocole RTP permet :
• d'identifier le type de l'information transportée,
• d'ajouter des marqueurs temporels permettant d’indiquer l’instant d’émission du
Premier paquet.
L’application destinataire peut alors synchroniser les flux et mesurer les Délais et la
gigue, ceci suppose que les deux applications émettrice et réceptrice disposent de la
même horloge, en utilisant le protocole NTP (Network Time Protocol).
• d’inclure des numéros de séquence à l'information transportée afin de détecter
L’occurrence de paquets perdus et de délivrer les paquets en séquence à l’application
Destinataire. De plus, RTP peut être véhiculé par des paquets multicast afin
d'acheminer des Conversations vers des destinataires multiples, comme dans le cas du
mode conférence par exemple. Mais, RTP n'a pas été conçu pour effectuer des
réservations de ressources ou contrôler la qualité de service et ne garantit pas la
livraison du paquet à l’arrivée.
II.3.2.1 Mixeur et Traducteur
Deux entités, le multiplexeur et le convertisseur, sont couramment utilisées avec RTP
pour faciliter le transport des flux multimédias et les adapter :
- Le (mixeur) : est une application qui reçoit des flux de données de plusieurs sources
qu’on appelle SSRCs (Synchronization Sources), en modifie éventuellement le format
et Renvoie un seul flux de données agrégé. Là encore, dans une application de
conférence, il est probablement économique de regrouper dès que possible les flots
sonores provenant de plusieurs sources, puisque, de toute façon, ils seront mélangés
chez les destinataires. En faisant ce travail, le mixer se comporte comme une source
particulière (SSRC) qui regroupe les données de plusieurs autres sources qui étaient
des SSRCs et qui deviennent des CSRC (Contributing Source).
Dans l’exemple représenté à la figure 1, un mixeur reçoit des paquets de trois sources
(SSRC). Il peut réaliser des conversions de format, mixe le contenu en fonction de
L’application et produit un nouveau paquet RTP qu’il relaye à la destination.
Le mixer fournit la synchronisation pour le nouveau flux et s’identifie comme la
nouvelle source SSRC.

5
CHAPITRE 2 les protocoles de la VOIP

Les trois sources origines sont déclarées comme CSRC dans le paquet RTP composé.

Figure II.3
-Le translator (traducteur) : est une application qui transmet les paquets RTP
qu’elle reçoit sans changer l’identificateur de SSRC (à l’inverse de ce que fait le
mixeur). Un traducteur permet par exemple de changer le codage d’une donnée ou le
débit, ou encore de traiter les problèmes de sécurité (firewalls) à la frontière d’un
réseau privé. Si un terminal utilisant un codage PCM μ-law à 64 kbit/s souhaite établir
une session avec un terminal supportant un codage G.726 ADPCM à 32 kbit/s, alors il
est nécessaire d’interfacer les deux terminaux à travers un translator.
Les fonctions Mixer et Translator sont généralement mises en oeuvre dans un
Gateway.
II.3.2.2 Format des paquets RTP
Le format de l’en-tête d’un paquet RTP est illustré à la figure

Figure II.

-Le champ Version V de 2 bits de longueur indique la version du protocole (V=2)

-Le champ padding P : 1 bit, si P est égal à 1, le paquet contient des octets
additionnels de bourrage (padding) pour finir le dernier paquet.

-Le champ extension X : 1 bit, si X=1 l'en-tête est suivie d'un paquet d'extension
-Le champ CSRC count CC : 4 bits, nombre de sources ayant contribué à la
génération du paquet.

6
CHAPITRE 2 les protocoles de la VOIP

-Le champ marker M: 1 bit, indique si des descriptifs sont associés.

-Le champ payload type PT : 7 bits, ce champ identifie le type du payload (audio,
vidéo, image, texte, html, etc.)

-Le champ séquence number : 16 bits, sa valeur initiale est aléatoire et il

s'incrémente de 1 à chaque paquet envoyé, il peut servir à détecter des paquets
perdus

-Le champ timestamp : 32 bits, reflète l'instant où le premier octet du paquet RTP
à été échantillonné. Cet instant doit être dérivé d'une horloge qui augmente de
façon monotone et linéaire dans le temps pour permettre la synchronisation et le
calcul de la gigue à la destination

-Le champ SSRC : 32 bits, identifie de manière unique la source, sa valeur est
choisie de manière aléatoire par l'application.

-Le champ CSRC : 32 bits, identifie les sources contribuant.

Facultatif, le champ CSRC est utilisé lorsque plusieurs sources ont contribué à la
conception d’un message. Le cas classique correspond à une conférence au cours de
laquelle plusieurs personnes conversent simultanément. Si une entité se charge de
rassembler les flux avant de les relayer à chaque source (comme le fait la MCU), alors
cette entité est source initiale du message, tandis que les contributeurs sont toutes les
personnes qui ont émis leur flux vers elle.

L’horloge utilisée pour le champ timestamp doit être partagée par la source comme
par l’émetteur. Il faut donc que l’un et l’autre soient synchronisés par une référence
Commune, et ce dès le premier paquet échangé. Pour cela, le protocole NTP (Network
Time Protocol) est généralement utilisé. Il retourne l’heure courante, sous différents
formats, aux différents intervenants.

L’estampille temporelle et la numérotation des paquets comportent toutes deux des

fonctionnalités d’ordonnancement, mais il n’y a pas de redondance entre ces deux
paramètres. L’estampille temporelle sert à synchroniser les flux, c’est-à-dire à préciser
le moment où le flux doit être joué. De la même façon, si les flux vidéo et audio sont
envoyés séparément, ce qui peut se révéler pratique si tous les intervenants d’une
conférence ne peuvent ou ne veulent supporter les flux vidéo mais se contentent des
flux audio, l’estampille temporelle assure la concordance de la voix avec la vidéo.

7
CHAPITRE 2 les protocoles de la VOIP

En revanche, l’estampille temporelle ne permet pas de détecter les pertes. À l’inverse,

la numérotation des paquets n’assure pas la synchronisation des flux mais permet de
détecter les pertes. Les paquets perdus ne sont pas réémis, puisque les contraintes de
temps ne le permettent généralement pas. Cependant, il est important de les détecter
afin de permettre une synthèse des paquets précédents et suivants et ainsi de rendre la
perte de paquets moins sensible aux interlocuteurs.

Exemple de mise en paquet et overhead

Considérons une application audio qui utilise le codec G.711, c’est-à-dire qui
transmet des données à un débit de 64 Kbit/s, et émet un paquet toutes les 10 ms. La
figure II illustre les encapsulations successives qui vont être appliquées aux données
générées par le codec.

Figure II.4
En 10 ms, pour respecter le débit de 64 Kbit/s, un paquet contiendra 80 octets de
données utiles. Plusieurs en-têtes successifs vont être appliqués pour encapsuler ces
données
Au final, on arrive à 146 octets transmis dans un réseau LAN de type Ethernet toutes
les 10 ms. Cela équivaut à un débit effectif réel de 116,8 Kbit/s. Si l’on compare ce
résultat avec les données réellement utiles transmises à un débit de 64 Kbit/s, on
constate que le débit a presque été doublé (il est 1,8 fois plus important).

8
CHAPITRE 2 les protocoles de la VOIP

Dans les applications de téléphonie, les paquets sont très petits et sont donc très
fortement surchargés par les en-têtes, pouvant être 10 fois plus importantes avec
certains codecs. Cette surcharge est appelée overhead. Elle comprend les données qui
ne sont pas utiles, c’est-à-dire les données de transport non multimédias. Avec la
vidéo, les paquets sont plus importants, si bien que la surcharge devient globalement
négligeable.
II.4.1 RTCP (Real-Time Control Transport Protocol)
Décrit dans la RFC 3550, RTCP est un protocole de contrôle et de supervision du
réseau. Son objectif est d’offrir aux participants d’une session une vision sur l’état du
réseau et de s’y adapter de façon dynamique. Il fournit pour cela un rapport sur la
qualité de distribution, incluant le délai de bout en bout, la gigue et le taux de pertes.
Ce rapport est envoyé de façon périodique de façon que les intervenants disposent
d’une mise à jour fréquente de l’état du réseau.
II.4.2 Format des paquets RTCP
Le format de l’en-tête d’un paquet RTP est illustré à la figure

Figure II.

V: Version : numéro de version de RTP 

P : Padding : à 1, il signifie qu’il contient des octets de bourrage à la fin de la trame 
RC : le nombre de rapport de réception contenu dans ce paquet. 
Type de paquet(PT): contient 200 pour identifier un paquet RTCP SR. 
Longueur : longueur totale du paquet
Les paquets RTPC sont classés en cinq catégories :
• SR (Sender Report). Ce type de paquet véhicule un rapport de l’émetteur, sous
forme d’un ensemble de statistiques relatives à la qualité de service concernant
l’émetteur.

9
CHAPITRE 2 les protocoles de la VOIP

On trouve parmi ces informations le nombre de paquets perdus et la gigue mesurée

par l’émetteur. La gigue est importante, car elle permet d’apprécier la régularité de
l’arrivée des paquets transportant de la parole. On repère ces paquets SR par la valeur
du champ PT (Payload Type), qui est mis à la valeur 201.
• RR (Receiver Report). Ce type de paquet véhicule un rapport de récepteur,
semblable aux paquets SR mais concernant le récepteur. La valeur du champ PT est
202.
• SDES (Source Description). Ce type de paquet décrit une source, avec un ensemble
de paramètres spécifiques parmi lesquels le nom permanent de la source, ou CNAME
(Canonical Name), le nom du participant, NAME, son adresse e-mail, EMAIL, son
numéro de téléphone (PHONE), sa localisation (LOC), le nom de l’application qu’il
utilise, avec si possible sa version (TOOL), et d’autres paramètres spéciaux (PRIV et
NOTE pour ajouter des informations complémentaires). Ce type de paquet porte la
valeur 203 dans le champ PT (Payload Type).
• BYE. Ce type de paquet est envoyé pour indiquer que l’émetteur quitte une session
multimédia. Le champ PT (Payload Type) prend la valeur 204.
• APP (Application). Ce type de paquet est réservé pour transporter des paramètres
spécifiques d’une application. Ce type de paquet est indiqué par la valeur 205 du
champ PT (Payload Type).

La fréquence des échanges de transmission des rapports doit être dosée en fonction du
type de média transporté et du nombre de participants, En règle générale les
différents rapports feedback du RTCP ne doit pas dépasser 5 % du trafic globale
(donnés voix et vidéo).
.

10