Présentation de l'instabilité dans les réseaux voix par paquets (plates-formes Cisco IOS)
Contenu
Introduction
Ce document décrit le jitter, et comment le mesurer et le compenser.
Conditions préalables
Conditions requises
Les lecteurs de ce document devraient avoir connaissance des sujets suivants :
-
Configuration vocale de base de Cisco IOS®
-
Compréhension de base de la qualité de service (QoS)
Components Used
Les informations de ce document s'appliquent aux passerelles vocales et aux routeurs Cisco IOS.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Jitter dans les réseaux vocaux par paquets
La gigue est définie comme une variation du délai des paquets reçus. Du côté émetteur, les paquets sont envoyés dans un flux continu, les paquets étant espacés uniformément. En raison d’une congestion du réseau, d’une mise en file d’attente incorrecte ou d’erreurs de configuration, ce flux continu peut devenir instable ou le délai entre chaque paquet peut varier au lieu de rester constant.
Ce schéma illustre la manière dont un flux continu de paquets est géré.
Lorsqu'un routeur reçoit un flux audio RTP (Real-Time Protocol) pour la voix sur IP (VoIP), il doit compenser la gigue rencontrée. Le mécanisme qui gère cette fonction est le tampon de délai de lecture. La mémoire tampon du délai de lecture doit mettre en mémoire tampon ces paquets, puis les diffuser en flux continu vers les processeurs de signal numérique (DSP) à convertir en flux audio analogique. Le tampon de délai de lecture est parfois appelé tampon de dégivrage.
Ce diagramme illustre la façon dont la gigue est traitée.
Si la gigue est si importante qu'elle provoque la réception de paquets hors de la plage de cette mémoire tampon, les paquets hors plage sont ignorés et les abandons sont entendus dans le son. Pour les pertes aussi petites qu'un paquet, le DSP interpole ce qu'il pense que le son devrait être et aucun problème n'est audible. Lorsque la gigue dépasse ce que le DSP peut faire pour compenser les paquets manquants, des problèmes audio sont entendus.
Ce diagramme illustre la façon dont la gigue excessive est traitée.
Déterminer la gravité de la gigue
La présence d'une gigue excessive peut être confirmée via Cisco IOS en procédant comme suit.
-
Une fois qu'un appel est actif et qu'il est suspecté de gigue, établissez une connexion Telnet avec l'une des passerelles concernées.
-
Activez Terminal Monitor afin de voir les messages de console via votre session Telnet.
Remarque : Cette étape n'est pas nécessaire si vous êtes connecté au port de console.
-
Entrez la commande show voice call summary. La sortie similaire à celle-ci apparaît :
PORT CODEC VAD VTSP STATE VPM STATE ============ ======== === ==================== ====================== 1/0/0 - - - FXSLS_ONHOOK 1/0/1 g729r8 y S_CONNECT FXSLS_CONNECT
Sélectionnez l'appel où la gigue est détectée. Dans cet exemple, il s'agit de 1/0/1.
-
Pour examiner cet appel spécifique, entrez la commande show voice call.
Dans cet exemple, il s'agit de show voice call 1/0/1. Le résultat fourni provient du DSP qui gère l'appel et est similaire à 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: 7129, Tx Sig Pkts: 0, Tx Comfort Pkts: 0 Tx Dur(ms): 150200, Tx Vox Dur(ms): 14259, Tx 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(dBm0): Rx -54.5 from PBX/Phone, Tx -64.7 to PBX/Phone TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +9.9 TDM Bgd Levels(dBm0): -49.4, with activity being voice -
Affichez la section ***STATISTIQUES VOIX DSP VP_ERROR*** dans le résultat.
Dans cette section, il y a plusieurs paramètres à examiner. La principale est le nombre de ms (Buf Overflow Discard) qui sont vus. Ceci compte les paquets qui sont hors limites pour le tampon de délai de lecture (abandonné). Cela peut avoir une certaine valeur, tant qu'il n'augmente pas constamment. Il est normal d'obtenir des débordements lorsqu'un appel est initié pour la première fois, mais cette valeur ne doit pas augmenter lorsque la commande show voice call X/X/X est répétée. Ce nombre est une indication directe de gigue excessive.
Par défaut, ce tampon s'exécute en mode adaptatif où il s'ajuste dynamiquement à la quantité de gigue présente (jusqu'à un point). Configurez la commande playout-delay pour modifier les valeurs par défaut du comportement dynamique du tampon de dégivrage. Cette mémoire tampon peut également être définie en mode fixe. Cela peut résoudre certains problèmes de gigue. Pour plus d'informations, référez-vous à Améliorations du délai de lecture pour la voix sur IP.
Qu'est-ce qui cause la gigue ?
La gigue est généralement due à la congestion du réseau IP. L’encombrement peut se produire soit sur les interfaces du routeur, soit sur un réseau de fournisseur ou d’opérateur si le circuit n’a pas été configuré correctement.
Considérations d’encapsulation
Le meilleur endroit pour commencer à chercher de la gigue se trouve sur les interfaces du routeur puisque vous avez un contrôle direct sur cette partie du circuit. La manière dont vous traquez la source de la gigue dépend largement de l’encapsulation et du type de liaison où la gigue se produit. En règle générale, les circuits ATM ne subissent pas de gigue lorsqu’ils sont configurés correctement en raison de la fréquence de cellules constante concernée. Cela donne une latence très cohérente. Si la gigue est détectée dans un environnement ATM, il est nécessaire d’examiner la configuration ATM. Quand ATM fonctionne correctement (pas de cellules abandonnées), vous pouvez vous attendre à ce que la gigue ne pose pas de problème. Dans l’encapsulation PPP (Point-to-Point Protocol), la gigue est presque toujours due au délai de sérialisation. Ceci peut être facilement géré avec Fragmentation de liaison et entrelacement sur la liaison PPP. La nature du protocole PPP signifie que les points d’extrémité PPP communiquent directement entre eux, sans réseau de commutateurs entre eux. Cela permet à l’administrateur réseau de contrôler toutes les interfaces concernées.
gigue dans un environnement Frame Relay
Trois paramètres doivent être traités pour détecter la gigue dans un environnement Frame Relay :
Pour des exemples de configuration et des informations relatives à cette configuration, référez-vous à VoIP sur Frame Relay avec qualité de service.
Modélisation du trafic
Vous devez vous assurer que vous formatez le trafic qui quitte le routeur vers le débit de données garanti (CIR) que le transporteur fournit. Vérifiez cela en examinant les statistiques Frame Relay et en vérifiant auprès de l’opérateur. Le premier point à examiner est les statistiques Frame Relay. Utilisez la commande show frame-relay pvc xx , où xx est le numéro DLCI (Data-link connection identifier). Vous devez recevoir une sortie similaire à celle-ci :
PVC Statistics for interface Serial0/1 (Frame Relay DTE) DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1 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 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec pvc create time 22:45:57, last time pvc status changed 22:45:57 Queueing strategy: weighted fair Current fair queue configuration: Discard Dynamic Reserved threshold queue count queue count 64 16 0 Output queue size 0/max total 600/drops 18303 fragment type end-to-end fragment size 1600 cir 20000 bc 1000 be 0 limit 125 interval 50 mincir 20000 byte increment 125 BECN response no IF_CONG no frags 103356 bytes 9807006 frags delayed 67241 bytes delayed 7127120 shaping active traffic shaping drops 18303
Reportez-vous à la description show frame-relay pvc pour une explication complète de tous les champs.
Que rechercher
Dans le résultat de la commande, vous devez vous préoccuper des valeurs qui indiquent si le réseau de trames a été encombré. Ces valeurs sont les paramètres FECN (Forward Explicit Congestion Notification), BECN (Backward Explicit Congestion Notification) et DE (Discard Eligible). Vous devez vous préoccuper uniquement des paquets d'entrée, car Cisco n'en envoie aucun. Vous pouvez voir une ou plusieurs de ces valeurs s'incrémenter. Cela dépend du type et de la configuration des commutateurs de trame que le fournisseur utilise. En termes généraux, si vous avez un formatage de trafic Frame Relay et que vous êtes configuré pour le même CIR que le circuit, vous ne devriez jamais voir ces valeurs incrémenter. Si ces valeurs s'incrémentent et que vous faites correspondre le véritable débit de données garanti du circuit, un élément du réseau du fournisseur de trames n'est pas configuré correctement.
Un bon exemple de ceci est si vous achetez un circuit CIR zéro, mais que vous avez une valeur de rafale. Certains fournisseurs vendent le circuit virtuel permanent (PVC) zéro CIR. Cela convient aux données, mais entraîne des problèmes de qualité vocale. Si vous regardez le résultat de la commande à partir d'un circuit CIR zéro, le nombre de paquets DE ou FECN est égal au nombre de paquets d'entrée. Pour aller plus loin, si vous avez un circuit virtuel permanent provisionné par le transporteur à 128 kb et que le débit de données garanti du routeur est défini à 512 kb, vous voyez ces compteurs augmenter (à un rythme plus lent). N’oubliez pas que vous ne regardez que les paquets qui entrent dans l’interface du routeur et que ce débit est contrôlé par les paramètres de formatage du trafic configurés sur le routeur à l’extrémité opposée du circuit virtuel permanent. Inversement, vous contrôlez ce qui est entré à l'autre routeur par lequel les paramètres de formatage du trafic sont configurés à l'extrémité locale.
Il est très important de ne pas dépasser le débit de données garanti pour le circuit virtuel permanent provisionné par le transporteur. Vous pouvez être sous ce débit de données garanti sans problème. Cependant, si vous l'excédez, vous verrez un encombrement.
La raison pour laquelle vous pouvez voir l'encombrement de cette manière est que le CIR configuré pour un circuit virtuel permanent spécifique sur un commutateur de trame détermine le débit de passage du trafic par ce commutateur (pour ce circuit virtuel permanent). Lorsque le débit de données garanti configuré sur le commutateur de trames est dépassé par le débit de données réel qu'il reçoit, il doit mettre en mémoire tampon les trames qui dépassent le débit de données garanti jusqu'à ce que la capacité soit disponible pour transférer les paquets mis en mémoire tampon. Tout paquet mis en mémoire tampon obtient soit le bit DE soit le bit FECN défini par le commutateur de trame.
Comme toujours, vous voulez également examiner de près les statistiques d'interface, et rechercher des pertes ou des erreurs pour vous assurer que tout fonctionne correctement au niveau de la couche physique. Pour ce faire, utilisez la commande show interface.
Si cela se produit, et que certains paquets doivent être mis en mémoire tampon dans le réseau de trames, la latence d’accès au routeur distant est plus longue. Cependant, lorsqu'il n'y a pas d'encombrement, ils passent par le temps de latence auquel vous vous attendez normalement. Cela entraîne une variation du temps delta entre les paquets reçus sur le routeur distant. D'où la gigue.
Fragmentation
La fragmentation est plus associée au délai de sérialisation qu'à la gigue. Cependant, sous certaines conditions, elle peut être la cause de la gigue. La fragmentation doit toujours être configurée dans la classe de mappage Frame Relay lors de l’utilisation de la voix en paquets. La configuration de ce paramètre a deux effets sur l'interface. Le premier effet est que tous les paquets de taille supérieure à la taille spécifiée sont fragmentés. Le deuxième effet est moins apparent, mais il est tout aussi 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 mise en file d'attente présentée dans le résultat de la commande show interface x montre que la mise en file d'attente FIFO (First In First Out) est en cours d'utilisation. Une fois la fragmentation appliquée à la classe de mappage Frame Relay, la sortie de cette commande affiche la stratégie de mise en file d’attente comme double FIFO. Ceci crée la file d'attente prioritaire qui est utilisée pour le trafic vocal sur l'interface. Il est fortement recommandé de définir la valeur de fragmentation sur les valeurs indiquées dans la section Fragmentation du document VoIP over Frame Relay with QoS. Si vous rencontrez toujours des problèmes de gigue à la valeur recommandée, diminuez la valeur de fragmentation une étape à la fois jusqu'à ce que la qualité de la voix devienne acceptable.
Mise en file d'attente
Il existe deux méthodes de mise en file d'attente généralement acceptées pour le trafic VoIP dans ce type d'environnement :
Une méthode ou l'autre doit être utilisée, ils ne doivent pas être configurés tous les deux. Si l'opération de mise en file d'attente semble correcte selon la documentation, vous pouvez conclure que la mise en file d'attente fonctionne correctement et que le problème se trouve ailleurs. La mise en file d'attente n'est généralement pas une cause de gigue, car les variations de délai qu'elle génère sont relativement faibles. Cependant, si les paquets VoIP ne sont pas mis en file d'attente correctement et qu'il y a des données sur le même circuit, la gigue peut en résulter.
Conclusion
La gigue est une variation de la latence des paquets vocaux. Les DSP à l’intérieur du routeur peuvent compenser une certaine gigue, mais peuvent être surmontés par une gigue excessive. Cela entraîne une mauvaise qualité de la voix. La cause de la gigue est qu'un paquet est mis en file d'attente ou retardé quelque part dans le circuit, où il n'y a pas eu de délai ou de mise en file d'attente pour d'autres paquets. Cela entraîne une variation de la latence. La gigue peut être causée à la fois par une mauvaise configuration du routeur et par une mauvaise configuration du circuit virtuel permanent par l'opérateur ou le fournisseur.
Informations connexes
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)