Voix : Qualité vocale

Utilisation de la commande show call active voice pour dépanner les problèmes de qualité vocale

16 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document discute la sortie de commande de show call active voice (clients enregistrés seulement) et montre comment la sortie de commande résout des problèmes de qualité voix.

Remarque: Les commandes référencées dans ce document sont liées au Command Lookup Tool (clients enregistrés seulement). Utilisez cet outil afin de le rechercher pour plus d'informations sur des commandes spécifiques.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

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

sortie de commande de show call active voice

La commande de show call active voice te permet pour afficher le contenu de la table d'appel actif. Les informations présentées incluent des temps d'appel, des pairs de cadran, des connexions, des paramètres de qualité de service, et la manipulation de passerelle du jitter. Ces informations peuvent être utiles quand vous dépannez une plage des problèmes de qualité voix.

La table dans ce document inclut la sortie d'une commande de show call active voice d'échantillon et d'une brève explication de chaque paramètre.

Remarque: Les données d'affichages de commande de show call active voice des tronçons de réseau téléphonique public commuté (POTS) et d'appel VoIP sur la passerelle de Voix. Quelques paramètres sont mis en valeur en texte en gras pour davantage de discussion dans le reste du document.

La commande d'appel est actif d'exposition affiche des valeurs pour la téléphonie et les tronçons VoIP de n'importe quel appel actif. Pour chaque tronçon, les mêmes paramètres génériques sont affichés suivi des paramètres spécifiques au type de tronçon d'appel. Dans cette table, ces sections de paramètre sont notées par une en-tête ombragée.

Employez la commande de show call active voice dans l'Exec de l'utilisateur ou le mode d'exécution privilégié afin d'afficher les informations d'appel pour des communications voix en cours.

show call active voice [brief [id identifier] | compact [duration {less time | more
 time}] | echo-canceller call-id | id identifier | redirect {rtpvt | tbct}] 

