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

Conditions requises

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

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

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

Components Used

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

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Causes du brouillage de la voix

La qualité vocale est instable en raison du retard ou de la perte de variables des 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 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 l'espace en temps réel vide. Sans rien pour combler cette lacune au niveau de la réception, une partie de la parole transmise est perdue. Cela donne une voix agitée. La plupart des problèmes de voix discrète sont résolus en s'assurant que les paquets de voix ne sont pas très retardés (et plus encore, ne sont pas retardés de façon variable). Parfois, la détection de l'activité vocale (VAD) ajoute une coupure frontale à une conversation vocale. Il s'agit d'une autre cause de voix agitée (ou coupée).

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

Bande passante requise

Avant d'envisager d'appliquer des mesures pour réduire la gigue, fournissez 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 la VAD affecte également les besoins en bande passante. Si la compression d’en-tête (cRTP) du protocole 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 (User Datagram Protocol) + en-tête IP) + en-tête de couche 2

Cela équivaut à :

• 20 octets + compressés (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 IP RTP à un maximum de 4 octets. Cela donne 11,2 kbits/s à un débit de codec de 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 vocal

Il y a deux éléments importants dans la hiérarchisation de la voix. La première est la classification et le marquage du trafic vocal intéressant. La seconde consiste à hiérarchiser le trafic vocal marqué intéressant. Les deux sous-sections discutent de 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 les traverse. Les périphériques réseau utilisent les adresses 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. C'est la base de toute QoS.

La classification des paquets peut être gourmande en processeurs. Par conséquent, la classification doit être effectuée aussi loin que 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 les plus significatifs de l’octet ToS sont appelés bits de priorité IP. La plupart des applications et des fournisseurs prennent actuellement en charge la configuration 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), puissent être utilisés. Reportez-vous à la demande de commentaires (RFC).

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 par comportement de tronçon (PHB) concernant la classification des paquets et les fonctions de conditionnement du trafic telles que la mesure, le marquage, le formatage et la réglementation. Outre les RFC mentionnés précédemment, RFC 2597 définit les classes de transfert garanti (AF). Il s'agit d'une ventilation 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

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

Les bits XXX0000 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 = CRITIC/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 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é)

00000XX Bits 6, 7 : ECN

Ces deux sections traitent de deux façons de procéder en matière de classification et de marquage.

Pairs de numérotation vocale à classifier et marquer des paquets

Avec les passerelles VoIP Cisco, 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 correspondant à 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 les plus significatifs 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 sur support (paquets de voix) définis avec le modèle de bit EF (Transmission accélérée) 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 le logiciel Cisco IOS® Version 12.2(2)T. La priorité IP n'est plus disponible dans le logiciel Cisco IOS Version 12.2T. Cependant, la même chose est obtenue par la commande ip qos dscp. La priorité IP 5 (101) est mappée à 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 classifier et marquer les paquets

La méthode de classification et de marquage recommandée est l'interface de ligne de commande QoS modulaire. 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 ensemble pour plusieurs classes. Utilisez une commande class-map pour classer le trafic en fonction de différents 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 exécutant 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 les plus significatifs 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 VoIP. De même, la liste de contrôle d’accès 101 correspond au trafic de signalisation H.323 (port TCP (Transmission Control Protocol) 1720). Tout autre trafic est défini avec la priorité IP 0. La politique est appelée « mqc ». Elle est appliquée au trafic entrant sur Ethernet 0/0.

Hiérarchisation

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

