Gestion de la qualité vocale avec CVM et Telemate

Introduction

Ce document décrit l'utilisation de Cisco Voice Manager et de Telemate pour gérer la qualité vocale dans un réseau VoIP. Tout le contenu est basé sur une implémentation de téléphonie IP dans le monde réel. Ce document se concentre sur l'application des produits et non sur l'utilisation des produits. Vous devez déjà être familier avec CVM et Telemate et avoir accès à la documentation produit requise. Voir Informations connexes pour une liste de la documentation connexe.

Lors de la gestion d'un réseau VoIP à grande échelle, vous devez disposer des outils nécessaires pour surveiller et signaler objectivement la qualité vocale sur le réseau. Il n'est pas possible de se fier uniquement aux commentaires des utilisateurs, car ils sont subjectifs et incomplets. CVM, avec Telemate, peut fournir une partie de cette fonction. Il établit des rapports sur la qualité de la voix à l'aide du facteur de planification de l'affaiblissement/de l'affaiblissement calculé (Icpif) calculé par une passerelle IOS pour chaque appel. Cela permet au gestionnaire de réseau d'identifier les sites qui souffrent d'une mauvaise qualité vocale et de les traiter de manière appropriée.

Une fois que vous avez identifié les sites problématiques, vous aurez peut-être besoin d'autres outils pour dépanner d'éventuels problèmes de QoS réseau. Deux outils sont l'IPM (Internetwork Performance Monitor) et Cisco Service Assurance Agent (CSAA). Ces sujets sont abordés dans un autre document affiché 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

Components Used

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

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

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

Présentation de la qualité vocale

Les sections suivantes présentent les problèmes de qualité vocale :

• Mesure de la qualité vocale
• Présentation de l'UIT G.113

Mesure de la qualité vocale

La norme ITU G.113 spécifie comment mesurer la qualité de la voix. Cette méthode vous permet de déterminer la qualité des appels vocaux en calculant l'Icpif. Les passerelles basées sur IOS calculent la valeur Icpif pour chaque appel et la consignent dans l'enregistrement CDR. En outre, il peut envoyer un déroutement de qualité de la voix (QoV) via SNMP si la valeur Icpif d'un appel dépasse une valeur prédéfinie. Cela signifie que les passerelles disposent de capacités de mesure de la qualité vocale intégrées. Il suffit de collecter ces mesures et d'analyser les données pour identifier les tendances.

La qualité de voix VoIP est principalement affectée par la qualité de service du réseau. L'analyse des appels se concentrera donc sur l'identification des problèmes de qualité vocale par site. Si vous pouvez identifier des sites qui ont un grand nombre d'appels avec une mauvaise qualité vocale, nous pouvons nous concentrer sur tous les problèmes de QoS dans le chemin réseau vers et depuis ces sites.

Présentation de l'UIT G.113

La section suivante n'est qu'un bref aperçu ; consultez la norme G.113 pour plus de détails.

L'idée générale derrière le G.113 est de calculer un facteur de déficience pour chaque équipement le long de la voie vocale, puis de les additionner pour obtenir la déficience totale. Il existe différents types de handicaps (bruit, délai, écho, etc.) et l'UIT les divise en cinq catégories. Ajoutez-les pour obtenir le total de la déficience Itot :

Itot = Io + Iq + Idte + Idd + Ie

