Etude sur les protocoles de la VoIP

Protocoles RTP/RTCP :

1.
L'existence d'applications temps réel, comme la parole numérique ou la visioconférence,
constitue un des problèmes posés par l'Internet. Ces applications demandent des qualités
de service que les protocoles classiques d'Internet ne peuvent pas offrir.

Pour transporter la voix ou la vidéo sur IP, le protocole IP au niveau 3 et le protocole

UDP au niveau 4 sont utilisés. En effet, si TCP 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 dans la mesure où les mécanismes de TCP sont trop lourd pour les
applications en temps réel.

Mais ces deux protocoles UDP et IP ne suffisent pas à assurer le transport de la voix. De
fait, UDP est un protocole sans correction d'erreur, et à aucun moment l'arrivée des
paquets dans leur ordre d’émission n’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 Protocol) et RTCP (Real Time Control Protocol) . Ce
sont des protocoles qui se situent au niveau de l'application et s’appuient sur le protocole
de transport UDP. RTP et RTCP peuvent utiliser aussi bien le mode unicast (point à point)
que le mode multicast (multipoint).

2.
2.1.

L’objectif du protocole RTP (acronyme de Real Time Transport Protocol) est de

fournir un moyen uniforme de transmettre sur IP des données soumises à des
contraintes de temps réel (audio, vidéo, etc.). RTP permet de :

 D'identifier le type de l'information transportée.

 Il permet aussi d'ajouter des marqueurs temporels permettant d’indiquer
l’instant d’émission du paquet. L’application destinataire peut alors
synchroniser les flux et mesurer les délais et la gigue.
 Permet 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.

1
2.2.
L’entête RTP comportera les informations suivantes :

32 bits

V P X CC M PT Sequence Number
Timestamp
Identificateur de la source de Synchronisation Source (SSRC)
Identificateur(S) de la(les) source(s) Contributrices(CSRC)
Données

V (2 bits) : indique la version du protocole V=2.

P (1 bit) : indique la présence d'un octet de bourrage (padding), à la fin du
paquet, pour obtenir un paquet de longueur paire.
X (1 bit) : indique la présence d'une extension d'en-tête.
CC (4 bits) : représente le nombre d'identifiants CSRC qui suivent l'en-tête fixe.
M (1 bit) : est un bit marqueur. Indique la présence d’un de descriptifs
contenant la trace d’évenements particulier.
PT (7 bits) indique le type du playload si c’est audio/vidéo.
Sequence Number (16 bits) : Numéro d’ordre d’émission des paquets il est
incrémenter d’une unité à chaque paquet envoyé. Il permet ainsi au destinataire
de détecter une perte de paquets et de réorganiser des paquets qui dû au réseau
seraient arrivées dans un ordre différents de celui d’émission.
Timestamp (32 bits) : Horloge système ou horloge d’échantillonnage de
l’émetteur elle doit être monotone et linaire pour assurer la synchronisation des
flux
Identificateur de la source de Synchronisation Source (SSRC) (32 bits):
l’émetteurs sur laquelle il faut caller la base de temps commune à tous les
participants
Les champs CSRC (32 bits) servent, notamment, pour les conférences. Listes des
participants ayant participer au paquet.
Remarque :
Bien qu’autonome, RTP peut être compléter par RTCP. Ce dernier apporte un
retour d’informations sur la transmission et sur les éléments destinataire ce
protocole de contrôle permet de renvoyer à la source des informations sur les
récepteurs et ainsi lui permettre, par exemple d'adapter un type de codage ou
encore de modifier le débit de données.

2
 Figure 1 : Relation RTP/RTCP

3.

Le protocole RTCP (acronyme de Real Time Transport Control Protocol) est basé
sur des transmissions périodiques de paquets de contrôle par tous les participants
dans la session. C'est un protocole de contrôle des flux RTP, permettant de
véhiculer des informations basiques sur les participants d'une session, et sur la
qualité de service. Il existe cinq types différents de paquets RTCP pour chaque
type d’informations.

 SR (Sender Report) contient des statistiques de transmission et de