Remarque : utilisez n'importe quel mécanisme de mise en file d'attente qui accorde 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 QoS CLI modulaire pour fournir la priorité à certaines classes et fournir une bande passante minimale garantie pour les autres classes. Pendant les périodes d'encombrement, la file d'attente prioritaire est contrôlé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 le respect des garanties de bande passante pour les autres classes.) 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 existe également 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 par défaut 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 à Mise en file d'attente à faible latence :

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 correspondant à la liste de contrôle d'accès 100 est classé comme « class voip » (c'est-à-dire trafic vocal). Il est prioritaire jusqu'à 32 kbits/s. La liste de contrôle d'accès 100 correspond aux ports UDP courants utilisés par VoIP. La liste d’accès 101 correspond au trafic de signalisation H.323 (port TCP 1720). Les données de classe 1 correspondent au trafic Web (port TCP 80, comme indiqué dans la liste de contrôle d’accès 102) et garantissent 64 kbits/s. La classe de données2 correspond au trafic Telnet (port TCP 23, comme indiqué dans la liste de contrôle d’accès 103) et garantit 32 kbits/s. La classe par défaut est configurée pour donner une part égale de la bande passante restante aux flux non classifiés. La politique s'appelle « 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-reserbandwidth 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 quittent la file d'attente dans le même ordre.	Configuration simple et fonctionnement rapide.	Aucune garantie de service prioritaire ou de bande passante n'est possible.1
Mise en file d'attente pondérée (WFQ)	Algorithme de hachage qui circule dans des files d'attente séparées où les poids sont utilisés pour déterminer le nombre de paquets traités à la fois. Vous définissez les poids en définissant la priorité IP et les valeurs DSCP.	Configuration simple. Valeur par défaut sur les liaisons inférieures à 2 Mbits/s.	Aucune garantie de service prioritaire ou de bande passante n'est possible.1
Mise en file d'attente personnalisée (CQ)	Le trafic est classifié en files d'attente multiples 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 supprimées pour chaque file d'attente. Par conséquent, il fournit la bande passante allouée statistiquement.	Est disponible depuis quelques années. Il 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. Il y a un nombre limité de files d'attente. La configuration est relativement difficile.1
Mise en file d'attente par priorité (PQ)	Le trafic est classé en files d'attente de priorité élevée, moyenne, normale et basse. Le trafic prioritaire est traité en premier, suivi du trafic de priorité moyenne, normale et basse.	Est disponible depuis quelques années. Il fournit des services prioritaires.	Le trafic de priorité supérieure interrompt les files d’attente de bande passante de priorité inférieure. Aucune garantie de bande passante n'est possible.2
Mise en file d'attente pondérée basée sur les classes (CBWFQ)	L'interface de ligne de commande QoS modulaire est utilisée pour classer le trafic. Le trafic classifié est placé dans des files d'attente de bande passante réservées ou dans une file d'attente non réservée par défaut. Un planificateur gère les files d'attente en fonction des pondérations afin que les garanties de bande passante soient respectées.	Semblable à LLQ, sauf qu'il n'y a pas de file d'attente prioritaire. Configuration simple et capacité à fournir des garanties de bande passante.	Aucun service prioritaire n'est possible.3
Priority Queue Weighted Fair Queuing (PQ-WFQ), également appelé IP RTP Priority	Une commande d’interface unique est utilisée pour fournir une maintenance prioritaire à tous les paquets UDP destinés à des numéros de port compris dans une plage spécifiée.	Configuration simple, une seule 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. Pas de bande passante garantie.4
LLQ, anciennement appelée PQCBWFQ (Priority Queue Class-Based Weighted Fair Queuing)	L'interface de ligne de commande 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, des files d'attente de bande passante réservées ou une file d'attente non réservée par défaut. Un planificateur gère les files d'attente en fonction des pondérations, de sorte que le trafic prioritaire soit envoyé en premier (jusqu'à une certaine limite contrôlée lors de l'encombrement) et que les garanties de bande passante soient respectées.	Configuration simple. Possibilité de donner la priorité à plusieurs classes de trafic et de donner des limites supérieures à 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 permettant de fournir plusieurs niveaux de priorité pour le moment, tout le trafic de priorité est envoyé via la même file d'attente de priorité. Des classes de priorité séparées peuvent avoir des limites de bande passante de priorité supérieure distinctes lors de l'encombrement. Cependant, le partage de la file d'attente prioritaire entre les applications peut potentiellement provoquer des instabilités4.

1. Non adapté à la voix.

2. Besoin de bande passante garantie pour la voix.

3. A besoin d'une latence à prendre en charge.

4. Suffisant pour la voix.

Délai de sérialisation

Même si la 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 retard de sérialisation lorsqu'ils doivent attendre derrière des paquets de données plus importants.

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 d'une taille pouvant atteindre 1 500 octets, sur une liaison plus lente, cela se traduit par un délai énorme. Le délai de sérialisation est très différent si le paquet de données est de 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/64 000 = 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/64 000 = 10 ms.

Par conséquent, un paquet vocal doit potentiellement attendre jusqu'à 187,5 ms avant d'être envoyé s'il est coincé 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. Cela entraîne une gigantesque gigue due à 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 retard de bout en bout de 150 ms et des exigences de gigue strictes, 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 dont le délai de sérialisation est supérieur à 10 ms doivent être fragmentés en blocs de 10 ms. Un bloc ou fragment de 10 ms est le nombre d'octets envoyés sur la liaison en 10 ms. Calculez la taille en utilisant la vitesse de liaison, comme indiqué dans cet exemple :

