Voix : Qualité vocale

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

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu

VAD

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 devraient être bien informés de ces derniers :

  • Configuration de base de la voix par paquets (VoIP, voix sur relais de trame (VOFR) ou Voix sur ATM (VoATM) selon leur condition requise).

  • Compréhension de base de hiérarchisation de Voix, de fragmentation, de différents codecs et de leurs bandes passantes nécessaires.

Composants utilisés

Les informations dans ce document appliquent à tout le Cisco des Passerelles voix logiciel et versions de matériel.

Les informations présentées dans ce document ont été créées à partir de périphériques dans un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). 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 de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Causes de voix saccadée

La qualité de voix saccadée est provoqué par par des paquets vocaux étant variable retardés ou perdus dans le réseau. Quand un paquet vocal est retardé en atteignant sa destination, la passerelle de destination a une perte de l'information en temps réel. Dans une telle éventualité, la passerelle de destination doit prévoir ce qu'être le contenu du paquet manqué peut probablement. La prévision mène à la Voix reçue n'ayant pas les mêmes caractéristiques comme la Voix transmise. Ceci mène à une Voix reçue que cela retentit robotique. Si un paquet vocal est retardé au delà de la capacité de prévision d'une passerelle de réception, la passerelle laisse l'écart en temps réel vide. Avec rien à combler cette lacune à l'extrémité réceptrice, une partie du discours transmis est perdue. Ceci a comme conséquence la voix saccadée. Plusieurs des questions de voix saccadée sont résolues en veillant que les paquets vocaux ne sont pas très retardés (et davantage que cela, pas variable retardé). Parfois, la détection d'activité vocale (VAD) ajoute le découpage frontal à une conversation vocale. C'est une autre cause (ou coupé) de Voix variable.

Les diverses sections dans ce document affichent comment réduire l'exemple de la voix saccadée. La plupart de ces mesures exigent assurer l'introduction du jitter minimum dans votre réseau voix.

Bande passante nécessaire

Avant que vous envisagiez d'appliquer toutes les mesures pour réduire le jitter, provision la bande passante suffisante de réseau pour prendre en charge le trafic vocal en temps réel. Par exemple, 80 bruits d'un appel du Kbps G.711 VoIP (charge utile de 64 Kbits/s + en-tête de 16 Kbit/s) pauvres au-dessus de l'des 64 Kbits/s joignent parce qu'au moins des 16 Kbit/s des paquets (qui est de 20 pour cent) sont relâchés. Les bandes passantes nécessaires varient basé sur les codecs utilisés pour le compactage. Les différents codecs ont différentes charges utiles et conditions requises d'en-tête. L'utilisation de VAD affecte également la bande passante nécessaire. Si la compression d'en-tête de Protocole RTP (Real-Time Protocol) (cRTP) est utilisée, elle peut plus loin diminuer la bande passante nécessaire.

Par exemple, la bande passante exigée pour une communication voix utilisant G.729 les codecs (par défaut charge utile de 20 octets) avec le cRTP, est comme ceci :

  • La charge utile voix + a compressé (en-tête de RTP + en-tête + en-tête IP de Protocole UDP (User Datagram Protocol)) l'en-tête +Layer 2

C'est équivalent à :

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

Ceci égale :

  • 28 octets, puisque la compression d'en-tête ramène l'en-tête du protocole RTP d'IP à un maximum de 4 octets. Ceci rapporte 11.2 Kbps à un débit de 8 codecs de Kbps (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 importants composants dans la Voix de donner la priorité. Le premier est classifiant et marquant le trafic vocal intéressant. Le deuxième donne la priorité au trafic vocal intéressant marqué. Les deux paragraphes ici discutent de diverses approches à la classification, marquant, et Voix de donner la priorité.

Classification et marquage

Afin de garantir la bande passante pour des paquets VoIP, un périphérique de réseau doit pouvoir identifier les paquets dans tout le trafic IP qui le traverse. Les périphériques de réseau emploient la source et l'adresse IP de destination dans l'en-tête IP, ou la source et les numéros de port UDP de destination dans l'en-tête d'UDP, pour identifier des paquets VoIP. Ce procédé d'identification et de groupement s'appelle la classification. Ce sert de base à fournir n'importe quel QoS.

La classification de paquet peut être processeur intensif. Par conséquent, la classification doit être faite en tant que loin vers la périphérie du réseau comme possible. Puisque chaque saut doit toujours faire une détermination sur le traitement un paquet devrait recevoir, vous doit avoir une méthode plus simple et plus efficace de classification dans le noyau de réseau. Cette classification plus simple est réalisée par le marquage ou la configuration l'octet de Type de service (ToS) dans l'en-tête IP. Les trois bits les plus significatifs de l'octet de tos s'appellent des bits de Priorité IP. La plupart des applications et constructeurs prennent en charge actuellement la configuration et identifier ces trois bits. Le marquage évolue de sorte que les six bits les plus significatifs de l'octet de tos, appelés le Differentiated Services Code Point (DSCP), puissent être utilisés. Référez-vous au Request For Comments (RFC).

