Voix et communications unifiées : Cisco Unified Communications Manager (CallManager)

Gestion de la qualité de la voix avec Cisco Voice Manager (CVM) et Telemate

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


Contenu


Introduction

Ce document décrit l'utilisation de Cisco Voice Manager et de Telemate de gérer la Qualité vocale dans un réseau VoIP. Tout le contenu est basé sur une implémentation de Téléphonie sur IP de monde réel. Ce document se concentre sur l'application des Produits et pas l'utilisation des Produits. Vous devriez déjà être familiarisé avec CVM et Telemate et avoir accès à la documentation du produit priée. Voir les informations relatives pour une liste de documentation associée.

En gérant un réseau VoIP de grande puissance, vous devez avoir les outils nécessaires pour objectivement surveiller et signaler la Qualité vocale dans le réseau. Compter sur seul le feedback des utilisateurs n'est pas faisable parce qu'il est subjectif et inachevé. CVM, ainsi que Telemate, peut fournir une partie de cette fonction. Il rend compte de la Qualité vocale à l'aide du problème/a calculé le facteur de planification de problème (icpif) calculé par une passerelle IOS pour chaque appel. Ceci permet au gestionnaire de réseau pour identifier les sites qui souffrent de la médiocre qualité de voix et traitent eux convenablement.

Une fois que vous identifiez des sites à problème, vous pouvez avoir besoin d'autres outils pour dépanner les questions possibles de QoS de réseau. Deux outils sont l'Internetwork Performance Monitor (IPM) et le Cisco Service Assurance Agent (CSAA). Ces thèmes sont discutés dans un autre document signalé sur notre site Web.

Conditions préalables

Conditions requises

Les lecteurs de ce document devraient avoir connaissance des sujets suivants :

  • Cisco Voice Manager et Telemate

Composants utilisés

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

Les informations contenues dans ce document ont été créées à partir des périphériques d'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 votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Aperçu de Qualité vocale

Les sections suivantes fournissent un aperçu des problèmes de qualité voix :

Qualité vocale de mesure

L'ITU G.113 standard spécifie comment mesurer la Qualité vocale. Cette méthode dicte que vous pouvez déterminer la qualité des communications voix en calculant l'icpif. les passerelles basées sur IOS calculent la valeur d'icpif pour chaque appel et se connectent l'en tant qu'élément de l'enregistrement CDR. En outre, il peut envoyer une qualité de déroutement de Voix (QoV) par l'intermédiaire du SNMP si la valeur d'icpif d'un appel dépasse une valeur de présélection. Ceci signifie que les passerelles ont des capacités intégrées de mesure de Qualité vocale. Tous ce qui sont nécessaires sont collectent ces mesures et analysent les données pour identifier toutes les tendances.

La Qualité vocale VoIP est principalement affectée par le réseau QoS. L'analyse d'appel se concentrera donc sur identifier des problèmes de qualité voix sur une base de par-site. Si des sites qui ont un grand nombre d'appels avec la médiocre qualité de voix peuvent être identifiés, nous pouvons nous concentrer sur toutes les questions de QoS dans le chemin réseau à et de ces sites.

Aperçu ITU G.113

La section suivante est seulement une brève présentation ; consultez la norme G.113 pour plus d'informations détaillées.

L'idée générale derrière G.113 est de calculer un facteur de problème pour chaque appareil le long du chemin voix et les ajouter alors obtenez jusqu'à tout le problème. Il y a les différents types de dégradation (bruit, retard, écho, etc.) et l'ITU les divise en cinq catégories. Ajoutez-les obtiennent jusqu'à tout le problème Itot :

Itot = E/S + Q.I. + Idte + Idd + IE

