LOUHICHI Zeineb

Cycle de formation des ingénieurs en Télécommunications
Option : Ingénierie de réseaux
Rapport de Projet de fin d’études
Thème :
Mesure des paramètres de qualité de service pour les

applications voix sur IP
Elaboré par : Melle LOUHICHI Zeineb
me
Encadrants : M OUERTANI Amel
M. HAMZA Rached
Année universitaire : 2005/2006

Dédicaces
A mes parents
Aucun hommage ne pourrait être à la hauteur de l’amour
Dont ils ne cessent de me combler.
Que dieu leur procure bonne santé et longue vie.
A mes frères
A mes sœurs
A mes amis
A mes enseignants
Je dédie ce modeste travail.
Remerciements
Au terme de ce projet de fin d’études, j’adresse mes sincères remerciements à Madame
Amel OUERTANI, chef de division à Tunisie Télécom, pour m’avoir proposé ce projet et pour
son encadrement.
Je tiens à remercier également Monsieur Rached HAMZA, Maître assistant à Sup’Com,
pour son suivi et ses remarques qui m’ont permis de mener à bien ce travail.
Mes remerciements s’adressent également à l’administration et aux professeurs de
Sup’Com pour les moyens qu’ils ont mis à ma disposition afin d’élaborer ce travail.
Je souhaite exprimer enfin ma gratitude et mes vifs remerciements à ma famille et mes
amis pour leur soutien.
LOUHICHI Zeineb
Résumé
La voix sur IP acquiert de plus en plus d’importance dans le domaine des

télécommunications, surtout pour les entreprises, grâce à ses avantages
économiques et techniques.
Avec l’augmentation des applications envoyées sur les réseaux IP, et afin de
fournir un service avec une bonne qualité, il faudrait utiliser des mécanismes
assurant cette qualité.
Dans ce projet de fin d’étude, nous avons tout d’abord réalisé une plate forme
d’un réseau supportant les applications voix sur IP en implémentant à chaque fois
un mécanisme de QoS (IntServ et DiffServ) et en mesurant les différents
paramètres de qualité de service. Finalement, nous avons évalué ces mécanismes.
Mots clés : Voix sur IP, Qualité de service, WFQ, IntServ, DiffServ.
Avant propos
Ce document s’inscrit dans le cadre du projet de fin d’études de l’école

supérieure des communications de Tunis. Il représente un travail de trois mois à
Sup’Com.
L’objectif de ce projet est de déterminer la qualité de service pour les
applications de la voix sur IP en implémentant IntServ et DiffServ.
Table de matières
Table des matières

Table des matières................................................................................................................ 1
Liste des illustrations ........................................................................................................... 4
Liste des tableaux ................................................................................................................. 5
Liste des acronymes ............................................................................................................. 6
Introduction Générale.......................................................................................................... 9
Chapitre 1 : La voix sur IP ................................................................................................ 11
I. Introduction........................................................................................................... 11
II. Généralités sur la voix sur IP .............................................................................. 11
II.1 Définition de la voix sur IP............................................................................ 11
II.2 Apports de la VoIP ........................................................................................ 12
II.3 Architecture d’une infrastructure VoIP ........................................................ 13
II.3.1 Architecture de VoIP hybride ............................................................. 13
II.3.2 Architecture de VoIP « full IP » .......................................................... 14
II.4 Le processus de traitement de la VoIP ......................................................... 15
II.4.1 Principe du transfert de la VoIP ......................................................... 15
II.4.2 Les protocoles de transport de la VoIP ............................................... 16
III. Concepts et standards de la VoIP ...................................................................... 17
III.1 Concept H.323 .............................................................................................. 17
III.1.1 Architecture de H.323 ........................................................................ 17
III.1.2 Architecture protocolaire de H.323 .................................................... 18
III.1.2.1 Les protocoles de communications RTP/RTCP (Real Time
Protocol/Control Protocol) ....................................................................................... 19
III.1.2.2 Les protocoles de codages audio et vidéo ............................ 19
III.1.2.3 Les protocoles de signalisation ............................................ 20
III.1.3 Etablissement d'une connexion H.323 .............................................. 20
III.2 Concept SIP ................................................................................................. 21
III.2.1 Architecture de SIP ............................................................................ 22
III.2.2 Architecture protocolaire de SIP ........................................................ 23
III.2.3 Initiation d'un appel SIP .................................................................... 23
III.3 Comparaison entre H.323 et SIP ................................................................. 25
-1-
Table de matières
III.4 MGCP (Media Gateway Control Protocol) ................................................. 25

III.4.1 Architecture de protocole MGCP ....................................................... 26
III.4.2 Architecture protocolaire de MGCP ................................................. 27
III.4.3 Fonctionnement de MGCP ................................................................. 28
III.4.3.1 Les commandes MGCP ................................................................... 28
III.4.3.2 Etablissement d'une connexion ....................................................... 29
III.4.3.3 Evolution de MGCP vers MEGACO/H.248 ................................... 31
IV. Conclusion ......................................................................................................... 32
Chapitre 2 : La qualité de service dans les réseaux IP...................................................35
I. Introduction........................................................................................................... 33
II. Problématique ..................................................................................................... 33
III. La qualité de service « QoS »............................................................................ 34
III.1 Définition ................................................................................................... 34
III.2 Paramètres de qualité de service ................................................................ 34
III.2.1 Débit ................................................................................................. 34
III.2.2 Délai de latence ................................................................................ 35
III.2.3 Gigue ................................................................................................. 36
III.2.4 Taux de perte de paquets................................................................... 37
III.3 Mécanismes de garantie de la qualité de service pour la VoIP .................... 38
III.3.1 Service Best effort............................................................................. 38
III.3.2 Services garantis (IntServ) ................................................................ 39
III.3.2.1 Présentation de IntServ......................................................... 39
III.3.2.2 Le protocole RSVP (ReSerVation Protocol)........................ 41
III.3.3 Services différenciés (DiffServ)........................................................ 43
III.3.3.1 Présentation .......................................................................... 43
III.3.3.2 Différentiation du trafic........................................................ 44
III.3.3.3 Coloration des paquets ......................................................... 45
III.3.3.4 Architecture DiffServ........................................................... 47
III.3.3.5 Les PHB (Per Hop Behavior)............................................... 48
III.3.4 Optimisation de trafic: MPLS (Multi-Protocol Label Switching) .... 49
III.3.4.1 Présentation .......................................................................... 49
III.3.4.2 Principe de fonctionnement de MPLS ................................. 50
IV. Les compléments de la QoS pour la VoIP ......................................................... 51
IV.1 RTP (Real Time Protocol) ......................................................................... 51
-2-
Table de matières
IV.1.1 Présentation de RTP........................................................................... 51

IV.1.2 Fonctionnement de RTP (Real time Transport Protocol) .................. 52
IV.1.3 Entête RTP ......................................................................................... 52
IV.2 RTCP (Real Time Control Protocol) ......................................................... 54
IV.2.1 Présentation de RTCP ........................................................................ 54
IV.2.2 Les paquets RTCP SR/RR ................................................................. 55
IV.2.3 Les paquets RTCP SDES................................................................... 57
V. Conclusion.......................................................................................................... 57
Chapitre 3 : Mesure de QoS dans les applications VoIP ........................................ 59
I. Introduction......................................................................................................... 59
II. Stratégie de mesure ........................................................................................... 59
II.1 Plateforme de mesure .................................................................................. 59
II.2 Principes de mesure ...................................................................................... 61
III. Evaluation des performances des mécanismes de la qualité de service .......... 62
III.1 Communication dans un réseau LAN ........................................................ 62
III.1.1 Conditions normales sans génération de trafic.................................. 62
III.1.2 Avec génération de trafic ................................................................. 63
III.2 Communication entre deux réseaux locaux ............................................... 63
III.2.1 Les modèles Best Effort ................................................................... 64
III.2.1.1 Trafic sans surcharge............................................................. 64
III.2.1.2 Trafic avec surcharge ............................................................ 66
III.2.2 Modèle IntServ................................................................................. 68
III.2.2.1 Trafic sans surcharge ............................................................ 69
III.2.2.2 Trafic avec surcharge ............................................................ 69
III.2.3 Modèle DiffServ .............................................................................. 71
III.2.3.1 Trafic sans surcharge............................................................. 73
III.2.3.2 Trafic avec surcharge ........................................................... 74
IV. Synthèse : comparaison des mécanismes de QoS .............................................. 76
V. Conclusion........................................................................................................... 78
Conclusion générale ........................................................................................................... 79
Bibliographie....................................................................................................................... 80
Annexes ............................................................................................................................... 81
-3-
Liste des illustrations
Liste des illustrations
Figure 1.1 : Architecture de la téléphonie classique ................................................................ 13

Figure 1.2 : Architecture hybride de Téléphonie sur IP........................................................... 14
Figure 1.3 : Architecture de Téléphonie sur IP « Full IP » ...................................................... 14
Figure 1.4 : Processus de traitement de la voix........................................................................ 15
Figure 1.5 : Architecture de H.323........................................................................................... 18
Figure 1.6 : Architecture protocolaire de H.323 ...................................................................... 19
Figure 1.7 : Etablissement d'une connexion H.323.................................................................. 21
Figure 1.8 : Architecture de SIP............................................................................................... 22
Figure 1.9 : Architecture protocolaire de SIP .......................................................................... 23
Figure 1.10 : Initiation d'un appel SIP...................................................................................... 24
Figure 1.11 : Architecture MGCP ............................................................................................ 27
Figure 1.12 : Architecture protocolaire de MGCP ................................................................... 28
Figure 1.13 : Etablissement d'un appel MGCP ........................................................................ 30
Figure 2.1 : Modèle IntServ entre un routeur et hôte ............................................................... 41
Figure 2.2 : Entête RSVP ......................................................................................................... 42
Figure 2.3 : Réservation de ressources..................................................................................... 43
Figure 2.4 : Champ ToS ........................................................................................................... 45
Figure 2.5 : Champ DSCP dans IPv4 et IPv6 .......................................................................... 46
Figure 2.6 : Architecture d'un modèle DiffServ....................................................................... 47
Figure 2.7 : Modèle MPLS....................................................................................................... 50
Figure 2.8 : Paquet RTP ........................................................................................................... 52
Figure 2.9 : Paquet RTCP SR/RR ............................................................................................ 55
Figure 2.10 : Paquet RTCP SDES............................................................................................ 57
Figure 3.1 : Plate-forme de mesure .......................................................................................... 60
Figure 3.2 : Capture du protocole RTP par Ethereal................................................................ 61
Figure 3.3 : Encapsulation des données voix ........................................................................... 62
Figure 3.4 : Répartition de la bande passante........................................................................... 68
Figure 3.5 : Répartition de la bande passante pour DiffServ ................................................... 72
-4-
Liste des tableaux
Liste des tableaux
Tableau 1.1 : Codecs audio ...................................................................................................... 16

Tableau 2.1 : Classes de service............................................................................................... 36
Tableau 2.2 : Seuil des paramètres critiques de VoIP.............................................................. 38
Tableau 2.3 : Critères de classification de types de données transitées ................................... 44
Tableau 2.4 : PHBs AF standardisés........................................................................................ 49
Tableau 2.5 : Codecs supportés par RTP ................................................................................. 53
Tableau 2.6 : différents types de paquets RTCP ...................................................................... 55
Tableau 3.1 : Classes de trafic selon Cisco .............................................................................. 71
Tableau 3.2 : Récapitulation des résultats................................................................................ 76
-5-
Liste des acronymes
Liste des acronymes
AF Assured Forwarding
CoS Class of Service
CRCX Create ConneXion
DiffServ Differenciated Services
DSCP Differentiated Service Code Point
EF Expedited Forwarding
FEC Forwarding Equivalence Class
FIFO First In First Out
GK GateKeeper
GW GateWay
IAM Initial Address Message
IETF Internet Engineering Task Force
IP Internet Protocol
IntServ Integrated Services
ISDN Integrated Services Digital Network
ISUP Integrated Services User Part
ITU International Telecommunication Union
LAN Local Area Network
QoS Quality Of Service
PDU Protocol Data Unit
LDP Label Distribution Protocol
LER Label Edge Routeur
-6-
Liste des acronymes
LSP Label Switch Path
LSR Label Switching Router
MCU Multipoint Control Unit
MG Media Gateway
MGCP Media Gateway Control Protocol
MPLS MultiProtocol Label Switching
NTFY NoTiFY
PABX Private Automatic Branch eXchange
PQ Priority Queuing
PS Proxy Server
PSTN Public Switched Telephone Network
RNIS Réseau Numérique à Intégration de Services
RS Redirect Server
RSVP Resource Reservation Protocol
RTCP Real-Time Transport Control Protocol
RTP Real-Time Transport Protocol
SAP Session Annoucement Protocol
SDES Source DEScription
SDP Session Description Protocol
SG Signalling Gateway
SSP Point de Signalisation
STP Point de Transfert de Signalisations
SIP Session Initiation Protocol
SLA Service Level Agreement
TCP Transport Control Protocol
-7-
Liste des acronymes
UDP User Datagram Protocol
VoIP Voice over Internet Protocol
WAN Wide Area Network
WFQ Weighted Fair Queuing
-8-
Introduction générale
Malgré la forte croissance des flux de données et des flux multimédias observée ces
dernières années, la téléphonie constitue encore pour les entreprises le principal média, aussi
bien en matière de communication interne qu’externe. La téléphonie classique (RTC ou
Réseau Téléphonique Commuté) repose sur une technologie de commutation de circuits, bien
antérieure à l’informatique et aux réseaux de données, mais robuste et présentant une forte
disponibilité. Les coûts téléphoniques pour une entreprise peuvent significativement être
réduits avec l’apparition de la Voix sur IP, en particulier dans les cas de communications
entre sites distants d’une même entreprise, d’une présence géographique internationale, de
communications longues distance nombreuses…
La voix sur IP est basée sur deux principes : Découpage du flux voix numérisé en une
suite de « paquets » et le transit sur un réseau IP.
Pour y parvenir il faut garantir certains services et répondre à plusieurs contraintes plus
précisément la qualité de service.
La qualité de service requise d’un réseau, pour la transmission de la parole, est très
différente de celle requise pour la transmission de données. En effet, le temps joue un rôle
primordial lorsqu’il s’agit de transmettre la voix, tant du point de vue du débit garantie que
des délais maximaux admissibles et de la gigue de ces mêmes délais. Alors que le taux
d’erreurs n’est, dans ce cas, que d’une importance relative. Pour la transmission de données,
en revanche, c’est le taux d’erreurs qu’il est important de maintenir faible, les délais de
transmission étant marginaux.
Le but de ce travail est de déterminer les paramètres de la qualité de service dans un
réseau supportant la voix sur IP et de comparer entre deux mécanismes tels que IntServ et
DiffServ.
Cette étude est organisée en trois chapitres :
Le premier chapitre est une présentation de la voix sur IP, son principe de
fonctionnement, ses concepts et ses standards.
Le deuxième chapitre décrit la qualité de service dans un réseau IP en se basant sur les
paramètres permettant de la mesurer ainsi que les mécanismes qui l’assurent.
-9-
Le dernier chapitre représente l’application qui a permis de mesurer les paramètres de la

qualité de service pour la voix sur IP et l’évaluation de deux mécanismes de la qualité de
service : IntServ et DiffServ.
- 10 -
Chapitre 1 La voix sur IP
Chapitre 1
La voix sur IP
I. Introduction
Les technologies « intégrées » proposant le transport de plusieurs informations

différentes sur un même support sont aujourd’hui très prisées non seulement pour les
économies qu’elles permettent de réaliser mais également par la souplesse d’utilisation
qu’elles proposent. Une nouvelle technologie permet de se passer complètement de centraux
téléphoniques et d'acheminer voix et données par les mêmes passerelles (gateways) et
routeurs. Cette technique, nommée voix sur IP, est en plein développement.
La voix sur IP est une technique qui permet d'acheminer la parole et les données sur un
même réseau de données.
Dans ce chapitre, on va définir la notion de voix sur IP tout en présentant quelques

