Résolution des problèmes de voix hachée du QoS

Introduction

Pour que le remplacement d'un réseau téléphonique commuté public (PSTN) par un système de voix par paquets soit réaliste, la qualité de réception d'un système de voix par paquets doit être comparable à celle des services de téléphonie de base. Ceci signifie que les transmissions vocales doivent être d'une qualité constamment élevée. Comme d'autres applications en temps réel, un système de voix par paquets possède une grande bande passante et est sensible aux retards. Pour que les transmissions vocales soient intelligibles (non saccadées) pour le récepteur, les paquets vocaux ne peuvent pas être perdus, excessivement retardés ou subir des retards variables (également appelés sautillements). Ce document aborde diverses considérations de Qualité de service (QoS) pour le dépannage des problèmes liés aux transmissions de voix saccadées. Les paquets vocaux perdus ou retardés sont les principales causes des transmissions de voix saccadées.

Conditions préalables

Exigences

Les lecteurs de ce document doivent connaître les points suivants :

• Configuration de base de la voix par paquets (VoIP, VoFR (Voice over Frame Relay) ou VoATM (Voice over ATM) selon leurs besoins).

• Compréhension de base de la hiérarchisation, de la fragmentation, des différents codecs et de leurs besoins en bande passante.

Composants utilisés

Les informations contenues dans ce document s'appliquent à toutes les versions logicielles et matérielles des passerelles vocales Cisco.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. All of the devices used in this document started with a cleared (default) configuration. Si vous travaillez dans un réseau opérationnel, assurez-vous de bien comprendre l'impact potentiel de toute commande avant de l'utiliser.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Causes de la voix saccadée

La qualité vocale instable est due au retard variable ou à la perte de paquets vocaux sur le réseau. Lorsqu'un paquet vocal est retardé pour atteindre sa destination, la passerelle de destination perd des informations en temps réel. Dans ce cas, la passerelle de destination doit prédire ce que peut être le contenu du paquet manqué. La prédiction conduit à ce que la voix reçue n'ait pas les mêmes caractéristiques que la voix transmise. Cela conduit à une voix reçue qui sonne robotique. Si un paquet vocal est retardé au-delà de la capacité de prédiction d'une passerelle de réception, la passerelle laisse vide l'intervalle de temps réel. Comme il n'y a rien pour combler ce vide à l'extrémité de réception, une partie de la parole transmise est perdue. Il en résulte une voix agitée. La plupart des problèmes vocaux instables sont résolus en s'assurant que les paquets vocaux ne sont pas très retardés (et plus que cela, pas de manière variable). Parfois, la détection d'activité vocale (VAD) ajoute une coupure frontale à une conversation vocale. C'est une autre cause de voix hachée (ou coupée).

Les différentes sections de ce document montrent comment réduire l'occurrence de voix saccadée. La plupart de ces mesures nécessitent l'introduction d'une gigue minimale dans votre réseau vocal.

Besoin en bande passante

Avant d'envisager d'appliquer des mesures de réduction de la gigue, prévoyez une bande passante réseau suffisante pour prendre en charge le trafic vocal en temps réel. Par exemple, un appel VoIP G.711 à 80 kbits/s (charge utile de 64 kbits/s + en-tête de 16 kbits/s) semble médiocre sur une liaison de 64 kbits/s, car au moins 16 kbits/s des paquets (soit 20 %) sont abandonnés. Les besoins en bande passante varient en fonction du codec utilisé pour la compression. Différents codecs ont des charges utiles et des exigences d'en-tête différentes. L’utilisation de VAD affecte également les besoins en bande passante. Si la compression d'en-tête RTP (Real Time Protocol) est utilisée, elle peut réduire davantage les besoins en bande passante.

Par exemple, la bande passante requise pour un appel vocal utilisant le codec G.729 (charge utile de 20 octets par défaut) avec cRTP est la suivante :

• Charge utile vocale + compressée (en-tête RTP + en-tête UDP + en-tête IP) + en-tête de couche 2

Cela équivaut à :

• 20 octets + compressé (12 octets + 8 octets + 20 octets) + 4 octets

Cela équivaut à :

• 28 octets, puisque la compression d'en-tête réduit l'en-tête RTP IP à un maximum de 4 octets. Cela permet d'obtenir un débit de codec de 11,2 kbits/s à 8 kbits/s (50 paquets par seconde).

Référez-vous à Voix sur IP (VoIP) - Consommation de bande passante par appel pour plus d'informations.

Priorité du trafic voix

La hiérarchisation de la voix comporte deux éléments importants. La première est la classification et le marquage du trafic vocal intéressant. La deuxième consiste à définir la priorité du trafic vocal intéressant marqué. Les deux sous-sections traitent des différentes approches de classification, de marquage et de hiérarchisation de la voix.

Classification et marquage

Afin de garantir la bande passante pour les paquets VoIP, un périphérique réseau doit être en mesure d'identifier les paquets dans tout le trafic IP qui le traverse. Les périphériques réseau utilisent l'adresse IP source et de destination dans l'en-tête IP ou les numéros de port UDP source et de destination dans l'en-tête UDP pour identifier les paquets VoIP. Ce processus d'identification et de regroupement est appelé classification. Elle constitue la base de toute qualité de service.

La classification des paquets peut être intensive en processeur. Par conséquent, la classification doit être effectuée le plus loin possible vers la périphérie du réseau. Comme chaque saut doit encore déterminer le traitement qu’un paquet doit recevoir, vous devez disposer d’une méthode de classification plus simple et plus efficace dans le coeur du réseau. Cette classification plus simple est obtenue en marquant ou en définissant l'octet de type de service (ToS) dans l'en-tête IP. Les trois bits de poids fort de l’octet ToS sont appelés bits de priorité IP. La plupart des applications et des fournisseurs prennent actuellement en charge la définition et la reconnaissance de ces trois bits. Le marquage évolue de sorte que les six bits les plus significatifs de l'octet ToS, appelés DSCP (Differentiated Services Code Point), peuvent être utilisés. Reportez-vous à la RFC (Request for Comments).