Chacune de ces derniers est définie comme suit (utilisant la terminologie ITU) :

  • E/S — problèmes provoqués par l'évaluation de volume de non-optimum et/ou le bruit de circuit globaux de haute.

  • Q.I. — problèmes provoqués par le type PCM quantifiant la déformation.

  • Idte — problèmes provoqués par écho de locuteur.

  • Idd — difficultés de communication orale provoquées par de longs délais de transmission à sens unique (retard).

  • IE — problèmes provoqués par le matériel spécial, en particulier codecs de faible débit de non-forme d'onde.

Quand le logiciel de Cisco IOS calcule Itot, il ignore l'E/S et le Q.I. en tant qu'étant négligeable et place Idte à 0. La valeur d'Idd est dérivée du tableau suivant, qui provient G.113 :

Retard Idd
150 0
200 3
250 10
300 15
400 25
500 30
600 35
800 40

Normalement l'IE est une valeur fixe, dépendant seulement des codecs tapent. G.113 spécifie les valeurs pour des codecs typiquement utilisés par des passerelles Cisco suivant les indications du tableau suivant :

Code IE
G.711 0
G.729/G.729a 10

Cependant, parce que ces codecs sont utilisés dans un environnement de voix par paquets, le problème réel dépend de la perte de paquets. Plus la perte de paquets est élevée, plus le problème est élevé. La construction de Cisco a mesuré la Qualité vocale avec PSQM (ITU P.861) aux niveaux discrets de perte de paquets. Les expositions de tableau suivant expriment à niveaux relatifs de perte de paquets de valeurs de déformation pour des codecs donnés :

Perte de paquets % G.711 G.729/G.729a
0 0 10
1 8 15
2 12 20
3 18 25
4 22 30
5 26 34
6 28 38
7 30 40
8 32 42
9 34 44

Comme prévu, est G.729 plus susceptible de la perte de paquets que G.711.

La Qualité vocale est tout au sujet de perception humaine et d'attente. Les attentes de niveau de service des utilisateurs de téléphone portable sont inférieures puis ceux de la ligne fixe utilisateurs. Nous prenons en considération ceci en calculant l'icpif en réduisant Itot par le facteur humain R. d'attente La formule pour ceci est :

Icpif = Itot - A

G.113 fournit également des facteurs d'attente pour les réseaux voix typiques. Voyez le tableau suivant :

Méthode d'accès de réseau voix Attendez-vous au facteur A
Ligne fixe conventionnelle PSTN 0
Radio locale (téléphone sans fil) 5
Radio d'étendu (téléphone portable) 10
Satellite 20

G.113 a également une table qui trace entre la valeur d'icpif et la Qualité vocale. On lui affiche dans le tableau suivant :

Méthode d'accès de réseau voix Attendez-vous au facteur A
5 Très bon
10 Bon
20 Adéquat
30 Cas de limitation
45 Cas exceptionnellement de limitation
55 Utilisateurs vraisemblablement à se plaindre fortement

Une valeur d'icpif de zéro pour un appel est un score parfait. C'est devrait être notre cible pour des réseaux VoIP.

Dans un réseau voix traditionnel, le créateur calculerait tout le budget de problème.

Par exemple, E/S = 0 ; Q.I. = 0 ; Idte = 0 ; Idd = 3 ; IE = 7, qui donne Itot = 10.

Si l'utilisateur accède au réseau d'un téléphone sans fil, alors le facteur maximum d'attente qui peut être soustrait est 5, ainsi le résultat final est :

Icpif = Itot - A = 10 - 5 = 5

Selon la table précédente, les utilisateurs sont susceptibles alors de percevoir la Qualité vocale en tant qu'étant très bons.

Ce document discute une solution qui utilise la valeur d'icpif pour surveiller la Qualité vocale plutôt qu'utilisant lui à des fins de planification.

Gestion de la qualité vocale avec CVM et Telemate

Les sections suivantes discutent comment gérer la Qualité vocale avec CVM et le Telemate :

Limites