généralités telles que les apports, l’infrastructure ainsi que les techniques et les standards
utilisés.
II. Généralités sur la voix sur IP
II.1 Définition de la voix sur IP
La Voix sur IP, dénommé ci-après, « VoIP » (Voice over Internet Protocol) est une
technique qui permet de transmettre une conversation vocale sur un réseau IP (Internet
Protocol), c'est-à-dire sur un réseau de données par opposition à une transmission sur le
réseau téléphonique.
Cette technique doit être effectuée indépendamment du type des terminaux qui peuvent
être des téléphones traditionnels, des téléphones IP ou des équipements terminaux
multimédias. Pour avoir la VoIP, il suffit qu’un seul segment soit convoyé au travers du
réseau IP.
- 11 -
Le terme générique VoIP est souvent utilisé dans son sens le plus général pour désigner
toutes les solutions permettant le transport de la parole sur un réseau IP. En fait, il faut
distinguer entre:
• la VoIP : transport de la parole uniquement sur un réseau IP.

• la téléphonie sur IP : en plus de la parole, les fonctions téléphoniques (fax,
multi-appel, consultation des messages vocaux dans la messagerie électronique,
ou inversement, écouter ses e-mails par téléphone) sur IP.
La technique VoIP est en plein essor grâce à ses avantages et surtout pour les
entreprises.
II.2 Apports de la VoIP
Il existe quelques raisons objectives pour que les communications sur IP soient moins
coûteuses que les communications sur RTC.
D’une part, la mise en œuvre de la transmission de la voix par paquets qui, par nature,
utilise mieux les liaisons de télécommunications que la technique de commutation de circuits
qui dédie un circuit de bout en bout à chaque communication téléphonique sans tenir compte
des temps morts de la conversation. En outre, la pratique d’une compression de l'information
numérique qui fait passer la voix numérisée du débit standard de 64 kbit/s à un débit de moins
de 10 kbit/s redonne une meilleure utilisation de la bande passante.
D’autre part, l'exploitation d'un seul réseau pour le transfert de la voix et des données
s’accompagne de la réduction des coûts d’investissement, à la simplification des procédures
d'installation, d’assistance et de configuration. Les entreprises peuvent réduire sensiblement
certains coûts de communications nationales ou bien internationales.
Enfin, la VoIP a engendré une suppression des distances. En effet, une des grandes
propriétés d'IP que l'on a vue à travers l'Internet c'est de pouvoir, grâce à ce protocole de base,
se connecter à n'importe quel serveur dans le monde entier, quelle que soit la distance. Dans la
technologie traditionnelle, les serveurs étaient locaux. Maintenant, les serveurs qui traitent le
transfert de la voix peuvent se trouver n'importe où. Ce principe de base ouvre sur de
nombreux services de mobilité.
- 12 -
II.3 Architecture d’une infrastructure VoIP
Traditionnellement, les réseaux téléphoniques et de données sont séparés.

Généralement, dans un réseau téléphonique, on distingue le réseau capillaire ou de
distribution, qui est le raccordement depuis chez l’abonné à un point d'entrée du réseau et le
réseau de transit, qui effectue pour sa part le transport des communications entre les nœuds de
transit (commutateurs).
En entreprise, on dispose de deux réseaux distincts : l’un pour la voix, l’autre pour les
données. Un autocommutateur ou PABX assure la connexion des postes téléphoniques aux
réseaux des opérateurs, tandis qu’un routeur connecte le réseau d’entreprise à Internet via un
fournisseur de services Internet.
Figure 1.1 : Architecture de la téléphonie classique
II.3.1 Architecture de VoIP hybride
Le choix de l’opérateur pour la mise en œuvre d’une solution VoIP sont les suivants :
• soit, par l’ajout d’une carte IP sur un PABX (IPABX), si celui-ci est évolutif en
IP (opération qui doit être faite par l’opérateur),
• soit, par l’ajout d’un boîtier « voice gateway » externe au PABX,
• soit, par un recours aux fonctionnalités de gateway intégrées aux routeurs de
dernière génération (sous forme de carte).
- 13 -
Figure 1.2 : Architecture hybride de Téléphonie sur IP
II.3.2 Architecture de VoIP « full IP »
La figure 1.3 présente l’architecture type d’un système complet de téléphonie sur IP.
Figure 1.3 : Architecture de Téléphonie sur IP « Full IP »
Cette représentation montre que, lors d’une communication IP inter ou intra-site, seuls
les flux de signalisation transitent par le gatekeeper. Celui-ci assure la mise en relation des
téléphones IP sans constituer un point de passage obligé des flux voix. La Voice Gateway est
la passerelle d’accès aux réseaux publics.
- 14 -
II.4 Le processus de traitement de la VoIP
Dans ce paragraphe, on va représenter le principe de traitement de la VoIP, et les

standards qui permettent de véhiculer la VoIP.
II.4.1 Principe du transfert de la VoIP
Le codec audio de l'émetteur numérise et compresse la voix. Ces données numériques,

après la suppression de silence et l'ajout des entêtes, sont acheminées jusqu'au destinataire
dans des paquets IP [1]. Ce processus est représenté par la figure 1.4.
Figure 1.4 : Processus de traitement de la voix
¾ La numérisation : La bande voix qui est un signal électrique analogique utilisant une
bande de fréquence de 300 à 3400 Hz. Ce signal doit d’abord être converti sous forme
numérique suivant le format PCM (Pulse Code Modulation) ou G.711 à 64 Kbps. Si
l’interface téléphonique est numérique (accès RNIS, par exemple), cette fonction est
omise. En effet, le signal est échantillonné à 8 khz selon la théorie de Shannon, soit un
échantillon toutes les 125 ms. Chaque échantillon est ensuite codé sur 8 bits, ce qui donne
un débit binaire de 8*8000=64 kbit/s. Ce débit binaire correspond à une voix numérique
non compressée.
¾ Compression numérique : De nombreux algorithmes permettent de réduire le besoin en
bande passante à des débits nettement inférieurs (16, 8 et même 4kbit/s) et d’augmenter
ainsi l’efficacité du transport de la voix sur les réseaux informatiques orientés paquets.
La fonction de codec est le plus souvent réalisée par un DSP (Digital Signal Processor).
Généralement, plus le taux de compression est élevé par rapport à la référence de 64

kbit/s, moins la qualité de la voix est bonne. Toutefois, les algorithmes de compression
récents permettent d’obtenir des taux de compression élevé, tout en maintenant une qualité de
la voix acceptable.
- 15 -
L’acceptabilité par l’oreille humaine des différents algorithmes est définie selon le
critère MOS (Mean Operational Score), défini par l’organisme de normalisation international
ITU [2].
Pour la voix, le codec le plus utilisé est le G.711.
Tableau 1.1 : Codecs audio
La signal numérisé et compressé va être après découpé, on ajoute des entêtes, et on les
achemine jusqu'au destinataire dans des paquets IP.
II.4.2 Les protocoles de transport de la VoIP
Le transport de la VoIP met en jeu de nombreux protocoles de couches inférieures à

celle qui contient l‘information voix parmi lesquels TCP, UDP et RTP.
Les protocoles de transport classiquement utilisés pour transporter les données sont TCP
et UDP. Le protocole TCP assure un bon contrôle de l’intégrité des informations transportées
(mécanismes d‘accusé de réception) mais n‘est pas particulièrement performant en termes de
délais. UDP est un protocole plus simple que TCP, présentant, de ce fait, de meilleures
performances moyennes car il permet l‘envoi de paquets sans contrôle de réception (pas
d’acquittement).
Le transport de la voix répond à des exigences différentes de celles relatives au transport

de données, à savoir les délais, sans garantie aussi forte de fiabilité. Le protocole répondant à
ces exigences est le protocole RTP (Real Time Protocol), utilisé pour les flux temps réel
encapsulés dans des paquets UDP. Le protocole RTCP (Real Time Control Protocol) est
associé à RTP afin de lui fournir les fonctionnalités de contrôle de la QoS qui lui manquent.
- 16 -
III. Concepts et standards de la VoIP
La VoIP n’a pas de standard unique. En effet, chaque constructeur apporte ses normes et
ses fonctionnalités à ses solutions. Il existe trois principaux standards qui sont H.323, SIP et
MGCP/MEGACO. Tous les acteurs de ce marché utilisent comme base pour leur produit une
ou plusieurs de ces trois architectures [3].
H.323 est un protocole très proche de Q.931 utilisé dans RNIS (ISDN : Integrated
Services Digital Network) et a été ratifié par ITU (International Telecommunication Union).
IETF (Internet Engineering Task Force) a développé de son côté SIP (Session
Initialisation Protocol) qui réutilise un certain nombre d'éléments familiers issus d'Internet,
tels que : SMTP, HTTP…
MGCP (Media Gateway Control Protocol) provient du monde des compagnies des
télécommunications. Il répond aux besoins des réseaux de téléphonie IP des transporteurs. Le
protocole est utilisé pour contrôler les passerelles de média.
III.1 Concept H.323
H.323 est un ensemble de protocoles développé par l'ITU pour les applications voix et
vidéo à travers un réseau à commutation de paquets. Il a été conçu de sorte à être utilisé au-
dessus de n'importe quel protocole de transport tels que TCP ou UDP. H.323 est une suite de
protocoles intégrés de manière verticale. Il utilise les protocoles suivants : Q.931 pour
l'établissement des appels, H.225 pour la signalisation des appels, H.245 pour la négociations
des paramètres entres les terminaux, RAS qui est chargé par l'enregistrement et admission,
RTP/ RTCP, et des codecs audio ou vidéo.
III.1.1 Architecture de H.323
Plusieurs entités sont nécessaires à la réalisation d’un service de communication

multimédia sur des réseaux de données. Ils sont représentés dans la figure 1.5.
- 17 -
Figure 1.5 : Architecture de H.323
• Les terminaux H.323 sont des systèmes multimédia (téléphone, PC) permettant de
communiquer en « temps réel ». Ils supportent des communications à deux sens avec d'autres
terminaux H.323 et doivent comporter un codec audio. Pour la négociation et l'établissement
de sessions, le terminal H.323 doit supporter le protocole H245 ainsi que le protocole de
signalisation H225, la fonction RAS pour communiquer avec le gatekeeper et le protocole
RTP/RTCP pour le séquencement des paquets audio.
• Le gatekeeper gère une zone H.323 qui correspond à une collection logique de
périphériques tels que les terminaux H.323, les passerelles et le MCU. Il identifie et traduit
les adresses, route et contrôle les appels, l'admission et la bande passante. Le gatekeeper
supporte aussi des fonctions optionnelles telles que le contrôle de la signalisation,
l'autorisation des appels, la gestion de la bande passante et des appels.
• La passerelle H.323 (gateway) permet d’interfacer le réseau IP avec le réseau

téléphonique classique. Elle assure donc la conversion des formats et la conversion de la
signalisation H.323 en signalisation RTC ou le contraire. Elle assure en plus la
compression/décompression de la voix.
• L’unité de contrôle MCU (Multipoint Controller Unit) gère les connexions multipoint
(ex. : appels de conférence). Il se décompose en un Multipoint Controller (MC), affecté à la
signalisation, et un Multipoint Processor (MP), dédié à la transmission proprement dite.
III.1.2 Architecture protocolaire de H.323
La figure 1.6 représente les différents couches constituant l’architecture H.323.
- 18 -
Figure 1.6 : Architecture protocolaire de H.323
L’architecture de H.323 s'appuie sur trois familles de protocoles telles que définies ci-
après.
III.1.2.1 Les protocoles de communications RTP/RTCP (Real Time

Protocol/Control Protocol)
Ce sont des protocoles situés au dessous d'UDP/TCP et utilisés pour transporter et

contrôler les données « temps réel » sur un réseau IP avec notamment des fonctions de
numérotation de séquence ou d’horodatage.
La voix est transmise dans des paquets qui utilisent la norme RTP (Real Time Protocol).
Chaque paquet RTP contient une partie d’un mot numérisé. Plusieurs paquets RTP doivent
être combinés au niveau du téléphone IP de réception pour produire un mot parlé.
Les passerelles et les téléphones IP collectent environ 10 à 30 ms de voix numérique et

la placent dans un paquet RTP pour la transmission.
III.1.2.2 Les protocoles de codages audio et vidéo
Pour le codage de la parole, le standard le plus utilisé est le G711 ou Pulse Code
Modulation (PCM) qui échantillonne la parole en mots de 8 bits à 8KHz. Le débit résultant est
de 64Kb/s et il existe deux variantes : la loi A (Amérique du Nord et Japon) et la loi MU
(Europe et reste du monde). D’autres codecs moins gourmands en bande passante sont utilisés
pour la VoIP ou pour les applications de téléphonie mobile. Ils exploitent plus finement les
- 19 -
caractéristiques de la parole (fréquences) et utilisent la compression pour atteindre des débits

allant jusqu'à 5,3 Kb/s.
III.1.2.3 Les protocoles de signalisation
¾ H.245 : Le protocole H.245 effectue les opérations de « control signalling » permettant

l’échange de messages entre les terminaux de façon à gérer la communication. Ces
messages de contrôle transportent les informations suivantes :
o Echange de capacité (performance) entre les terminaux (codecs
disponibles, débits, type de données, etc.)
o Ouverture et fermeture de canaux logiques: H.245 spécifie les canaux
logiques (unidirectionnels) et contrôle l’ouverture et la fermeture de ces
canaux. Il est à noter que le canal logique 0 est toujours ouvert et utilisé
par H.245 pour les messages de contrôle.
o Contrôle de flux: le contrôle de flux est réalisé par l’envoi, dans les
messages de contrôle H.245 de type « Open Logical Channel », de
l’adresse de transport du canal RTCP (numéro de port alloué pour les
messages RTCP).
¾ H.225 : RAS et Q.931 : RAS est chargé des opérations administratives tels que
l’enregistrement, l’admission et l’état. Il est utilisé par les terminaux pour communiquer
avec le gatekeeper tandis que Q.931 est utilisé pour l’établissement et la libération des
connexions. TCP est utilisé parce qu’il garantit un transport fiable de la connexion.
III.1.3 Etablissement d'une connexion H.323
L'établissement d'une connexion H.323 illustré par la figure 1.7 s'effectue à travers les
étapes suivantes :
• Etablissement de la communication.
• Communication initiale et échange des capacités.
• Etablissement de la communication audiovisuelle.
• Services de communication.
- 20 -
Figure 1.7 : Etablissement d'une connexion H.323
Le dialogue commence par l'ouverture d'une session TCP sur le port 1720 pour
l'échange des données de signalisation. Durant cet échange, les terminaux conviennent d'un
numéro de port TCP supérieur à 1024 qui sera utilisé pour l'échange de contrôle (H245). Les
messages H.245 échangés correspondent à la négociation des paramètres (type codec voix…).
Puis une séquence d'initialisation des canaux logique H.323 est échangée. L’échange de RTP
et RTCP se fait sur UDP.
III.2 Concept SIP
Le standard SIP (Session Initiation Protocol,), proposé par l’IETF en 1999, est un
protocole de signalisation pour l’établissement d’appel et de conférences temps réel sur des
réseaux IP. SIP est rapidement apparu comme une alternative à H.323.
Chaque communication doit pouvoir inclure différents types de données telles que
l’audio et la vidéo. SIP est indépendant du protocole de transport utilisé. Il utilise le protocole
SDP (Session Description Protocol) pour la description des communications média.
- 21 -
III.2.1 Architecture de SIP
L'architecture de SIP est basée sur des relations client/serveur. Les principales
composantes sont le terminal (User Agent), le Proxy Server, le Redirect Server et le Registrar.
Figure 1.8 : Architecture de SIP
Les terminaux sont considérés comme clients lorsqu'ils effectuent une requête et appelés
dans ce cas UAC (User Agent Client), et comme des serveurs lorsqu'ils y répondent et alors
appelés UAS (User Agent Server). Les terminaux peuvent communiquer directement entre
eux ou par l'intermédiaire d'autres serveurs.
Les serveurs SIP peuvent se comporter comme proxy serveur, serveur de redirection
(redirect server) ou bien registrar server.
¾ Proxy server : c'est un serveur auquel est relié le terminal fixe ou mobile. Il joue le rôle
de serveur d’un côté (réception de requête) et de client de l’autre (envoi de requête). Il
permet de relayer les messages vers le ou les terminaux auxquels ceux-ci sont destinés.
¾ Redirect server : il répond à une requête SIP « Invite ». Il établit la correspondance entre
l’adresse SIP du terminal appelé et la ou les adresses où il pourra effectivement être
joignable. Le redirect server n’est pas chargé d’accepter les appels ni d’émettre des
requêtes. Il ne fait que répondre aux requêtes émises par des terminaux SIP appelants.
¾ Registrar server : c'est un serveur qui traite les requêtes « Register ». Il est généralement
une base de données qui permet de mémoriser les différents utilisateurs (droits, mots de
passe, etc.) ainsi que leurs positions actuelles. Sa fonction est alors connaître l’endroit où
se trouve un usager et de fournir cette information au proxy et au redirect server. En effet
- 22 -
pour pouvoir joindre un usager à partir d’une adresse SIP, il faut faire une correspondance
avec une adresse IP qui peut être variable (mobilité IP) : c’est le rôle du registrar.
III.2.2 Architecture protocolaire de SIP
Le schéma suivant donne l'architecture protocolaire de SIP.
Figure 1.9 : Architecture protocolaire de SIP
Le standard SIP se base sur les protocoles suivants :
• RSVP (Ressource Reservation Protocol) : il est utilisé pour la réservation des