La Différenciation de services (DiffServ) est 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 de 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.leavingcisco.com leavingcisco.com leavingcisco.com 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 de DiffServ définit le champ de DiffServ. Il remplace l'octet de tos dans IP V4 pour prendre des décisions du comportement de Par-saut (PHB) au sujet de classification de paquet et pour trafiquer des fonctions de traitement telles que doser, marquer, former, et maintenir l'ordre. En plus des RFC précédemment mentionnés, RFC 2597leavingcisco.com définit les classes assurément de l'expédition (AF). C'est une panne des champs de 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.

Octet de tos - CU du t1 T0 de T2 de T3 P2 P1 P0

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

Champ de DiffServ - DS1 DS0 ECN ECN DS3 DS2 DS5 DS4

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

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

  • 111 = Network Control = priorité 7

  • 110 = contrôle d'interréseau = priorité 6

  • 101 = CRITIC/ECP = priorité 5

  • 100 = dépassement d'instantané = priorité 4

  • 011 = éclair = 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 retard, de débit, et de fiabilité.

  • 3 mordus = retard [D] (0 = normale ; 1 = bas)

  • 4 mordus = débit [T] (0 = normale ; 1 = haute)

  • 5 mordus = fiabilité [R] (0 = normale ; 1 = haute)

000000XX bits 6, 7 : ECN

Ces deux sections discutent deux manières dans lesquelles la classification et le marquage sont faits.

Pairs de cadran de Voix pour classifier et marquer des paquets

Avec des passerelles VoIP de Cisco, vous utilisez habituellement des pairs de cadran de Voix pour classifier les paquets VoIP et pour marquer les bits de Priorité IP. Cette configuration affiche 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, n'importe quel appel VoIP qui apparie la commande de voip du dial-peer voice 100 a tous ses paquets de charge utile voix réglés avec la Priorité IP 5. Ceci signifie que les trois bits les plus significatifs de l'octet de tos IP sont placés à 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, n'importe quel appel VoIP qui apparie la commande de voip du dial-peer voice 100 a tous ses paquets de charge utile de medias (paquets vocaux) réglés avec la séquence de bits (E-F) expédiée 101110 d'expédition. Tous les paquets de signalisation sont placés avec la séquence de bits 011010 AF.

Remarque: La commande d'ip qos dscp est prise en charge depuis la version de logiciel 12.2(2)T de ½ du ¿  de Cisco IOSïÂ. La Priorité IP n'est plus disponible dans la version du logiciel Cisco IOS 12.2T. Cependant, le même est réalisé par la commande d'ip qos dscp. La Priorité IP 5 (101) trace à l'IP DSCP 101000. Le pour en savoir plus, se rapportent à classifier la signalisation VoIP et les medias avec le DSCP pour QoS.

QoS modulaire CLI pour classifier et marquer des paquets

La méthode recommandée de classification et de marquage à l'utiliser est le QoS modulaire CLI. C'est une méthode basée sur modèle de configuration qui sépare la classification de la stratégie. Ceci permet de plusieurs caractéristiques de QoS à configurer ensemble pour des plusieurs classes. Utilisez une commande de class-map de classifier le trafic basé sur le divers critère de correspondance et une commande de policy-map de déterminer quels besoins d'arriver à chaque classe. Appliquez la stratégie à entrant ou le trafic sortant sur une interface en émettant la commande de service-stratégie. Cet exemple de configuration affiche comment employer QoS modulaire CLI pour classifier et marquer des 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, n'importe quel trafic qui apparie la liste de contrôle d'accès (ACL) 100 est classifié en tant que le « voip de classe » et positionnement avec la Priorité IP 5. Ceci signifie que les trois bits les plus significatifs de l'octet de tos IP sont placés à 101. L'ACL 100 apparie les ports UDP communs utilisés par VoIP. De même de l'ACL 101 de correspondances le trafic de signalisation H.323 (port 1720 de Protocole TCP (Transmission Control Protocol)). Tout autre trafic est placé avec la Priorité IP 0. La stratégie s'appelle le « mqc ». Il est appliqué au trafic entrant sur les Ethernets 0/0.

Donner la priorité

Après que chaque saut dans le réseau puisse classifier et identifier les paquets VoIP (par le port/informations d'adresse ou par l'octet de tos), ces sauts puis fournissent à chaque paquet VoIP le QoS exigé. À ce moment là, configurez les techniques spéciales pour fournir la file d'attente à priorité déterminée pour s'assurer que les grands paquets de données ne gênent pas la transmission de données vocales. Ceci est habituellement exigé sur des liens WAN plus lents où il y a une possibilité élevée d'encombrement. Une fois que tout le trafic intéressant est placé dans des classes de QoS basées sur leurs conditions requises de QoS, fournissez les garanties et la priorité de bande passante entretenant par un mécanisme de mise en file d'attente intelligent de sortie. Une file d'attente prioritaire est exigée pour le VoIP.

