Voix sur IP (VoIP) - Comprendre la variation de délai ou gigue dans les réseaux avec voix paquétisée.

Présentation au sujet: "Voix sur IP (VoIP) - Comprendre la variation de délai ou gigue dans les réseaux avec voix paquétisée."— Transcription de la présentation:

1 Voix sur IP (VoIP) - Comprendre la variation de délai ou gigue dans les réseaux avec 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 La variation de délai dans les avec voix paquétisée
Introduction Ce document décrit la variation du délai, comment la mesurer et comment la compenser. 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é. Temps Flux continu de paquets Le même flux de paquets après congestion ou problème de file d'attente 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. Flux de paquets avec gigue compensée transmis au DSP Flux continu de paquets Buffer de compensation de gigue

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 de compensation de gigue Paquet avec gigue excessive éliminé 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: Une fois que la communication est active, et qu'il y a présomption de gigue, connectez vous avec Telnet à une des passerelles Passez la commande terminal monitor pour pour voir les messages de la console au travers de Telnet Note : Cette étape n'est pas nécessaire si vous êtes connecté par le port console 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/ FXSLS_ONHOOK 1/0/ 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 communication, 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 /0/1 vtsp level 0 state = S_CONNECT vpm level 1 state = FXSLS_CONNECT vpm level 0 state = S_UP MS B# ***DSP VOICE VP_DELAY STATISTICS*** Clk Offset (ms) : 0, Rx Delay Est (ms) : Rx Delay Lo Water Mark(ms): 50, Rx Delay Hi Water Mark(ms): ***DSP VOICE VP_ERROR STATISTICS*** Predict Conceal(ms): 0, Interpolate Conceal(ms): Silence Conceal(ms): 0, Retroact Mem Update(ms): Buf Overflow Discard(ms): 0, Talkspurt Endpoint Detect Err: ***DSP VOICE RX STATISTICS*** Rx Vox/Fax Pkts: 1187, Rx Signal Pkts: 0, Rx Comfort Pkts: Rx Dur(ms): , Rx VoX Dur(ms): 23740, Rx Fax Dur(ms): Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: Rx Early Pkts: 0, Rx Late Pkts: ***DSP VOICE TX STATISTICS*** Tx Vox/Fax Pkts: 1187, Rx Signal Pkts: 0, Rx Comfort Pkts: Tx Dur(ms): , Rx VoX Dur(ms): 23740, Rx Fax Dur(ms): ***DSP VOICE ERROR STATISTICS*** Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM overflow): ***DSP LEVELS*** TDM Bus levels(dBmo): Rx -54,5 from PBX/Phone, Tx to PBX/Phone TDM ACOM levels(dBmo): +2.0, TDM ERL Level(dBmo): 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'accroître constamment. Il est normal d'avoir des paquets hors-intervalle lorsqu'une communication est initialisée, mais cette valeur ne doit pas s'accroître 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 congestion peut se produire soit à l'interface du routeur soit dans le réseau du fournisseur 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 contrôle 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 apparaît 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 contrôle 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: Singapour#show 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 output pkts in bytes out bytes dropped pkts in FECN pkts 0 in BECN pkts out FECN pkts out BECN pkts 0 in DE pkts out DE pkts 0 out bcast pkts out bcast bytes pvc create time 00:13:16, last time pvc status changed 00:13:17 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 contrôlés par le formatage de trafic configuré sur le routeur à l'autre extrémité du PVC. De la même manière vous contrôlez 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ées 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 attente dans les équipements traversés par les paquets. La varia- tion de délai peut être due à une mauvaise configuration du routeur et du PVC fourni par l'opérateur