Chacun de ces éléments est défini comme suit (en utilisant la terminologie de l'UIT) :

• Io : altérations causées par un niveau de bruit global non optimal et/ou un bruit de circuit élevé.

• Iq—dépréciations causées par le type de PCM quantifiant la distorsion.

• Idte : incapacités causées par l'écho du locuteur.

• Idd : difficultés de communication vocale causées par de longs temps de transmission à sens unique (délai).

• Ie—dépréciations causées par des équipements spéciaux, en particulier les codecs à faible débit de forme d'onde.

Lorsque le logiciel Cisco IOS calcule l'Itot, il ignore l'Io et l'Iq comme étant négligeables et définit Idte sur 0. La valeur Idd provient du tableau suivant, qui provient de G.113 :

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

Normalement, Ie est une valeur fixe, selon le type de codec. G.113 spécifie les valeurs des codecs généralement utilisés par les passerelles Cisco, comme indiqué dans le tableau suivant :

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

Cependant, comme ces codecs sont utilisés dans un environnement de voix par paquets, la perte réelle dépend de la perte de paquets. Plus la perte de paquets est élevée, plus la dégradation est élevée. L'ingénierie de Cisco a mesuré la qualité vocale avec PSQM (ITU P.861) à des niveaux de perte de paquets distincts. Le tableau suivant présente les valeurs de distorsion de la voix par rapport aux niveaux de perte de paquets pour des codecs donnés :

% de 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, le G.729 est plus susceptible de perte de paquets que le G.711.

La qualité de la voix est une question de perception et d'attente humaines. Les attentes des utilisateurs de téléphones portables en termes de niveau de service sont inférieures à celles des utilisateurs de lignes fixes. Nous en tenons compte lors du calcul de l'Icpif en réduisant l'Itot par le facteur d'attente humain A. La formule est la suivante :

Icpif = Itot - A

Le G.113 fournit également des facteurs d'attente pour les réseaux vocaux classiques. Reportez-vous au tableau suivant :

Méthode d'accès au réseau vocal	Facteur A attendu
RTPC de ligne fixe classique	0
Sans fil local (téléphone sans fil)	5
Sans fil WAN (téléphone portable)	10
Satellite	20

G.113 dispose également d'un tableau qui établit une correspondance entre la valeur Icpif et la qualité de la voix. Le tableau ci-dessous indique :

Méthode d'accès au réseau vocal	Facteur A attendu
5	Très bon
10	Bon
20	Adéquat
30	Case de limitation
45	Cas exceptionnellement restrictif
55	Utilisateurs susceptibles de se plaindre fortement

Une valeur Icpif de zéro pour un appel est un score parfait. Ceci devrait être notre cible pour les réseaux VoIP.

Dans un réseau vocal traditionnel, le concepteur calcule le budget total des dépréciations.

Par exemple, Io = 0 ; Iq = 0 ; Idte = 0 ; Idd = 3 ; Ie = 7, qui donne Itot = 10.

Si l'utilisateur accède au réseau à partir d'un téléphone sans fil, le facteur d'attente maximum pouvant être soustrait est 5, de sorte que le résultat final est :

Icpif = Itot - A = 10 - 5 = 5

Selon le tableau précédent, les utilisateurs sont alors susceptibles de percevoir la qualité vocale comme étant très bonne.

Ce document traite d'une solution qui utilise la valeur Icpif pour surveiller la qualité vocale plutôt que de l'utiliser à des fins de planification.

Gestion de la qualité vocale avec CVM et Telemate

Les sections suivantes expliquent comment gérer la qualité vocale avec CVM et Telemate :

• Limites
• Configuration de la passerelle
• Architecture CVM et Telemate
• Répertoire de télédiffusion
• Rapports

Limites

Bien que la solution proposée présente certaines limites, il semble qu'aucun autre outil évolutif ne soit disponible. Les limitations connues sont les suivantes :

• Seuls les appels via une passerelle sont soumis à un contrôle de qualité. Vous ne pouvez pas mesurer les appels entre IPhone et IPhone. La passerelle ne voit pas ces appels et CallManager ne prend pas actuellement en charge G.113.

• Le calcul Icpif ne prend en compte que la perte et le retard de paquets. Echo n'est pas inclus dans les calculs Icpif. Par conséquent, un appel peut subir un écho sévère et obtenir toujours un score Icpif parfait.

• La qualité vocale est mesurée uniquement dans la direction IPhone-to-gateway. La valeur Icpif dans un réseau vocal par paquets est susceptible d'être asymétrique dans les deux directions. Aucun problème de QoS réseau unidirectionnel dans la direction de passerelle vers IPhone ne sera reflété dans la valeur Icpif calculée par la passerelle.

• Les problèmes de qualité vocale sont généralement plus problématiques sur un WAN. La solution décrite convient le mieux dans un environnement avec des passerelles centralisées, car les appels des téléphones IP des sites distants doivent traverser le WAN pour accéder aux passerelles. Si des passerelles sont distribuées (c'est-à-dire que chaque site distant est géré par une passerelle locale), la plupart des appels de passerelle ne traversent pas le WAN. Les appels VoIP sur le WAN sont principalement des appels IPhone vers IPhone, qui ne sont pas visibles par la passerelle.

Configuration de la passerelle

Dans le cadre 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

La fonctionnalité de déroutement QoV doit également être activée sur toutes les passerelles. Cette fonction 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 fonctionnalité est activée par terminal de numérotation dial-peer VoIP en ajoutant les éléments suivants :

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

Lorsqu'un appel est terminé, la passerelle calcule la valeur totale de l'affaiblissement (Itot) de cet appel. Il soustrait ensuite le facteur d'attente configuré de Itot pour obtenir la valeur Icpif réelle. Si ce nombre dépasse le seuil Icpif, un déroutement QoV est envoyé. La durée de l'appel doit être d'au moins 10 secondes pour que la passerelle puisse calculer la valeur Icpif de l'appel.

Examinons un exemple où la configuration de la passerelle est la suivante :

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

Supposons qu'un appel se termine avec une valeur Itot de 20. La passerelle soustrait ensuite un facteur d'attente de 5 de ce nombre, donnant une valeur Icpif de 15. Comme 15 est supérieur à 10, la passerelle génère un déroutement SNMP QoV.

Globalement, il est nécessaire de permettre l'envoi de pièges QoV à CVM :

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

Veillez à ce que les passerelles vocales génèrent des interruptions SNMP de liaison/liaison chaque fois qu'un appel est configuré ou désactivé. Cela peut représenter un nombre énorme de déroutements sur les passerelles haute densité. Assurez-vous de désactiver ces déroutements en ajoutant la commande suivante :

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

Architecture CVM et Telemate

CVM et Telemate sont des applications totalement distinctes. Comme son nom l'indique, CVM est un produit développé par Cisco. Telemate, en revanche, est un produit tiers que Cisco vend avec CVM.

CVM remplit diverses fonctions. Les deux fonctions que nous allons utiliser sont les suivantes :

• Collecte des enregistrements détaillés des appels (CDR) à partir des passerelles via SNMP.

• Réception d'interruptions SNMP de qualité de la voix (QoV) des passerelles.

Après avoir collecté ces informations, CVM formate les données et les transmet à Telemate via un simple partage de fichiers. Telemate traite ensuite ces données et les stocke dans une base de données Microsoft SQL. Le résultat final est une base de données avec une liste d'appels avec leurs détails respectifs, y compris la valeur Icpif. Divers rapports peuvent ensuite être exécutés sur la base de données, y compris les rapports QoV.

Le rapport Telemate QoV qui nous intéresse est le rapport Packet Voice Calls with Quality of Service Traps. Ce rapport répertorie tous les appels pour lesquels la passerelle a généré un déroutement QoV. Nous ne sommes pas intéressés par les appels individuels ; nous souhaitons plutôt identifier les sites, le cas échéant, qui ont un pourcentage d'appels de qualité vocale supérieur à la moyenne. Pour ce faire, Telemate doit être en mesure de catégoriser les appels par site. Cette question est traitée dans la section suivante.

Répertoire de télédiffusion

En renseignant le répertoire Telemate avec la connaissance des postes situés sur les sites, nous pouvons utiliser Telemate pour classer les appels par site.

Le répertoire Telemate est une hiérarchie à cinq couches, avec les niveaux suivants :

• Niveau 1 - Société

• Niveau 2 - Division

• Niveau 3 - Département

• Niveau 4 - Utilisateur

• Niveau 5 - Extension

Vous pouvez associer plusieurs postes à un utilisateur.

Idéalement, nous souhaiterions que chaque appel du rapport QoV soit répertorié avec le nom du service. Nous pourrions alors utiliser le nom du service pour représenter un site donné. Cela nous permet de trier les appels par service/site. Mais comme les extensions ne peuvent être associées qu'aux utilisateurs, nous devons y parvenir d'une manière un peu maladroite. En gros, nous créons un utilisateur factice par site, et nous faisons du nom de cet utilisateur le nom du site ou le code du site. Tous les postes de ce site particulier sont ensuite affectés à cet utilisateur factice. Nous pouvons ensuite trier les appels par utilisateur, qui devient alors l'équivalent de les trier par site.

Pour les rapports QoV, nous ne nous soucions pas des trois niveaux supérieurs de la hiérarchie des répertoires, et ceux-ci peuvent être affectés n'importe quelle valeur arbitraire.

Pour cette mise en oeuvre, il y a 200 sites avec 45 000 extensions assignées, mais pas nécessairement tous en usage. Le répertoire contient donc 200 utilisateurs factices et chaque utilisateur factice est associé à la plage d'extensions de son site. Remplir le répertoire manuellement serait une tâche impossible, donc nous le faisons semi-automatiquement en générant un fichier CSV avec une ligne par extension, puis nous utilisons la fonction d'importation Telemate pour importer le fichier dans le répertoire. Chaque ligne de ce fichier CSV a le format suivant :

Company,Division,Department,User,Extension

La génération du fichier CSV lui-même est également effectuée semi-automatiquement en exécutant un script shell Unix. Ce script prend un fichier d'amorçage en entrée. Ce fichier de démarrage répertorie les sites et les plages d'extensions associées. Chaque ligne du fichier de démarrage a le format suivant :

site_name,extention_start,extension_end

Le script 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 ------------------------

En supposant que le script lui-même est nommé 'make_dir' et que le fichier de démarrage est appelé 'seedfile.csv', le fichier télémère_dir.csv CSV d'importation 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 ensuite importé dans Telemate. Reportez-vous à la documentation de Telemate pour obtenir des instructions détaillées sur la façon de procéder.

Rapports

Lors de l'exécution d'un rapport Telemate, vous pouvez sélectionner la destination de sortie. Pour les rapports volumineux, il est recommandé de produire le fichier au format CSV. Vous pouvez ensuite manipuler le rapport dans Excel, où il ressemblerait à ceci :

Durée	N° composé	Emplacement	Date	Heure	Site	Ext.
0:00:57	3-573-7783	10.200.16.33	10/05/2000	16h49:45	BLM	37569
0:00:57	3-573-7783	10.200.16.33	10/05/2000	16h49:45	BLM	37569
0:00:38	3-577-2958	10.200.16.33	10/05/2000	16h28	BLM	37576
0:00:38	3-577-2958	10.200.16.33	10/05/2000	16h28	BLM	37576
0:00:52	3-577-2985	10.200.16.33	10/05/2000	21h26	BLM	37593
0:01:19	3-577-1770	10.200.16.33	10/05/2000	19h26:05	BMC	34270
0:00:23	3-577-1770	10.200.16.33	10/05/2000	20:08:27	BMC	34270
0:00:23	3-577-1770	10.200.16.33	10/05/2000	20:08:27	BMC	34270
0:00:11	4-566-5302	10.132.16.33	10/05/2000	19h05:33	COR	42791
0:00:32	4-567-0417	10.132.16.33	10/05/2000	17h29:51	COR	42805
0:00:32	4-567-0417	10.132.16.33	10/05/2000	17h29:51	COR	42805
0:00:36	4-232-8545	10.132.16.33	10/05/2000	17h42	COR	42823
0:00:36	4-232-8545	10.132.16.33	10/05/2000	17h42	COR	42823
0:00:39	4-472-5011	10.132.16.33	10/05/2000	17h59:23PM	COR	46578
0:00:39	4-472-5011	10.132.16.33	10/05/2000	17h59:23PM	COR	46578
0:00:28	4-236-7687	10.132.16.33	10/05/2000	19h17:51	COR	46578
0:00:17	6-867-9766	10.132.16.35	10/05/2000	16:08:02	SIG	64197
0:00:17	6-867-9766	10.132.16.35	10/05/2000	16:08:02	SIG	64197
0:00:30	6-868-6889	10.132.16.35	10/05/2000	18h15:48	SIG	68549
0:00:30	6-868-6889	10.132.16.35	10/05/2000	18h15:48	SIG	68549
0:01:26	6-876-5223	10.132.16.35	10/05/2000	19 h 10 h 23	HABILER	68369
0:01:26	6-876-5223	10.132.16.35	10/05/2000	19 h 10 h 23	HABILER	68369
0:00:52	6-876-2223	10.132.16.35	10/05/2000	17h37:58	HABILER	68397
0:01:05	4-477-5402	10.132.16.33	10/05/2000	16h23	JVL	47162
0:00:24	4-478-8848	10.132.16.33	10/05/2000	19:07:09	JVL	47168
0:00:24	4-478-8848	10.132.16.33	10/05/2000	19:07:09	JVL	47168
0:00:44	4-387-1333	10.132.16.33	10/05/2000	19h49:16	KIB	49252
0:00:44	4-387-1333	10.132.16.33	10/05/2000	19h49:16	KIB	49252
0:01:14	4-389-4299	10.132.16.33	10/05/2000	16h07	KIB	49254
0:01:14	4-389-4299	10.132.16.33	10/05/2000	16h07	KIB	49254
0:00:29	4-387-1337	10.132.16.33	10/05/2000	16h45	KIB	49256
0:00:29	4-387-1337	10.132.16.33	10/05/2000	16h45	KIB	49256
0:00:41	4-384-9269	10.132.16.33	10/05/2000	16 h 38	KIB	49261
0:00:41	4-384-9269	10.132.16.33	10/05/2000	16 h 38	KIB	49261
0:00:41	4-384-9269	10.132.16.33	10/05/2000	16 h 38	KIB	49261
0:00:17	4-387-1344	10.132.16.33	10/05/2000	16h33	KIB	49263
0:00:17	4-387-1344	10.132.16.33	10/05/2000	16h33	KIB	49263
0:00:31	6-367-5103	10.132.16.35	10/05/2000	20h44:46	LEV	64233
0:00:31	6-367-5103	10.132.16.35	10/05/2000	20h44:46	LEV	64233
0:00:30	6-368-9088	10.132.16.35	10/05/2000	16h11	LEV	64247
0:00:30	6-368-9088	10.132.16.35	10/05/2000	16h11	LEV	64247
0:00:38	4-570-2450	10.132.16.33	10/05/2000	16:08:26	LHT	43636
0:00:38	4-570-2450	10.132.16.33	10/05/2000	16:08:26	LHT	43636

Utilisez la fonction « sous-totaux » Excel pour compter le nombre d'appels incorrects par utilisateur/site. Ensuite, créez une macro Excel pour semi-automatiser le sous-total. Reportez-vous à l'exemple suivant :

Durée	N° composé	Emplacement	Date	Heure	Site	Ext.
				Nombre de BCM	5
				Nombre BMC	3
				Nombre de COR	8
				Nombre de SIG	4
				Nombre de HAH	3
				Nombre JVL	3
				Nombre de KIB	11
				Nombre de LEV	4
				Nombre LHT	2
				Grand nombre	43

La colonne Site contient désormais le nombre d'appels erronés à destination/en provenance de ce site. La colonne Emplacement du rapport correspond à l'adresse IP de l'autre extrémité de la branche VoIP et provient de l'enregistrement CDR de la passerelle. Dans un environnement CallManager (CCM), les points d’extrémité de signalisation et de support sont deux adresses IP distinctes. L’adresse IP indiquée est le point de terminaison de signalisation (c’est-à-dire le CallManager). Un DDTS (CSCds23283) a été envoyé pour demander un bouton permettant à l'enregistrement CDR de consigner l'adresse IP du support à la place. Cela permettrait de trier les appels incorrects par sous-réseau. Cela donne une meilleure granularité car il y aurait généralement plusieurs sous-réseaux par site. Si seulement certains de ces sous-réseaux rencontrent des problèmes de QoV, ils peuvent être identifiés.

Nous vous recommandons de configurer le planificateur Telemate pour qu'il exécute automatiquement le rapport Packet Voice Calls with Quality of Service Traps une fois par jour. Les rapports complétés peuvent ensuite être envoyés par courrier électronique au personnel opérationnel sélectionné. Ces membres du personnel effectuent ensuite un audit QoV quotidien au cours des 24 dernières heures. Les rapports doivent être archivés pendant au moins un mois afin que toute détérioration de QoV puisse être corrélée à toute modification du réseau effectuée au cours de cette période.

Remarque : Telemate version 4.7 ou ultérieure est nécessaire pour que les rapports fonctionnent correctement avec les passerelles fonctionnant dans un environnement CallManager. Les versions antérieures de Telemate supposent que les postes locaux sont toujours du côté POTS de la passerelle. Dans un environnement CallManager, les postes locaux (IPhones) se trouvent du côté VoIP de la passerelle. Par conséquent, les versions antérieures de Telemate sont confondues et les rapports sont d'une valeur limitée.

Informations connexes

• Assistance produit Unified Communications
• Dépannage des problèmes de téléphonie IP Cisco
• Support et documentation techniques - Cisco Systems