Tandis que la solution proposée a quelques limites, il semble n'y avoir de pas autres outils extensibles disponibles. Les limitations connues incluent :

  • Seulement les appels par une passerelle sont sujets au contrôle qualité. Vous ne pouvez pas mesurer des appels d'IPhone à IPhone. La passerelle ne voit pas que ces appels et CallManager ne prend en charge pas actuellement G.113.

  • Le calcul d'icpif prend en considération seulement la perte de paquets et le retard. L'écho n'est pas inclus dans les calculs d'icpif. Par conséquent, un appel peut souffrir l'écho grave et encore obtenir un score parfait d'icpif.

  • La Qualité vocale est seulement mesurée dans la direction d'IPhone-à-passerelle. La valeur d'icpif dans un réseau voix par paquets est susceptible d'être asymétrique dans les deux directions. Aucun problème unidirectionnel de QoS de réseau dans passerelle--IPhone à la direction ne sera reflété en valeur d'icpif calculée par la passerelle.

  • Les problèmes de qualité voix sont généralement plus d'une question à travers un WAN. La solution discutée équipe le meilleur dans un environnement des passerelles centralisées, comme les appels d'IPhones aux sites distants doivent croiser le WAN pour accéder aux passerelles. Si des passerelles sont distribuées (c.-à-d., chaque site distant est entretenu par une passerelle locale), alors la plupart des appels de passerelle ne croiseront pas le WAN. Les appels VoIP à travers le WAN seront principalement IPhone-à-IPhone, et ce ne sont pas visibles à la passerelle.

Configuration de passerelle

En tant qu'élément de la solution proposée, toutes les passerelles doivent être configurées pour la collecte CDR :

dial-control-mib max-size <max-number-of-cdr>
dial-control-mib retain-timer 600

Toutes les passerelles doivent également avoir la fonction activée de déroutement de QoV. Cette caractéristique est désactivée par défaut :

Calibra#show dial-peer voice 99 | include QOV|Icpif
Expect factor = 0, Icpif = 20,
VAD = enabled, Poor QOV Trap = disabled,

Cette caractéristique est activée sur a par base d'homologue de numérotation VoIP en ajoutant ce qui suit :

dial-peer voice XYZ voip
snmp enable peer-trap poor-qov
icpif <threshold>
expect-factor 0

Quand un appel se termine, la passerelle calcule tout le problème (Itot) pour cet appel. Il soustrait alors l'expect-factor configuré d'Itot pour arriver à la valeur d'icpif réelle. Si ce nombre dépasse le seuil d'icpif, alors un déroutement de QoV est envoyé. Les durées de l'appel doivent être au moins de 10 secondes pour que la passerelle calcule la valeur d'icpif pour l'appel.

Regardons un exemple, où la configuration de passerelle est comme suit :

dial-peer voice XYZ voip
icpif 10
expect-factor 5

Supposez qu'un appel se termine avec une valeur d'Itot de 20. La passerelle soustrait alors un facteur de prévoir de 5 de ce nombre, donnant une valeur d'icpif de 15. Puisque 15 est puis 10, la passerelle génère un déroutement SNMP de QoV.

Globalement, il est nécessaire de permettre à des déroutements de QoV d'être envoyé à CVM :

snmp-server enable traps voice poor-qov
snmp-server host 10.x.x.x.x public<----- CVM station

Prenez garde que les Passerelles voix génèrent des déroutements SNMP de lien/linkdown qu'un appel est installé ou vers le bas chaque fois déchiré. Ceci peut s'élever à énormément de déroutements sur la passerelle à haute densité. Veillez à désactiver ces déroutements en ajoutant la commande suivante :

interface serial1/0:15no snmp trap link-status

CVM et architecture de Telemate

CVM et Telemate sont des applications complètement distinctes. Car le nom implique, CVM est un produit développé par Cisco. Telemate, d'autre part, est un produit tiers que les ventes de Cisco ont empaqueté avec CVM.