Remarque:  Utilisez n'importe quel mécanisme de mise en file d'attente qui accorde efficacement la haute priorité VoIP. Cependant, le Fonction Low Latency Queuing (LLQ) est recommandé parce qu'il est flexible et facile de configurer.

LLQ emploie la méthode modulaire de configuration de QoS CLI pour fournir la priorité à certaines classes et pour fournir la garantie de bande passante minimale pour d'autres classes. Au cours des périodes d'encombrement, la file d'attente prioritaire est maintenue l'ordre au débit configuré de sorte que le trafic prioritaire n'épuise pas toute la bande passante disponible. (Si le trafic prioritaire monopolise la bande passante, il empêche des garanties de bande passante pour d'autres classes d'être rencontré.) Si vous provision LLQ correctement, le trafic qui entre dans la file d'attente prioritaire devrait ne jamais dépasser le débit configuré.

LLQ laisse également des profondeurs de la file d'attente à spécifier pour déterminer quand le routeur doit relâcher des paquets s'il y a trop de paquets qui attendent dans n'importe quelle file d'attente particulière de classe. Il y a également une commande de classe-par défaut qui est utilisée pour déterminer le traitement de tout le trafic non classifié par une classe configurée. Le classe-par défaut est configuré avec une commande de foire-file d'attente. Ceci signifie que chaque écoulement non classifié est donné un partage approximativement égal de la bande passante restante.

Cet exemple affiche comment configurer LLQ. Le pour en savoir plus, se rapportent à la basse Mise en file d'attente de 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, n'importe quel trafic qui apparie l'ACL 100 est classifié en tant que « voip de classe » (le trafic vocal de signification). C'est donné à une haute priorité jusqu'à 32 Kbps. L'ACL 100 apparie les ports UDP communs utilisés par VoIP. La liste d'accès 101 apparie H.323 le trafic de signalisation (port TCP 1720). Classez le trafic web des correspondances data1 (port TCP 80 comme vu dans liste d'accès 102) et garantissez des 64 Kbits/s. Le trafic de telnet de correspondances de la classe data2 (port TCP 23 comme vu dans ACL 103) et garanties 32 Kbps. La classe par défaut est configurée pour donner un partage égal de la bande passante restante aux écoulements non classifiés. La stratégie s'appelle le « llq ». Il est appliqué au trafic sortant sur Serial1/0, qui a une bande passante totale de 256 Kbps.

Remarque: Par défaut, la toutes les bande passante garantie et bande passante prioritaire pour toutes les classes doit être moins de 75 pour cent de la bande passante d'interface. Modifiez ce pourcentage en émettant la commande d'interface maximum-réservée de bande passante.

Cette table compare différents mécanismes de mise en file d'attente de logiciel à leurs avantages et limites respectifs.