Les services différenciés (DiffServ) sont un nouveau modèle dans lequel le trafic est traité par des systèmes intermédiaires avec des priorités relatives basées sur le champ ToS. Définie dans RFC 2474 et RFC 2475 , la norme DiffServ remplace la spécification initiale pour définir la priorité des paquets décrite dans RFC 791. Le DiffServ augmente le nombre de niveaux de priorité définissables en réappropriant des bits d'un paquet IP pour le marquage prioritaire. L'architecture DiffServ définit le champ DiffServ. Il remplace l'octet ToS dans IP V4 pour prendre des décisions de comportement par saut (PHB) sur la classification des paquets et les fonctions de conditionnement du trafic telles que le comptage, le marquage, la mise en forme et la réglementation. En plus des RFC mentionnés précédemment, le RFC 2597 définit les classes de transfert assuré (AF). Il s'agit d'une répartition des champs DSCP. Pour plus d'informations sur DSCP, référez-vous à Mise en œuvre des stratégies en matière de qualité de service avec DSCP.

ToS Byte - P2 P1 P0 T3 T2 T1 T0 CU

Priorité IP: trois bits (P2-P0), ToS : quatre bits (T3-T0), CU : un bit

Champ DiffServ - DS5 DS4 DS3 DS2 DS1 DS0 ECN ECN

DSCP: six bits (DS5-DS0), ECN : deux bits

XXX00000 Les bits 0, 1, 2 (DS5, DS4, DS3) sont des bits de priorité, où :

• 111 = Contrôle du réseau = Priorité 7

• 110 = Contrôle interréseau = Priorité 6

• 101 = CRITIQUE/ECP = priorité 5

• 100 = Remplacement Flash = Priorité 4

• 011 = Flash = Priorité 3

• 010 = Immédiat = Priorité 2

• 001 = Priorité = Priorité 1

• 000 = Routine = Priorité 0

000XXX00 Les bits 3, 4, 5 (DS2, DS1, DS0) sont des bits de délai, de débit et de fiabilité.

• Bit 3 = Délai [D] (0 = Normal ; 1 = Faible)

• Bit 4 = Débit [T] (0 = Normal ; 1 = Élevé)

• Bit 5 = Fiabilité [R] (0 = Normal ; 1 = Élevé)

000000XX Bits 6, 7 : ECN

Ces deux sections traitent de deux méthodes de classification et de marquage.

Homologues de numérotation vocale pour classer et marquer les paquets

Avec les passerelles Cisco VoIP, vous utilisez généralement des terminaux de numérotation dial-peer vocaux pour classer les paquets VoIP et marquer les bits de priorité IP. Cette configuration montre comment marquer les bits de priorité IP :

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip precedence 5

Dans l'exemple ci-dessus, tout appel VoIP qui correspond à la commande dial-peer voice 100 voip a tous ses paquets de données utiles vocales définis avec la priorité IP 5. Cela signifie que les trois bits de poids fort de l'octet ToS IP sont définis sur 101.

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip qos dscp ef media
ip qos dscp af31 signaling

Dans l'exemple ci-dessus, tout appel VoIP qui correspond à la commande dial-peer voice 100 voip a tous ses paquets de données utiles multimédias (paquets vocaux) définis avec le modèle de bit EF 101110. Tous les paquets de signalisation sont définis avec le modèle de bit AF 011010.

Remarque : la commande ip qos dscp est prise en charge depuis la version 12.2(2)T du logiciel Cisco IOS®. La priorité IP n'est plus disponible dans le logiciel Cisco IOS Version 12.2T. Cependant, la même chose est réalisée par la commande ip qos dscp. La priorité IP 5 (101) correspond à IP DSCP 101000. Pour plus d'informations, référez-vous à Classification de la signalisation VoIP et des supports avec DSCP pour QoS.

CLI QoS modulaire pour classer et marquer les paquets

La méthode de classification et de marquage recommandée est l'interface de ligne de commande modulaire QoS. Il s'agit d'une méthode de configuration basée sur un modèle qui sépare la classification de la stratégie. Cela permet de configurer plusieurs fonctions QoS pour plusieurs classes. Utilisez une commande class-map pour classer le trafic en fonction de divers critères de correspondance et une commande policy-map pour déterminer ce qui doit arriver à chaque classe. Appliquez la stratégie au trafic entrant ou sortant sur une interface en émettant la commande service-policy. Cet exemple de configuration montre comment utiliser l'interface de ligne de commande QoS modulaire pour classer et marquer les paquets :

access-list 100 permit udp any any range 16384 32767
access-list 101 permit tcp any any eq 1720
!
class-map match-all voip
match access-group 100
class-map match-all control
match access-group 101
!
policy-map mqc
class voip
set ip precedence 5
class control
set ip precedence 5
class class-default
set ip precedence 0
!
interface Ethernet0/0
service-policy input mqc

Dans cet exemple de configuration, tout trafic correspondant à la liste de contrôle d'accès (ACL) 100 est classé comme « class voip » et défini avec la priorité IP 5. Cela signifie que les trois bits de poids fort de l'octet ToS IP sont définis sur 101. La liste de contrôle d'accès 100 correspond aux ports UDP courants utilisés par la VoIP. De même, la liste de contrôle d’accès 101 correspond au trafic de signalisation H.323 (port TCP 1720). Tout autre trafic est défini avec la priorité IP 0. La stratégie est appelée « mqc ». Il est appliqué au trafic entrant sur Ethernet 0/0.

Hiérarchisation

