Pr

1
Voix sur IP (VoIP) -Comprendre la variationde
délai ou giguedans les réseauxavec voix
paquétisée
2
Sommaire
Introduction La variation de délai dans les
réseaux avec voix paquétisée Déterminer la
gravité de la variation du délai Quelles sont
les causes de la variation du délai - Prise
en compte de l'encapsulation - La variation
du délai dans un environnement Frame Relay -
conclusion
3
Introduction
Ce document décrit la variation du délai, comment
la mesurer et comment lacompenser. Pour lire
ce document il est nécessaire d'avoir des
connaissances sur Configuration de base de la
voix avec l'IOS Cisco Connaissance de base
sur la Qualité de Service (QoS)
La variation de délai dans les avec voix
paquétisée La variation de délai ou gigue est
définie comme une variation du délai à la
réception des paquets. A l'extrémité émettrice,
les paquets sont transmis en un flux continu
avec un espacement constant entre paquets. A
cause d'une congestion du réseau, d'une gestion
incorrecte des files d'attente ou d'erreur de
configuration, ce flux cons- tant peut devenir
irrégulier ou le délai entre les paquets peut
devenir variable au lieu de rester constant.
Le schéma suivant illustre comment un flux
constant de paquets est géré.
Quand un routeur reçoit un flux audio RTP pour
de la Voix sur IP (VoIP), il doit compenser la
variation de délai rencontrée. Le système qui
permet de gérer cette compensation c'est le
buffer de compensation de gigue. Ce buffer doit
tamponner les paquets et ensuite les sortir en
un flux constant vers le processeur de signal
pour être converti en un flux audio analogique.
Le schéma suivant montre comment la gigue est
gérée.
4
Si le délai est trop grand au point que les
paquets reçus sont hors des limites pour ce
buffer, ces paquets seront éliminés et des
distorsions pourront être perçues dans le
signal audio. Pour la perte d'un paquet, le
processeur de signal fera une interpo- lation
pour le signal et il n'y aura qu'une très légère
distorsion. Quand le délai excède ce que
le processeur de signal peut compenser, des
perturbations très nettes seront perçues sur
le signal audio. Le schéma suivant montre
comment une variation de délai excessive est
traitée.
Flux avec gigue excessive
Buffer decompensationde gigue
Paquet avec gigue excessive éliminée
Déterminer la gravité de la variation de délai
La présence de gigue excessive peut être
confirmée au travers de l'IOS Cisco en suivant
les étapes suivantes 1. Une fois que la
communication est active, et quil y a présomption
de gigue, connectez vous avec Telnet à
une des passerelles. 2. Passez la commande
terminal monitor pour pour voir les messages de
la console au tevaers de Telnet.
Note Cette étape n'est pas nécessaire si
vous êtes connecté par le port console 3.
Entrez la commande show voice call summary et
vous verrez un affichage simi- laire à ce
qui suit PORT CODEC VAD VTSP
STATE VPM STATE