ressources dans le réseau IP.
• RTP/RTCP.
• SAP (Session Annoucement Protocol) : qui précise l'état des sessions
multimédia ouvertes.
• Session Description Protocol (SDP) : Le protocole SDP est un protocole qui
décrit les sessions audio, vidéo et multimédia. SDP utilise des caractères ASCII
et donne les informations nécessaires à l’établissement d’une communication
multimédia telles que l’identité de l’initiateur de la session, la bande passante
disponible, les codeurs utilisés.
III.2.3 Initiation d'un appel SIP
Le protocole SIP est très simple et ses messages sont inspirés du protocole http. Un
exemple d'appel avec serveur Proxy est illustré par la figure 1.10.
- 23 -
Figure 1.10 : Initiation d'un appel SIP
La localisation physique d’un usager s’effectue en deux étapes. L’URL SIP permet à
l’usager appelant de localiser le SIP Server auquel est rattaché la machine de l’appelé. Celui-
ci sera la destination du message « Invite » initial. Soit le serveur connaît l’adresse physique
de l’usager appelé et il permettra l’établissement d’une connexion, soit il redirige la requête
vers un autre lieu où il sait que l’appelé pourra être joint.
Le fait que l’URL SIP pointe sur un serveur et non sur l’usager terminal donne à ce
dernier une plus grande mobilité. Cela permet aussi de soulager le serveur DNS qui n’a qu’à
connaître l’adresse du serveur et non de tous les terminaux reliés au serveur.
Pour faire appel à SIP, l’application de l’UAC appelant envoie une requête INVITE au
Proxy Server (PS) auquel il est relié. Ce serveur, via d'autres PS, transmet cette requête à
l'UAS auquel est relié l’appelé. Cette requête demande à l’appelé s’il veut rejoindre un forum
de discussion, assister à une visioconférence ou établir simplement une communication privée
avec l’appelant. Si l’appelé est d’accord, il renvoie une réponse OK (code 200) à l’appelant
qui confirme alors qu’il a bien reçu la réponse de l’appelant. Pour cela, il envoie une requête
ACK, acquittement à l’appelé. De la même manière, si l’utilisateur souhaite se déconnecter,
l’application de l’utilisateur émet une requête BYE au lieu de ACK.
La requête INVITE contient la description de la session ouverte qui stipule quels sont
les médias et formats des messages SIP utilisés (protocole SDP). Pour une communication
- 24 -
unicast, la requête INVITE précise les types de média et formats que l’appelant utilisera et
vers où il souhaite que les données soient envoyées. Si l’appelé est d’accord avec cette
description, sa réponse contiendra les mêmes paramètres. En multicast, l’appelé répondra que
si sa description est différente.
La requête INVITE peut s'établir en deux modes. Soit en mode Proxy Server ou bien en
mode Redirect Server. Dans le premier cas, c'est le PS qui envoie une requête INVITE au
serveur destinataire dont l’adresse lui a été fournie par Location Server. Tandis que dans le
deuxième cas, le RS renvoie au client appelant l'adresse précise de destinataire fournie par
Location Server. Le client envoie alors la requête INVITE directement au serveur du
destinataire.
III.3 Comparaison entre H.323 et SIP
Les deux concepts H.323 et SIP diffèrent dans quelques aspects:
• H.323 est spécifié par l'UIT tandis que SIP est développé par IETF. H.323 est
plus complexe que SIP.
• H.323 est inspiré du réseau RNIS. Par contre, SIP est dérivé du monde Internet:
http.
• H.323 et SIP utilisent les protocoles RTP et RTCP pour la synchronisation de la
voix.
• H.323 ne peut pas évoluer très vite parce que l'ajout d'extensions propriétaires
sans concertation entre constructeurs pose un problème. SIP est une norme
ouverte donc elle est plus extensible et permet l'interopérabilité entre les
constructeurs.
III.4 MGCP (Media Gateway Control Protocol)
Le protocole MGCP, défini par l'IETF, est la réunion des deux protocole SGCP (Simple
Gate Control Protocol) et du protocole IPDC (Internet Protocol Device Control). Le protocole
SGCP est utilisé pour contrôler l’activité d’une Telephony Gateway à travers un élément de
contrôle d’appel externe nommé Call Agent ou Media Gatway Controller. Le protocole IPDC
est utilisé pour réaliser le control de connexions du Media Gateway et le transport de la
- 25 -
signalisation. MGCP définit donc le protocole entre les passerelles (MG) et un équipement
permettant de contrôler ces dernières dans le contexte d'un réseau public (MGC).
Ce protocole suppose une architecture de contrôle d’appel (MGC ou Call Agent) dans
laquelle l’élément intelligent de contrôle qui assure le contrôle de l’activité de la passerelle
multimédia à l’aide d’un protocole de contrôle.
Etant donné que l'architecture H.323 n'est pas compatible avec le monde des réseaux
publics de téléphonie intégrant de multiples passerelles et la signalisation SS7, il a fallu
trouver un protocole (MGCP) qui permet l'interconnexion du SS7 et VoIP. Il est utilisé pour
des réseau de grandes tailles et fonctionnant avec différentes architectures tels que H.323 et
SIP.
Par cette nouvelle architecture, on n'a plus besoin du Gatekeeper et on a supprimé la

signalisation du Gateway pour la mettre dans les Media Gateway Controllers.
III.4.1 Architecture de protocole MGCP
L’architecture générale du protocole MGCP est la suivante :
• STP Point de Transfert de Signalisations

• SSP Point de Signalisation
• SG Gateway de Signalisation
• MG Media Gateway (Passerelle Multimédia)
• ISUP ISDN User Part
Dans cette architecture la gestion des différents Gateways ainsi que les interconnexions
avec le RTC est assurée par les Call Agents. L’identification d’une extrémité ce fait par le
nom du domaine de la Gateway a laquelle l’extrémité est reliée et par un nom local dans ce
Gateway.
L’interconnexion entre le réseau téléphonique et le réseau IP est assurée par deux

niveaux logiques :
- 26 -
• Niveaux de signalisation assurés par l’utilisation du SG (Signalling Gateway)

qui convertit la signalisation ISUP en une signalisation correspondante au
monde IP.
• Niveaux de voix assurés par l’utilisation de passerelle multimédia qui assure la
transformation d'un flux vocal entre le mode circuit et le mode paquet.
Dans cette architecture la gestion des différents Gateways ainsi que les interconnexions
avec le réseau RTC est assurée par les Call Agents ou MGC. L’identification d’une extrémité
ce fait par le nom du domaine de la Gateway a laquelle l’extrémité est reliée et par un nom
local dans ce Gateway.
Figure 1.11 : Architecture MGCP
III.4.2 Architecture protocolaire de MGCP
Les messages de signalisation MGCP sont convoyés au moyen du protocole UDP. Les
protocoles de transfert des informations audio, vidéo et des données sont identiques dans les
environnements MGCP, SIP et H.323. La comptabilité au niveau des flux des médias
informationnels est ainsi assurée.
- 27 -
Figure 1.12 : Architecture protocolaire de MGCP
III.4.3 Fonctionnement de MGCP
III.4.3.1 Les commandes MGCP
Le protocole MGCP est un protocole de contrôle de fonctionnement de Media Gateway.

Dans ce protocole l’élément intelligent est le Call Agent. Il contrôle les passerelles par
l’utilisation des huit commandes échangées entre lui et les passerelles.
¾ Notification Request : Le Call Agent peut envoyer cette commande au Gateway, pour lui
demander de détecter l’apparition des évènements spécifiques pour un terminal. Ces
spécifications peuvent être des signalisations téléphoniques comme l’accrochage ou le
décrochage du téléphone ou bien des tonalités pour des extrémités spécifique. Une des
plus importantes options de Notification Request est l’association d’une action avec
chaque évènement. L’utilisation de cette option permet la réduction de nombre de
messages échangés entre le Call Agent et le Media Gateway.
¾ Notification Command : Le Gateway l'utilise comme réponse à la commande
Notification Request envoyée par le Call Agent, cette commande indique au Call Agent
que l’évènement est déclenché.
¾ Create Connection : Elle est envoyée par le Call Agent au Media Gateway pour créer
une connexion entre deux extrémités. Autres que les paramètres nécessaires qui
permettent au Media Gateway de créer des connexions, il y a des options
LocalConnectionOptions qui définissent la qualité de service de la connexion.
¾ Modify Connection : Cette directive permet au Call Agent de modifier les paramètres
associés à une connexion déjà établie.
- 28 -
¾ Delete Connection : Cette commande est envoyée par le Call Agent au Gateway. Elle
permet de terminer une conversation téléphonique. S’il existe plus d’un seul Media
Gateway pour une conversation le Call Agent doit envoyer cette commande à chaque
Gateway.
¾ Audit Endpoint : Le Call Agent l'utilise pour détecter si une extrémité est décrochée ou
en état de sonnerie.
¾ Audit Connection : Cette commande permet au Call Agent de détecter tous les
paramètres liés à une connexion spécifique.
¾ Restart In Progress : Cette instruction est envoyée par le Gateway au Call Agent. Elle
permet de demander le Call Agent de mettre hors service une extrémité ou un groupe
d’extrémités qui ont des problèmes.
III.4.3.2 Etablissement d'une connexion
L’utilisateur A utilise un terminal analogique et servi par le commutateur (Central

Office CO). Il est connecté à un réseau de signalisation SS7 à travers un STP (Point de
Transfert de sémaphore). Le STP est connecté au Call Agent à travers une Gateway de
signalisation (SG), le rôle de SG est de convertir la signalisation SS7 du réseau téléphonique
en une signalisation sur le réseau IP. Dans ce cas le Call Agent joue le rôle d’une entité
intermédiaire entre le Gateway de signalisation et le gateway de multimédia.
Le transfert de la voix se fait à travers le Media Gateway après un contrôle par le Call
Agent.
- 29 -
Figure 1.13 : Etablissement d'un appel MGCP
1. CO: émet un message d’initialisation (IAM) au Call Agent à travers son STP.
2. SS7 : le point de transfert de signalisation (STP) conduit le message ISUP au Gateway de
signalisation attaché au Call Agent.
3. Call Agent : cherche dans la base de données l’adresse IP de la Gateway à laquelle le
destinataire qui correspond à ce numéro est rattaché.
4. Call Agent : envoie un message Create Connection au Gateway de l’utilisateur A pour ce
connecter au réseau téléphonique.
5. Media Gateway (émetteur): envoie un message ACK au Call Agent pour lui indiquer la
réception du message CRCX (Create Connection).
6. Call Agent : saisit la réponse et envoie un message CRCX au Gateway de l’utilisateur B.
7. Media Gateway (récepteur): envoie un message ACK au Call Agent pour lui indiquer la
réception du message CRCX.
8. Call Agent : indique ces informations au Media Gateway (émetteur) par l’envoie d’un
message Modify Connection.
9. Media Gateway (émetteur): envoie un message ACK au Call Agent.
- 30 -
10. Call Agent : envoie un message Notification Request au Media Gateway (récepteur) B
pour lui indiquer de sonner le téléphone B.
11. Media Gateway (récepteur): envoie un message ACK au Call Agent.
12. Call Agent : quand le Call Agent reçoit le message ACK, il envoie un message ACM
(Address Complete Message) au Gateway de signalisation.
13. SS7 : le STP transporte cette information au CO.
14. Utilisateur B : le terminal B se décroche.
15. Media Gateway (récepteur): détecte cet évènement et informe le Call Agent par envoie de
message Notification.
16. Call Agent : envoie un message ACK au Media Gateway (récepteur).
17. Call Agent : dans l’ordre de pouvoir détecter la terminaison de la conversation, le Call
Agent demande au Media Gateway (récepteur) de lui informer le raccrochage du téléphone et
ceci par l’envoie d’un message Notification Request.
18. Media Gateway (récepteur): envoie un message ACK au Call Agent.
19. Call Agent : maintenant le canal de voix doit être transformé en mode full duplex ; le Call
Agent fait ceci par l’envoie du message Modify Connection au Media Gateway (émetteur).
20. Media Gateway (émetteur): envoie un message ACK au Media Gateway (récepteur).
21. Call Agent : peut dans ce cas envoyer un message de réponse au Gateway de signalisation.
22. SS7 : le STP envoie cette information aux CO.
23. Les deux parties entrent en conversation.
24. Media Gateway (récepteur): l’utilisateur B se raccroche.
25. le Media Gateway (récepteur) envoie un message de Notification au Call Agent.
26. Call Agent : envoie un message ACK au Media Gateway (récepteur).
27. Call Agent : envoie un message Delete Connection au Media Gateway (récepteur) B.
28. Call Agent : envoie un message Delete Connection au Media Gateway (émetteur) A.
29. Call Agent : émet un message RELEASE au Gateway de signalisation.
30. SS7 : le STP transport cette information au CO.
III.4.3.3 Evolution de MGCP vers MEGACO/H.248
Le groupe de travail MEGACO (MEdia GAteway COntrol) a été constitué en 1998 pour
compléter les travaux sur le protocole MGCP au sein de l’IETF.
Depuis 1999, l’UIT et l’IETF travaillent conjointement sur le développement du

protocole MEGACO/H.248 ; c’est un standard permettant la communication entre les Media
- 31 -
Gateway Controller (MGC) et les Media Gateway (MG). Il est dérivé de MGCP et possède
des améliorations par rapport à celui-ci :
• Support de services multimédia et de vidéoconférence

• Possibilité d’utiliser UDP ou TCP
• Utilise le codage en mode texte ou binaire
Une première version de H.248 a été adoptée en juin 2000. L’implémentation de H.248
permet une grande modularité ; en effet, ce protocole est étendu par des « packages »
répondant à des besoins spécifiques. Ce système permet de couvrir un nombre très important
d’applications, mais complique aussi grandement les inter-fonctionnements d’équipements
d’origine différente. Ainsi un constructeur peut implémenter, suivant ses besoins, tel ou tel «
package » qui ne sera pas obligatoirement choisi par un autre constructeur.
IV. Conclusion
Dans ce chapitre, nous nous sommes consacrés, dans une première partie, à la
présentation des généralités sur la technologie VoIP, ses apports, son fonctionnement et dans
une deuxième partie, à détailler les différents standards et architectures de la VoIP telles que
H.323, SIP et MGCP.
Dans le deuxième chapitre, nous présenterons les mécanismes qui assurent la qualité de
service pour la VoIP.
- 32 -
Chapitre 2 La qualité de service dans les réseaux IP
Chapitre 2
La qualité de service dans les réseaux IP
I. Introduction
Les réseaux de transmission de données ont pour fonction initiale le transport

d’informations numériques entre des ordinateurs distants. Les trois principales utilisations de
l’Internet furent d’abord l’accès distant, le transport de fichiers et la messagerie électronique.
L’avènement du WorldWideWeb qui permet une navigation transparente au travers de
milliards de données stockées à travers le monde, a fait explosé les réseaux et particulièrement
la technologie IP. Aujourd’hui, de nouvelles applications voient le jour et se répandent telles
que la diffusion des applications de commerce électronique (e-business), l’apparition des
applications pair à pair, les applications sensibles au délai telles que la téléphonie IP, la
vidéoconférence et les jeux vidéo interactifs.
Dans ce chapitre, on va évoquer le problème de la qualité de service dans le réseau IP

tout en détaillant les paramètres de performances du réseau afin de fournir un service
meilleur et plus prévisible en terme de : débit, délai de latence, variation de délai ou gigue et
taux de pertes de paquet.
II. Problématique
Les réseaux IP classiques offrent un simple service : le service best effort. Un tel
modèle de service permet aux routeurs d’être sans état et de ne garder aucune information de
grain fin à propos du trafic. L’inconvénient est que, puisqu’il n’y a pas de contrôle
d’admission, le réseau peut être perturbé par des utilisateurs trop gourmands. Comme IP est
un protocole sans connexion, le concept de contrat de trafic n’existe pas. Si le débit avec
lequel le trafic est dirigé sur les interfaces dépasse la vitesse avec laquelle ces mêmes
interfaces sont capables d’acheminer le trafic vers l’aval, des congestions peuvent se produire.
- 33 -
Le trafic en excès est placé dans les files d’attente des dispositifs physiques jusqu’à
débordement de ces files.
L’utilisation du réseau IP pour transmettre la voix humaine nécessite des performances