Une fois que chaque saut du réseau est capable de classer et d'identifier les paquets VoIP (via les informations de port/d'adresse ou via l'octet ToS), ces sauts fournissent ensuite à chaque paquet VoIP la QoS requise. À ce stade, configurez des techniques spéciales pour fournir une mise en file d'attente prioritaire afin de vous assurer que les paquets de données volumineux n'interfèrent pas avec la transmission de données vocales. Cela est généralement nécessaire sur les liaisons WAN plus lentes où il existe un risque élevé d'encombrement. Une fois que tout le trafic intéressant est placé dans des classes de QoS en fonction de leurs exigences de QoS, fournissez des garanties de bande passante et un service prioritaire par le biais d'un mécanisme intelligent de mise en file d'attente de sortie. Une file d'attente prioritaire est requise pour la VoIP.

Remarque :  Utilisez un mécanisme de mise en file d'attente qui donne une priorité élevée à la VoIP. Cependant, la mise en file d'attente à faible latence (LLQ) est recommandée, car elle est flexible et facile à configurer.

LLQ utilise la méthode de configuration modulaire QoS CLI pour donner la priorité à certaines classes et pour garantir une bande passante minimale aux autres classes. Pendant les périodes d'encombrement, la file d'attente prioritaire est régulée au débit configuré de sorte que le trafic prioritaire n'utilise pas toute la bande passante disponible. (Si le trafic prioritaire monopolise la bande passante, il empêche les garanties de bande passante pour les autres classes d'être respectées.) Si vous provisionnez correctement LLQ, le trafic qui entre dans la file d'attente prioritaire ne doit jamais dépasser le débit configuré.

LLQ permet également de spécifier les profondeurs de file d'attente pour déterminer quand le routeur doit abandonner des paquets s'il y a trop de paquets qui attendent dans une file d'attente de classe particulière. Il y a aussi une commande class-default qui est utilisée pour déterminer le traitement de tout le trafic non classifié par une classe configurée. La classe-default est configurée avec une commande fair-queue. Cela signifie que chaque flux non classifié reçoit une part approximativement égale de la bande passante restante.

Cet exemple montre comment configurer LLQ. Pour plus d'informations, référez-vous à Low Latency Queuing :

access-list 100 permit udp any any range 16384 32000
access-list 101 permit tcp any any eq 1720
access-list 102 permit tcp any any eq 80
access-list 103 permit tcp any any eq 23
!
class-map match-all voip
match access-group 100
class-map match-all voip-control
natch access-group 101
class-map match-all data1
match access-group 102
class-map match-all data2
match access-group 103
!
policy-map llq
class voip
priority 32
class voip-control
bandwidth 8
class data1
bandwidth 64
class data2
bandwidth 32
class class-default
fair-queue
!
interface Serial1/0
bandwidth 256
service-policy output llq

Dans cet exemple, tout trafic qui correspond à la liste de contrôle d'accès 100 est classé comme « class voip » (ce qui signifie le trafic vocal). Il bénéficie d'une priorité élevée jusqu'à 32 Kbits/s. La liste de contrôle d’accès 100 correspond aux ports UDP courants utilisés par la VoIP. La liste d'accès 101 correspond au trafic de signalisation H.323 (port TCP 1720). La classe data1 correspond au trafic Web (port TCP 80, comme indiqué dans la liste d'accès 102) et garantit 64 kbits/s. Les données de classe 2 correspondent au trafic Telnet (port TCP 23 tel qu’il apparaît dans la liste de contrôle d’accès 103) et garantissent 32 kbits/s. La classe par défaut est configurée pour attribuer une part égale de la bande passante restante aux flux non classés. La politique est appelée « llq ». Il est appliqué au trafic sortant sur Serial1/0, qui a une bande passante totale de 256 kbits/s.

Remarque : par défaut, la bande passante totale garantie et la bande passante prioritaire pour toutes les classes doivent être inférieures à 75 % de la bande passante de l'interface. Modifiez ce pourcentage en émettant la commande max-reserved bandwidth interface.

Ce tableau compare les différents mécanismes de mise en file d'attente logicielle avec leurs avantages et limitations respectifs.

Mécanisme De Mise En File D'Attente Logicielle	Description	Avantages	Limites
Premier entré, premier sorti (FIFO)	Les paquets arrivent et sortent de la file d'attente dans le même ordre.	Configuration simple et fonctionnement rapide.	Aucune garantie de priorité ou de bande passante.1
Weighted Fair Queuing (WFQ)	Algorithme de hachage qui circule dans des files d’attente séparées où des pondérations sont utilisées pour déterminer le nombre de paquets traités simultanément. Vous définissez des pondérations en définissant des valeurs de priorité IP et de DSCP.	Configuration simple. Valeur par défaut sur les liaisons inférieures à 2 Mbits/s.	Aucune garantie de priorité ou de bande passante.1
Mise en file d'attente personnalisée	Le trafic est classé en plusieurs files d'attente avec des limites de file configurables. Les limites de file d'attente sont calculées en fonction de la taille moyenne des paquets, de l'unité de transmission maximale (MTU) et du pourcentage de bande passante à allouer. Les limites de file d'attente (en nombre d'octets) sont retirées de la file d'attente pour chaque file d'attente. Par conséquent, il fournit statistiquement la bande passante allouée.	Il est disponible depuis quelques années. Elle permet une allocation approximative de bande passante pour différentes files d'attente.	Aucune maintenance prioritaire n'est possible. Les garanties de bande passante sont approximatives. Le nombre de files d'attente est limité. La configuration est relativement difficile.1
Mise en file d'attente prioritaire	Le trafic est classé en files d'attente de priorité élevée, moyenne, normale et faible. Le trafic de priorité élevée est traité en premier, suivi du trafic de priorité moyenne, normale et faible.	Il est disponible depuis quelques années. Il fournit une maintenance prioritaire.	Le trafic prioritaire prive les files d'attente de bande passante de priorité inférieure. Aucune garantie de bande passante n’est possible.2
CBWFQ (Class-Based Weighted Fair Queuing)	La CLI QoS modulaire est utilisée pour classer le trafic. Le trafic classifié est placé dans des files d'attente de bande passante réservée ou dans une file d'attente non réservée par défaut. Un ordonnanceur gère les files d'attente en fonction des pondérations, de sorte que les garanties de bande passante sont respectées.	Similaire à LLQ, sauf qu'il n'y a pas de file d'attente prioritaire. Configuration simple et capacité à fournir des garanties de bande passante.	Aucune maintenance prioritaire n'est possible.3
File d'attente prioritaire - Mise en file d'attente pondérée (PQ-WFQ), également appelée priorité IP RTP	Une commande d'interface unique est utilisée pour fournir un service prioritaire à tous les paquets UDP destinés à des numéros de port pairs dans une plage spécifiée.	Configuration simple d'une commande. Assure la maintenance prioritaire des paquets RTP.	Tout autre trafic est traité avec WFQ. Le trafic RTCP (Real-Time Conferencing Protocol) n'est pas prioritaire. Aucune capacité de bande passante garantie.4
LLQ, précédemment appelé PQCBWFQ (Priority Queue Class-Based Weighted Fair Queuing)	La CLI QoS modulaire avec file d'attente prioritaire est utilisée pour classer le trafic. Le trafic classifié est placé dans une file d'attente prioritaire, dans des files d'attente de bande passante réservée ou dans une file d'attente non réservée par défaut. Un ordonnanceur gère les files d'attente sur la base de pondérations de sorte que le trafic prioritaire soit envoyé en premier (jusqu'à une certaine limite régulée pendant l'encombrement) et que les garanties de bande passante soient satisfaites.	Configuration simple. Possibilité de donner la priorité à plusieurs classes de trafic et de définir des limites supérieures pour l'utilisation prioritaire de la bande passante. Vous pouvez également configurer des classes à bande passante garantie et une classe par défaut.	Aucun mécanisme ne permet encore de fournir plusieurs niveaux de priorité, tout le trafic prioritaire est envoyé par la même file d'attente prioritaire. Des classes de priorité distinctes peuvent avoir des limites de bande passante de priorité supérieure distinctes pendant l'encombrement. Cependant, le partage de la file d'attente prioritaire entre les applications peut potentiellement introduire une gigue.4