CVM remplit un grand choix de fonctions. Les deux fonctions dont nous nous servirons sont :

  • Collecter l'Enregistrements détaillés des appels (CDR) des passerelles par l'intermédiaire du SNMP.

  • Réception de la qualité des déroutements SNMP de Voix (QoV) des passerelles.

Après avoir collecté ces informations, CVM formate les données et les passe sur Telemate par l'intermédiaire du partage de fichier simple. Telemate alors traite ces données et les enregistre dans une base de données SQL de Microsoft. Le résultat final est une base de données avec une liste d'appels avec leurs détails respectifs, y compris la valeur d'icpif. De divers états peuvent alors être exécutés contre la base de données, y compris des états de QoV.

Le signaler de Telemate QoV que nous sommes intéressés dedans est des « appels de voix par paquets avec l'état de déroutements de qualité de service ». Les listes de cet état toutes nécessite ce que la passerelle a généré un déroutement de QoV. Nous ne sommes pas intéressés par les différents appels ; en revanche, nous sommes intéressés à identifier les sites, le cas échéant, qui ont un pourcentage moyen ci-dessus des appels avec la Qualité vocale. Pour réaliser ceci, Telemate doit pouvoir classer les appels par catégorie par le site. Ceci est discuté dans la section suivante.

Répertoire de Telemate

En remplissant répertoire de Telemate avec la connaissance dont les extensions résident à quels sites, nous peuvent employer Telemate pour classer des appels par catégorie par le site.

Le répertoire de Telemate est une hiérarchie de cinq-couche, avec les niveaux suivants :

  • Niveau 1 - Société

  • Niveau 2 - Division

  • Niveau 3 - Service

  • Niveau 4 - Utilisateur

  • Niveau 5 - Extension

Vous pouvez associer de plusieurs extensions avec un utilisateur.

Dans le meilleur des cas, nous voudrions que chaque appel dans l'état de QoV soit répertorié avec le nom de service. Nous pourrions alors employer le nom de service pour représenter un site donné. Ceci nous permet pour trier des appels par service/site. Mais parce que des extensions peuvent être associées avec des utilisateurs seulement, nous devons réaliser ceci d'une manière légèrement maladroite. Fondamentalement nous créons un utilisateur factice par site, et nous faisons au nom de cet utilisateur le nom du site ou le code de site. Cet utilisateur factice est alors assigné toutes les extensions pour ce site particulier. Nous pouvons alors trier les appels par l'utilisateur, qui devient alors l'équivalent aux trier par le site.

Afin de l'enregistrement de QoV, nous ne nous inquiétons pas des trois niveaux principaux de la hiérarchie de répertoire, et ceux-ci peuvent être assignés n'importe quelle valeur arbitraire.

Pour cette implémentation, il y a 200 sites avec 45,000 extensions assignées bien que pas nécessairement tout en service. Ainsi le répertoire contient 200 utilisateurs factices et chaque utilisateur factice est associé avec la plage des extensions pour leur site. Remplir répertoire manuellement serait une tâche impossible ainsi nous faisons ceci semi-automatiquement en générant un fichier CSV avec une ligne par extension, et nous employons alors la caractéristique d'importation de Telemate pour importer le fichier dans le répertoire. Chaque ligne dans ce fichier CSV a le format suivant :

Company,Division,Department,User,Extension

Générer le fichier CSV lui-même est également fait semi-automatiquement en exécutant un script shell Unix. Ce script prend un fichier "seed" comme entrée. Ce fichier "seed" répertorie les sites et les plages d'extensions associées. Chaque ligne dans le fichier "seed" a ce format :

site_name,extention_start,extension_end

Le script de shell lui-même est très simple, et ressemble à ceci :

#--------------------------- Telemate script start ------------------------

#!/bin/ksh
 
 for i in `cat ./$1`
 do (
   echo $i | awk 'BEGIN{FS=","}{for (j=($2+0);j<($3+0);++j) printf "Company,Division,Dept,%s,%s\n", $1,j}'
) done
#--------------------------- Telemate script end ------------------------