1/0/0 - - -
FXSLS_ONHOOK 1/0/1 g729r8 y
S_CONNECT FXSLS_CONNECT Vous
pouvez maintenant sélectionner la communication
pour laquelle il y a de la gigue. Dans cet
exemple c'est le port 1/0/1.
5
4. Pour examiner cette communnication, entrez la
commande show voice call. Dans cet exemple,
c'est show voice call 1/0/1. La sortie qui est
affichée est donnée par le DSP qui gère
cette communication et ressemble à ceci.
1/0/1 vtsp level 0 state S_CONNECT vpm
level 1 state FXSLS_CONNECT vpm level 0
state S_UP MS-2621-3B DSP VOICE
VP_DELAY STATISTICS Clk Offset (ms)
0, Rx Delay Est (ms) 50 Rx Delay Lo
Water Mark(ms) 50, Rx Delay Hi Water Mark(ms)
7 DSP VOICE VP_ERROR STATISTICS
Predict Conceal(ms) 0, Interpolate Conceal(ms)
0 Silence Conceal(ms) 0, Retroact Mem
Update(ms) 0 Buf Overflow Discard(ms) 0,
Talkspurt Endpoint Detect Err 0 DSP
VOICE RX STATISTICS Rx Vox/Fax Pkts
1187, Rx Signal Pkts 0, Rx Comfort Pkts 0
Rx Dur(ms) 150200, Rx VoX Dur(ms) 23740, Rx
Fax Dur(ms) 0 Rx Non-seq Pkts 0, Rx Bad
Hdr Pkts 0 Rx Early Pkts 0, Rx Late
Pkts 0 DSP VOICE TX STATISTICS
Tx Vox/Fax Pkts 1187, Rx Signal Pkts 0, Rx
Comfort Pkts 0 Tx Dur(ms) 150200, Rx VoX
Dur(ms) 23740, Rx Fax Dur(ms) 0
DSP VOICE ERROR STATISTICS Rx Pkt
Drops(Invalid Header) 0, Tx Pkt Drops(HPI SAM
overflow)0 DSP LEVELS TDM Bus
levels(dBmo) Rx -54,5 from PBX/Phone, Tx -64.7
to PBX/Phone TDM ACOM levels(dBmo) 2.0,
TDM ERL Level(dBmo) 9.9 TDM Bgd
levels(dBmo) -49,4 with activity being voice
5. Examinez la section DSP VOICE VP_ERRORS
STATISTICS dans la sortie. Sous cette
section il y a quelques paramètres à examiner, le
principal est le nombre de "Buf Overflow
Discard(ms)". C'est le nombre de paquets qui sont
hors intervalle pour le buffer de
compensation de gigue (éliminées). Il peut y
avoir une valeur non nulle, mais celle-ci ne
doit pas s'accroitre constanment. Il est normal
d'avoir des paquets hors-intervalle lorsqu'une
communication est initialisée, mais cette
valeur ne doit pas s'accroitre lorsque la
commande show voice call x/x/x est répétée.
Ce nombre est une indication directe d'une
variation excessive du délai. Par
défaut ce buffer fonctionne dans un mode
adaptatif dans lequel il ajuste la variation
de délai (jusqu'à une certaine limite).Le
comportement par défaut de la compensation
de délai peut être modifié par la commande
playout-delay. Ce buffer peut être aussi
positionné en mode non-adaptatif. Ceci peut
régler quelques problèmes liés à la
variation de délai.
6
Quelle est la cause de la variation du délai
La variation du délai est généralement causée
par la congestion dans un réseau IP. La
congeston peut se produire soit à l'interface du
routeur soit dans le réseau du foiurnisseur
d'accès si le circuit n'est pas correctement
géré. Considérations sur l'encapsulation
Le meilleur endroit pour vérifier la variation du
délai est l'interface du routeur car vous avez
un controle direct à cette portion de circuit. La
manière dont vous allez rechercher la source
de la variation du délai dépend de
l'encapsulation et du type de liaison sur
lesquels le délai se produit. Normalement, les
circuits ATM ne rencontrent pas de variation de
délai quand ils sont configurés correctement
avec un débit de cellules constant. Si la
variation de délai apparait dans un
environnement ATM, l'examen de la configuration
ATM est nécessaire. Avec l'encapsulation PPP,
la variation de délai est presque toujours due
au délai de sérialisation. Ceci peut facilement
être géré en utilisant la fragmentation et
l'entrelacement sur la liaison PPP. La
constitution de PPP fait que les extrémités
communiquent directement entre elles sans
passer par des commutateurs ainsi
l'administrateur a le controle sur toutes les
interfaces incluses dans la liaison. La
variation de délai dans un environnement Frame
Relay Trois paramètres doivent être vérifiées
pour gérer la variation du délai dans un
environnement Frame Relay Formatage du
trafic (Traffic Shaping) Fragmentation
Files d'attentes (Queueing)
7
Traffic Shaping Vous devez vous assurer que
vous lissez le trafic qui sort du routeur à la
valeur du CIR que l'opérateur fournit. Ceci
peut être vérifié en regardant les statistiques
Frame Relay et en testant avec l'opérateur. Pour
voir les statistiques Frame Relay utilisez la
commande show frame-relay pvc xx, (xx DLCI).
Vous devez obtenir une sortie similaire à
celle qui suit Singapourshow frame-relay
pvc 16 PVC Statistics for interface Serial0/0
(Frame Relay DTE) DLCI 16, DLCI USAGE
LOCAL, PVC STATUS ACTIVE, INTERFACE
Serial0/0 input pkts 103611 output
pkts 120054 in bytes 9909818
out bytes 10962348 dropped pkts 0
in FECN pkts 0 in BECN pkts 0
out FECN pkts 0 out BECN pkts 0
in DE pkts 0 out DE pkts 0
out bcast pkts 1366 out bcast
bytes 448048 pvc create time 001316,
last time pvc status changed 001317 Que
Rechercher? Ce que vous devez rechercher dans
la sortie ci-dessus ce sont les valeurs qui mon-
trent s'il y a eu congestion dans le réseau. Ce
sont les paramètres FECN, BECN et DE. Vous
devez regarder uniquement les paquets entrants
car Cisco ne transmet pas ces informations.
Vous pouvez voir des valeurs de ces paramètres
s'incrémen- ter, tout dépend du type et de la
configuration des commutateurs Frame Relay
utilisés par l'opérateur. En général, si vous
avez du Frame Relay avec du "Lissage de
trafic" et que le CIR est le même que celui du
circuit, les paramètres FECN, BECN et DE
doivent rester stables. Si ces paramètres
s'incrémentent et que vous respectez le CIR,
c'est que le commu- tateur de l'opérateur est
mal configuré. Si vous louez un CIR nul mais
avec une valeur de "Burst" cela constitue un bon
exemple pour illustrer la congestion. Quelques
opérateurs fournissent un PVC avec un CIR nul
ce qui est bon pour les données mais produit des
effets très néfastes sur la qualité de la
voix. Si l'on regarde dans la sortie précédente,
avec un CIR nul le nombre de paquets avec FECN
ou DE sera égal au nombre de paquets entrants.
En allant plus loin, si vous avez un PVC à 128
Kb/s loué à l'opérateur et que le routeur est
positionné à 512 Kbit/s vous verrez les
paramètres FECN, BECN et DE s'incré- menter
lentement. Rappelez-vous que vous regardez les
paquets entrants controlés par le formatage de
trafic configuré sur le routeur à l'autre
extrémité du PVC. De la même manière vous
controlez ce qui entre sur l'autre routeur avec
les paramètres de formatage de trafic
configurés sur le routeur local. La chose
importante à retenir est que vous ne devez pas
dépasser le CIR du PVC loué à l'opérateur.
8
La raison pour laquelle vous pouvez voir la
congestion est simple Le CIR qui est
configuré pour un PVC sur un commutateur dicte le
débit du trafic passé par le commutateur pour
ce PVC. Quand le CIR configuré sur le commutateur
est dépassé par le flux de données reçu, il
bufferise les trames en excès par rapport au CIR
jusqu'à ce que la capacité d'acheminement soit
disponible pour les paquets buffe- risés .
Chaque trame bufferisée a été marquée avec le
bit DE ou FECN par le commutateur. Si vous
voulez examiner les statistiques des interfaces
pour vérifier que tout fonctionne
correctement, utilisez la commande show
interface. Fragmentation La fragmentation
est plus associée au délai de sérialisation qu'à
la variation du délai mais sous certaines
conditions elle peut être la cause de variation
de délai. La fragmentation doit toujours être
configurée dans la classe de trafic Frame relay
quand on utilise la voix paquétisée. La
configuration de ce paramètre a deux effets
sur l'interface. L'effet évident est que tous les
paquets dont la taille est supérieure à celle
spécifiée seront fragmentés. L'autre effet est
moins apparent mais assez important. Si vous
regardez l'interface sur laquelle la
fragmentation est configurée, vous pouvez
voir l'effet de cette commande. Sans
fragmentation, la stratégie de de mise en
file d'attente affichée par la commande show
interface x est de type FIFO. Lorsque la
fragmentation est configurée la commande
affichera une mise en file d'attente de type
Dual-FIFO. C'est la Priority-Queue qui a été crée
et qui sera utilisée pour le trafic voix de
l'interface. Si vous avez toujours des problèmes
de variations de délai, diminuez la valeur de
fragmentation jusqu'à ce que la qualité de la
voix devienne acceptable. Mise en file
d'attente Il y a généralement deux méthodes
de mises en file d'attente utilisées pour le
trafic VoIP IP RTP Priority
Queueing Low Latency Queueing L'une
ou l'autre des méthodes doit être utilisée, elles
ne doivent pas être configurées simultanément.
Si la mise en file d'attente est configurée
correctement d'après la documentation, vous
pouvez conclure que la mise en file d'attente
fonctionne nor- malement et que le problème de
variation de délai est situé ailleurs. La mise
en file d'attente n'est généralement pas une
cause de variation de délai car les variations
créees sont très faibles. Cependant si les
paquets VoIP ne sont pas mis correctement en file
d'attente et qu'il y a des données sur le
même circuit, cela peut entrainer des variations
de délai. Conclusion Nous pouvons en
conclure que la gigue est une variation de délai
dans le transport des paquets VoIP. Le DSP à
l'intérieur du routeur peut compenser cette gigue
si celle-ci n'est pas excessive. La cause de
la variation du délai (gigue) est générale-
ment due à une attete dans les équipements
traversés par les paquets. La variation de
délai peut être due à une mauvaise configuration
du routeur et du PVC fourni par l'opérateur