1. Ne convient pas à la voix.

2. Besoin de bande passante garantie pour la voix.

3. Nécessite que la latence soit prise en charge.

4. Suffisant pour la voix.

Délai de sérialisation

Même si la mise en file d'attente fonctionne au mieux et donne la priorité au trafic vocal, il arrive que la file d'attente prioritaire soit vide et qu'un paquet d'une autre classe soit traité. Les paquets des classes de bande passante garanties doivent être traités en fonction de leur poids configuré. Si un paquet vocal prioritaire arrive dans la file d'attente de sortie pendant que ces paquets sont traités, le paquet vocal peut attendre un temps important avant d'être envoyé. Les paquets vocaux subissent un délai de sérialisation lorsqu'ils doivent attendre derrière des paquets de données plus volumineux.

Le délai de sérialisation peut introduire la pire forme de gigue pour les paquets vocaux. Si les paquets vocaux doivent attendre derrière un paquet de données de 1500 octets, sur une liaison plus lente, cela se traduit par un retard important. Le délai de sérialisation est très différent si le paquet de données comporte 80 octets, comme illustré dans cet exemple :

• Délai de sérialisation sur une liaison de 64 kbits/s en raison d’un paquet de 1 500 octets = 1 500*8/64000 = 187,5 ms.

• Délai de sérialisation sur une liaison de 64 kbits/s en raison d’un paquet de 80 octets = 80*8/64000 = 10 ms.

Par conséquent, un paquet vocal doit potentiellement attendre jusqu’à 187,5 ms avant d’être envoyé s’il est bloqué derrière un seul paquet de 1 500 octets sur une liaison de 64 kbits/s. D’autre part, un autre paquet vocal doit attendre seulement 10 ms au niveau de la passerelle de destination. Il en résulte une gigue importante qui se produit en raison de la variance du délai entre les paquets. Sur la passerelle d'origine, les paquets vocaux sont généralement envoyés toutes les 20 ms. Avec un budget de délai de bout en bout de 150 ms et des exigences strictes de gigue, un écart de plus de 180 ms est inacceptable.

Introduire un mécanisme de fragmentation qui garantit que la taille d’une unité de transmission est inférieure à 10 ms. Tous les paquets ayant un délai de sérialisation supérieur à 10 ms doivent être fragmentés en segments de 10 ms. Un morceau ou un fragment de 10 ms correspond au nombre d'octets envoyés sur la liaison en 10 ms. Calculez la taille à l'aide de la vitesse de liaison, comme indiqué dans cet exemple :

• Taille de fragmentation = (0,01 seconde * 64 000 bits/s) / (8 bits/octet) = 80 octets

Il faut 10 ms pour envoyer un paquet ou un fragment de 80 octets sur une liaison de 64 kbits/s.

Dans le cas de plusieurs circuits virtuels permanents (PVC) ATM ou Frame Relay sur une seule interface physique, configurez les valeurs de fragmentation (sur tous les PVC) en fonction du PVC dont la bande passante disponible est la plus faible. Par exemple, si trois circuits virtuels permanents disposent d’une bande passante garantie de 512, 128 et 256 kbits/s, configurez les trois circuits virtuels permanents avec une taille de fragment de 160 octets (la vitesse la plus faible étant de 128 kbits/s, ce qui nécessite une taille de fragment de 160 octets). Ces valeurs sont recommandées pour différentes vitesses de liaison :

Link Speed (kbps)         Fragmentation Size (bytes) 
56                                  70 
64                                  80 
128                                 160 
256                                 320 
512                                 640 
768                                 960 
1024                                1280 
1536                                1920