Supposant que le script lui-même est nommé « make_dir » et que le fichier "seed" s'appelle le « seedfile.csv », le fichier de l'importation CSV telemate_dir.csv est créé en exécutant la commande suivante à l'invite Unix :

unix$ make_dir seedfile.csv > telemate_dir.csv

Le fichier de sortie telemate_dir.csv est alors importé dans Telemate. Référez-vous à la documentation de Telemate pour le mode d'emploi détaillé sur la façon dont faire ceci.

Signaler

En exécutant un état de Telemate, vous pouvez sélectionner la destination de sortie. Pour de grands états, l'il est recommandé que le fichier soit produit dans le format CSV. Vous pouvez alors manipuler l'état dans Exceler, où il ressemblerait à ceci :

Durée Composé # Emplacement Date Heure Site Extérieur.
0:00:57 3-573-7783 10.200.16.33 10/05/2000 4:49:45PM BLM 37569
0:00:57 3-573-7783 10.200.16.33 10/05/2000 4:49:45PM BLM 37569
0:00:38 3-577-2958 10.200.16.33 10/05/2000 4:28:28PM BLM 37576
0:00:38 3-577-2958 10.200.16.33 10/05/2000 4:28:28PM BLM 37576
0:00:52 3-577-2985 10.200.16.33 10/05/2000 9:26:33PM BLM 37593
0:01:19 3-577-1770 10.200.16.33 10/05/2000 7:26:05PM BMC 34270
0:00:23 3-577-1770 10.200.16.33 10/05/2000 8:08:27PM BMC 34270
0:00:23 3-577-1770 10.200.16.33 10/05/2000 8:08:27PM BMC 34270
0:00:11 4-566-5302 10.132.16.33 10/05/2000 7:05:33PM COR 42791
0:00:32 4-567-0417 10.132.16.33 10/05/2000 5:29:51PM COR 42805
0:00:32 4-567-0417 10.132.16.33 10/05/2000 5:29:51PM COR 42805
0:00:36 4-232-8545 10.132.16.33 10/05/2000 5:42:07PM COR 42823
0:00:36 4-232-8545 10.132.16.33 10/05/2000 5:42:07PM COR 42823
0:00:39 4-472-5011 10.132.16.33 10/05/2000 5:59:23PM COR 46578
0:00:39 4-472-5011 10.132.16.33 10/05/2000 5:59:23PM COR 46578
0:00:28 4-236-7687 10.132.16.33 10/05/2000 7:17:51PM COR 46578
0:00:17 6-867-9766 10.132.16.35 10/05/2000 4:08:02PM GIS 64197
0:00:17 6-867-9766 10.132.16.35 10/05/2000 4:08:02PM GIS 64197
0:00:30 6-868-6889 10.132.16.35 10/05/2000 6:15:48PM GIS 68549
0:00:30 6-868-6889 10.132.16.35 10/05/2000 6:15:48PM GIS 68549
0:01:26 6-876-5223 10.132.16.35 10/05/2000 7:10:23PM HAH 68369
0:01:26 6-876-5223 10.132.16.35 10/05/2000 7:10:23PM HAH 68369
0:00:52 6-876-2223 10.132.16.35 10/05/2000 5:37:58PM HAH 68397
0:01:05 4-477-5402 10.132.16.33 10/05/2000 4:23:20PM JVL 47162
0:00:24 4-478-8848 10.132.16.33 10/05/2000 7:07:09PM JVL 47168
0:00:24 4-478-8848 10.132.16.33 10/05/2000 7:07:09PM JVL 47168
0:00:44 4-387-1333 10.132.16.33 10/05/2000 7:49:16PM KIB 49252
0:00:44 4-387-1333 10.132.16.33 10/05/2000 7:49:16PM KIB 49252
0:01:14 4-389-4299 10.132.16.33 10/05/2000 4:07:10PM KIB 49254
0:01:14 4-389-4299 10.132.16.33 10/05/2000 4:07:10PM KIB 49254
0:00:29 4-387-1337 10.132.16.33 10/05/2000 4:06:45PM KIB 49256
0:00:29 4-387-1337 10.132.16.33 10/05/2000 4:06:45PM KIB 49256
0:00:41 4-384-9269 10.132.16.33 10/05/2000 4:09:38PM KIB 49261
0:00:41 4-384-9269 10.132.16.33 10/05/2000 4:09:38PM KIB 49261
0:00:41 4-384-9269 10.132.16.33 10/05/2000 4:09:38PM KIB 49261
0:00:17 4-387-1344 10.132.16.33 10/05/2000 4:33:04PM KIB 49263
0:00:17 4-387-1344 10.132.16.33 10/05/2000 4:33:04PM KIB 49263
0:00:31 6-367-5103 10.132.16.35 10/05/2000 8:44:46PM LEV 64233
0:00:31 6-367-5103 10.132.16.35 10/05/2000 8:44:46PM LEV 64233
0:00:30 6-368-9088 10.132.16.35 10/05/2000 4:11:06PM LEV 64247
0:00:30 6-368-9088 10.132.16.35 10/05/2000 4:11:06PM LEV 64247
0:00:38 4-570-2450 10.132.16.33 10/05/2000 4:08:26PM LHT 43636
0:00:38 4-570-2450 10.132.16.33 10/05/2000 4:08:26PM LHT 43636