Il y a beaucoup d'options d'arguments à cette commande. Cette liste décrit certains des arguments plus utiles :

  • brief — (facultatif) affiche une version tronquée.

  • contrat — appels actifs (facultatifs) d'affichages qui sont plus longs ou plus courts qu'un temps spécifié.

  • durée — appels actifs (facultatifs) d'affichages qui sont plus longs ou plus courts qu'un temps spécifié.

  • appel-id d'écho-annuleur — affiche des informations (facultative) au sujet de l'état de l'annuleur d'écho étendu (l'EC). Afin de questionner l'état d'écho, vous devez connaître l'ID hexadécimal à l'avance. Afin de trouver l'ID hexadécimal, sélectionnez la commande brief de show call active voice ou utilisez la commande d'état de show voice call. La plage est de 0 à FFFFFFFF.

paramètre de show call active voice Explication de paramètre
GÉNÉRIQUE : Les stats génériques pour les POTS appellent le tronçon qui suit
Ms SetupTime=866793 Le temps d'horloge dans 100 incréments de ms quand le tronçon de POTS est initié. Pour le RNIS entrant les POTS appelle, ceci est le moment où le message d'établissement d'appel Q.931 est reçu.
Index=1  
PeerAddress=100 La destination-pattern qui apparie ce pair de POTS. Pour les POTS entrants appellent le tronçon, c'est le numéro d'appel ou l'enregistrement automatique des numéros (ANI).
PeerSubAddress=  
PeerId=100 L'ID de pair de cadran utilisé pour ce tronçon d'appel. Dans ce cas, bien qu'inutile, le PeerID et le PeerAddress sont identique.
PeerIfIndex=9 L'index de port vocal pour ce pair. Pour des medias RNIS, c'est l'index du canal B utilisé pour cet appel.
LogicalIfIndex=5 L'index l'a utilisé intérieurement afin d'identifier l'interface logique pour l'appel.
ConnectTime=867030 Le temps d'horloge dans 100 incréments de ms quand le tronçon de POTS se connecte. Pour un RNIS entrant les POTS appellent le tronçon, ceci est le moment où l'appel Q.931 connectent le message est envoyé.
CallDuration=00:12:26 Le temps dans le hh : millimètre : solides solubles pour lesquels l'appel établit.
CallState=4 L'état d'appel pour le tronçon d'appel (4=active,3=connected,2=connecting). L'état d'appel est en activité.
CallOrigin=2 Commencez contre la réponse (1=originate, 2=answer) pour le tronçon d'appel. Cette passerelle répond à ce tronçon d'appel (de POTS).
ChargedUnits=0 Le nombre total d'unités de remplissage qui s'appliquent à ce pair depuis le démarrage du système. L'unité de mesure pour ce champ est des centièmex d'une seconde.
InfoType=2 L'information de type pour cet appel (1=fax, 2=voice). C'est une communication voix.
TransmitPackets=37291 Le nombre de paquets qui transmettent du processeur de signaux numériques (DSP) à l'interface de téléphonie.
TransmitBytes=725552 L'équivalent de nombre d'octets de la valeur de TransmitPackets de POTS.
ReceivePackets=1689 Le nombre de paquets reçus par le DSP de l'interface de téléphonie.
ReceiveBytes=33780 L'équivalent de nombre d'octets de la valeur de ReceivePacketsPackets de POTS.
TÉLÉ- : Tronçon d'appel de POTS
ConnectionId=[0xC59FE183 0xB1700D7 0x0 0x84431C] C'est le numéro d'identification de connexion que la passerelle donne afin de représenter seulement cet appel. Il s'assortit à travers tous les tronçons d'appel du faire appel à cette passerelle.
Ms TxDuration=746070 La durée de la minute 12 d'appel (ms) = 26 secondes = 746 secondes = 746070 ms.
Ms VoiceTxDuration=33780 Le temps cumulatif dans le ms quand des paquets vocaux sont envoyés du pair de POTS de téléphonie à la passerelle VoIP.
Ms FaxTxDuration=0 Le temps cumulatif dans le ms quand le routeur est dans le mode 'fax'.
CoderTypeRate=g729r8 Les codecs utilisés pour l'appel.
NoiseLevel=-59 Le niveau sonore actif pour cet appel. Cette valeur est calculée dans le module de génération de bruit de confort et est utilisée pour générer le bruit de confort quand la détection d'activité vocale (VAD) est activée.
ACOMLevel=20 Le niveau du courant ACOM pour cet appel. ACOM est la perte combinée réalisée par l'annuleur d'écho. Cette valeur est la somme de la perte de retour d'écho (ERL), d'amélioration de perte de retour d'écho (ERLE), et de perte de traitement non-linear (de NLP) pour l'appel.
OutSignalLevel=-64 Le niveau du signal de sortie dans les décibels par milliwatt (dBm).
InSignalLevel=-58 Le niveau de signal d'entrée dans le dBm.
InfoActivity=2 L'état actif d'activité de transfert de l'information pour cet appel.
ERLLevel=20 L'ERL pour ceci appel.
SessionTarget= Cette valeur applique aux tronçons d'appel VoIP. Cette valeur est spécifiée dans le pair de cadran VoIP. Il n'y a aucune cible de session pour des tronçons d'appel de POTS.
ImgPages=0  
   
GÉNÉRIQUE : Statistiques génériques pour que le tronçon d'appel de VOIP suive :
Ms SetupTime=866928 Le temps d'horloge dans 100 incréments de ms quand le tronçon d'appel VoIP est initié. Pour H.323 des appels sortants VoIP, c'est le moment où H.323 le message d'établissement d'appel est envoyé.
Index=1  
PeerAddress=200 La destination-pattern du pair. Pour un tronçon sortant d'appel VoIP, c'est le numéro appelé ou Service d'identification du numéro composé réacheminé (RDNIS).
PeerSubAddress=  
PeerId=200 Le peerID ce les correspondances DNIS. Dans ce cas, bien qu'inutile, le peerID et les DNIS sont identique.
PeerIfIndex=11  
LogicalIfIndex=0  
ConnectTime=867029 Le temps d'horloge dans 100 incréments de ms auxquels le tronçon VoIP se connecte. Pour H.323 un VoIP sortant appelez le tronçon, ceci est le moment où H.323 l'appel connectent le message est reçu.
CallDuration=00:12:27 La durée dans le hh : millimètre : solides solubles d'un appel.
CallState=4 L'état d'appel pour le tronçon d'appel (4=active,3=connected,2=connecting). L'état d'appel est en activité.
CallOrigin=1 Commencez contre la réponse (1=originate, 2=answer) pour le tronçon d'appel. Cette passerelle lance ce tronçon de l'appel (VoIP).
ChargedUnits=0  
InfoType=2  
TransmitPackets=1689 Le nombre de paquets VoIP transmis par cette passerelle sur ce tronçon d'appel.
TransmitBytes=33780 L'équivalent de nombre d'octets de la valeur VoIP TransmitPackets. Ceci doit apparier VoiceTxDuration du tronçon d'appel de téléphonie puisqu'avec G.729, un octet est envoyé par 1 ms.
ReceivePackets=37343 Le nombre de paquets VoIP reçus par cette passerelle sur ce tronçon d'appel.
ReceiveBytes=746860 L'équivalent de nombre d'octets de la valeur VoIP ReceivePackets.
VOIP : Tronçon d'appel VoIP
ConnectionId[0xC59FE183 0xB1700D7 0x0 0x84431C] C'est le numéro d'identification de connexion que la passerelle donne afin de représenter seulement cet appel. Il s'assortit à travers tous les tronçons d'appel du faire appel à cette passerelle.
RemoteIPAddress=10.1.1.2 L'adresse IP distante pour l'appel.
RemoteUDPPort=18280 Le port distant de Protocole UDP (User Datagram Protocol) pour l'appel.
Ms RoundTripDelay=53 Le délai d'aller-retour comme mesuré par la passerelle.
SelectedQoS=best-effort Le Protocole RSVP (Resource Reservation Protocol) n'est pas sélectionné dans le pair de cadran pour cet appel.
tx_DtmfRelay=cisco-rtp La forme du RELAIS DE DTMF utilisée pour l'appel (le cas échéant).
SessionProtocol=cisco La session Protocol pour l'appel. Protocol « Cisco » est le par défaut, utilisant H.323 la signalisation et les paquets de RTP pour le trafic vocal. La session Intitiation Protocol (SIP) est l'autre protocole de signalisation VoIP qui peut être spécifié avec l'aide de l'ordre de pair de cadran de protocole de session (clients enregistrés seulement). Les protocoles Non-VoIP tels qu'AAL2 pour VoATM ou le protocole de propriété industrielle de voix sur relais de trame (VOFR) de Cisco et FRFll pour le vofr peuvent également être spécifiés.
SessionTarget=ipv4:10.1.1.2 La cible de session du pair de cadran. La cible de session est RAS si un garde-porte est utilisé.
OnTimeRvPlayout=742740 La durée dans le ms du playout de Voix des données reçues à l'heure pour cet appel. Toute la durée de Playout de Voix peut être dérivée en ajoutant les durées de remplissage d'écart à la durée d'OnTimeRvPlayout.
Ms GapFillWithSilence=0 Chronométrez le silence lu de la passerelle (de ms) (gw). Le silence joue dans ces situations :
  • Quand un paquet est perdu et il n'y a aucun échantillon sonore disponible pour lire. Par exemple, quand deux paquets ou plus sont perdus dans l'ordre. Cette situation peut avoir comme conséquence un clic audible ou entailler être entendu par l'utilisateur.
  • Quand le tampon d'extraction s'adapte à une plus grande valeur en insérant le silence entre les paquets vocaux mis en mémoire tampon. Cette situation n'a pas comme conséquence une perte audible de qualité.
Ms GapFillWithPrediction=0 La durée dans le ms du signal vocal l'a lu avec le signal synthétisé des paramètres, ou des échantillons de données qui le précèdent à temps. Ce remplissage d'écart se produit parce que des données vocales sont perdues ou pas reçues à temps de la passerelle de Voix pour cet appel. Les exemples d'un tel dégagement sont trame-effaceur et stratégies de trame-dissimulation dedans G.729 et algorithmes de compression G.723.1.
Ms GapFillWithInterpolation=0 Quant à GapFillWithPrediction mais à la prise dans des échantillons de considération reçus après le trafic vocal manquant et enregistrés dans le tampon d'élimitation d'instabilité. Pas actuellement utilisé.
Ms GapFillWithRedundancy=0 Si un schéma de codage redondant est utilisé par l'émetteur, alors la charge utile des paquets perdus ou en retard peut récupérer partiellement ou entièrement et lire avec une incidence réduite sur la Qualité vocale. Cette technique n'est pas actuellement prise en charge.
Ms HiWaterPlayoutDelay=70 La bonne note en mémoire tampon de jitter du first-in, first-out (FIFO) qui indique la profondeur maximum à laquelle le tampon d'élimitation d'instabilité s'adapte pour cet appel.
Ms LoWaterPlayoutDelay=69 Marque de mémoire tampon de jitter FIFO la basse qui indique la profondeur minimum à laquelle le tampon d'élimitation d'instabilité s'adapte pour cet appel.
Ms ReceiveDelay=69 Le retard en cours FIFO de playout plus le retard de décodeur pour l'appel.
Ms LostPackets=0 Les paquets perdus de RTP représentés dans le ms. N'importe quel accès positif dans le numéro de séquence ajoute au compteur de LostPackets. Par exemple, si une passerelle reçoit des paquets avec un ordre des nombres dans la commande de N-1, N, N+1, N+3, N+2, N+4, puis les incréments de compteur de LostPackets. La taille de la mémoire tampon de dejitter et quand « a perdu » paquet arrive détermine si le paquet peut le lire.
Ms EarlyPackets=1 Le nombre de premiers paquets de RTP représentés en paquets de Mme RTP sont horodaté pendant qu'ils sont transmis et la valeur d'horodateur de RTP est incluse dans le paquet. Le temps à l'où le paquet est reçu est également chronométré par l'horloge locale de la passerelle. Si la différence de temps d'horloge locale (temps reçu) de deux paquets adjacents est plus petite que leur différence d'horodateurs de RTP (temps envoyé) alors le deuxième paquet est considérée tôt. Un premier paquet peut se produire quand l'usage du réseau chute soudainement. Ceci a comme conséquence le délai réseau inférieur pour un paquet particulier.
Ms LatePackets=0 Le nombre de paquets en retard de RTP représentés dans le ms. Cette valeur est incrémentée quand un paquet est reçu avec un numéro de séquence de RTP dans l'un ou l'autre de ces circonstances :
  • Le numéro de séquence de RTP est plus tôt que le numéro de séquence de RTP du paquet qui le lit actuellement.
  • Le numéro de séquence de RTP est plus tard que le paquet qui le lit actuellement mais en dehors du tampon d'extraction disponible.
VAD = activé VAD est activé pour ce tronçon d'appel.
CoderTypeRate=g729r8 Le type de codecs utilisé pour cet appel.
CodecBytes=20 La taille de charge utile, dans les octets, pour les codecs utilisés.
SignalingType=cas Le type de signalisation pour l'appel. C'est seulement pour des appels permanents.

Utilisation de la sortie de commande de dépanner des problèmes de qualité voix

Cette section inclut une discussion sur l'incidence de la Qualité vocale des paramètres mis en valeur dans la table de paramètres.

Apparier et consommation de bande passante de pair de cadran

Ces paramètres fournissent des informations associées avec un tronçon particulier VoIP d'un appel. Dans cet exemple particulier de tronçon d'appel, les correspondances d'appel avec le pair de cadran 200, les codecs utilisés est G.729 avec une taille de charge utile de 20 octets, et VAD est activé.

  • PeerId=200

  • CoderTypeRate=g729r8

  • CodecBytes=20

  • VAD = activé

Ces informations, une fois combinées avec des informations sur la configuration réseau, telle que le transport de la couche 2 et l'utilisation facultative du RTP comprimé te permettent pour déterminer par bandes passantes nécessaires d'appel pour les appels qui apparient ce pair de cadran. Référez-vous à Voix sur IP (VoIP) - Consommation de bande passante par appel pour plus d'informations.

Si la bande passante provisioned est insuffisante afin de prendre en charge le nombre d'appels, alors le résultat peut être Voix variable ou synthétique.

Remarque: Le seuil d'appel de commande peut être utilisé en tant qu'une des méthodes pour le contrôle d'admission d'appel, mais cette commande ne fonctionne pas pour des appels sortants des interfaces RNIS aux réseaux de h323.

Si les caractéristiques du tronçon d'appel ne semblent pas correctes, passez en revue votre configuration de homologue et apparier de cadran. Référez-vous à certains des documents connexes de pair de cadran répertoriés au pour en savoir plus de page de Soutien technique de Routage des appels/Plan de composition.

Voix déformée

La Voix déformée, dont la Voix variable et synthétique sont de bons exemples, peut se produire sous un certain nombre de circonstances habituellement associées avec les liens WAN inexactement provisioned. Ceux-ci résultent potentiellement du manque du contrôle d'admission approprié de connexion (CAC), ou de la hiérarchisation inexactement configurée de Voix. La commande de show call active voice fournit à la visibilité dans ces questions ces paramètres :

  • OnTimeRvPlayout=742740

  • Ms GapFillWithSilence=0

  • Ms GapFillWithPrediction=0

  • Ms HiWaterPlayoutDelay=70

  • Ms LoWaterPlayoutDelay=69

  • Ms ReceiveDelay=69

  • Ms LostPackets=0

  • Ms EarlyPackets=1

  • Ms LatePackets=0

La commande d'OnTimeRvPlayout fournit une bonne vue générale des santés de l'appel quand elle est comparée à toute la durée de Playout de Voix. Toute la durée de Playout de Voix peut être dérivée en plus des durées de remplissage d'écart à la durée d'OnTimeRvPlayout. Si la proportion de temps de playout de Voix de temps est élevée puis l'appel est susceptible d'être sain.

Les paquets ont relâché ou ont retardé trop long dans le réseau à commutation de paquets peuvent entraîner des problèmes de qualité voix.

À la réception des paquets qui sont retardés très longtemps qu'ils ne peuvent pas être utilisé, ou quand des paquets sont lâchés dans le réseau et pas reçus du tout, d'un téléphone IP ou des tentatives de passerelle de Voix de reconstruire le flux voix comme mieux il peut par la prévision du signal vocal.

Émettez à plusieurs reprises la commande de show call active voice sur une passerelle IOS afin de fournir la visibilité dans cette question :

  • LatePackets — Le nombre de paquets qui arrivent en dehors de la période de retard de lecture de tampon d'élimitation d'instabilité. Ces paquets sont jetés.

  • LostPackets — Le nombre de paquets qui n'arrivent jamais au téléphone IP ou à la passerelle de réception.

  • GapFillWithPrediction — La quantité de prévision de paquet dans un appel. Divisez ce nombre par le temps d'échantillon de paquet afin de déterminer le nombre de paquets affectés.

  • GapFillWithSilence — La quantité de mise en place de silence dans l'appel.

Remarque: La commande active de Voix de show port sur une passerelle de Catalyst te donne une indication de jitter pour un appel (délai d'extraction de l'eau Hi/Low) bien qu'il ne différencie pas entre la mise en place prévisionnelle et de silence.

  • Voix synthétique

    Un peu de mise en place prévisionnelle est indétectable à l'oreille humaine. Cependant, un grand nombre entraîne probablement une qualité déformée dans la Voix qui peut être décrite en tant que Voix synthétique ou robotique.

  • Voix saccadée

    Si des paquets sont lâchés ou arrivent tard, alors il n'est pas possible que le décodeur de réception de codecs prévoie le signal vocal. Dans ce cas, le signal est remplacé par le silence inséré dans la parole.

    En outre, si le retard est variable (jitter), des paquets qui arrivent tard mais au cours de la période de délai d'extraction du tampon d'élimitation d'instabilité de réception, sont lus mais peuvent entraîner un underrun du tampon d'élimitation d'instabilité. Un underrun se produit quand il n'y a aucun paquets tenu dans la mémoire tampon et le discours est retardé quand la mémoire tampon attend le paquet suivant pour arriver. L'écart audible dans la parole peut résulter.

    Un peu de mise en place ou de jitter de silence est indétectable à l'oreille humaine. Cependant, un grand nombre entraîne probablement une qualité dans la Voix qui peut être décrite comme voix saccadée ou Voix cassée.

    Remarque: Si le délai réseau est assez variable, il est probable que le bruit en résultant du discours soit synthétique et variable.

Problèmes de Voix déformés par résolution

Déterminez la cause du retard et (si possible) éliminez-le.

Les causes des baisses ou des retards dans un réseau téléphonique de paquet peuvent être beaucoup et varié. Quelques exemples classiques incluent :

  • Basse Mise en file d'attente Misconfigured de latence

  • Fragmentation Misconfigured pour des liaisons à bas débit

  • Formation Misconfigured et/ou Relais de trames CIR (clients enregistrés du trafic seulement) dépassés

  • Liens avec la bande passante sur-commise dans le chemin de l'appel. Par exemple, CAC pauvre pour des communications voix. Un exemple est G.711 un appel sans le cRTP ou VAD à travers des 64 Kbits/s joignent.

  • Conflits du mode bidirectionnel dans un environnement d'Ethernets

  • Exécutions intensives CPU sur un routeur dans le chemin de l'appel. Par exemple, met au point à une console ou enregistrer la configuration de routeur peut entraîner l'utilisation du CPU élevé qui retarde les paquets qui la traversent.

Il est également possible d'accorder les tampons d'élimitation d'instabilité de passerelle pour une meilleure performance vocale dans les réseaux de données suboptimaux. Cependant, les résultats sont limités au degré auquel le réseau de données se comporte correctement. Le pour en savoir plus, se rapportent dépannage derrière des questions de voix saccadée de QoS ou d'un certain nombre de documents répertoriés à la page de Soutien technique de Qualité vocale.

Sifflement, charge statique, et coupage

Ces paramètres les identifient si VAD est utilisé pour cet appel et quel pair de cadran est utilisé :

  • VAD = activé

  • PeerId=200

  • NoiseLevel=-59

Problèmes de sifflement et de coupage de résolution

Afin de résoudre problèmes sifflants et quelques frontaux de découpage, ajuster le music-threshold ou les valeurs de vad-temps (ou le débronchement VAD) avant que vous dépanniez d'autres problèmes éventuels.

Testez en désactivant le comfort-noise (clients enregistrés seulement) ou en désactivant VAD entièrement. Si le symptôme arrête, alors la génération de bruit de confort est la cause probable du problème. La réduction du music-threshold (clients enregistrés seulement) auquel la Voix est détectée ou augmentation du vad-temps (clients enregistrés seulement) évalue sur la passerelle peut faire le sifflement ou couper moins apparent sans nécessité de désactiver VAD de manière permanente. Ces techniques désactivent essentiellement VAD aux volumes bas et/ou pendant de petites lacunes, respectivement. Il n'est pas pratique pour désactiver juste le bruit de confort puisque cette action entraîne d'autres symptômes de Qualité vocale tels que cliquer sur et/ou lacunes de silence absolu entre les phrases.

Référez-vous au sifflement de dépannage et au pour en savoir plus statique. Si ces techniques de accord ne résolvent pas le problème, alors désactivez VAD. Ceci a comme conséquence une perte de gain de bande passante.

Problèmes de sifflement et de coupage de résolution en One Direction

VAD est la cause de la plupart des problèmes de sifflement. Par conséquent, il est important de l'identifier s'il est activé. Une des premières étapes pour dépanner le découpage sifflant ou frontal des phrases est de désactiver VAD. Il est donc important de pouvoir identifier s'il est désactivé.

Si sifflant ou coupant se produit seulement dans une direction, la direction sortante, alors elle peuvent être dues à VAD étant activé dans cette direction quoique vous ayez essayé de la désactiver dans le pair de cadran VoIP. Dans ce cas, les expositions VAD de commande de show call active voice activées et le PeerID en service étant 0. afin de surmonter cette question, configurent la commande entrante de <number_dialed> de numéro appelé (clients enregistrés seulement) sur le pair de cadran VoIP de s'assurer que les appels au PSTN apparient ce pair à la passerelle. Autrement, les appels dans cette direction s'assortissent avec l'homologue de numérotation par défaut qui fait activer VAD par défaut.

Écho

Ces paramètres sont importants pour dépanner l'écho :

  • ACOMLevel=20

  • OutSignalLevel=-64

  • InSignalLevel=-58

  • ERLLevel=20

    La sortie de tonalité de test est -15 et est faite une boucle - arrière avec 0 pertes de dB. Par conséquent, il revient au dB -15. La valeur ERL ici n'a aucune importance en ce moment puisque l'annuleur d'écho ne considère pas le signal d'entrée pour être écho.

    Remarque: L'OutSignalLevel affiche la valeur du niveau après que l'output attenuation soit appliqué au signal. L'InSignalLevel affiche la valeur du niveau après que l'input gain soit appliqué.

    Si la valeur ERL est si basse, le signal d'écho qui les retours à la passerelle pourraient être trop bruyants (à moins de DB 6 du signal de locuteur). Ceci fait le considérer l'annuleur d'écho comme Voix (charabia) au lieu de l'écho. Par conséquent, l'annuleur d'écho n'annule pas l'écho. ERL devrait être entre le DB 6 le DB et 20 pour que l'annuleur d'écho engage.

Référez-vous aux problèmes d'écho de dépannage entre les passerelles de Téléphones IP et de Cisco IOS et l'écho de dépannage dans des réseaux de Téléphonie sur IP (à la demande sonore) pour les informations sur des problèmes d'écho de dépannage.

Jitter et symptômes typiques de Qualité vocale

Cette section explique comment employer la commande de show call active voice afin d'identifier le jitter et les symptômes typiques de Qualité vocale.

Une idée générale de jitter dans le réseau peut être déterminée en émettant à plusieurs reprises la commande de show call active voice tandis qu'un appel est en cours. Dans le meilleur des cas, ces paramètres devraient rester relativement fermement. S'ils font, c'est une indication d'écoulement régulier de paquet. Cependant, si le jitter est présent, il y a de dièse, les pics à court terme comme ceux affichés dans ces deux sorties témoin :

GapFillWithSilence=950 ms
GapFillWithPrediction=1980 ms
GapFillWithInterpolation=0 ms 
GapFillWithRedundancy=0 ms 
HiWaterPlayoutDelay=350 ms 
LoWaterPlayoutDelay=25 ms 
ReceiveDelay=29 ms
LostPackets=0 
EarlyPackets=0 
LatePackets=83 
. 
. 
GapFillWithSilence=1040 ms 
GapFillWithPrediction=2350 ms 
GapFillWithInterpolation=0 ms 
GapFillWithRedundancy=0 ms 
HiWaterPlayoutDelay=40 ms 
LoWaterPlayoutDelay=28 ms 
ReceiveDelay=35 ms   
LostPackets=0 
EarlyPackets=0 
LatePackets=99

Le nombre de incrémentation de paquets en retard dans ces sorties témoin indiquent un degré de jitter. La mise en place de silence indiquée par une augmentation en valeur de GapFillWithSilence se manifeste comme voix saccadée. La mise en place prévisionnelle, indiquée par une augmentation en valeur de GapFillWithPrediction, tend à se manifester en tant que Voix synthétique.

Afin de modifier la quantité de signal vocal qui est mis en mémoire tampon pour éviter des sous-passages ou des dépassements de mémoire tampon de jitter, émettez la commande de délai d'extraction.

Les deux modes de la configuration pour le délai d'extraction sont adaptatifs et fixes :

  • L'adaptatif permet à la mémoire tampon de jitter pour se développer et se rétrécir pour la durée de l'appel dans une marge configurée quand vous émettez le délai d'extraction {valeur nominale | valeur maximale | minimum {par défaut | bas | commande de haute}}.

  • Fixe est placé au début d'un appel quand vous émettez le mode de délai d'extraction {adaptatif | [NO--horodateurs]} commande fixe.

Référez-vous aux améliorations de délai d'extraction pour plus d'informations sur le VoIP.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 40309