Remarque : aucune fragmentation n'est requise si la taille du fragment est supérieure à la taille MTU de la liaison. Par exemple, pour une liaison T1 avec une MTU de 1 500 octets, la taille du fragment est de 1 920 octets. Par conséquent, aucune fragmentation n'est requise. La taille de fragmentation des paquets ne doit jamais être inférieure à la taille des paquets VoIP. Ne fragmentez pas les paquets VoIP. La fragmentation de ces paquets entraîne de nombreux problèmes de configuration et de qualité des appels.

Trois mécanismes de fragmentation et d’entrelacement des liaisons sont actuellement disponibles. Pour plus d'explications sur les différents retards introduits dans un réseau par paquets, référez-vous à Comprendre le retard dans les réseaux vocaux par paquets. Ce tableau répertorie leurs avantages et leurs limites :

Mécanisme de fragmentation et d'entrelacement de liaison (LFI)	Description	Avantages	Limites
Fragmentation MTU avec WFQ	Commande de niveau interface pour modifier la taille MTU ou la taille MTU IP. Utilisé pour fragmenter de grands paquets IP à la taille MTU spécifiée. LFI utilise WFQ pour entrelacer des paquets en temps réel entre les fragments.	Configuration simple.	Les fragments sont réassemblés uniquement par l'application réceptrice. Par conséquent, une utilisation inefficace du réseau. Seuls les paquets IP dont le bit Ne pas fragmenter (DF) n'est pas défini peuvent gérer correctement la fragmentation. Forte sollicitation du processeur. Non recommandé.
Multilink Point-to-Point Protocol (MLPPP) LFI	Sur les liaisons série point à point, le protocole MLPPP doit d’abord être configuré, puis une taille de fragmentation doit être définie en ms. L'entrelacement doit également être activé sur l'interface multiliaison.	Les paquets sont fragmentés à une extrémité de la liaison et réassemblés à l’autre extrémité. Plusieurs liaisons peuvent être combinées pour faire office de grand canal virtuel.	Disponible uniquement sur les liaisons configurées pour PPP. Les solutions PPP sur Frame Relay ou PPP sur ATM sont également prises en charge dans le logiciel Cisco IOS version 12.1(5)T ou ultérieure.
Fragmentation Frame Relay (FRF.12)	Sur les circuits virtuels permanents Frame Relay, la commande frame-relay traffic-shaping doit être activée et une taille de fragmentation doit être définie sous map-class.	Les paquets sont fragmentés à une extrémité du circuit virtuel permanent et réassemblés à l’autre extrémité.	Uniquement disponible sur les circuits virtuels permanents Frame Relay avec la commande frame-relay traffic-shaping activée.

VAD

Une conversation vocale régulière se compose de plusieurs moments de silence. Une conversation vocale typique se compose de 40 à 50 % de silence. Étant donné qu'aucune voix ne transite par le réseau pendant 40 % d'un appel vocal, le déploiement de la fonctionnalité VAD permet d'économiser une partie de la bande passante. Avec VAD, la passerelle recherche les lacunes dans la voix. Il remplace ces espaces par du bruit de confort (bruit de fond). Ainsi, une quantité de bande passante est économisée. Cependant, il y a un compromis. Un petit temps (de l'ordre de quelques millisecondes) s'écoule avant que les codecs ne détectent une activité vocale suivie d'une période de silence. Ce temps réduit entraîne l'écrêtage frontal de la voix reçue. Pour éviter l’activation pendant de très courtes pauses et compenser l’écrêtage, le VAD attend environ 200 ms après l’arrêt de la parole avant d’arrêter la transmission. Lors du redémarrage de la transmission, il inclut les 5 ms de parole précédents avec la parole actuelle. VAD se désactive automatiquement sur un appel si le bruit ambiant l'empêche de faire la distinction entre la parole et le bruit de fond. Toutefois, si la bande passante ne pose pas de problème, désactivez le VAD.

Régler les paramètres VAD

Deux paramètres dictent le fonctionnement de VAD. Il s'agit des commandes music-threshold et voice vad-time.

seuil de musique