• Taille de fragmentation = (0,01 secondes * 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 des valeurs de fragmentation (sur tous les circuits virtuels permanents) en fonction du circuit virtuel permanent qui dispose de la bande passante la plus faible disponible. Par exemple, si trois circuits virtuels permanents ont une bande passante garantie de 512 kbits/s, 128 kbits/s et 256 kbits/s, configurez les trois circuits virtuels permanents avec une taille de fragment de 160 octets (la vitesse la plus basse est de 128 kbits/s 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 de MTU de 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.

Il existe actuellement trois mécanismes de fragmentation et d’entrelacement des liaisons. Pour plus d'informations sur les différents retards introduits dans un réseau de paquets, référez-vous à Comprendre le délai dans les réseaux vocaux de paquets. Ce tableau répertorie les avantages et les limites de ces solutions :

Mécanisme de fragmentation et d’entrelacement des liaisons (LFI)	Description	Avantages	Limites
Fragmentation MTU avec WFQ	Commande de niveau interface pour modifier la taille de MTU ou de MTU IP. Utilisé pour fragmenter de grands paquets IP à la taille de MTU spécifiée. LFI utilise WFQ pour interlaisser des paquets en temps réel entre les fragments.	Configuration simple.	Les fragments ne sont réassemblés que par l'application réceptrice. Par conséquent, une utilisation inefficace du réseau. Seuls les paquets IP dont le bit DF (Do not Fragment) n'est pas défini peuvent gérer correctement la fragmentation. Très gourmand en processeurs. Non recommandé.
LFI MLPPP (Multilink Point-to-Point Protocol)	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 agir comme un canal virtuel de grande taille.	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-formatage doit être activée et une taille de fragmentation 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é.	Disponible uniquement sur les circuits virtuels permanents Frame Relay avec la commande frame-relay traffic-formatage activée.

VAD

Une conversation vocale régulière consiste en plusieurs moments de silence. Une conversation vocale typique se compose d'un silence de 40 à 50 %. Étant donné qu'aucune voix ne transite par le réseau pour 40 % d'un appel vocal, une partie de la bande passante peut être économisée en déployant VAD. Avec la technologie VAD, la passerelle recherche les failles dans la parole. Il remplace ces espaces par du bruit de confort (bruit de fond). Ainsi, une quantité de bande passante est économisée. Mais il y a un compromis. Il y a peu de temps (en ordre de millisecondes) avant que les codecs détectent l'activité vocale suivie d'une période de silence. Cette petite durée entraîne la coupure frontale de la voix reçue. Pour éviter l'activation pendant des pauses très courtes et pour compenser la coupure, 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, elle inclut les 5 ms précédents et le discours en cours. VAD se désactive automatiquement lors d'un appel si le bruit ambiant l'empêche de distinguer le bruit de la parole du bruit de fond. Cependant, si la bande passante n'est pas un problème, désactivez le VAD.

Régler les paramètres VAD

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

music-threshold

Un seuil initial est déterminé qui détermine quand VAD doit devenir actif. Ceci est contrôlé en définissant la commande music-threshold threshold_value sur un port vocal, comme illustré dans cet exemple. La plage pour cela 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 VAD à une puissance de signal beaucoup plus faible (le volume doit chuter très bas avant d'être considéré comme un silence). La configuration d’une valeur supérieure (plus proche de -30 dBm) entraîne l’activation de la fonction VAD pour une faible perte de puissance du signal vocal. Il entraîne la lecture des paquets de bruit de confort plus souvent. Cependant, cela conduit parfois à une petite coupure 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

voice vad-time

Une fois que le VAD devient actif, le composant du bruit de fond et du bruit de confort est contrôlé en configurant la commande voice vad-time timer_value dans la configuration globale, comme illustré dans cet exemple. Il s'agit du délai en millisecondes pour la détection des silences et la suppression de la transmission de paquets vocaux. La valeur par défaut de la durée d'efficacité est 250 ms. Cela signifie qu'en moins de 250 ms, le bruit de confort commence. La plage de ce compteur est comprise entre 250 et 65 536 ms. Si une valeur élevée est configurée pour cela, le bruit de confort entre en jeu beaucoup plus tard (le bruit de fond continue à être émis). Si ce paramètre est configuré pour 65 536 ms, le bruit de confort est désactivé. Une valeur plus élevée pour ce compteur est souhaitée pour une transition plus douce 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 ne permet pas d'économiser 30 à 35 % de la bande passante souhaitée.

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 type de 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 VoIPoFR - QoS

Dans cet exemple (qui contient uniquement les sections pertinentes de la configuration), on suppose que la vitesse du circuit de relais de trame est de 256 kbits/s. Le débit garanti CIR (Committed Information Rate) 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. Le 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 à 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 de PVC 100 (qui est de 64 kbits/s). Comme le montre 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, formatage du trafic, priorité LLQ / IP RTP).

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 les sections pertinentes de la configuration), on suppose que la QoS doit être configurée pour un contrôleur T1 fractionné point à point (comportant douze canaux). Il existe un maximum de quatre appels vocaux simultanés à un moment donné. La tâche de configuration consiste à configurer cette interface série avec encapsulation PPP, à la faire partie d’un groupe multiliaison, à créer une interface multiliaison (appartenant au même groupe multiliaison) et à configurer toute la QoS sur l’interface multiliaison. Pour plus de détails sur la configuration de VoIP sur PPP, référez-vous à Liens VoIP sur PPP 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
!

Mécanisme de gigue et de lecture

Il y a toujours des entités non contrôlées dans un réseau qui contribuent à d'autres retards et gigue dans les paquets vocaux reçus. En modifiant la mémoire 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 lecture

Le tampon d'instabilité est un tampon temporel. 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 sélection :

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 rétention du tampon d'instabilité, le paquet est immédiatement abandonné. Si le paquet est dans la capacité de mise en mémoire tampon, il est placé dans la mémoire tampon d'instabilité. L'emplacement de ce paquet dans la mémoire tampon de gigue dépend de l'horodatage RTP calculé pour ce paquet. Si aucun paquet vocal n'est disponible, le contrôle de lecture tente de le cacher (prédit le paquet manquant). Si la fonction VAD est activée, le bruit de confort est émis.

La responsabilité du contrôle d'exécution 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 sur l'hôte.

La dissimulation d’un paquet vocal se fait soit par dissimulation de prédiction, soit par dissimulation de silence. La dissimulation de prédiction est basée sur le paquet précédent et le paquet suivant (si disponible). Il fonctionne mieux avec des codecs à faible débit (5 à 16 kbits/s). La perte de paquets vocaux pour un codec à débit élevé (32 à 64 kbits/s) peut entraîner une mauvaise dissimulation de prédiction. La dissimulation de 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 mener à la qualité de la voix robotisée. La dissimulation de silence est la pire forme de dissimulation de prédiction. Il entre en jeu quand il n'y a aucune information disponible pour prédire. Il s'agit simplement d'une dissimulation de fond. Elle commence lorsqu'il y a des retards élevés et un plus grand nombre de pertes de paquets. Trop de dissimulation de silence conduit à une qualité vocale agitée. La dissimulation de prédiction est bonne pour 30 secondes après quoi le silence se joue.

Tampon de gigue

Le tampon de gigue est confiné par un point d'eau élevé et un point d'eau faible. La limite supérieure de temps est la limite supérieure dans laquelle un paquet doit arriver pour être exécuté à temps. Les paquets qui arrivent après la limite supérieure sont marqués comme des paquets en retard ou perdus. La limite inférieure est la durée minimale pendant laquelle un paquet doit arriver pour être exécuté à temps. Les paquets qui arrivent avant la limite inférieure sont considérés comme des paquets précoces (ils peuvent encore ê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 les points d'eau élevés reste la même pendant toute la durée de l'appel. Ceci est augmenté 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 identique tout au long de la durée de l'appel. Ce mode de tampon de gigue est appelé « mode adaptatif », où la passerelle de terminaison adapte sa mémoire tampon de gigue en fonction du modèle de trafic. L'autre mode est le mode fixe. En mode fixe, il y a une valeur initiale pour la limite inférieure et la limite supérieure. Cette valeur est basée sur le délai de réception estimé (voir la section show voice call <numéro-port> de ce document).

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

Identification du délai et de 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 fournit de nombreuses informations sur une conversation en cours. Cette sortie affiche certains 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

D'après la sortie de la commande show call active voice brief, vous voyez que tout ce qui est reçu sur la branche de 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 branches IP (26165) qui sont transférés à la branche 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 d'autres 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 bien connecté à la passerelle ou si vous êtes connecté à une passerelle, assurez-vous d'avoir émis la commande terminal monitor depuis le niveau exec.

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

Dans cette sortie, la valeur pour Rx Delay Est (ms) est 71. Il s'agit de la valeur actuelle du tampon d'instabilité. On en déduit une valeur pour la limite supérieure et la limite inférieure. Une valeur initiale moyenne pour la limite supérieure de l'eau est de 70 ms, alors que celle pour la limite inférieure est de 60 ms. Une fois qu'une valeur initiale est définie, la passerelle garde le suivi de tous les paquets précoces ou tardives reçus. Comme le montre le résultat ici, les chutes de dissimulation de prédiction sont proches de 250 ms, tandis que la dissimulation de silence est de 30 ms. Il y a toujours une valeur plus élevée pour la dissimulation de prédiction puisque la dissimulation de silence n'est qu'un scénario pire de dissimulation de prédiction. Pour chaque perte de dissimulation de prédiction, il y a une augmentation de l'abandon de dépassement de tampon.

Si vous voyez un rejet de la mémoire tampon, cela ne signifie pas nécessairement que vous voyez une augmentation de la limite supérieure d'eau. La limite supérieure de la zone tampon de gigue est la limite supérieure. Elle ne change que si une tendance est observée. En d'autres termes, il doit y avoir un flux continu de paquets en retard. Cela entraîne une augmentation du tampon de gigue. Dans le résultat ici, une telle tendance est présente. Par conséquent, la limite d'eau élevée est augmentée de 70 ms à 161 ms. Si cette valeur n'est pas modifiée (et si vous voyez toujours 14 paquets en retard), cela signifie 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, deux paquets sont hors séquence. Ceci est visible dans la sortie Rx Non-Seq Pkts. Comme il ne s’agit pas d’une valeur positive, il est conclu qu’il n’y a pas eu non plus de pertes 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 kits de confort Tx et les kits de confort Rx. En ce qui concerne les résultats de l'exemple, il est conclu que le téléphone connecté à ce routeur reste généralement silencieux puisque vous disposez de nombreux Comfort Pkts Tx. En même temps, vous avez zéro Rx Comfort Pkts, ce qui signifie que l'autre extrémité parle continuellement.

Comparez le résultat ici avec le résultat de la commande précédente. Il y a une augmentation du nombre de paquets en retard Rx (de 14 à 26). Cependant, il n'y a pas d'augmentation de la valeur de la limite supérieure. Cela indique que les 12 paquets sont retardés sporadiquement. Le dépassement de mémoire tampon est porté à 910 ms. Toutefois, comme aucune tendance n'est observée, la limite élevée n'est pas augmentée.

Dans le résultat ici, vous avez un Rx Early Pkts : 3. Cela signifie qu’un paquet arrive beaucoup avant qu’il ne soit attendu. Comme le montre le résultat ici, le tampon de gigue s'est étiré pour s'adapter à tout paquet plus précoce 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

Configuration de la mémoire tampon d'instabilité sur une passerelle

Les directives QoS traitées dans ce document permettent de résoudre le problème de qualité vocale qui se complique ou se détériore. La configuration de la mémoire tampon de délai de lecture est une solution de contournement pour une mise en oeuvre de QoS incorrecte dans le réseau. Utilisez-la uniquement comme solution de blocage ou comme outil de dépannage et de réduction des problèmes de gigue introduits dans le réseau.

Mode de délai de lecture

La mémoire tampon d'instabilité est configurée pour le mode fixe ou le mode adaptatif. En mode adaptatif, la passerelle vous permet de configurer une valeur minimale pour la mémoire tampon de gigue, une valeur maximale et une valeur nominale. Le tampon d'instabilité 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 atteindre 1 700 ms. L'introduction d'un délai de bout en bout pose un problème de configuration de la valeur maximale élevée. Choisissez la valeur du délai d'exécution 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
!

Sous le mode fixe, la passerelle examine la valeur configurée pour le mode nominal. Bien qu'il vous permette de configurer la valeur minimale et maximale pour le délai de lecture, il est ignoré lorsqu'il est configuré pour le mode fixe. En mode fixe, la valeur de la marque d'eau élevée ou la valeur de la marque d'eau faible reste toujours constante. Il est basé sur la valeur nominale et sur la valeur Rx Delay Est (ms). Il est donc possible qu'en mode fixe, vous configuriez la valeur sur 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 le protocole 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

Historique de révision