réception pour les participants qui sont des émetteurs actifs.
 RR (Receiver Report) contient des statistiques de réception pour les
participants qui ne sont pas des émetteurs actifs mais récepteurs d’une
session.
 SDES (Source Description) décrit la source : nom, email, tél, etc.
 BYE permet à une station d’indiquer la fin de sa participation à une session.

3
  APP (Application) est un paquet de signalisation spécifique à une
application.

3.2.

32 bits

V P RC PT Longueur
Rapport(s)

V (2 bits) : version de RTCP

P (1 bit) : Padding indique s’il Ya des octets de bourrage
RC (5 bits) : Reporte Conter contient le nombre de rapport contenue dans le
paquet
PT (8 bits) : indique le type de paquet (SR, RR, SDES, BYE, APP)
Longueur (16 bits) : longueur du paquet.

3.3.

 Limitation du flux de contrôle : qui est directement lié au nombre de

participants. Lors de chaque session, le flux de données rencontre une limite
appelée "bande passante de session" répartie entre les participants. Cette B.P.
est déterminée à partir de la B.P. disponible du réseau. Il est suggéré de
n'allouer qu'un maximum de 5% de cette BP de session aux données RTCP.

Dans ce volume, 25% sont réservées aux informations des sources (messages
SR). Cela garantit ainsi une possibilité de gérer des groupes de grande taille du
point de vue du volume d’information échangé. Plus le nombre de participants
est élevé, moins précise est la vision qu’à chaque participant de l’état du
réseau.

En conclusion l'association des protocoles RTP (Realtime Transport Protocol) et

RTCP (Realtime Transport Control Protocol) permet de transporter et de contrôler
des flots de données qui ont des propriétés temps-réel. RTP et RTCP sont des
protocoles qui se situent au niveau de transport et utilisent le protocole sous-
jacent de transport UDP. RTP et RTCP peuvent utiliser aussi bien le mode Unicast
(point à point) que le mode Multicast (multipoint).

RTCP mesure donc les performances, par contre il n'offre pas de garantie. Pour
cela, il faut employer un protocole de réservation du type RSVP pour bien
s'assurer que les liens de communications utilisés sont correctement
dimensionnés par rapport à l'utilisation.

4
Protocole RSVP :

1.
Le protocole RSVP (Resource ReSerVation Protocol) est un protocole de
contrôle de réseau qui permet au destinataire des données de demander une
certaine qualité de service (par exemple le délai ou la bande passante) à
travers le réseau. Ce protocole de signalisation permet d'allouer
dynamiquement de la bande passante : il est utilisé par les applications "temps
réel" afin de réserver les ressources nécessaires au niveau des routeurs pour
que la bande passante nécessaire soit disponible lors de la transmission.

 RSVP travaille au-dessus de IP (IPv4 ou IPv6) et occupe la place d'un protocole

de transport dans la pile des protocoles mais ne transporte pas de données
utilisateurs. RSVP est encapsulé dans des paquets UDP.
RSVP passe de façon transparente les routeurs non RSVP.

3.

 RSVP n’est pas un protocole de routage, mais il dépend des protocoles de routage
RSVP utilise les protocoles de routage qui continuent à fonctionner sans
modifications, en déterminant le plus court chemin vers la destination.,

 RSVP est orienté vers le récepteur. C'est le récepteur d'un flux de données qui
initie et maintient la réservation de ressources utilisée pour ce flux, d'après les
informations fournies par l'émetteur.

 la norme RSVP ne précise pas comment le réseau fournit la bande passante

réservée aux flux de données. Il s'agit simplement d'un protocole qui permet aux
applications de réserver la bande passante de liaison nécessaire.

5
 32 BITS

• V (4 bits) : désigne la version du protocole RSVP.