Un seuil initial est défini pour déterminer le moment où le VAD doit devenir actif. Ceci est contrôlé en définissant la commande music-threshold threshold_value sur un port vocal, comme montré dans cet exemple. La plage est comprise entre -70 décibels par milliwatt (dBm) et -30 dBm. La valeur par défaut est -38 dBm. La configuration d'une valeur inférieure (vers -70 dBm) entraîne l'activation de la VAD à une intensité de signal beaucoup plus faible (le volume doit baisser très bas avant d'être considéré comme un silence). La configuration d’une valeur plus élevée (proche de -30 dBm) rend la VAD active, même pour une faible baisse de la puissance du signal vocal. Il conduit la lecture à jouer des paquets de bruit de confort plus souvent. Cependant, cela conduit parfois à une coupure mineure de l'audio.

3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#music-threshold ?
WORD Enter a number b/w (-70 to -30)
3640-6(config-voiceport)#music-threshold -50
3640-6(config-voiceport)#end
3640-6#
3640-6#show run | be voice-portvoice-port 3/0/0 music-threshold -50

voix vad-time

Une fois que le VAD devient actif, la composante de bruit de fond et de bruit de confort est contrôlée en configurant la commande voice vad-time timer_value sous la configuration globale, comme indiqué dans cet exemple. Délai en millisecondes pour la détection de silence et la suppression de la transmission de paquets vocaux. La valeur par défaut du temps de maintien est de 250 ms. Cela signifie que dans les 250 ms, le bruit de confort commence. La plage de ce minuteur est comprise entre 250 et 65536 ms. Si une valeur élevée est configurée pour cela, le bruit de confort intervient beaucoup plus tard (le bruit de fond continue d'être émis). Si ce paramètre est configuré pour 65536 ms, le bruit de confort est désactivé. Une valeur plus élevée pour ce minuteur est souhaitée pour une transition plus lisse entre le bruit de fond et le bruit de confort. L'inconvénient de la configuration de la commande voice vad-time à un niveau élevé est qu'elle n'atteint pas l'économie de bande passante souhaitée de 30 à 35 %.

3640-6#
3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice vad-time ?
<250-65536> milliseconds
3640-6(config)#voice vad-time 750
3640-6(config)#end
3640-6#
3640-6#
3640-6#
3640-6#show run | be vad-time voice vad-time 750

Exemples de configuration type pour QoS

Un scénario typique pour la configuration d'appels VoIP est soit sur une liaison Frame Relay, soit sur une liaison PPP. Voici des exemples de configuration pour ces scénarios.

Exemple de configuration de VoIPoFR - QoS

Dans cet exemple (qui ne contient que des sections pertinentes de la configuration), on suppose que la vitesse du circuit frame-relay est de 256 kbits/s. Le débit garanti d'informations garanti (CIR) sur PVC 100 est de 64 kbits/s et sur PVC 200 est de 192 kbits/s. Le circuit virtuel permanent 100 est utilisé pour transporter les données et la voix. PVC 200 est utilisé uniquement pour transporter des données. Il existe un maximum de quatre appels vocaux simultanés à un moment donné. Configurez la fragmentation sur les deux circuits virtuels permanents en fonction du débit de données garanti du circuit virtuel permanent vocal à bande passante la plus faible (PVC transportant la voix). D'après les exemples de ce document, cela signifie que la taille de fragmentation est décidée sur la base du CIR du PVC 100 (qui est de 64 Kbits/s). Comme indiqué dans le tableau de la section Délai de sérialisation, pour une liaison de 64 kbits/s, une taille de fragmentation de 80 octets est requise. La même taille de fragmentation doit être configurée pour PVC 200.

Pour plus de détails sur la configuration de VoIP sur Frame Relay, référez-vous à VoIP sur Frame Relay avec qualité de service (Fragmentation, Traffic Shaping, LLQ / IP RTP Priority).

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoFR
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Serial4/0:0
bandwidth 256
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial4/0:0.1 point-to-point
bandwidth 64
ip address 10.10.10.10 255.255.255.0
frame-relay ip rtp header-compression
frame-relay interface-dlci 100
 class voice
!
interface Serial4/0:0.2 point-to-point
bandwidth 192
ip address 20.20.20.20 255.255.255.0
frame-relay interface-dlci 200
class data
!
map-class frame-relay data
frame-relay fragment 80
frame-relay adaptive-shaping becn
frame-relay cir 256000
frame-relay bc 32000
frame-relay be 0
frame-relay mincir 192000
frame-relay fair-queue
!
map-class frame-relay voice
frame-relay fragment 80
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 640
frame-relay be 0
frame-relay mincir 64000
service-policy output VoIPoFR
!
!
access-list 101 permit tcp any any eq 1720
!
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1

Exemple de configuration de VoIP sur PPP - QoS

Dans cet exemple (qui ne contient que des sections pertinentes de la configuration), on suppose que la QoS doit être configurée pour un contrôleur T1 fractionné point à point (qui a douze canaux). Il existe un maximum de quatre appels vocaux simultanés à un moment donné. La tâche de configuration implique la configuration de cette interface série avec l'encapsulation PPP, son intégration dans un groupe multiliaison, la création d'une interface multiliaison (qui appartient au même groupe multiliaison) et la configuration de la qualité de service sur l'interface multiliaison. Pour plus de détails sur la configuration de VoIP sur PPP, référez-vous à VoIP sur PPP Liens avec Qualité de Service (LLQ / IP RTP Priority, LFI, cRTP).

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoPPP
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Multilink7
bandwidth 768
ip address 10.10.10.10 255.255.255.0
ip tcp header-compression iphc-format
service-policy output VoIPoPPP
no cdp enable
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 7
ip rtp header-compression iphc-format
!
!
interface Serial4/0:0
bandwidth 768
no ip address
encapsulation ppp
no fair-queue
ppp multilink
multilink-group 7
!
!
access-list 101 permit tcp any any eq 1720
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1
!

Gigue et mécanisme de lecture

Il existe toujours des entités non contrôlées dans un réseau qui contribuent à des retards et des gigues supplémentaires dans les paquets vocaux reçus. En modifiant le tampon de gigue sur la passerelle de terminaison, la gigue non contrôlée est résolue dans le réseau vocal.

Mécanisme De Jeu

Le tampon d'instabilité est un tampon de temps. Il est fourni par la passerelle de terminaison pour rendre le mécanisme de lecture plus efficace. Voici un schéma fonctionnel du mécanisme de lecture :

Lorsque le contrôle de lecture reçoit un paquet vocal, il analyse l'horodatage RTP. Si le paquet vocal est retardé au-delà de la capacité de stockage du tampon d'instabilité, le paquet est immédiatement abandonné. Si le paquet se trouve dans la capacité de mise en mémoire tampon, il est placé dans la mémoire tampon de gigue. L'emplacement de ce paquet dans le tampon d'instabilité dépend de l'horodatage RTP calculé pour ce paquet. Dans le cas où il n'y a pas de paquet vocal disponible, le contrôle de lecture tente de le dissimuler (prédit le paquet en absence). Si VAD est activé, le bruit de confort est émis.

La responsabilité du contrôle de lecture est de gérer les événements de paquets perdus, de paquets dupliqués, de paquets corrompus et de paquets hors séquence. Ces événements sont gérés par l'alignement temporel des paquets vocaux instables, la lecture du bruit de confort (si VAD est configuré) ou même la régénération des tonalités DTMF (dual tone multifrequency) à diffuser à l'hôte.

La dissimulation d'un paquet vocal se fait soit par dissimulation de prédiction, soit par dissimulation de silence. Le masquage de prédiction est basé sur le paquet précédent et le paquet suivant (s'il est disponible). Il fonctionne mieux avec des codecs à faible débit binaire (5 à 16 kbits/s). La perte de paquets vocaux pour un codec à débit binaire élevé (32 kbits/s à 64 kbits/s) peut potentiellement entraîner une mauvaise dissimulation de prédiction. La dissimulation de la prédiction commence lorsqu’il y a des retards faibles et peu fréquents ou un nombre moindre de pertes de paquets. Trop de dissimulation de prédiction peut entraîner une qualité vocale robotique. La dissimulation de silence est la pire forme de dissimulation de prédiction. Elle intervient lorsqu'il n'y a pas d'information disponible pour prédire. Il s'agit simplement d'une dissimulation de fond. Elle commence lorsque les délais sont élevés et que le nombre de paquets perdus augmente. Un silence trop dissimulé conduit à une qualité vocale instable. La dissimulation de prédiction est bonne pendant 30 ms après quoi la dissimulation de silence entre en jeu.

Tampon D'Instabilité

Le tampon de gigue est confiné par une marque d'eau haute et une marque d'eau basse. La limite supérieure de la limite de temps est la limite supérieure dans laquelle un paquet est censé arriver pour une lecture dans les délais. Les paquets qui arrivent après la limite supérieure sont marqués comme paquets en retard ou paquets perdus. La limite inférieure de l'eau est le temps minimal pendant lequel un paquet est censé arriver pour une lecture dans les délais. Les paquets qui arrivent avant la limite inférieure sont considérés comme des paquets précoces (ils peuvent toujours être lus à temps).

Si la passerelle de terminaison continue de voir un incrément dans l'arrivée des paquets en retard, elle augmente la limite supérieure. Cette valeur pour la limite supérieure reste la même pendant toute la durée de l'appel. Cette valeur est augmentée jusqu'à un maximum défini dans la configuration. De la même manière, la passerelle de terminaison observe le nombre de paquets précoces reçus. Si ces paquets commencent à fréquenter la passerelle, cela réduit la limite inférieure. Cette valeur reste la même pendant toute la durée de l'appel. Ce mode de tampon de gigue est appelé « mode adaptatif », où la passerelle de terminaison adapte son tampon de gigue en fonction du modèle de trafic. L'autre mode est "fixe". Dans le mode fixe, il y a une valeur initiale pour le repère de niveau bas et le repère de niveau haut. Cette valeur est basée sur le délai de réception estimé ( voir la section show voice call <port-number> de ce document).

Pour plus de détails sur la mémoire tampon de gigue, référez-vous à Présentation de la gigue dans les réseaux vocaux par paquets (plates-formes Cisco IOS).

Identifier le délai et la gigue

Cette section décrit comment identifier la gigue dans votre réseau.

show call active voice

La commande show call active voice brief donne beaucoup d'informations sur une conversation en cours. Cette sortie affiche quelques points importants qui sont appris à partir de cette commande :

11E4 : 2170927hs.1 +600 pid:10 Answer 1000 active
dur 00:08:43 tx:26157/522967 rx:7044/139565
Tele 3/0/0:9: tx:151310/755/0ms g729r8 noise:-62 acom:0 i/0:-56/-48 dBm
11E4 : 2171198hs.1 +329 pid:20 Originate 2000 active
dur 00:08:43 tx:7044/139565 rx:26165/523127
IP 30.30.30.29:18682 rtt:51ms pl:148590/290ms lost:0/0/15 delay:65/60/132ms g729r8

Dans la sortie de la commande show call active voice brief, vous voyez que tout ce qui est reçu sur la branche Téléphonie (rx:7044) est transmis à la branche IP (tx:7044). Il en va de même pour les paquets reçus sur les tronçons IP (26165) qui sont transférés vers le tronçon de téléphonie (26157). La différence entre le nombre de paquets reçus sur la branche IP et le nombre de paquets transmis sur la branche Téléphonie est due aux paquets en retard qui ne parviennent pas à temps.

Cette sortie de la commande show call active voice (sans le mot clé « brief »), indique plus de détails sur les paramètres qui identifient directement la gigue.

GapFillWithSilence=850 ms
GapFillWithPrediction=9230 ms
GapFillWithInterpolation=0 ms
GapFillWithRedundancy=0 ms

show voice call <numéro-port>

La commande show voice call port-number fournit des informations utiles. Assurez-vous d'être soit sur console dans la passerelle, soit si vous êtes connecté à une passerelle par Telnet, assurez-vous que vous avez émis la commande terminal monitor du niveau d'exécution.

Remarque : cette commande n'est pas disponible sur les plates-formes AS5x00/AS5x50.

Dans cette sortie, la valeur de Rx Delay Est (ms) est 71. Il s'agit de la valeur de tampon d'instabilité actuelle. Une valeur pour la marque de haute eau et la marque de basse eau est déduite sur cette base. La valeur initiale moyenne de la laisse de haute mer est de 70 msec, alors que celle de la laisse de basse mer est de 60 msec. Une fois qu'une valeur initiale est définie, la passerelle conserve une trace de tous les paquets précoces ou tardifs reçus. Comme on le voit dans la sortie ici, les pertes de masquage de prédiction sont voisines de 250 ms, alors que les pertes de masquage de silence sont de 30 ms. Il y a toujours une valeur plus élevée pour la dissimulation de prédiction, car la dissimulation de silence n'est qu'un scénario pire de dissimulation de prédiction. Pour chaque perte de masquage de prédiction, il y a une augmentation de la suppression du dépassement de tampon.

Si vous constatez une élimination de la mémoire tampon, cela ne signifie pas nécessairement que vous constatez une augmentation de la limite supérieure de l'eau. La limite supérieure de la zone tampon de gigue est la limite supérieure de la limite supérieure. Il ne change que si une tendance est observée. En d'autres termes, il doit y avoir un flux continu de paquets en retard. Il en résulte une augmentation du tampon de gigue. Dans le résultat ici, une telle tendance est présente. Par conséquent, la limite supérieure est augmentée de 70 msec à 161 msec. Si cette valeur n'est pas modifiée (et si vous voyez toujours 14 paquets en retard), cela implique qu'il s'agit de paquets en retard sporadiques, ne formant pas une tendance.

À partir du résultat de la commande show call active voice, recherchez les paquets perdus. Pour chaque paquet perdu, vous voyez deux paquets qui sont hors séquence. Ceci est visible sur la sortie Rx Non-Seq Pkts. Comme il ne s’agit pas d’une valeur positive, on conclut qu’il n’y a pas non plus eu de perte de paquets.

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 195, Tx Sig Pkts: 0, Tx Comfort Pkts: 10
Tx Dur(ms): 192070, Tx Vox Dur(ms): 388, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 9604, Rx Signal Pkts: 0, Rx Comfort Pkts: 0
Rx Dur(ms): 192070, Rx Vox Dur(ms): 191560, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 0, Rx Late Pkts: 14
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 71
Rx Delay Lo Water Mark(ms): 60, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 250, Interpolate Conceal(ms): 0
Silence Conceal(ms): 30, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 500, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -49.9 from PBX/Phone, Tx -41.7 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.1
TDM Bgd Levels(dBm0): -58.9, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

Observez les packs confort Tx et confort Rx. D'après les résultats de l'exemple, il est conclu que le téléphone connecté à ce routeur est généralement silencieux, car vous disposez de nombreux kits de confort Tx. En même temps, vous avez zéro Rx Comfort Pkts, ce qui signifie que l'autre extrémité parle en permanence.

Comparez le résultat obtenu ici avec celui de la commande précédente. Le nombre de paquets Rx Late (de 14 à 26) a augmenté. Toutefois, il n'y a pas d'augmentation de la valeur de la laisse de haute mer. Cela indique que les 12 paquets sont retardés sporadiquement. La suppression du Buffer Overflow passe à 910 ms. Cependant, comme aucune tendance n'est observée, la limite supérieure n'est pas augmentée.

Dans le résultat ici, vous avez un paquet Rx Early : 3. Cela signifie qu’un paquet arrive bien avant qu’il ne soit attendu. Comme le montre la sortie ici, le tampon de gigue s'est étiré pour s'adapter à d'autres paquets précoces en réduisant la limite inférieure de 60 à 51.

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 209, Tx Sig Pkts: 0, Tx Comfort Pkts: 11
Tx Dur(ms): 337420, Tx Vox Dur(ms): 416, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 16843, Rx Signal Pkts: 0, Rx Comfort Pkts: 1
Rx Dur(ms): 337420, Rx Vox Dur(ms): 335920, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 3, Rx Late Pkts: 26
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 72
Rx Delay Lo Water Mark(ms): 51, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 510, Interpolate Conceal(ms): 0
Silence Conceal(ms): 70, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 910, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -51.5 from PBX/Phone, Tx -44.1 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.9
TDM Bgd Levels(dBm0): -61.3, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

Configurer le tampon d'instabilité sur une passerelle

Les directives QoS couvertes dans ce document prennent en charge le problème de qualité vocale instable ou détériorée. La configuration du tampon de délai de lecture est une solution de contournement pour une implémentation QoS incorrecte dans le réseau. Utilisez-le uniquement comme solution de continuité ou comme outil de dépannage et de réduction des problèmes de gigue introduits dans le réseau.

Mode Playout-delay

Le tampon d'instabilité est configuré pour le mode fixe ou le mode adaptatif. En mode adaptatif, la passerelle vous permet de configurer une valeur minimale pour le tampon d'instabilité, une valeur maximale et une valeur nominale. Le tampon de gigue attend que les paquets arrivent dans la plage de valeurs nominales. La valeur nominale doit être égale ou supérieure au minimum, et égale ou inférieure au maximum. La mémoire tampon s'étend jusqu'à la valeur maximale configurée. Cela peut s'étendre jusqu'à 1 700 ms. L'introduction d'un délai de bout en bout est un problème lié à la configuration d'une valeur maximale élevée. Choisissez la valeur du délai de lecture maximal de sorte qu'il n'introduise pas de délai indésirable dans le réseau. Ce résultat est un exemple de tampon de gigue configuré pour le mode adaptatif :

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode adaptive
3640-6(config-voiceport)#playout-delay maximum 400
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#playout-delay minimum low
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay maximum 400
playout-delay nominal 70
playout-delay minimum low
playout-delay mode adaptive
!

En mode fixe, la passerelle recherche la valeur nominale dans la valeur configurée. Bien qu'il vous permette de configurer la valeur minimale et maximale du délai de lecture, il est ignoré lorsqu'il est configuré pour le mode fixe. En mode fixe, la valeur de la marque de l'eau haute ou la valeur de la marque de l'eau basse reste toujours constante. Il est basé sur la valeur nominale et sur la valeur Rx Delay Est (ms). Il est donc possible que dans le mode fixe, vous configuriez la valeur comme 200 ms. Cependant, si le délai de réception estimé est proche de 100 ms, c'est ce que la limite supérieure et la limite inférieure sont définies pour toute la durée de l'appel.

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode fixed
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay mode fixed
playout-delay nominal 70
!

Pour plus de détails sur la configuration du délai de lecture, référez-vous à Améliorations du délai de lecture pour la voix sur IP.

Informations connexes

• Implémentation de stratégies de qualité de service avec le point de code de services différenciés (DSCP)
• Mise en file d'attente à faible latence (LLQ)
• Comparaison des commandes bandwidth et priority d'une stratégie de service QoS
• Configuration de la fragmentation et de l’entrelacement des liaisons pour les circuits virtuels Frame Relay et ATM
• Configuration de la fragmentation et de l’entrelacement des liaisons pour PPP multiliaison
• Assistance technique concernant la technologie vocale
• Assistance concernant les produits vocaux et de communications unifiées
• Dépannage des problèmes de téléphonie IP Cisco
• Support technique - Cisco Systems