respectables ainsi qu’une grande stabilité. Une conversation téléphonique est gravement
perturbée par d’éventuels retards ou coupures à cause de congestion généralement. Il faut
donc veiller à ce que le flot soit le plus continu possible et que les variations restent faibles.
III. La qualité de service « QoS »
III.1 Définition
La qualité de service est un ensemble de caractéristiques de performance de service qui

sont perçues et exprimées par l'utilisateur. Elle se manifeste par des paramètres pouvant
prendre des valeurs qualitatives, c'est à dire qui ne peuvent pas être mesurées directement
mais perceptibles par l'utilisateur ou bien se traduit par des valeurs quantitatives qui sont
directement observées et mesurées aux points d'accès.
Il est intéressant de noter qu'on ne parle de la qualité de service que s'il y a une
dégradation de la performance d'un réseau.
III.2 Paramètres de qualité de service
III.2.1 Débit
Le débit binaire ou par abus de langage, la bande passante, entre deux systèmes
communicants est le nombre de bits que le réseau est capable d’accepter ou de délivrer par
unité de temps. C’est le taux de transfert maximum pouvant être maintenu entre deux points.
Le débit utile dépend du niveau auquel on se place dans la hiérarchie protocolaire. Par
exemple, la bande passante d’un lien réseau représente la capacité de transport d’un lien
réseau, mesurée en bits par seconde, dans laquelle les données n’incluent pas les bits
nécessaires pour les entêtes de niveau 2. Lorsque l’on se place à niveau supérieur à la couche
réseau, on considère la capacité du lien (throughput) qui correspond au volume effectif de
données application transmis. La capacité utile du lien (goodput) est égale au nombre total de
bits issus de l’application et correctement transmis par unité de temps. Par exemple pour un
flux TCP, on ne comptabilise que les bons paquets reçus et on retire des statistiques les
- 34 -
paquets retransmis. C’est cette capacité utile qui est le paramètre pertinent pour l’application.
Comme il existe différentes implémentations du protocole TCP pour acheminer l’information,
cette métrique est empirique et délicate à manipuler. L’IPPM (IP Performance Supervision) a
défini un cadre pour la mesure de cette capacité de transport (Bulk Transport Capacity (BTC),
définie par la formule BTC = V/T où V est le volume de données reçues et T le temps écoulé.
III.2.2 Délai de latence
Il est dit aussi temps de réponse. Il s'agit du temps d’attente pour mesurer le temps
écoulé pour la transmission de la voix.
La maîtrise du délai de transmission est un élément essentiel pour bénéficier d'un

véritable mode conversationnel et minimiser la perception d'écho.
Or la durée de traversée d'un réseau IP dépend de nombreux facteurs:
• Le débit de transmission sur chaque lien ;

• Le nombre d’éléments réseaux traverses.
Le délai de transport est la durée passée à traverser les routeurs, les commutateurs et les
autres composants du réseau. Le temps de traversée de chaque élément est fonction de la
puissance et la charge de ce dernier, du temps de mise en file d'attente des paquets, et du
temps d'accès en sortie de l’élément. L’ordre de grandeur est des dizaines de millisecondes.
Le délai de propagation de l'information, est généralement très faible par rapport aux
autres composantes du délai de transit. Il est de l’ordre de quelques millisecondes. Ce temps
peut être non négligeable si on communique à l'opposé de la terre.
Le délai d’échantillonnage est la durée de numérisation de la voix à l’émission puis de

conversion en signal voix à la réception. Ce temps dépend du type de codec choisi et varie de
quelques millisecondes avec le codec G.711 (échantillonnage 64 kbps) à plus de 50 ms en
G.723 (échantillonnage 6,3 ou 5,3 kbps). C’est une des raisons pour laquelle le choix du
codec impacte le score MOS d’appréciation de la clarté de la voix, indépendamment des
autres caractéristiques de l’infrastructure.
Le délai des buffers de gigue est le retard introduit à la réception en vue de lisser la
variation de temps de transit, et donc de réduire la gigue de phase. L’ordre de grandeur est de
- 35 -
quelques ms. Les éléments d’infrastructure, notamment les routeurs, peuvent également
mettre en œuvre des buffers de gigue.
Les chiffres suivants (tirés de la recommandation UIT-T G114) sont donnés à titre
indicatif pour préciser les classes de qualité et d'interactivité en fonction du retard de
transmission dans une conversation téléphonique. Ces chiffres concernent le délai total de
traitement, et pas uniquement le temps de transmission de l'information sur le réseau.
Tableau 2.1 : Classes de service
On déduit alors que:
Délai de latence = délai d’échantillonnage+délai de propagation+délai de transport+ délai

des buffers de gigue
III.2.3 Gigue
La gigue est la variance du délai de transmission. En fait, elle mesure la variation

temporelle entre le moment où deux paquets auraient dû arriver et le moment de leur arrivée
effective. Cette irrégularité d'arrivée des paquets est due aux raisons suivants: l'encapsulation
des paquets IP dans les protocoles supportés, la charge du réseau à un instant donné, la
variation des chemins empruntés dans le réseau, etc…
Pour le cas de la VoIP, les paquets contenant des échantillons de voix ne vont pas
traverser le réseau à la même vitesse ce qui va causer la gigue et donc une déformation de la
voix.
La dégradation de la qualité de service due à la présence de gigue, se traduit en fait, par

une combinaison des deux facteurs qui sont le délai et la perte de paquets; puisque d'une part
on introduit un délai supplémentaire de traitement (buffer de gigue) lorsque l'on décide
- 36 -
d'attendre les paquets qui arrivent en retard, et que d'autre part on finit tout de même par jeter
certains paquets ayant un retard qui dépasse le délai maximum autorisé par le buffer. La
valeur de la gigue va de quelques ms à quelques dizaines de ms.
III.2.4 Taux de perte de paquets
Lorsque les buffers des différents éléments réseaux IP sont congestionnés, ils essaient
automatiquement de libérer de la bande passante en se débarrassant d'une certaine proportion
des paquets entrants, en fonction de seuils prédéfinis. Cela permet également d'envoyer un
signal implicite aux terminaux TCP qui diminuent d'autant leur débit au vu des acquittements
négatifs émis par le destinataire qui ne reçoit plus les paquets.
Le taux de pertes = nombre de paquets non arrivés / le nombre total de paquets transmis.
Les pertes sur IP sont causées par la congestion, l’instabilité du routage, les défaillances
de liens. La congestion est la cause la plus importante de pertes. La perte de paquet peut se
produire soit par dépassement de capacité des buffers dans les routeurs ou dans les systèmes
d’extrémité soit par violation de délai borné. La distribution des pertes est aussi une métrique
très importante pour les protocoles adaptatifs tels que TCP. Un lien réseau peut être
caractérisé par son taux d’erreur e qui est calculé par intervalle de temps relativement long.
e = nombre de bits reçus erronés / le nombre total de bit reçus
ou
e = nombre de paquet erronés / le nombre total de paquets reçus.
Pour le cas de la VoIP, il est inutile de retransmettre les paquets perdus à cause de
contrainte de temps réel. En effet, il est trop tard de reconstituer les paquets RTP retransmis
mais cette perte n’est pas vraiment grave car cela se traduit par un parasite sur la voix. Le taux
de perte en VoIP est typiquement de quelques pourcents ou dixièmes de pourcent.
On représente dans le tableau 2.2 les seuils de valeurs pour les paramètres critiques et
les conséquences constatées pour le niveau de service de VoIP en codec G.711:
- 37 -
Tableau 2.2 : Seuil des paramètres critiques de VoIP
III.3 Mécanismes de garantie de la qualité de service pour la VoIP
La transmission de la voix humaine à travers un réseau IP nécessite des performances

respectables ainsi qu’une grande stabilité. Une conversation téléphonique est gravement
perturbée par d’éventuels retards ou coupures. Il faut donc veiller à ce que le flot soit le plus
continu possible et que les variations restent faibles [4].
Un réseau IP classique offre un simple service qui est le best effort. La diversité des
services à supporter entraîne également une stratégie de gestion de Qualité de Service
différente. IntServ est une technique qui permet un service garanti en traitant les flux des
paquets en fonction de la demande de la source juste avant de démarrer l'envoi des paquets
utiles et cela par la réservation des ressources. Cependant, ce mécanisme se heurte à un autre
problème, celui du facteur d'échelle. Avec IntServ, chaque routeur dans le réseau doit garder
l'état de chaque flux qui y transite jusqu'au moment où la liaison s'achève. Un deuxième
service qui est permis sur le réseau IP est le service différencié et cela par le mécanisme
DiffServ. Ce dernier permet de différencier les classes au niveau de chaque routeur. Il résout
le problème du facteur d'échelle de IntServ en définissant un nombre limité de comportement
PHB (Per Hop Behaviour) au niveau de chaque noeud. Le MPLS est aussi un mécanisme de
qualité de service au niveau des réseaux fédérateurs et permettant des applications temps réel
parce qu'il permet une optimisation de trafic et délai d'acheminement plus court.
Cette partie présente plus en détails les mécanismes IntServ (INTegrated SERVices),
DiffServ (Differenciated Services) et finalement le MPLS (Multi-Protocol Label Switching).
III.3.1 Service Best effort
Les réseaux IP classiques offrent un simple service : le service best effort. Un tel
modèle de service permet aux routeurs d’être sans état et de ne garder aucune information à
propos du trafic. L’architecture Internet est donc basée sur le concept que tous les états relatifs
- 38 -
à un flux doivent être dans le système d’extrémité. Cette propriété confère au système global
une grande robustesse. En fournissant un modèle de service minimaliste, l’Internet est
extensible en taille et en hétérogénéité des applications et des technologies. Ensemble, elles
sont les deux raisons techniques majeures de son succès. Par ailleurs, l’utilisation de la couche
réseau est libre de toute tarification puisque les mêmes ressources sont disponibles pour tous
les utilisateurs. L’inconvénient est que, puisqu’il n’y a pas de contrôle d’admission, le réseau
peut être perturbé par des utilisateurs trop gourmands. Comme IP est un protocole sans
connexion, le concept de contrat de trafic n’existe pas. Si le débit avec lequel le trafic est
dirigé sur les interfaces dépasse la vitesse avec laquelle ces mêmes interfaces sont capables
d’acheminer le trafic vers l’aval, des congestions peuvent se produire. Le trafic en excès est
placé dans les files d’attente des dispositifs physiques jusqu’à débordement de ces files.
Ainsi, les applications peuvent faire l’expérience de délais variables ou de pertes de

paquets. Les congestions peuvent entraîner des pertes transitoires ou bien des pertes de longue
durée. Le protocole d’extrémité TCP a été conçu pour assurer la fiabilité et la retransmission
si nécessaire. Par ailleurs, comme le réseau n’effectue pas contrôle de congestion, cette
fonction doit impérativement être assurée par les extrémités.
III.3.2 Services garantis (IntServ)
II.3.2.1 Présentation de IntServ
Le modèle IntServ a marqué historiquement, en 1994, la volonté de l'IETF de définir

une architecture capable de prendre en charge la qualité de service en temps réel et le contrôle
de partage de la bande passante sur les liens réseau [5].
IntServ se repose sur deux principes fondamentaux tels que le contrôle d'admission et le
mécanisme de réservation de ressources.
En effet, le réseau doit être contrôlé et soumis à des mécanismes de contrôle

d’admission. Ce mécanisme détermine si un routeur ou un hôte, est capable de répondre à une
nouvelle demande de QoS, sans gêner les demandes qui ont été déjà accordées. Le contrôle
d’admission, est invoqué dans chaque noeud afin de prendre la décision d'accepter ou de
refuser une demande de service temps réel le long du chemin entre les utilisateurs finaux.
Afin de pouvoir garantir que la QoS demandée est bien présente, l'on confie au contrôle
d’admission, d'autres tâches, comme l'authentification de ceux qui effectuent des réservations
- 39 -
ainsi que d'établir des rapports concernant ce qui a été fait, qui a demandé quelle réservation,
cela afin d’obtenir une sorte de feedback de l’utilisation des mécanismes de QoS.
Le deuxième mécanisme c'est la réservation de ressources par un protocole de

signalisation établissant cette réservation (RSVP). Ce dernier est utilisé pour transporter les
messages de réservation de ressources. Ces messages sont ceux qui indiquent aux différents
noeuds, la quantité de bande passante qu'une communication souhaite disposer.
Chaque routeur IntServ est ainsi constitué des éléments suivants :
¾ Le classificateur : afin de pouvoir effectuer un contrôle du trafic, il s'agit de pouvoir

identifier chaque paquet entrant à l’aide de champ descripteur de flux et donc pouvoir
l'associer à une certaine classe; sachant que tous les paquets figurants dans une classe sont
soumis au même traitement. Le classificateur se basant sur le contenu de l'en-tête du
paquet détermine à quelle classe appartient le paquet. Une classe correspond à une
catégorie de flux, par exemple le flux audio, ou encore le flux vidéo. Cela permet
d'attribuer des caractéristiques distinctes à chaque flux.
¾ L'ordonnanceur de paquets : il contrôle l’acheminement vers la prochaine destination,
qui peut être un autre routeur, ou un LAN des différents paquets. Pour cela, il travaille
avec différentes files d'attente, ainsi que d'autres mécanismes comme par exemple les
timers. Il doit être implémenté à l'endroit où les paquets sont mis en files d'attente, cela
correspond souvent à l'interface de sortie et donc au protocole de niveau liaison de
données.
¾ Le contrôle d'admission : il implémente l'algorithme qui détermine si un routeur ou un
hôte, est à même de répondre à une nouvelle demande de QoS, sans entraver les demandes
qui ont été déjà accordées. Le contrôle d'admission, est invoqué dans chaque noeud afin
de prendre la décision d'accepter ou de refuser une demande de service temps réel le long
du chemin entre les utilisateurs finaux.
¾ Le protocole de réservation de ressources : il est nécessaire afin de créer et maintenir un
état décrivant les spécificités d'un flux dans chaque routeur le long du chemin, ainsi que
dans les hosts finaux. De manière à pouvoir indiquer de quel type de ressources a besoin
une application, elle doit spécifier la QoS désirée en utilisant une liste de paramètres.
- 40 -
Hôte Routeur
RSVP
Applica- Processus Processus

tion RSVP RSVP
Routage
Gestion Gestion
d’accès d’accès
Classifi ordonn Contrôle Classifi ordonn Contrôle

cateur anceur d’adm. cateur anceur d’adm.
Données
Figure 2.1 : Modèle IntServ entre un routeur et hôte
III.3.2.2 Le protocole RSVP (ReSerVation Protocol)
RSVP est un protocole qui réserve des flux de données simples, c’est à dire dans une
seule direction. En fait, RSVP traite l’émetteur et le récepteur de manière distincte, cela même
si parfois les deux interagissent sur la même application. RSVP n’est pas un protocole de
transport de données, mais plutôt un protocole de contrôle. RSVP se situe au-dessus de IP,
c’est un protocole qui se charge de contrôler la qualité de l’acheminement des paquets, et non
de « router » les messages. Il consulte la table de routage locale, pour obtenir les routes des
destinations à atteindre.
De manière à pouvoir satisfaire un grand nombre de récepteurs, RSVP rend responsable

le récepteur de demander une configuration spécifique de QoS. A partir de là, une demande de
QoS est acheminée au « processus » local de RSVP. Une fois la demande de QoS connue, le
protocole RSVP achemine cette demande vers tous les noeuds (routeurs et hôtes), en
empruntant le chemin inverse jusqu’à la source. Pendant la phase de réservation et de
configuration, la demande de QoS passe au travers de deux modules différents, que sont
"l’admission control" et "le policy control".
• L’admission control garantit que le noeud a suffisamment de ressources disponibles

pour répondre à la demande de QoS.
• Le policy control détermine si l’utilisateur a les droits pour faire une réservation.
- 41 -
Si ces deux tests sont passés avec succès, les paramètres sont inscrits dans le "packet
classifier" et dans ce qui sert de couche de liaison, afin d’obtenir la QoS demandée. Si l’un de
ces deux tests échoue, le programme RSVP émet un message d’erreur à l’application qui est à
l’origine de la demande.
Du fait que la disposition des topologies d’acheminement est susceptible de changer au

cour du temps, RSVP a prévu cela. En fait RSVP envoie périodiquement des messages de
rafraîchissement, afin de continuer à maintenir les différentes réservations le long du chemin.
En absence de ces messages de rafraîchissement, l’état est automatiquement effacé et les
ressources libérées.
Sept Types de Messages RSVP ont été prévus:
Path : envoyé par la source pour indiquer la liste des routeurs du chemin suivi par les
données.
Resv : demande de réservation.
PathErr : message d'erreur concernant le chemin.
ResvErr : message d'erreur de demande de réservation.
PathTear : indique aux routeurs d'annuler les états concernant la route.
ResvTear : indique aux routeurs d'annuler les états de réservation (fin de session).
ResvConf (optionnel) : message de confirmation envoyé par le routeur au demandeur de la
réservation.
Un message RSVP est constitué d'une en-tête et d'un nombre variable d'objets qui
dépend du type du message.
L'entête est constitué de 64 bits:
Vers Flags Type du Msg Checksum

Send_TTL Réservé Longueur Msg.
Figure 2.2 : Entête RSVP
Vers (4 bits) : version du protocole RSVP (=1);

Flags (4) : non utilisé à ce jour;
Type de Msg (8) : 1 à 7 selon le type ci-dessus;
Checksum (16) : Contrôle d'erreurs;
- 42 -
Send_TTL (8) : valeur du TTL IP à comparer avec le TTL du paquet IP pour savoir s'il y a
des routeurs non-RSVP;
Longueur (16) : longueur du message en octets (en-tête et objets)
RSVP travaille notamment avec les messages PATH et RESV. Le message PATH part
de la source vers la destination et RESV emprunte le chemin inverse. PATH indique les
caractéristiques du trafic, et RESV opère la réservation.
Figure 2.3 : Réservation de ressources
III.3.3 Services différenciés (DiffServ)
III.3.3.1 Présentation
DiffServ est un modèle qui permet de classifier chaque paquet selon son contenu, plus
précisément selon l’information se trouvant dans le champ (Type Of Service sur IPV4, Class
of Service et Flow Label sur IPV6) de la trame IP et d’appliquer un traitement en fonction de
celui-ci. Chaque paquet se verrait donc confier une estampille de couche réseau indiquant
quelle information il transite. Dès son entrée sur un réseau, il lui sera donc accordé des
privilèges de traitement valables sur tout ou partie de celui-ci. Cette méthode permet donc
d’appliquer des concepts de priorité déjà supportés par des appareils de routage dans le cadre
du traitement des files d’attente et de la congestion.
Les critères de classification des paquets doivent refléter les besoins réels de
l’information qu’ils transportent ; il va de soi que le choix d’un degré de priorité n’est pas
arbitraire. Pour ce faire, une petite étude des besoins en bande passante et de la sensibilité des
différents types de données s’impose.
- 43 -
III.3.3.2 Différentiation du trafic
Comme déjà exposé dans les paragraphes précédents, les besoins des différents types
d’information transmis sont très variables. Cependant, il n’est pas possible d’être exhaustifs et
de considérer chaque cas particulier. L’approche se révèlera donc générale et traitera des
types susceptibles de justifier l’existence de la QoS :
¾ La VoIP : justifie à elle seule la notion de qualité de service. L’utilisation du réseau

Internet pour transmettre la voix humaine nécessite des performances respectables ainsi
qu’une grande stabilité. Une conversation téléphonique est gravement perturbée par
d’éventuels retards ou coupures. Il faut donc veiller à ce que le flot soit le plus continu
possible et que les variations restent faibles.
¾ La Vidéo : Les besoins sont ici identiques à la voix sauf que le volume de données est
encore plus important et le besoin en bande passante plus élevé.
¾ Les données usuelles : Celles-ci peuvent être très variables ; il peut s’agir de
téléchargements de gros fichiers, de surf sur des pages web, e-mail, jeux sur Internet,
etc… En principe, ce genre de trafic est le moins gourmand en ressources.
¾ Les données critiques : Certaines informations échangées sur Internet doivent être
considérées avec une toute autre attention ; on pense notamment au commerce en ligne,
opérations bancaires par Internet voire les projets ERP (Enterprise Resource Planning). Le
volume de données est rarement élevé mais le délai d’attente doit être le plus court
possible et la fiabilité irréprochable.
Au vu des types de trafic décrits, voici un tableau récapitulatif mettant en évidence les
différents paramètres dont il faudra tenir compte :
Tableau 2.3 : Critères de classification de types de données transitées
- 44 -
III.3.3.3 Coloration des paquets
Une fois la définition des types de paquets établie, il faut trouver un moyen d’indiquer à
quelle catégorie chaque paquet appartient.
Les trames IPv4 contiennent un champ permettant d’attribuer une estampille destinée à
identifier le type du contenu et par la même occasion de connaître quels privilèges QoS lui
appliquer : Service Type ou mieux connu sous l’abréviation ToS pour Type of Service. Dès
lors qu’une valeur précise est attribuée à ce champ, le paquet est dit « coloré » (l’attribution
de la couleur sera abordée au chapitre suivant).
Figure 2.4 : Champ ToS
Bits 0 à 2 : IP Precedence: Influe sur les mises en file d'attente des messages. La valeur la
plus élevée correspond aux messages les plus prioritaires. En règle générale, ils sont liés aux
messages de gestion d’un réseau.
Bits 3 à 6: Type of Service. Indique quel privilège appliquer à la trame.
Bit 3 : 0 = Délai normal 1 = Délai minimal
Bit 4 : 0 = Début (Throughput) normal 1 = Début (Throughput) maximal
Bit 5 : 0 = Fiabilité normale 1 = Fiabilité maximale
Bit 6 : 0 = Coût normal 1 = Coût minimal
Bit 7 : Toujours à 0 car inutilisé pour l’instant.
Avec IPv6, le champ ToS est devenu « Class of Traffic » et devrait en théorie être
pleinement compatible avec IPv4. Le Class of Traffic est logiquement composé de 8 bits et
reçoit exactement les mêmes caractéristiques que le ToS.
Le champ ToS destiné lors de la création d’IP à améliorer les performances du protocole
n’est pas du tout adapté aux besoins de la QoS ; c’est pourquoi, il fut remplacé par DSCP
(Differentiated Service Code Point Field) de IPv4 et IPv6 :
- 45 -
Figure 2.5 : Champ DSCP dans IPv4 et IPv6
DSCP est codé sur 6 bits et les deux derniers bits sont inutilisés. Chaque DSCP
représente une valeur. Chaque nœud doit utiliser cette valeur pour sélectionner le
comportement (PHB) à appliquer au paquet.
- 46 -
III.3.3.4 Architecture DiffServ
Figure 2.6 : Architecture d'un modèle DiffServ
L'architecture DiffServ définit les principes suivants:
¾ Domain DiffServ (DS Domain) : C'est une zone administrative, avec un ensemble
commun de politiques d'approvisionnement du réseau et de définitions de PHB, équivalent
à un ensemble de nœuds (routeurs) qui possèdent une même définition de services et de
PHB.
¾ Nœuds frontières (DS boundary nodes) : Ce sont les équipements de bordure du
domaine DiffServ. On distingue:
o Les nœuds d'entrée de domaine (DS Ingress Node) : Ce sont des routeurs qui
permettent de classer les trafics dans un niveau de service et qui doivent également
appliquer un comportement approprié (PHB) aux paquets IP en fonction de DSCP.
o Les nœuds de sortie de domaine (DS Egress Node) : Ce sont des routeurs qui
exécute un certain nombre de contrôle de sortie du domaine.
¾ Nœuds intérieurs (DiffServ Interior Nodes) : Ce sont des équipements centraux du
réseau (généralement des routeurs à haute performance de commutation), qui appliquent
un comportement approprié (PHB) aux paquets IP, en fonction de la valeur du DSCP, et
assurent le service de transit sur le réseau.
- 47 -
III.3.3.5 Les PHB (Per Hop Behavior)
Le PHB correspond à la description du comportement de routage d'un routeur, face à un

trafic particulier. La définition du PHB porte sur le contenu du paquet traité (sensibilité aux
délais, gigue), les ressources à disposition (bande passante disponible, taille des tampons)
ainsi que sur les services prioritaires qui restent à définir. En principe, pour éviter de redéfinir
un comportement pour chaque besoin, les PHBs sont regroupés pour offrir des comportements
conditionnés par les degrés de priorités absolus contenus dans le champ DSCP. Un PHB seul
est généralement un cas particulier ou critique.
Les PHB sont mis en œuvre dans les routeurs à l'aide de mécanismes de gestion des
files d'attente (FIFO, Weighted Fair Queing,…) et de régulation de flux. Il existe pour les
PHB standardisés une valeur de DSCP recommandée :
Expedited Forwarding EF : Le PHB EF (traitement accéléré) a pour but de fournir une

garantie de bande passante avec des taux de perte, délai et gigue faibles, soit un service
similaire à une réservation de ressource. Une file d’attente apparaît lorsque le débit d’arrivée
est supérieur au débit de sortie. La création d’un tel service passe par deux étapes:
• Configurer de manière appropriée le débit de sortie alloué dans les noeuds.
• Conditionner le trafic à l'entrée du domaine de façon que le débit d'arrivée à chaque

noeud soit inférieur au débit de sortie.
Le DSCP correspondant au service EF est 101110 en binaire, ce qui donne 46 en décimal.

Tout trafic à l’intérieur du réseau DiffServ possédant une valeur 46 dans le champ DSCP doit
être considéré comme un trafic prioritaire nécessitant un traitement EF pour autant qu’il
réponde aux critères de vérification. Le trafic entrant doit être vérifié aux noeuds d’entrée
(ingress node) et coloré pour répondre aux spécifications du nuage DiffServ.
Pour répondre aux exigences de la VoIP, l’utilisation d’une priorité stricte comme vue
précédemment correspond pleinement à un traitement EF.
Assured Forwarding AF : Ce sont un groupe qui permet de distribuer le trafic en quatre

classes. Il s’agit de quatre classes de « traitement assuré » comprenant trois niveaux de
priorité spatiale (drop precedence). Dans un noeud donné, le niveau d'assurance de traitement
d'un paquet dépend de la bande passante allouée à la classe, de la charge actuelle de la classe
- 48 -
et de la priorité spatiale du paquet. La nature de la différence entre les classes n'est pas
spécifiée, mais le critère général est le plus souvent les délais de livraison.
Un trafic peut par exemple être divisé en trois classes AF qui correspondent aux différents
niveaux de priorité. A l’intérieur de chaque classe, un paquet IP est marqué avec l’un des
différents niveaux de priorité spatiale (drop precedence).
L’une des particularités essentielles d’AF est de pouvoir rejeter les paquets de façon «
intelligente » en cas de congestion. Si nous prenons par exemple la classe AF1 qui comprend
3 niveaux de « drop precedence » différents : AF11, AF12, AF13. Les paquets seront rejetés
en premier dans la classe AF13, puis AF12 et enfin AF11. On peut ainsi favoriser certains
flux uniquement en cas de congestion et prévenir la perte de paquets plus importants que
d’autres avec une probabilité de rejet plus forte. Les CodePoints AF standardisés sont les
suivants :
Tableau 2.4: PHBs AF standardisés
III.3.4 Optimisation de trafic: MPLS (Multi-Protocol Label Switching)
III.3.4.1 Présentation
Il s'agit d'un nouveau standard de l'IETF permettant de simplifier l’administration d’un

tel coeur de réseau en ajoutant de nouvelles fonctionnalités particulièrement intéressantes
pour la gestion de la qualité de service. Dans le même esprit que l’architecture DiffServ,
MPLS permet de réduire le coût des traitements associés au relayage des paquets en les
reportant à la périphérie du réseau et en en réduisant la fréquence. Il apporte aussi un
mécanisme de routage hiérarchique efficace, c’est-à-dire des tunnels permettant de gérer les
réseaux privés virtuels (VPN).
Il permet également de pouvoir acheminer tous les types d'applications, données, audio,
vidéo. Ainsi que de différencier le trafic selon les classes de service employées.
- 49 -
L’architecture MPLS est constitué de :
¾ Routeur d'extrémité (LER : Label Edge Router) : situé à la frontière de réseau. Il

responsable d’insérer et de retirer le Label à un paquet au moment de son entrée et de sa
sortie.
¾ Routeur (commutateur) central (LSR : Label Switcher Router) : responsable de la
commutation des paquets en fonction du Label. Dans le cœur de réseau, les LSR lisent
uniquement les labels, et non les adresses des protocoles de niveau supérieur c à d les
adresses IP.
Figure 2.7 : Modèle MPLS
III.3.4.2 Principe de fonctionnement de MPLS
Le principe de MPLS est d’attribuer un label (une étiquette) à chaque paquet lorsqu’il
entre dans le réseau. Ce label est attribué en fonction de la classe de relayage (FEC :
Forwarding Equivalent Classe) à laquelle appartient le paquet. La définition de ces classes
dépend de l’opérateur du réseau, généralement une classe correspond à une entrée de la table
de routage ou à un routeur de sortie du réseau. Le routeur à l'entrée décide de la FEC à
laquelle appartient un paquet en fonction des informations contenues dans son en-tête (adresse
destination, classe de service DiffServ, appartenance à un VPN, ...) et éventuellement de la
connaissance qu’il a de la topologie du réseau. Une fois à l’intérieur du réseau les paquets ne
sont plus traités qu’en fonction du label qui leur a été associé et l’en-tête IP n’est plus
- 50 -
consulté. Ce label décide donc dans chaque routeur : du prochain routeur, du comportement
DiffServ et de l’utilisation éventuelle des ressources réservées.
Les tables de commutation qui sont interrogées pour chaque paquet dans chaque routeur
peuvent rester de taille réduite puisque le nombre d’étiquettes ne dépend plus du nombre de
préfixes annoncés par les opérateurs mais du nombre de routeurs de sortie du réseau. MPLS
ne remplace pas le routage IP mais utilise les informations que celui-ci calcule pour établir
des chemins entre les routeurs d’entrée et les routeurs de sortie. Les chemins sont établis
grâce à une signalisation explicite ou implicite. Le protocole de distribution des labels LDP se
charge de la signalisation implicite en établissant automatiquement un chemin pour chaque
préfixe contenu dans les tables de routage IP. Les tables de routage ne servent donc plus à
relayer les paquets mais à construire les chemins. La commutation de label est plus efficace
que le routage IP classique mais elle se fait sur les mêmes bases.
IV. Les compléments de la QoS pour la VoIP
Comme le réseau IP n'est pas synchrone, il a fallu définir de nouveaux éléments

assurant la possibilité de transfert des flux multimédia. Les éléments nécessaires à la mise en
œuvre d'une application temps réel comme la VoIP sont la garantie de la réservation de bande
passante et essentiellement la synchronisation des paquets grâce de nouveaux protocoles de
transport qui tiennent compte des besoins d'horodatage des flux audio afin qu'ils puissent être
reconstitués à l'arrivée avec un contrôle des sources audio.
Dans ce paragraphe, on va détailler les protocoles de synchronisation RTP (Real Time

Protocol) et RTCP (Real Time Control Protocol).
IV.1 RTP (Real Time Protocol)
IV.1.1 Présentation de RTP
RTP développé par l'IETF permet le transport des données « temps réel » tels que les
flux audio et vidéo. Il est basé sur les protocoles IP/UDP. UDP est préféré à TCP pour les
transmissions « temps réel » ; en effet la priorité est donnée à la rapidité plus qu’à qualité de
transmission. RTP fournit des services tels que le séquencement temporel, la détection des
pertes, la sécurité et l’identification du contenu. Ce protocole a été défini pour diffuser aussi
bien en mode multicast qu’en mode unicast.
- 51 -
RTP est utilisé en association avec le protocole de contrôle RTCP (Real Time Control
Protocol) qui fournit les informations nécessaires sur la qualité de transmission des données et
sur les participants aux sessions multimédia.
Cependant, RTP ne fournit pas de lui-même les mécanismes nécessaires à la gestion des
informations « temps réel ». Pour cela, les couches protocolaires inférieures doivent mettre en
oeuvre des solutions nécessaires à ces données sensibles au délai.
IV.1.2 Fonctionnement de RTP (Real time Transport Protocol)
IP est un réseau partagé en mode paquet. Les paquets envoyés sur un réseau IP ont une
gigue et un délai de transmission imprévisibles. Cependant les applications multimédia
requièrent des caractéristiques appropriées à la transmission et la gestion des applications
dites « temps réel ». RTP fournit, pour chaque paquet, un marquage temporel, un numéro de
séquence et d’autres paramètres permettant d’offrir un transport, de bout en bout, des données
« temps réel » sur un réseau en mode paquet.
IV.1.3 Entête RTP
L'entête d'un paquet RTP est constituée de 16 octets. Cette entête précède le "payload"
qui représente les données utiles.
0 4 8 16 31
Ver P X CC M Payload Type Sequence number
Timestamp
Synchronisation source (SSRC) identifier
Contributing source (CSRC) identifiers
Figure 2.8 : Paquet RTP
Les douze premiers octets figurent dans chaque TPDU RTP alors que les identificateurs
CSRC ne sont présents que lorsque la TPDU provient d’un mélangeur (Mélange des flots
vidéos individuels pour simuler une image de groupe composite: n flots deviennent un flot).
Les champs ont la signification suivante :
- 52 -
Champ V : Ce champ, codé sur 2 bits, permet d'indiquer la version de RTP. Actuellement,
V=2.
Champ P : Ce bit indique, si il est à 1, que les données possèdent une partie de bourrage.
Champ X : Ce bit spécifie, si il est à 1, que l'entête est suivie d'une entête supplémentaire.
Champ CC : Ce champ, codé sur 4 bits, représente le nombre de CSRC qui suit l'entête.
Champ M : Ce bit, lorsqu'il est à 1, définie que l'interprétation de la marque est par un profil
d'application.
Champ PT : Basé sur 7 bits, ce champ identifie le type du payload (audio, vidéo, image,
texte, html, etc.).
Champ Numéro de séquence : Ce champ, d'une taille de 2 octets, représente le numéro
d'ordre d'émission des paquets. Sa valeur initiale est aléatoire et il s'incrémente de 1 à chaque
paquet envoyé, il peut servir à détecter des paquets perdus.
Champ Timestamp ou aussi horodate : représente l’instant d’échantillonnage du premier
octet de données de la TPDU RTP, lu d’une horloge dont la fréquence dépend du type de la
charge utile (voir tableau 2.5). Dans le cas d’un flux audio PCMA, par exemple, l’horloge
génère un top chaque fois qu’un échantillon est prélevé (8000 Hz). Si le flux audio est
transmis dans des TPDUs RTP de 160 octets de données, le champ horodate sera incrémenté
de 160 à chaque fois. Comme pour le numéro de séquence, la valeur initiale de l’horodate est
choisie aléatoirement.
Tableau 2.5 : Codecs supportés par RTP
Champ SSRC : Basé sur 4 octets, ce champ identifie de manière unique la source de
synchronisation, sa valeur est choisie de manières aléatoire par l'application.
- 53 -
Champ CSRC : Ce champ, sur 4 octets, identifie les sources de contribution par une liste des
participants ayant leur contribution (audio, vidéo) aux données du paquet.
IV.2 RTCP (Real Time Control Protocol)
IV.2.1 Présentation de RTCP
Le protocole RTCP est fondé sur la transmission périodique de paquets de contrôle à

tous les participants d’une session. C’est le protocole UDP qui permet le multiplexage des
paquets de données RTP et des paquets de contrôle RTCP. Le protocole RTP utilise le
protocole RTCP qui transporte les informations supplémentaires suivantes pour la gestion de
la session :
Les récepteurs utilisent RTCP pour renvoyer vers les émetteurs un rapport sur la QoS.
Ces rapports comprennent le nombre de paquets perdus, le paramètre indiquant la variance
d’une distribution ou bien la gigue et le délai aller-retour. Ces informations permettent à la
source de s’adapter, par exemple, de modifier le niveau de compression pour maintenir une
QoS.
RTCP permet également une synchronisation supplémentaire entre les médias. En fait,
les applications multimédias sont souvent transportées par des flots distincts. Par exemple, la
voix, l’image ou même des applications numérisées sur plusieurs niveaux hiérarchiques
peuvent voir les flots gérés suivre des chemins différents.
Les paquets RTCP permettent ainsi l’identification puisqu’ils contiennent des

informations d’adresses, comme l’adresse d’un message électronique, un numéro de
téléphone ou le nom d’un participant à une conférence téléphonique.
Le protocole RTCP demande aux participants de la session d’envoyer périodiquement

les informations citées ci-dessus. La périodicité est calculée en fonction du nombre de
participants de l’application. On peut dire que les paquets RTP ne transportent que les
données des utilisateurs. Tandis que les paquets RTCP ne transportent en temps réel, que de la
supervision. Le tableau suivant représente les paquets de supervision :
Type de paquet de Nom du paquet Rôles

supervision
200 rapport de l’émetteur (SR : Sender Transmet les statistiques
- 54 -
Report) d’émission et de réception des

stations émettrices actives.
201 rapport du récepteur (RR : Receiver Transmet les statistiques de
Report) réception des stations qui ne
sont pas des émetteurs actifs.
202 description de la source (SDES : Transmet la description de la
Source DEScriptor) source.
203 Au revoir Indique la fin de participation.
204 Application spécifique Sert aux fonctions propres à
l’application
Tableau 2.6 : différents types de paquets RTCP
Ces différents paquets de supervision fournissent aux nœuds du réseau les instructions
nécessaires à un meilleur contrôle des applications temps réel.
IV.2.2 Les paquets RTCP SR/RR
L'entête RTCP SR/RR est constituée de 8 octets:
V P RC (5) PT Length
SSRC of sender
NTP timestamp (most significant word)
Seulement NTP timestamp (least significant word)

pour SR RTP timestamp
Sender’s packet count
Sender’s octet count
SSRC # 1 (SSRC of first source)
Fraction lost Cumulative number of packet lost
Bloc de
rapport Highest sequence number received
Inter-arrival jitter
Last SR (LSR)
Delay since last SR (DLSR)
Figure 2.9 : Paquet RTCP SR/RR
Les champs ont la signification suivante :
V et P désignent les mêmes significations que celles de RTP.
- 55 -
Champ compte de rapports de réception RC : Ce champ, basé sur 5 bits, indique le nombre
de blocs de rapport de réception contenus en ce paquet. Une valeur de zéro est valide.
Champ type de TPDU (PT) : Ce champ, codé sur 1 octet, est fixé à 200 pour identifier ce
datagramme RTCP comme Sender Report ou bien 201 pour rapport d’émetteur.
Champ Longueur : Ce champ de 2 octets, représente la longueur de ce paquet RTCP
incluant l'entête et le bourrage.
Champ SSRC : Basé sur 4 octets, ce champ, représente l'identification de la source pour le
créateur de ce paquet Sender Report.
Le champ fraction perdue : exprime sur un octet, en représentation en virgule fixe, la
fraction des TPDUs en provenance de la source SSRC qui ont été perdues depuis l’envoi du
SR ou RR précédent. La virgule est placée au bord gauche du champ (la valeur du champ
correspond à la fraction multipliée par 256).
Le champ nombre total de TPDUs perdues : Basé sur 3 octets et représente le nombre de
TPDUs en provenance de la source SSRC qui ont été perdues depuis le début de la réception.
Le nombre de TPDUs prévues est calculé par soustraction des numéros de séquence contenus
dans la dernière TPDU reçue et dans la TPDU initiale. Ce champ peut être négatif car les
TPDU dédoublées sont comptées deux fois.
Le champ plus grand numéro de séquence reçu étendu : Basé sur 4 octets, est formé du
plus grand numéro de séquence RTP reçu (16 bits poids faible) et d’un nombre calculé de
cycles des numéros de séquence (16 bits poids fort).
Le champ nombre total de TPDUs perdues : représente sur 3 octets le nombre de TPDUs
en provenance de la source SSRC qui ont été perdues depuis le début de la réception. Le
nombre de TPDUs prévues est calculé par soustraction des numéros de séquence contenus
dans la dernière TPDU reçue et dans la TPDU initiale. Ce champ peut être négatif car les
TPDU dédoublées sont comptées deux fois.
Le champ plus grand numéro de séquence reçu étendu : Basé sur 4 octets, est formé du
plus grand numéro de séquence RTP reçu (16 bits poids faible) et d’un nombre calculé de
cycles des numéros de séquence (16 bits poids fort).
Le champ gigue inter arrivée : contient sur 4 octets une évaluation de la variance statistique
du temps inter-arrivée des TPDUs RTP reçues. Cette variance est calculée à partir du temps
absolu de réception des TPDUs dans le récepteur et des horodates des TPDU RTP reçues.
Le champ horodate du dernier SR (LSR, last SR timestamp) : contient les 4 octets du
milieu de l’horodate NTP du dernier rapport d’émetteur reçu de la source SSRC. ce champ
- 56 -
permet, en conjonction avec le champ suivant, de calculer dans l’émetteur le temps de

transmission aller-retour émetteur-récepteur.
Le champ délai depuis le dernier SR (DLSR, Delay since LAST SR) : Basé sur 4 octets,
contient le délai écoulé depuis la réception du dernier rapport d’émetteur de la source SSRC.
IV.2.3 Les paquets RTCP SDES
Le paquet RTCP SDES a le format suivant :
V P SC PT=SDES=202 Length
(5 bits)
SSRC/CSRC # 1
SDES info
SSRC/CSRC # 2
SDES info
Figure 2.10 : Paquet RTCP SDES
Les champs de la TPDU de description de source sont les suivants :

Les champs V, P, PT et longueur sont identiques à ceux des TPDUs RR et SR, à cette
différence près que le champ PT contient la valeur 202 (SDES).
Le champ compte de la source (SC, Source Count, 5 bits) indique le nombre d’éléments
SSRC/CSRC figurant dans la TPDU.
Chaque élément comporte l’identificateur de la source de synchronisation, respectivement de

contribution (SSRC/CSRC) et une liste d’éléments SDES tels que le nom de la machine,
e_mail, etc.
V. Conclusion
Dans ce chapitre, nous avons présenté les paramètres de qualité de service pour un
réseau IP ainsi que les différents mécanismes en introduisant les trois principaux protocoles
de QoS sur les réseaux IP, à savoir IntServ, DiffServ et MPLS.
Enfin, nous avons défini les protocoles complément à un réseau IP supportant la VoIP
et garantissant la synchronisation pour le transport des flux temps réel qui sont RTP, RTCP.
- 57 -
Le dernier chapitre qui est le suivant présentera la réalisation de la plateforme qui

supporte les flux VoIP en implémentant à chaque étape un mécanisme QoS (IntServ et
DiffServ) ainsi que l’évaluation de l’impact de ces mécanismes sur les performances du
réseau.
- 58 -
Chapitre 3 Mesure de QoS dans les applications VoIP
Chapitre 3
Mesure de QoS dans les applications VoIP
I. Introduction
Afin de pouvoir assurer une bonne exploitation de la VoIP, les opérateurs doivent
fournir un niveau de qualité de service pour éviter la dégradation de la performance de la
transmission de la voix qui est particulièrement sensible au délai de transfert des données et à
la perte de paquets. La conversation peut être aussi perturbée par l’irrégularité des inter-
arrivées des paquets transportant la voix. Des mécanismes de qualité de services, déjà
détaillés dans le chapitre précédent, sont donc indispensables dans le réseau IP.
Le but de ce chapitre est de mesurer les paramètres de qualité de services sur des
communications VoIP en implémentant différents mécanismes introduisant la qualité.
II. Stratégie de mesure
Deux types de communications VoIP sont mesurés :

Communication sur un même réseau LAN ;
Communication entre deux réseaux LAN distincts empruntant un réseau WAN.

Les mécanismes de qualités de service implémentés dans la plate-forme et exploités un
par un sont : Bestffort, IntServ et DiffServ.
II.1 Plateforme de mesure
La plateforme de mesure réalisée pour effectuer les mesures est de type « Full IP »
utilisant le protocole H.323 (voir figure ….).
- 59 -
HostA H.323 HostB H.323

HostC H.323
Réseau IP LA N
LA N
RouteurA RouteurB RouteurC
Cas d’une Cas d’une

Légende : communication communication
L AN WAN
Figure 3.1 : Plate-forme de mesure
Les moyens matériels et logiciels utilisés sont les suivants :
• Routeurs : il s’agit de trois routeurs Cisco 2600 équipés de l’IOS 12.1(3). Par cet
IOS, on peut implémenter seulement IntServ où DiffServ. Mpls et IPv6 ne sont pas
supportés.
• Hosts : des postes Windows 2000 où XP.
• Codec : G.711 qui code la voix sur 64 kb/s.
• Analyseurs : Ethereal comme analyseur de protocole et DUmeter pour la
visualisation de la bande passante.
• Générateur de trafic : TrafficEmulator. Ce générateur utilisable sous Windows
permet de générer un trafic UDP ou TCP, en précisant certaines propriétés tels que
le nombre de paquets, les ports des protocoles…
• Connectique : Câbles droits avec RG45 pour les interfaces Ethernet et câble série
classique DCE DTE entre les routeurs.
• Terminal H323 : il s’agit d’un ordinateur équipé d’un logiciel supportant le
standard H.323 « Netmeeting » doté d’un microphone et d’un haut parleur
- 60 -
II.2 Principes de mesure
Le protocole de routage au niveau des trois routeurs est le Open Shortest Path First
(OSPF). Il permet de diviser le réseau en zones engendrant ainsi une diminution du trafic au
niveau de la mise à jour des tables de routage et du traitement CPU des routeurs.
Afin d’évaluer les mécanismes de qualité de service lors des communications VoIP, on
s’est basé sur deux méthodes de mesure.
Première méthodes, dite « active »

Elle consiste à injecter du trafic connu sur le réseau et contrôler les paquets retournés.
Pour simuler ce scénario, on utilise le générateur de trafic TrafficEmulator.
Deuxième méthode, dite « passive »

Elle consiste à analyser les paquets reçus à l’aide de Ethereal et DUmeter. Cette
approche nécessite le lancement de l’application sur laquelle on souhaite appliquer la QoS.
Ces deux méthodes permettent de mesurer les paramètres de qualité de service, à savoir :
le temps de latence, la gigue, le débit et la perte de paquets.
Pour rendre le réseau surchargé, on a été amener à injecter des flux de données de
diverses natures (UDP, TCP, http, FTP…). Il est à signaler que les mécanismes de QoS ne
peuvent être visibles que lorsque le réseau commence à être surchargé.
Etant donné qu’il s’agit de communication voix, ont s’est basé dans nos mesures
essentiellement sur le protocole RTP (Real Time Protocol), un exemple du trafic capturé sur
Ethereal est donné dans la figure suivante :
Figure 3.2 : Capture du protocole RTP par Ethereal
- 61 -
La figure suivante présente le processus d’encapsulation des paquets voix par les entêtes,
RTP, UDP et IP :
Figure 3.3 : Encapsulation des données voix
La voix compressée est donc encapsulée par l’entête RTP, UDP, IP et enfin Ethernet.
III. Evaluation des performances des mécanismes de la qualité de

service
Les tests ont été effectués sur deux types de réseaux : LAN et WAN et à chaque étape,
on implémente un mécanisme de QoS sur les routeurs (Best-effort, IntServ et DiffServ).
III.1 Communication dans un réseau LAN
III.1.1 Conditions normales sans génération de trafic
Sur le plan technique, le LAN se caractérise par des débits binaires très élevés, de 10 à
100 Mbits/s pour un réseau Ethernet, avec un taux d’erreur très faible dû aux distances faibles
et à la traversée de peu d’équipements. L’interface LAN qu’on a utilisé dans nos tests est de
10 Mb/s.
L’utilisation de la VoIP dans un réseau LAN ne produit pas facilement une situation de
crise surtout que la majorité des applications VoIP tel que le Netmeeting utilise par défaut le
protocole de réservation RSVP. La congestion se produit quand la bande passante allouée
n’est pas suffisante, or une communication voix à travers un réseau IP ne nécessite qu’un
débit de 64 kb/s (pour le codec G.711).
- 62 -
La simulation d’une communication VoIP durant 10 mn sur notre réseau local donne une
qualité audio nette sans coupure ni retard et un temps de latence pas très élevé. Les valeurs
mesurées sont :
¾ La latence a atteint au maximum 30.1 ms ;

¾ La gigue est restée faible 0.01 (gigue = variation entre les valeurs de latence) ;
¾ Le flux Netmeeting a pris ce dont il a besoin en bande passante, soit 76.16 kb/s.
III.1.2 Avec génération de trafic
La génération d’un flux de trafic UDP ou TCP avec un débit inférieur à 10 Mbits/s, débit
du réseau local, n’affecte pas la qualité de la communication VoIP et le taux de perte reste
égal à 0.
Or, quand on commence à générer un flux supérieur à 10 Mbits/s, le flux vocal conserve
toujours sa part dans la bande passante puisque Netmeeting utilise le RSVP pour l’allocation
des ressources, mais cela engendre la perte d’autres types de flux tels que UDP et TCP.
III.2 Communication entre deux réseaux locaux
C’est dans ce cas de figure, qu’on va exploiter les mécanismes Best-effort, IntServ et
DiffServ.
La conversation Netmeeting se fait entre deux PC de deux réseaux locaux distincts.

Toutes les communications entre ces deux PCs vont devoir transiter par le biais d'une
interface Ethernet à 10 Mbits/s, puis passer du premier routeur au troisième routeur au travers
d'une interface série à 256 kb/s et sortir du deuxième routeur sur une interface Ethernet à 10
Mbits/s pour arriver vers l'autre PC.
Le point central dans cette plate-forme, est l’interface de sortie du routeur d’extrémité
vers la ligne série où se crée le goulot d'étranglement, c'est à dire le passage obligé qui est trop
étroit pour tout laisser passer, par conséquent l’administrateur du réseau doit donc mettre en
place le mécanisme afin de prioriser les flux de passage, comme la voix.
La ligne série est fixée dans nos tests à 256 kb/s. Or, par défaut elle est de 1544 kb/s et
pour la limiter, on a été amené à taper sous l’interface série « bandwidth 256 ».
Durant les tests, l’état des files d’attentes et l’activité des concepts QoS sont visualisés
depuis les routeurs.
- 63 -
III.2.1 Les modèles Best Effort
III.2.1.1 Trafic sans surcharge
Best effort présente deux modèles de traitement de la file d’attente, FIFO et WFQ.
Modèle Best effort avec FIFO « First In First Out »

La file d’attente FIFO est la file d’attente activée par défaut en cas d’absence de
mécanisme de QoS.
Le trafic Netmeeting mesuré dans ce cas présente une bonne qualité voix et ne présente
aucune perte de paquets. Les valeurs mesurées sont :
¾ La latence égale à 25 ms ;
¾ La gigue égale à 10 ms ;
¾ Le débit a atteint 78 kb/s ;
¾ A l’aide de Traffic Emulator, on a simulé un flux de paquet TCP de 200 kb/s. En
analysant les protocoles par le logiciel Ethereal, le taux de perte de paquets voix
enregistré est égal à 0%, également celui du flux TCP. Cela s’explique par la
fiabilité de TCP et son adaptation à la congestion. Quand aux trafics UDP,
l’émetteur envoi ce qu’on lui indique indépendamment de la congestion et
engendre une perte de paquets.
Par ailleurs, à l’examen des paramètres de QoS pour la voix, les valeurs mesurées sont :
¾ La latence est presque égale à celle du cas de trafic sans surcharge, soit 25.88ms ;
¾ La gigue est de 13 ms ;
¾ Le débit est de 73 kb/s.
En simulant un flux Netmeeting avec un trafic UDP de 200 kb/s, la qualité de la voix
devient médiocre et les valeurs mesurées changent :
¾ Le taux de perte de paquets passe à 8% en RTP ;

¾ Le débit chute à 54 kb/s ;
¾ La file d’attente FIFO se remplit entraînant une augmentation du temps de
transmission des paquets VoIP (174 ms). Le retard devient très significatif avec
une moyenne d’environ 82.09 ms.
En effet, FIFO ne donne aucune priorité au trafic et celui qui arrive le premier sera le
premier servi.
Observons ce qui se passe au niveau du routeur :
- 64 -
Interface Serial0/0 queueing strategy: fifo

Queueing strategy: fifo
Output queue 25/40, 397 drops; input queue 0/75, 0 drops
On remarque qu’il n’y a pas de congestion au niveau de la file d’attente d’entrée du

routeur. La file d’attente de sortie peut supporter jusqu’à 40 paquets. A l’instant de capture de
l’état de la file représenté ci-dessus, 25 paquets sont stockés et 397 paquets ont été déjà jetés.
Modèle amélioré Best-effort avec WFQ (Weighted Fair Queueing)

Les trois routeurs sont configurés de façon à utiliser le WFQ par défaut et aucun autre
concept de QoS.
Le WFQ est un concept de file d’attente hautement élaboré et utilisé par défaut par notre
version de IOS 12.1. WFQ applique des privilèges de priorité aux paquets de façon à pondérer
les flux en fonction de la valeur du champ ToS dans l’entête IP. Chaque flux obtiendra donc
une file d’attente dynamique entre lesquelles les priorités seront respectées. Les éléments de
base du WFQ sont donc un classificateur pour détecter les différents flux et leur allouer une
file d’attente Fifo, un filtre supplémentaire pour analyser l’entête IP et attribuer le poids qui
lui convient à la file d’attente et un élément de contrôle pour la transmission des paquets qui
tiennent compte du poids.
Tous les flux bénéficient d’une part de bande passante proportionnelle à la valeur de leur
précédente. La règle d’attribution est la suivante :
Bytes envoyés par cycle et par flux = précédence + 1

Part de bande passante = Bytes envoyés par cycle et par flux/ Total de bytes envoyés par
cycle
Pour la VoIP, la précédence est égale à 5.
Un flux Netmeeting a été envoyé dans le réseau et les valeurs mesurées trouvées sont les
suivants :
¾ La latence égale à 25.72 ms ;

¾ La gigue égale à 10.5 ms ;
¾ Le débit égale à 75.78 kb/s ;
¾ Le taux de perte est nul.
- 65 -
C’est un résultat proche de celui de FIFO. En effet, WFQ est la réunion de FIFO, les
Priority Queues et les Custom Queues. Si on n’a pas de surcharge de réseau c’est le FIFO qui
va être appliqué.
III.2.1.2 Trafic avec surcharge
Un flux Netmeeting et un flux TCP de 200 kb/s

Le flux TCP se caractérise par une précédence qui est égale à 0. On rappelle que la
précédence est les trois premiers bits du champ TOS. Le flux TCP obtient la part de la bande
passante égale à 36 kb/s, soit le 1/7 de 256 kb/s et la part restante est celle du flux voix. Après
mesure, on constate ce qui suit :
¾ La latence augmente pour atteindre 27 ms ;

¾ La gigue augmente aussi pour atteindre 15 ms ;
¾ Le débit pour la voix reste constant égale à 75.78 kb/s ;
¾ Le taux de perte reste égale à 0% puisque le mécanisme de WFQ permet d’allouer
une part dynamique de 220 kb/s.
Pour consulter l’état des files d’attente dans l’interface série, on tape la commande
« show queue s0/0 », les résultats obtenus sont les suivants :
Input queue: 0/75/20/0 (size/max/drops/flushes); Total output drops: 0

Queueing strategy: weighted fair
Output queue: 46/1000/64/0 (size/max total/threshold/drops)
Conversations 2/5/256 (active/max active/max total)
Reserved Conversations 0/0 (allocated/max allocated)
(depth/weight/discards/tail drops/interleaves) 1/5397/0/0/0

Conversation 192, linktype: ip, length: 284
source: 192.16.87.103, destination: 195.16.87.2, id: 0x D244, ttl: 127,
TOS: 160 prot: 17, source port 49576, destination port 495576

source: 192.16.68.103, destination: 195.16.87.2, id: 0xD243, ttl: 127,
Autant de files ont été créées qu’il y a de flux. Puisqu’on a deux flux, donc on aura deux
files d’attente. Chaque file est identifiée par un numéro de conversation, les adresses, les
numéros de port ainsi que le protocole véhiculé (prot=6 pour TCP). La valeur des champs
Time to Live et TOS est également donnée. Les autres paramètres importants sont la
profondeur de la file (depth), son poids (weight) et le nombre de paquets rejetés (total drops).
- 66 -
La profondeur, donne la quantité d’éléments présents dans la file d’attente. Celle-ci étant
presque saturée, il faut s’attendre à des rejets. Le poids donne l’importance du flux. Les flux
étant équivalents, il ne jouissent donc pas de privilèges et se voient attribuer un poids de
32384 qui correspond au trafic « Best-effort ». Logiquement, les files d’attente WFQ ont le
même comportement avec des flux de même importance au niveau priorité quel que soit le
volume de données.
Le flux TCP sera alors en excès et subira normalement une perte de paquets. Or d’après
le résultat obtenu, on remarque que le taux d’erreur est égal à 0% pour TCP. Cela s’explique
par le fait que TCP est un protocole fiable et s’adapte à la congestion de réseau par le
mécanisme de fenêtrage. C’est pour cette raison que la file d’attente est de profondeur égale à
57 paquets.
Un flux Netmeeting et un flux UDP de 200kb/s

Les tests précédents ont été effectués avec le protocole UDP. Après mesures, on
constate que la qualité de la voix devient moins bonne et les valeurs mesurées sont les
suivantes :
¾ La latence est de 24.93 ms ;
¾ Le débit égale à 72 kb/s ;
¾ Le taux d’erreur reste à 0.1%.
Interface Serial0/1 queueing strategy: fair

192.16.68.103, destination: 195.16.87.2, id: 0x045C, ttl: 127,
(depth/weight/discards/tail drops/interleaves) 11/ 5397/57/0/0

192.16.68.103, destination: 195.16.87.2, id: 0xE997, ttl: 127,
Le protocole UDP est représenté dans la file d’attente par la valeur 17 et par un poids de
32384 paquets. Les paquets voix se caractérisent par un poids égal à 5397.
- 67 -
Le flux UDP a subi une perte de paquets, perturbant ainsi le système et engendrant
également une perte de paquet RTP d’une valeur presque égale à 0.1%.
On remarque que la file d’attente de sortie est pleine (64), donc rejet de paquets UDP.
III.2.2 Modèle IntServ
Ce modèle met en évidence la réservation de ressources opérée par le protocole RSVP

selon l’architecture IntServ.
La configuration RSVP pour une communication VoIP au niveau de chaque interface est
la suivante :
Router(config-if)# ip rsvp bandwidth 150 80

Router(config-if)# fair-queue 64 256 1500
Router(config-if)# exit
Il est à noter que lorsque RSVP est activé sur l’interface série, le WFQ est
automatiquement activé, sachant que le logiciel Netmeeting est une application utilisant
RSVP. La part réservée est par défaut 75% de la bande passante sur la ligne série. On réserve
dans notre cas 150 kb/s pour la communication VoIP. Pour un codec G.711, un flux
Netmeeting doit avoir au maximum 80 kb/s en tenant compte des entêtes RTP, UDP et IP.
Cette valeur, enregistrée dans le paquet RSVP, permet d’identifier le flux par le routeur.
La figure ci-après représente la répartition de la bande passante adoptée par IntServ.
160 VOIP
140
120 Autre
Trafic (kb/s)
100
80
60
40
20
0
1 2
Figure 3.4 : Répartition de la bande passante
- 68 -
Un flux Netmeeting a été injecté dans le réseau réseau. Les résultats obtenus sont les
suivants :
¾ Si on compare ce flux par un flux VoIP véhiculé en mode FIFO sans réservation
RSVP, le délai d’acheminement passe de 25 à 25.7 ms. L’écart est donc très faible
au niveau du délai de transmission. Et le fait d’avoir une réservation RSVP,
n’influe le résultat que de très peu.
¾ La gigue est de 10.3 ms ;
¾ Le taux d’erreur est de 0% ;
¾ Le débit est de 75.87 kb/s.
Ci après le comportement des files d’attentes, ce qui est justifié puisqu’il n’y a pas de
trafic autre que celui de Netmeeting.

Un flux Netmeeting et un flux TCP de 200 kb/s

Une surcharge du réseau par un trafic TCP n’affecte pas le flux Netmeeting. Dans le cas
d’un réseau non congestionné, le mécanisme de gestion de la file d’attente est le FIFO qui
passe systématiquement à une gestion WFQ lors d’une congestion. Les résultats enregistrés
sont les suivants :
¾ La latence augmente et passe à 28.1 ms, puisque les paquets reçus sont insérés
dans un buffer avant d’être transmis ;
¾ La gigue est de 13.89 ms ;
¾ Le débit est à une moyenne de 75.78 Kb/s ;
¾ Le taux de perte est de 0%.

- 69 -

(depth/weight/total drops/no-buffer drops/interleaves) 16/32384/0/0/0

source: 10.192.63.2, destination: 10.192.72.3, id: 0xA507, ttl: 127,

source: 10.192.63.2, destination: 10.192.72.3, id: 0xA53D, ttl: 127,
Un flux Netmeeting et un flux UDP de 200 kb/s

Le même test a été effectué mais cette fois-ci, on remplaçant le protocole TCP par UDP.
¾ Le taux de perte de flux Netmeeting est de 0% ;

¾ La latence est de 29.82ms ;
¾ La gigue est de 13ms ;
¾ Le débit est à une moyenne de 75.78 Kb/s.

source: 192.16.87.103, destination: 195.16.87.2, id: 0x0390, ttl: 127,

source: 10.192.63.2, destination: 10.192.72.3, id: 0x0970, ttl: 127,
On constate que dans la file d’attente le flux audio ne contient qu’une seule unité, étant
donné que la bande passante est largement suffisante. Il ne subit donc pas de perte de paquets.
Par contre, 647 paquets du flux UDP sont rejetés. Ce nombre de paquets perdus est
nettement supérieur à celui du flux TCP. Le flux UDP ne s’adapte donc pas.
- 70 -
III.2.3 Modèle DiffServ
Le modèle DiffServ consiste à séparer le trafic conventionnel VoIP des autres types du
trafic en se basant sur le champ DSCP et en appliquant un traitement spécifique à chacun.
La transmission de la voix est considérée comme prioritaire et sera désignée Premium∗.

La classe de trafic Gold comprendra les flots de données de configuration TACACS propres
aux équipements CISCO∗∗ et contenant les valeurs DSCP 12 et 14 standardisées. La classe
Silver concerne les transferts de données de type FTP, Telnet et SMTP. Celle du Bronze,
concerne le trafic Internet et des données contenant les valeurs DSCP 28 et 30. Tout le reste
sera considéré comme trafic « Best-effort ».
Tableau 3.1 : Classes de trafic selon Cisco
La seconde étape dite « Action & Queueing » permet de donner une priorité stricte au
trafic VoIP concernant la bande passante. La classe Premium devra être transmise avec le
minimum de délai possible (si possible sans file d’attente comme le préconise le PHB EF)
jusqu’à un taux de 500 kb/s. La part de la bande passante pour la classe premium a été fixée à
80 kb/s. Les autres classes se partageront le reste de la bande passante avec un avantage pour
le Gold sur le Silver. Idem pour le Bronze qui viendra après le Silver. Le trafic Best-Effort
sera simplement limité à 44 kb/s (policing).
La figure suivante représente le partage de la bande passante choisi pour nos mesures
avec le mécanisme DiffServ :
∗
Premium : Première Classe
∗∗
le protocole TACACS « Terminal Access Controller Access Control System » est une méthode qui permet à
un routeur d’interroger une base de données distante.
- 71 -
Figure 3.5 : Répartition de la bande passante pour DiffServ
Pour implémenter ce modèle sur les routeurs, il faut développer un « policy-map» qui
intègre les classes nécessaires et qui leur attribue un PHB à l’aide de la class-map.
A l’entrée du routeur, il faut vérifier les paquets reçus et les colorer correctement. Pour
différencier les groupes de trafic, des Access-lists (ACL) sont utilisés pour ensuite être activés
dans des access-groups. Un access-list doit comporter un numéro (de 100 à 199 pour les
ACLs étendus standardisés), indiquer s’il s’agit d’une permission ou d’un refus, spécifier quel
protocole est concerné (TCP, UDP ou IP) ainsi que d’autres paramètres spécifiques
permettant de différencier les groupes de trafic (numéros de ports, sources, destinations, etc.).
Ci-après quelques commandes concernant le traitement de la VoIP et le reste sera décrit
en annexe.
Pour les deux routeurs d’extrémité :
class-map EF
match access-group 101
policy-map SETDSCP
class EF
set ip dscp 46
class-map premium
match ip dscp 46
policy-map VOIP
class premium
priority 80
L’interface Ethernet0/0 applique la coloration en entrée.
- 72 -
interface e0/0
service-policy input SETDSCP
L’interface Serial 0/0 applique la politique VoIP en sortie.
interface Serial0/0
service-policy output VOIP
Pour repérer les différents types de trafic, on définit des access-lists:
access-list 101 permit udp any any range 16384 50000
Pour le routeur central, il s’agit d’exploiter le champ DSCP étant donné qu’il peut identifier la
provenance des paquets par la couleur appliquée par le routeur. Il s’agit donc d’effectuer une
détection de ce champ puis d’appliquer le modèle.
class-map premium
match ip dscp 46
policy-map VOIP
class premium
priority 80
interface s0/0 et s0/1

service-policy output VOIP
Dans les conditions normales, le délai de transmission reste très stable par rapport aux
mécanismes précédents (File d’attente de type FIFO). Les valeurs sont les suivantes :
¾ La latence augmente faiblement pour atteindre 26ms. Ceci s’explique par le fait
que le routeur doit effectuer des opérations supplémentaires propre au DiffServ ;
¾ La gigue est égale à 12 ms ;
¾ La part de bande passante est la même, soit 75.87 kb/s.
À l’interface Ethernet, le modèle DiffServ colorie bien le flux Voix :
RouterA#sh policy-map int e0/0
Ethernet0/0
input : setdscp
Class ef
QoS Set
ip dscp 46
Packets marked 5590
- 73 -
Interface série:
RouterA#sh policy-map int s0/0
Serial0/0
output : voip
Class premium
Weighted Fair Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 80 (kb/sps) Burst 12500 (Bytes)
(pkts matched/bytes matched) 5598/1659804
(pkts discards/bytes discards) 0/0
Class gold
Bandwidth 35 (%) Max Threshold 64 (packets)
(pkts discards/bytes discards/tail drops) 0/0/0
Class bronze
Class silver
A l’instant de capture, les paquets VoIP sont bien marqués à l’entrée de l’interface Ethernet :
5598 paquets avec un DSCP qui est égal à 46.
Le policy-map à l’interface série montre que le trafic VoIP bénéficie d’une bande passante de
80 kb/sps et 5590 paquets sont détectés à la sortie.
Aucune perte de paquets de la voix n’est détectés (pkts discards=0).
Un flux Netmeeting avec un flux TCP de 200 kb/s

La latence et la gigue augmentent considérablement. Les routeurs vont buffériser les
paquets et effectuer les traitements nécessaires tels que la classification du trafic, l’affectation
de la priorité pour la voix. Les valeurs mesurées sont :
- 74 -
¾ La latence passe à 31ms ;

¾ Le taux de perte est nul.
QoS Set
ip dscp 46
Packets marked 5427
QoS Set
ip dscp 22
Packets marked 4866
router1#sh queueing int s0/0


source: 192.16.87.103, destination: 195.16.87.2, id: 0x019A, ttl: 63,
Le DSCP égal à 22 correspond bien à la classe Silver (trafic FTP). On lui a alloué 25%
de la bande passante. Le taux de perte de paquets est dans ce cas nul.
Un flux Netmeeting avec un flux UDP de 200 kb/s

La génération de flux UDP engendre la coloration de la classe Best-effort.
La bande passante allouée à cette classe est 44 kb/s et c’est la raison pour laquelle il y a
beaucoup de paquets UDP perdus.
¾ Le flux Voix a subi une légère perte (0.08%). En effet, la part de la bande passante
réservée pour la voix est faible (80 kb/s).
¾ Le débit de la voix peut dépasser parfois le normal faute de fonctionnement de
l’application Netmeeting et le débit moyen est de 75.78 kb/s.
¾ Le délai de transmission est de 30.07ms.
¾ La gigue équivaut à 15.91ms.

- 75 -


source: 192.16.87.103, destination: 195.16.87.2, id: 0x02B5, ttl: 63,
IV. Synthèse : comparaison des mécanismes de QoS
Cette partie récapitule et synthétise les résultats trouvés. Le tableau suivant expose les
résultats des différentes mesures effectuées pour les mécanismes QoS testés.
Paramètres Best-Effort IntServ DiffServ

de QoS FIFO WFQ
Latence 25 25.72 25.70 26.03
(ms)
Gigue (ms) 10 10.5 10.3 12
Sans
surcharge Débit (kb/s) 78 75.78 75.78 75.78
Taux de 0 0 0 0
perte (%)
Latence 25.88 27 28.1 31
(ms)
Surcharge Gigue (ms) 13 15 13.98 18
par un flux
TCP Débit 73 75.78 75.78 75.78
(kb/s)
Taux de 0 0 0 0
perte (%)
Latence 174 24.93 29.82 30.07
(ms)
Surcharge Gigue (ms) 82.09 13 13 15.91
par un flux
UDP Débit 54 72 75.78 75
(kb/s)
Taux de 8 0.1 0 0.08
perte (%)
Tableau 3.2 : Récapitulation des résultats
On constate qu’il n’y a pas une grande différence entre IntServ et DiffServ. Il est donc
difficile de préciser quel est le meilleur mécanisme. En fait tout dépend du milieu dans lequel
- 76 -
la qualité de service doit être appliquée. Par contre la différence entre les deux mécanismes de
gestion de la file d’attente pour le modèle Best-Effort est claire.
On remarque que dans le cas d’un réseau non congestionné les valeurs de la latence sont
très proches pour tous les mécanismes. En effet, lorsqu’il n’y pas autre flux que la voix, la
gestion FIFO sera appliquée car on n’a pas besoin d’un mécanisme performant. Ainsi, WFQ
est plus lent que FIFO à cause de ses réactions dynamiques aux flux.
Pour déterminer si les valeurs sont bonnes ou pas, il faut toujours faire la référence au
tableau 2.2 du deuxième chapitre. On dit que la qualité de la voix est bonne si respectivement,
la latence, la gigue et le taux d’erreur sont inférieurs respectivement à 150 ms, 20 ms et 1%.
Lors de la saturation du réseau, on distingue deux cas : le cas de surcharge avec un flux
TCP et celui de UDP. Le flux TCP n’a pas de grande influence sur la perte de paquets de la
voix qui est nulle car TCP est un protocole fiable qui laisse la place au protocole UDP et
s’adapte à la congestion du réseau en se basant sur un mode d'acquittement des segments
faisant appel au fenêtrage. Contrairement à TCP, UDP peut gêner le réseau surtout si on n’a
pas de qualité de service (cas de FIFO où la perte est de 8%).
D’autre part, la congestion du réseau engendre un retard de la latence et par conséquent
un retard de la gigue. Pour FIFO, les performances du réseau deviennent médiocres. La
latence dépasse le seuil (174 ms > 150 ms) et la gigue est élevée (Gigue > 20ms).
L’importance des mécanismes de qualité de service apparaît dans cette situation. Par exemple,
le mécanisme IntServ est efficace pour la VoIP car il lui garantit une bande passante mais cela
peut être discriminatoire pour d’autres types de flux tels que le UDP et le TCP. En plus,
IntServ n’est efficace que si on le configure sur chaque nœud du réseau. Cela est donc
applicable pour un petit réseau et non pas sur un réseau fédérateur.
On remarque aussi que IntServ se caractérise par la séparation des réservations. En effet
pour chaque flux NetMeeting (il y en a un dans chaque sens et par conversation) sont établies
des réservations de manière autonome, chaque flux a la sienne. Tant que la somme des débits
des flux Netmeeting ne dépasse pas la bande passante réservée, il n’y a pas de perte de
paquets. Le cas de DiffServ est différent puisque les flux Netmeeting doivent partager la
bande passante qui lui est réservée et cela peut altérer la qualité de la voix.
Un autre élément intéressant à mettre en évidence est le fait que la qualité de service «
coûte » du temps. En effet les nœuds tels que les routeurs vont prendre de temps selon le
mécanisme de qualité de service pour l’analyse et la détermination du flux lequel il faut
acheminer de manière prioritaire et la façon d’expédier le trafic. Cela va influencer la latence
- 77 -
et la gigue qui sont un peu plus supérieures pour DiffServ par rapport à IntServ puisqu’il faut
classer les flux et attribuer à chaque classe un traitement bien particulier.
V. Conclusion
Ce projet nous a aussi permis d’étudier les normes et concepts de VoIP utilisés pour le
développement des applications de VoIP et surtout la norme H.323 implantée dans notre
plate-forme de mesure ce qui nous a fait comprendre aux mieux l’impact des paramètres
réseau tels que le délai, la gigue, le débit et la perte de paquets sur la qualité de service.
- 78 -
Conclusion générale
Conclusion générale
L’Internet, comme la majorité des réseaux en mode paquets, n’a pas été initialement
prévu pour prendre en compte les paramètres de qualité de service. Avec l’avènement de
l’utilisation de la VoIP et surtout par les entreprises, vu leurs apports, il a fallu mettre en place
de nouveaux mécanismes de qualité de service par les opérateurs et les équipementiers.
Il y a quatre paramètres techniques à prendre en compte dans la qualité de service qui

sont le temps de réponse ou latence, le débit, le taux d’erreur et la gigue.
Le but de ce projet a été l’implémentation de deux mécanismes de qualité de service tels

que IntServ et DiffServ sur une plate-forme supportant la VoIP et la comparaison entre ces
différents mécanismes en terme de paramètres de QoS.
IntServ convient plutôt aux réseaux de petite taille, mais il n'est pas vraiment adapté à
Internet dans son ensemble. DiffServ lui, assure une distinction des paquets par classes de
flux.
D’après les résultats obtenus, la qualité de service coûte plus de temps, pour cette
raison, DiffServ se caractérise par un délai et une gigue relativement plus longs que celles de
IntServ.
Faute de matériels, il a été impossible pour moi d’effectuer mes tests sur le MPLS et sur
une plateforme se basant sur IPv6. Cela demande une version de IOS de routeur plus évolué
que celle disponible à Sup’Com.
- 79 -
Bibliographie
Bibliographie
[1] Marc Chutet, «TOIP », 2003
[2] Jean-Louis Mélin, « Qualité de service sur IP », Edition Eyrolle, 2000
[3] Etude réalisée par le cabinet Ovum, « L'évolution du coeur de réseau des opérateurs
fixes », 2006
[4] Marc BALLESTEROS Biasino CASSELLA, « Qualité de Service pour la Voix sur
IP », 2002
[5] Dominique PRESENT, « Qualité de service sur Internet », 2001
[6] Éric HORLAIT, « QoS IP avec RTP/RTCP », 2000
Sites Web
www.cisco.com : le site officiel de Cisco.
- 80 -
Annexes
Annexes
I. Allocation de la bande passante pour les codecs en IntServ
Codec Voice Bandwidth (kb/s) Transport Bandwidth (kb/s)

G .711 64 80
G.729 8 12
G.726 16 40
Allocation en bande passante selon le codec
II. Configuration de DiffServ
Les deux routeurs d’extrémités sont configures de la manière suivante:
A l’entrée de toutes les interfaces ethernet :
SETDSCP Policy Map
class-map EF
class-map AF1
class-map AF21
class-map AF22
class-map AF23
class-map AF3
policy-map SETDSCP
class EF
- 81 -
Annexes
set ip dscp 46
class AF1
set ip dscp 10
class AF21
set ip dscp 18
class AF22
set ip dscp 20
class AF23
set ip dscp 22
class AF3
set ip dscp 26
A la sortie des interfaces série:
VOIP Policy Map
class-map premium
match ip dscp 46
class-map gold
match ip dscp 10 12 14
class-map silver
class-map bronze
class-map best-effort
policy-map VOIP
class premium
- 82 -
Annexes
priority 80
class gold
bandwidth percent 35
class silver
class bronze
class best-effort
rate-limit 44000 1750 1750 conform-action set-dscp-transmit 0
access-list 101 permit udp any any range 16384 50000
access-list 102 permit tcp any any eq tacacs
access-list 104 permit tcp any any eq www
access-list 105 permit ip any any
access-list 108 permit tcp any any eq telnet
access-list 109 permit tcp any any eq smtp
access-list 110 permit tcp any any eq ftp
Pour le routeur central, à la sortie des interfaces série:
class-map gold
class-map bronze
class-map premium
match ip dscp 46
class-map silver
- 83 -
Annexes
class-map best-effort
match ip dscp 0
policy-map AVVID
class silver
class gold
class bronze
class premium
priority 80
policy-map AVVID
class silver
random-detect dscp-based
random-detect dscp 18 20 40 10
class gold
class bronze
- 84 -
Résumé
La voix sur IP acquiert de plus en plus d’importance dans le domaine des
télécommunications, surtout pour les entreprises, grâce à ses avantages économiques
et techniques.
Avec l’augmentation des applications envoyées sur les réseaux IP, et afin de fournir
un service avec une bonne qualité, il faudrait utiliser des mécanismes assurant cette
qualité.
Dans ce projet de fin d’études, nous avons tout d’abord réalisé une plate forme d’un
réseau supportant les applications voix sur IP en implémentant à chaque fois un
mécanisme de QoS (IntServ et DiffServ) et en mesurant les différents paramètres de
qualité de service. Finalement, nous avons évalué ces mécanismes.
Mots clés :
Voix sur IP, Qualité de service, WFQ, IntServ, DiffServ.
Abstract
Voice over IP acquires more and more importance in the field of telecommunications,
especially for the companies, thanks to its economical and technical advantages.
Because of the increase of applications on the IP networks, and in order to provide a
service with a good quality of service, it was necessary to use mechanisms ensuring
this quality.
In this project of end of study, we first realized a platform supporting the applications
of the voice over IP and implemented mechanisms of QoS (IntServ and DiffServ) to
measure the parameters of quality of service. Finally, we evaluated these mechanisms
and compared between them.
Keywords
Voice over IP, Quality of service, WFQ, Intserv, DiffServ.

LOUHICHI Zeineb

Transféré par

Droits d'auteur :

Formats disponibles

LOUHICHI Zeineb

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

LOUHICHI Zeineb

Transféré par

Droits d'auteur :

Formats disponibles

Cycle de formation des ingénieurs en Télécommunications

Option : Ingénierie de réseaux

Rapport de Projet de fin d’études

Mesure des paramètres de qualité de service pour les

Elaboré par : Melle LOUHICHI Zeineb

Année universitaire : 2005/2006

Au terme de ce projet de fin d’études, j’adresse mes sincères remerciements à Madame

Je tiens à remercier également Monsieur Rached HAMZA, Maître assistant à Sup’Com,

Mes remerciements s’adressent également à l’administration et aux professeurs de

Je souhaite exprimer enfin ma gratitude et mes vifs remerciements à ma famille et mes

amis pour leur soutien.

La voix sur IP acquiert de plus en plus d’importance dans le domaine des

Ce document s’inscrit dans le cadre du projet de fin d’études de l’école

Table des matières

Liste des illustrations ........................................................................................................... 4

Liste des tableaux ................................................................................................................. 5

Liste des acronymes ............................................................................................................. 6

III.4 MGCP (Media Gateway Control Protocol) ................................................. 25

IV.1.1 Présentation de RTP........................................................................... 51

Conclusion générale ........................................................................................................... 79

Liste des illustrations

Figure 1.1 : Architecture de la téléphonie classique ................................................................ 13

Liste des tableaux

Tableau 1.1 : Codecs audio ...................................................................................................... 16

Liste des acronymes

CoS Class of Service

CRCX Create ConneXion

DiffServ Differenciated Services

DSCP Differentiated Service Code Point

FEC Forwarding Equivalence Class

FIFO First In First Out

IAM Initial Address Message

IETF Internet Engineering Task Force

IntServ Integrated Services

ISDN Integrated Services Digital Network

ISUP Integrated Services User Part

ITU International Telecommunication Union

LAN Local Area Network

QoS Quality Of Service

PDU Protocol Data Unit

LDP Label Distribution Protocol

LER Label Edge Routeur

LSP Label Switch Path

LSR Label Switching Router

MCU Multipoint Control Unit

MGCP Media Gateway Control Protocol

MPLS MultiProtocol Label Switching

PABX Private Automatic Branch eXchange

PSTN Public Switched Telephone Network

RNIS Réseau Numérique à Intégration de Services

RSVP Resource Reservation Protocol

RTCP Real-Time Transport Control Protocol

RTP Real-Time Transport Protocol

SAP Session Annoucement Protocol

SDES Source DEScription

SDP Session Description Protocol

SSP Point de Signalisation

STP Point de Transfert de Signalisations

SIP Session Initiation Protocol