Utilisez les Exceler « fait le sous-total » de la caractéristique pour compter le nombre de mauvais appels par utilisateur/site. Créez alors une macro-instruction d'Exceler semi-pour automatiser faire le sous-total. Voyez l'exemple suivant :

Durée Composé # Emplacement Date Heure Site Extérieur.
        Compte BCM 5  
        Compte BMC 3  
        Compte de COR 8  
        Compte de GIS 4  
        HAH compte 3  
        Compte JVL 3  
        Compte KIB 11  
        Compte de LEV 4  
        Compte LHT 2  
        Compte grand 43  

La colonne de site contient maintenant le nombre de mauvais appels à/de ce site. La colonne d'emplacement dans l'état est l'adresse IP de l'autre extrémité du tronçon VoIP et provient l'enregistrement de la passerelle CDR. Dans un environnement de CallManager (CCM), la signalisation et les points d'extrémité de medias sont deux adresses IP distinctes. L'adresse IP répertoriée est le point final de signalisation (c.-à-d., le CallManager). Un DDTS (CSCds23283) a été soumis pour demander une molette qui permet à l'enregistrement CDR pour se connecter l'adresse IP de medias à la place. Ceci permettrait de mauvais appels à trier par sous-réseau. Ceci donne une meilleure finesse car il y aurait typiquement de plusieurs sous-réseaux par site. Si seulement certains de ces sous-réseaux souffrent des problèmes de QoV, alors ceux-ci peuvent être identifiés.

Nous recommandons que vous installiez le programmateur de Telemate pour exécuter automatiquement les « appels de voix par paquets avec des déroutements de qualité de service » signaliez une fois par jour. Des états terminés peuvent alors être envoyés au personnel d'exploitation sélectionné. Ces membres du personnel font alors un audit quotidien de QoV pour les dernières 24 heures. Des états devraient être archivés pour au moins un mois de sorte que n'importe quelle détérioration dans QoV puisse être corrélée avec toutes les modifications de réseau exécutées autour de ce temps.

Remarque: La version 4.7 ou ultérieures de Telemate est exigée pour que signaler fonctionne correctement avec des passerelles fonctionnant dans un environnement de CallManager. Les versions antérieures de Telemate supposent que les postes locaux sont toujours du côté de POTS de la passerelle. Dans un environnement de CallManager, les postes locaux (IPhones) sont du côté VoIP de la passerelle. En conséquence, les versions antérieures de Telemate obtiennent confus et les états sont de valeur limite.

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: 13940