• Flags (4 bits) : contient plusieurs indicateurs qui indiquent des options ou des
informations sur le message RSVP, telles que la destination du flux de données,
la confirmation de réception, la présence d'erreurs, la propagation du message,
et des options de traitement de messages spécifiques.
• Type de message (8 bits) : 1 à 7 selon le type ci-dessus.
• Checksum RSVP (16 bits) : est utilisé pour fournir une vérification d'intégrité
des données dans le message RSVP,
• Send_TTL (8 bits) : valeur du TTL IP à comparer avec le TTL du paquet IP
pour savoir s'il y a des routeurs non-RSVP
• Réservé : il n'a pas de signification spécifique et est réservé pour une
utilisation future potentielle dans le protocole RSVP. Il est actuellement inutilisé
et est généralement mis à zéro lorsqu'un message RSVP est envoyé.
• Longeur RSVP (16 bits) : longueur du message RSVP en octets.

 Sept Types de Messages RSVP :

Message PATH (Path message) : le message PATH est envoyé par

l'expéditeur pour annoncer l'existence d'un flux de données et pour demander
aux routeurs de la communication de réserver les ressources nécessaires pour
ce flux.

Message RESV (Réservation message) : le message RESV est envoyé par

les routeurs pour demander la réservation de ressources pour un flux de
données particulier. Le message est transmis à l'expéditeur via les routeurs
pour confirmer la disponibilité des ressources.

PathErr: il est envoyé pour signaler une erreur sur le chemin de transmission,
tel qu'une erreur de routage.

ResvErr: il est envoyé pour signaler une erreur de réservation de ressources,

telle que l'indisponibilité de ressources suffisantes pour répondre à la demande.

PathTear: il est envoyé pour signaler l'annulation d’un chemin RSVP établie

ResvTear: il est envoyé pour annuler la réservation de ressources pour une

session particulière.

ResvConf (optionnel): message de confirmation envoyé par le routeur au

demandeur de la réservation.

6
 L'émetteur envoie un message PATH de routeur en routeur afin de dresser la
liste des nœuds traversés pour déterminer le chemin qui sera emprunté par
la requête RESV. Le chemin des RESV indique la réservation dans le réseau
du flux QoS demandé par la source.

1. avant de pouvoir effectuer une réservation RSVP, il est nécessaire de

déterminer les exigences de ressources pour le flux de données en question.
Cela peut inclure des informations telles que le débit binaire requis, la latence
minimale, et la taille du paquet.….etc.

Source Destination
2. Une fois que les exigences de ressources ont été déterminées, l'expéditeur doit
envoyer un message PATH pour annoncer l'existence du flux de données et
demander la réservation de ressources nécessaires. Le message PATH contient
des informations sur l'identité du flux de données, les paramètres de qualité de
service (QoS) requis, et les adresses IP de l'expéditeur et du destinataire. Le
message PATH est acheminé de routeur en routeur jusqu’à la destination. A
chaque routeur, il y a création d’un état PATH-STATE qui permettra aux
messages RESV d’être acheminés
Path Path Path Path

Destination
Source

3. Dès que la destination a reçu le message PATH, elle envoie un message RESV
incluant les spécifications de la QoS demandée. Ce message RESV est à son
tour acheminé jusqu’à la source.

7
4. A la réception du RESV, le dernier routeur avant la source génère un message
RESVCONF qu’il envoie à la destination. Cet échange de messages permet de faire
la réservation RSVP entre la source et la destination.

6.

L'architecture RSVP (Resource ReSerVation Protocol) est constituée des

éléments suivants :

Processus RSVP: est un programme qui s'exécute sur un routeur ou un commutateur et les HOST. Le
RSVP Daemon gère les demandes de réservation de ressources, les réponses aux demandes, et maintient
un état des réservations de ressources en cours.
Admission Control : qui détermine si les ressources sont suffisantes .
Policy Control : qui vérifie que l'utilisateur a l'autorisation administrative de faire cette réservation.
Le packet classifier le rôle du packet classifier dans RSVP est d'identifier et de classifier les paquets
RSVP entrants en fonction de leur type et de leur contenu.
Le packet scheduler le rôle du packet scheduler de RSVP est de planifier la transmission des paquets
RSVP en fonction des réservations de ressources pour chaque session, tout en respectant les exigences
de qualité de service et en évitant la congestion du réseau.