Mécanisme de mise en file d'attente de logiciel Description Avantages Limites
First-In-First-Out (FIFO) Les paquets arrivent et partent de la file d'attente dans exactement la même commande. Configuration simple et exécution rapide. Aucune garanties possible.1 d'entretien ou de bande passante prioritaire
Mise en file d'attente pondérée (WFQ) Un algorithme de hachage qui circule dans des files d'attente séparée où des poids sont utilisés pour déterminer combien des paquets sont entretenus à la fois. Vous définissez des poids en plaçant la Priorité IP et les valeurs DSCP. Configuration simple. Par défaut sur des liens moins de 2 Mbits/s. Aucune garanties possible.1 d'entretien ou de bande passante prioritaire
Mise en file d'attente faite sur commande (CQ) Le trafic est classifié dans de plusieurs files d'attente avec des limites configurables de file d'attente. Les limites de file d'attente sont calculées ont basé en moyenne la longueur de paquet, le Maximum Transmission Unit (MTU), et le pourcentage de la bande passante à allouer. Des limites de file d'attente (en terme des octets) sont retirées de la file d'attente pour chaque file d'attente. Par conséquent il fournit la bande passante allouée statistiquement. A été disponible pendant quelques années. Il permet l'allocation approximative de bande passante pour différentes files d'attente. Aucun entretien 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 difficult.1
Mise en file d'attente par priorité (PQ) Le trafic est classifié dans la haute, le support, la normale, et les files d'attente à basse priorité. Le trafic prioritaire est entretenu d'abord, suivi du trafic de support, de normale et de faible priorité. A été disponible pendant quelques années. Il fournit l'entretien prioritaire. Le trafic plus prioritaire meurt de faim les files d'attente de faible priorité de la bande passante. Aucune garantie de bande passante n'est possible.2
Mise en file d'attente pondérée basée sur classe (CBWFQ) QoS modulaire CLI est utilisé pour classifier le trafic. Le trafic classifié est placé dans des files d'attente de bande passante réservée ou une file d'attente franche par défaut. Un programmateur entretient les files d'attente basées sur des poids de sorte que les garanties de bande passante soient honorées. Semblable à LLQ, sauf qu'il n'y a aucune file d'attente prioritaire. Configuration et capacité simples de fournir des garanties de bande passante. Aucun entretien prioritaire n'est possible.3
Mise en file d'attente pondérée de file d'attente prioritaire (PQ-WFQ), également appelée l'IP RTP Priority Une commande d'interface unique est utilisée de fournir la priorité entretenant dans tous les paquets UDP destinés aux numéros de port pairs dans une marge spécifiée. Simple, une configuration de commande. Fournit la priorité entretenant au RTP des paquets. Tout autre trafic est traité avec WFQ. Le trafic de Protocol de Conférences en temps réel (RTCP) n'est pas donné la priorité. Aucune bande passante garantie capability.4
LLQ, précédemment appelé la file d'attente prioritaire la mise en file d'attente pondérée basée sur classe (PQCBWFQ) QoS modulaire CLI avec la file d'attente prioritaire est utilisé pour classifier le trafic. Le trafic classifié est placé dans une file d'attente prioritaire, la bande passante réservée s'aligne, ou une file d'attente franche par défaut. Un programmateur entretient les files d'attente basées sur des poids de sorte que le trafic prioritaire est envoyé d'abord (jusqu'à une certaine limite maintenue l'ordre pendant l'encombrement) et les garanties de bande passante sont rencontrées. Configuration simple. Capacité de fournir la priorité aux plusieurs classes du trafic et de donner les limites supérieures sur l'utilisation de bande passante prioritaire. Vous pouvez également configurer des classes garanties par bande passante et une classe par défaut. Aucun mécanisme pour fournir de plusieurs niveaux de priorité encore, tout le trafic prioritaire n'est envoyé par la même file d'attente prioritaire. Les classes distinctes prioritaires peuvent avoir les limites supérieures distinctes de bande passante prioritaire pendant l'encombrement. Cependant, partager de la file d'attente prioritaire entre les applications peut potentiellement introduire jitter.4

  1. Non approprié à la Voix.

  2. A besoin de bande passante garantie pour la Voix.

  3. La latence des besoins à sont géré.

  4. Suffisamment pour la Voix.

Délai de sérialisation

Même si la queue fonctionne à son meilleur et donne la priorité au trafic vocal, il y a des périodes où la file d'attente prioritaire est vide et un paquet d'une autre classe est entretenu. Des paquets des classes de bande passante garantie doivent être entretenus ont basé sur leur poids configuré. Si un paquet vocal prioritaire arrive dans la file d'attente de sortie tandis que ces paquets sont entretenus, le paquet vocal peut attendre une importante quantité d'heure avant qu'il soit envoyé. Retard de fabrication en série d'expérience de paquets vocaux quand ils doivent attendre derrière de plus grands paquets de données.

Le retard de fabrication en série peut introduire la plus mauvaise forme du jitter pour des paquets vocaux. Si les paquets vocaux doivent attendre derrière un paquet de données qui est aussi grand que 1500 octets, sur un lien plus lent, ceci se traduit à un retard énorme. Le retard de fabrication en série est énormément différent si le paquet de données est de 80 octets, suivant les indications de cet exemple :

  • Le retard de fabrication en série sur des 64 Kbits/s joignent en raison d'un paquet de 1500 octets = d'un 1500*8/64000 = 187.5 ms.

  • Le retard de fabrication en série sur des 64 Kbits/s joignent en raison d'un paquet 80bytes = d'un 80*8/64000 = 10 ms.

Par conséquent, un paquet vocal potentiellement doit attendre jusqu'à 187.5 ms avant qu'il soit envoyé s'il est bloqué derrière un paquet 1500-byte simple sur un lien de 64 Kbits/s. D'autre part, un autre paquet vocal doit attendre seulement 10 ms à la passerelle de destination. Ceci résulte dans un jitter énorme qui se produit en raison de la variance dans le retard d'inter-paquet. Sur la passerelle d'origine, des paquets vocaux sont habituellement envoyés à chaque 20 ms. Avec un budget de retard de bout en bout de 150 ms et de conditions requises strictes de jitter, un écart de plus de 180 ms est inacceptable.

Introduisez un mécanisme de la fragmentation qui s'assure que la taille d'une unité de transmission est moins de 10 ms. Tous paquets qui ont plus le besoin de retard de fabrication en série du ms de 10 d'être fragmenté dans 10 blocs de ms. Un bloc ou un fragment du ms 10 est le nombre d'octets qui est envoyé au-dessus du lien dans 10 que Mme calculent la taille à l'aide de la vitesse de liaison, suivant les indications de cet exemple :

  • Taille de fragmentation = (0.01 seconde * 64,000 bps)/(8 bits/octet) = 80 octets

Il prend 10 ms pour envoyer un paquet de 80 octets ou pour fragmenter au-dessus d'un lien de 64 Kbits/s.

En cas d'atmosphère de multiple ou de circuits virtuels permanents en relais de trame (PVCs) sur une seule interface physique, configurez les valeurs de fragmentation (sur tout le PVCs) basées sur le PVC qui a la plus basse bande passante disponible. Par exemple, s'il y a de trois PVCs qui ont une bande passante garantie de 512 Kbps, 128 Kbps, et 256 Kbps, puis configurent chacun des trois PVCs avec une taille de fragment de 160 octets (le plus à vitesse réduite est de 128 Kbps qui exige une taille de fragment 160-byte). 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 exigée si la taille de fragment est plus grande que la taille de MTU de lien. Par exemple, pour un lien de t1 avec un MTU 1500-byte, la taille de fragment est de 1920 octets. Par conséquent, aucune fragmentation n'est exigée. La taille de fragmentation de paquets devrait ne jamais être inférieure à la longueur de paquet VoIP. Ne fragmentez pas les paquets VoIP. Fragmenter ces paquets entraîne de nombreuses questions d'établissement d'appel et de qualité.

Il y a actuellement trois mécanismes de fragmentation de liaison et d'interfoliage disponibles. Pour davantage d'explication de divers retards introduits dans un réseau à commutation de paquets, référez-vous compréhension derrière le retard dans les réseaux voix par paquets. Ce tableau présente leurs avantages et limites :

Mécanisme de Fonction Link Fragmentation and Interleaving (LFI) Description Avantages Limites
Fragmentation de MTU avec WFQ Commande de niveau d'interface de changer la taille de MTU ou la taille d'IP MTU. Utilisé pour fragmenter de grands paquets IP à la taille spécifiée de MTU. LFI emploie WFQ pour intercaler les paquets en temps réel entre les fragments. Configuration simple. Les fragments sont rassemblent seulement par l'application de réception. Par conséquent, utilisation inefficace du réseau. Seulement les paquets IP avec ne fragmentent pas (DF) mordu non réglé peuvent manipuler la fragmentation bien. Fortement processeur intensif. Non recommandé.
Protocole point-à-point de Multilien (MLPPP) LFI Sur les liaisons série point par point, MLPPP doit d'abord être configuré, puis une taille de fragmentation doit être fixée dans Mme que l'interfoliage doit également être activé sur l'interface multiliaison. Des paquets sont fragmentés sur une fin du lien et rassemblés à l'autre. Plusieurs liens peuvent être combinés pour agir en tant que grand canal virtuel. Seulement disponible sur des liens configurés pour le PPP. Des solutions pour la Fonction PPP over Frame Relay ou le PPP au-dessus de l'atmosphère sont également prises en charge dans Logiciel Cisco IOS version 12.1(5)T ou plus tard.
Norme FRF.12 (Frame Relay Fragmentation) Sur le PVC en relais de trame, la commande de frame-relay traffic-shaping doit être activée et une taille de fragmentation être fixée sous le map-class. Des paquets sont fragmentés sur une extrémité du PVC et rassemblés à l'autre. Seulement disponible sur le PVC en relais de trame avec la commande enabled de frame-relay traffic-shaping.

VAD

Une conversation vocale régulière se compose de plusieurs minutes de silence. Une conversation vocale typique se compose de 40 à 50 pour cent de silence. Puisqu'il n'y a pas aucune Voix allant par le réseau pour 40 pour cent d'une communication voix, une certaine bande passante peut être enregistrée en déployant VAD. Avec VAD, la passerelle regarde pour des lacunes dans la parole. Il remplace ces lacunes par le bruit de confort (bruit de fond). Ainsi, une quantité de bande passante est enregistrée. Cependant, il y a un compromis. Il y a un petit temps (par ordre millisecondes), avant que les codecs détectent l'activité de la parole suivie d'une période de silence. Cette petite fois a comme conséquence le découpage frontal de la Voix reçue. Pour éviter le lancement pendant des pauses très courtes et compenser le découpage, VAD attend approximativement 200 ms après que la parole arrête avant qu'elle arrête la transmission. En redémarrant la transmission, il inclut les 5 ms précédent de la parole avec le discours en cours. VAD se désactive à un appel automatiquement si le bruit ambiant l'empêche de distinguer la parole et le bruit de fond. Cependant, si la bande passante n'est pas une question, arrêtez le VAD.

Paramètres de l'optimisation VAD

Il y a deux paramètres qui dictent le fonctionnement de VAD. Ce sont les commandes de music-threshold et de voice vad-time.

music-threshold

On décide un premier seuil qui régit quand VAD doit devenir actif. Ceci est contrôlé en définissant la commande de threshold_value de music-threshold sur un port vocal, suivant les indications de cet exemple. La plage pour ceci est de -70 décibels par milliwatt (dBm) au dBm -30. La valeur par défaut pour ceci est le dBm -38. Configurer une valeur inférieure (vers dBm -70) a comme conséquence VAD devenant actif à la force du signal un beaucoup inférieure (le volume doit relâcher vraiment bas avant qu'il soit considéré comme silence). Configurer une valeur supérieure (plus près de dBm -30) a comme conséquence VAD devenant actif pour même une petite baisse dans le point fort de signal vocal. Il pilote le playout pour lire des paquets de bruit de confort plus souvent. Cependant, ceci mène parfois au découpage mineur 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

voice vad-time

Une fois que le VAD devient actif, le composant du bruit et du bruit de confort de fond est contrôlé en configurant la commande de timer_value de voice vad-time sous la configuration globale, suivant les indications de cet exemple. C'est le temps de retard en quelques millisecondes pour la détection de silence et la suppression de la transmission de paquet vocal. La valeur par défaut pendant le temps de maintien est de 250 millisecondes. Ceci signifie que dans un délai de 250 millisecondes, le bruit de confort commence. La plage pour ce temporisateur est de 250 millisecondes à de 65536 millisecondes. Si une valeur élevée est configurée pour ceci, le bruit de confort entre dans le jeu beaucoup plus tard (le bruit de fond continue à être joué). Si ceci est configuré pour 65536 millisecondes, alors le bruit de confort est arrêté. Une valeur supérieure pour ce temporisateur est désirée pour une transition plus douce entre le bruit de fond et le bruit de confort. Le du côté incliné à configurer la commande de voice vad-time à un haut niveau est qu'il ne réalise pas l'économie désirée de bande passante de 30 à 35 pour cent.

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 typiques de configuration pour QoS

Un scénario typique pour installer des appels VoIP est au-dessus d'un lien de Relais de trames ou au-dessus d'un lien de PPP. Ce sont des exemples de configuration pour ces scénarios.

VoIPoFR - Exemple de configuration QoS

Dans cet exemple (qui contient seulement des sections afférentes de la configuration), on le suppose que la vitesse de circuit en relais de trame est de 256 Kbps. Le débit de données garanti garanti (CIR) sur PVC 100 est des 64 Kbits/s et sur le PVC 200 est de 192 Kbps. PVC 100 est utilisé pour porter les deux données et Voix. PVC 200 est utilisé pour porter seulement des données. Un maximum de quatre communications voix simultanées existe à un moment donné. Configurez la fragmentation sur des les deux PVCs basé sur le CIR du bas-bande passante-Voix-PVC (Voix de transport PVC). Basé sur les exemples dans ce document, ce signifie que la taille de fragmentation est décidée a basé sur PVC 100's CIR (qui est des 64 Kbits/s). Suivant les indications de la table de la section de retard de fabrication en série, pour les 64 Kbits/s joignent, une taille de fragmentation de 80 octets est exigés. La même taille de fragmentation doit être configurée pour PVC 200.

Pour d'autres détails au sujet de la configuration du VoIP sur frame relay, référez-vous au VoIP sur frame relay avec la qualité de service (fragmentation, trafic formant, 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

VoIP au-dessus de PPP - Exemple de configuration QoS

Dans cet exemple (qui contient seulement des sections afférentes de la configuration), on le suppose que le QoS doit être configuré pour un contrôleur point par point de T1 fractionné (qui a douze canaux). Un maximum de quatre communications voix simultanées existe à un moment donné. La tâche de configuration implique de configurer cette interface série avec l'encapsulation PPP, de lui faire une partie d'un multilink group, de créer une interface multiliaison (qui appartient au même multilink group), et de configurer tout le QoS sur l'interface multiliaison. Pour d'autres détails au sujet de la configuration du VoIP au-dessus du PPP, référez-vous au VoIP au-dessus des liens de PPP avec la 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
!

Jitter et mécanisme de Playout

Il y a toujours quelques entités incontrôlées dans un réseau qui contribuent vers d'autres retards et instabilité dans les paquets vocaux reçus. En modifiant la mémoire tampon de jitter sur la dernière passerelle le jitter incontrôlé est résolu dans le réseau voix.

Mécanisme de Playout

La mémoire tampon de jitter est une mémoire tampon de temps. Il est fourni par la dernière passerelle pour rendre le mécanisme de playout plus efficace. C'est un schéma fonctionnel du mécanisme de playout :

/image/gif/paws/20371/troubleshoot_qos_voice1.gif

Quand le contrôle de playout reçoit un paquet vocal, il analyse l'horodateur de RTP. Si le paquet vocal est retardé au delà de la capacité de mise en attente de la mémoire tampon de jitter, alors le paquet est immédiatement lâché. Si le paquet est dans la capacité de mise en mémoire tampon, il est placé dans la mémoire tampon de jitter. L'emplacement de ce paquet dans la mémoire tampon de jitter dépend de l'horodateur de RTP calculé pour ce paquet. En cas il n'y a aucun paquet vocal disponible, les essais de contrôle de playout pour le cacher (prévoit manqué le paquet). Si VAD est activé, le bruit de confort est lu.

La responsabilité du contrôle de playout est de manipuler les événements des paquets perdus, des paquets reproduits, des paquets corrompus, et des paquets de -de-ordre. Ces événements sont manipulés par le temps alignant les paquets vocaux trémoussés, jouant le bruit de confort (si VAD est configuré), ou même régénérant des tonalités multifréquences de double tonalité (DTMF) à jouer à l'hôte.

La dissimulation d'un paquet vocal est faite par la dissimulation de prévision ou par la dissimulation de silence. La dissimulation de prévision est basée sur le paquet précédent et le paquet suivant (si disponible). Cela fonctionne meilleur avec les bas codecs de débit binaire (5 Kbps aux 16 Kbit/s). La perte de paquets vocaux pour un codec élevé de débit binaire (32 Kbps aux 64 Kbits/s) peut potentiellement avoir comme conséquence la dissimulation pauvre de prévision. Débuts de dissimulation de prévision quand il y a de bas et peu fréquents retards ou un peu de nombre de perte de paquets. Trop de dissimulation de prévision peut mener à la Qualité vocale robotique. La dissimulation de silence est la plus mauvaise forme de la dissimulation de prévision. Il entre dans le jeu quand il n'y a aucune informations disponibles à prévoir. C'est simplement une dissimulation de fond. Il commence quand il y a les retards élevés et plus de nombre de perte de paquets. Trop de dissimulation de silence mène à la qualité de voix saccadée. La dissimulation de prévision est bonne pour 30 msecs après quoi le silence cachent entre dans le jeu.

Mémoire tampon de jitter

La mémoire tampon de jitter est confinée par un seuil supérieur et un seuil inférieur. Le seuil supérieur est le délai supérieur dans lequel on s'attend à ce qu'un paquet arrive pour le playout de période active. Paquets qui arrivent après que le seuil supérieur soient marqués en tant que les paquets en retard ou paquets perdus. Le seuil inférieur est le temps minimum l'où on s'attend à ce qu'un paquet arrive pour le playout de période active. Des paquets qui arrivent avant que le seuil inférieur soient considérés de premiers paquets (il peuvent encore être lus à l'heure).

Si la dernière passerelle continue à voir un incrément dans l'arrivée des paquets en retard, elle augmente le seuil supérieur. Cette valeur pour le seuil supérieur demeure la même durant toute la durée de l'appel. Ceci est augmenté jusqu'à un maximum défini dans la configuration. D'une manière semblable, la dernière passerelle observe le nombre de premiers paquets reçus. Si le début de ces paquets pour fréquenter la passerelle, il réduit le seuil inférieur. Cette valeur demeure la même durant toute la durée de l'appel. Ce mode de mémoire tampon de jitter désigné sous le nom « du mode adaptatif, » où la dernière passerelle adapte sa mémoire tampon de jitter basée sur la structure de trafic. L'autre mode est « mode fixe. » En mode fixe, il y a une valeur initiale pour le seuil inférieur et le seuil supérieur. Cette valeur est basée sur le retard reçu prévu (voyez la section de <port-number> de show voice call de ce document).

Pour d'autres détails sur la mémoire tampon de jitter, référez-vous compréhension derrière le jitter dans les réseaux voix par paquets (plates-formes Cisco IOS).

Identifiez le retard et instabilité

Cette section décrit comment identifier le jitter dans votre réseau.

show call active voice

La commande brief de show call active voice fournit beaucoup d'informations sur une conversation actuelle. Cette sortie affiche quelques points importants qui sont appris 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

De la sortie de commande brief de show call active voice, vous voyez que celui qui soit reçu sur le tronçon de téléphonie (rx:7044) est transmis au tronçon IP (tx:7044). Le même est vrai pour des paquets reçus sur les tronçons IP (26165) qui sont expédiés au tronçon de téléphonie (26157). La différence dans le nombre de paquets reçus sur le tronçon IP contre le nombre de paquets transmis sur le tronçon de téléphonie est contribuée aux paquets en retard qui ne le font pas à temps.

Cette sortie de la commande de show call active voice (sans « bref » mot clé), points d'autres à détails au sujet des paramètres qui identifient directement le jitter.

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

<port-number> de show voice call

La commande de numéro de port de show voice call fournit les informations utiles. Veillez à être consolé dans la passerelle, ou si vous êtes Telnetted dans une passerelle, veillez-vous pour avoir émis la commande de terminal monitor du niveau d'exécutif.

Remarque: Cette commande n'est pas disponible sur les Plateformes AS5x00/AS5x50.

Dans cette sortie, la valeur pour l'est de retard de Rx (ms) est 71. C'est la valeur de mémoire tampon en cours de jitter. Une valeur pour le seuil supérieur et le seuil inférieur est déduite sur ceci. Une valeur initiale moyenne pour le seuil supérieur est de 70 millisecondes, alors que ce pour le seuil inférieur est de 60 millisecondes. Une fois qu'une valeur initiale est placée, la passerelle maintient tous les premiers paquets ou paquets en retard reçus. Comme est vu dans la sortie ici, les baisses de dissimulation de prévision sont proches de 250 ms, alors que la dissimulation de silence sont 30 ms. Il y a toujours une valeur supérieure pour la dissimulation de prévision puisque la dissimulation de silence est seulement un scénario de plus mauvais cas de la dissimulation de prévision. Pour chaque baisse de dissimulation de prévision, il y a une augmentation de l'écart de débordement de tampon.

Si vous voyez la mémoire tampon jeter, il ne signifie pas nécessairement que vous voyez une augmentation du seuil supérieur. Le seuil supérieur est la limite supérieure de la mémoire tampon de jitter. Il change seulement si on observe une tendance. En d'autres termes, il devrait y a un flux continu des paquets en retard. Ceci a comme conséquence une augmentation de la mémoire tampon de jitter. Dans la sortie ici, une telle tendance est présente. Par conséquent, le seuil supérieur est grimpé de 70 millisecondes jusqu'à 161 millisecondes. Si cette valeur n'est pas changée (et si vous voyez toujours 14 paquets en retard), elle implique que ce sont les paquets en retard sporadiques, ne formant pas une tendance.

De la sortie de la commande de show call active voice, regardez pour les paquets perdus. Pour chaque paquet perdu, vous voyez deux paquets qui sont hors de l'ordre. Ceci est vu sur la sortie Non-Seq de paquets de Rx. Puisque ce n'est pas une valeur positive, on le conclut qu'il n'y a pas eu aucune perte de paquets non plus.

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 paquets de confort de Tx et les paquets de confort de Rx. Comme des exemples de sortie, on le conclut que le téléphone connecté à ce routeur maintient en grande partie tranquille puisque vous avez un bon nombre de paquets de confort de Tx. En même temps, vous avez les paquets zéro de confort de Rx, ainsi il signifie que l'autre extrémité parle continuellement.

Comparez la sortie ici à la sortie de commande précédente. Il y a un nombre accru de défunts paquets de Rx (de 14 à 26). Cependant, il n'y a aucun incrément en valeur de seuil supérieur. Ceci indique que les 12 paquets sont sporadiquement retardés. L'écart de Buffer Overflow est grimpé jusqu'à 910 msecs. Cependant, puisqu'il n'y a aucune tendance observée, le seuil supérieur n'est pas augmenté.

Dans la sortie ici, vous avez des paquets tôt d'un Rx : 3. Ceci signifie qu'un paquet arrive beaucoup avant qu'il soit prévu. Comme vu de la sortie ici, la mémoire tampon de jitter s'est étirée pour faciliter pour plus de premiers paquets en ramenant le seuil inférieur 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

Configurez la mémoire tampon de jitter sur une passerelle

Les instructions de QoS couvertes dans ce document prennent soin du problème de qualité voix variable ou détérioré. La configuration de la mémoire tampon de délai d'extraction est un contournement pour l'implémentation inexacte de QoS dans le réseau. Utilisez seulement ceci comme difficulté transitoire ou comme outil pour dépanner et se rétrécir vers le bas des problèmes de jitter introduits dans le réseau.

Mode de délai d'extraction

La mémoire tampon de jitter est configurée pour le mode réparé ou le mode d'adaptatif. Sous le mode adaptatif, la passerelle te permet pour configurer une valeur minimum pour la mémoire tampon de jitter, une valeur maximale, et une valeur nominale. La mémoire tampon de jitter s'attend à ce que les paquets arrivent dans la marge de valeur nominale. La valeur nominale doit être égal ou plus qu'au minimum, et égal ou moins qu'au maximum. La mémoire tampon développe jusqu'à la valeur maximale configurée. Ceci peut s'étendre jusqu'à 1700 millisecondes. Une question avec configurer la valeur maximale élevée est l'introduction du retard de bout en bout. Choisissez la valeur du délai d'extraction maximum tels qu'elle n'introduit pas le retard non désiré dans le réseau. Cette sortie est un exemple de la mémoire tampon de jitter configurée 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 regarde la valeur configurée pour le nominal. Bien qu'il te permette pour configurer le minimum et la valeur maximale pour le délai d'extraction, il est ignoré une fois configuré pour le mode fixe. Quand en mode fixe, la valeur de seuil supérieur ou la valeur de seuil inférieur demeure toujours constante. Il est basé sur la valeur nominale et basé sur la valeur est de retard de Rx (ms). Ainsi il est possible que sous le mode fixe, vous configuriez la valeur en tant que 200 millisecondes. Cependant, si le retard reçu prévu est proche de 100 ms, est qui ce que le seuil supérieur et le seuil inférieur est placé à pour la durée entière 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 de délai d'extraction, référez-vous aux améliorations de délai d'extraction pour la voix sur ip.


Informations connexes


Document ID: 20371