Voz y Comunicaciones unificadas : Cisco Unified Communications Manager (CallManager)

Administración de la Calidad de la Voz con Cisco Voice Manager (CVM) y Telemate

17 Octubre 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

Este documento describe el uso de Cisco Voice Manager y Telemate para administrar la calidad de voz en una red VoIP. Todo contenido se basa en una implementación de IP Telephony del mundo real. Este documento se concentra en la aplicación de los productos y no en el uso de los productos. Ya debería estar familiarizado con CVM y Telemate y tener acceso a la documentación del producto requerida. Vea Información Relacionada para obtener una lista de documentación relacionada.

Al administrar una red VoIP a gran escala, deberá contar con las herramientas necesarias para supervisar e informar objetivamente la calidad de la voz en la red. Confiar solamente en los comentarios de usuarios no es viable ya que son subjetivos e incompletos. CVM, junto con Telemate, pueden proporcionar parte de esta función. Señala sobre la Calidad de voz usando el Impairment/Calculated Impairment Planning Factor (Icpif) calculado por un gateway del IOS para cada llamada. Esto le permite al administrador de red identificar sitios con mala calidad de voz y tratarlos de forma adecuada.

Una vez idenfiticados algunos sitios con problemas, tal vez necesite otras herramientas para resolver posibles problemas de Calidad de servicio (QoS) de la red. Dos de las herramientas son Supervisión del rendimiento entre redes (IPM) y Agente de garantía de servicio de Cisco (CSAA). Estos temas se discuten en otro documento fijado en nuestro sitio web.

prerrequisitos

Requisitos

Quienes lean este documento deben tener conocimiento de los siguientes temas:

  • Cisco Voice Manager y Telemate

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte las Convenciones de Consejos Técnicos de Cisco.

Descripción General de Calidad de la Voz

Las siguientes secciones ofrecen una descripción general de los problemas de calidad de voz.

Medición de la Calidad de la Voz

El estándar G.113 de ITU especifica cómo medir la calidad de la voz. Este método dicta que usted puede determinar las calidades de la llamada de voz calculando el Icpif. Las gateways basadas en el IOS calculan el valor lcpif para cada llamada y lo registran como parte del registro de CDR. Además, puede enviar una calidad del desvío de la Voz (QoV) vía el SNMP si el valor Icpif de una llamada excede un valor preestablecido. Esto significa que las gateways tienen incorporada la capacidad de medir la calidad de la voz. Todos que son necesarios son recogen estas medidas y analizan los datos para identificar cualquier tendencia.

La Calidad de voz VoIP es afectada principalmente por la red QoS. Por lo tanto, el análisis de las llamadas se concentrará en la identificación de problemas de calidad de voz por sitio. Si se pueden identificar aquellos sitios que tienen gran cantidad de llamadas con una calidad de voz deficiente, podemos centrarnos en cualquier problema de QoS en el trayecto de red desde y hacia tales sitios.

Descripción general de ITU G.113

La sección siguiente es solamente una breve descripción; consulte el estándar G.113 para más información detallada.

La idea general detrás del G.113 es calcular un factor de defecto para cada pieza de equipo del trayecto de voz y luego agregarlas para obtener el defecto total. Existen diferentes tipos de desperfectos (ruido, retardo, eco, etc.) y la ITU los divide en cinco categorías. Agreguelas hasta consiguen el Itot total de la debilitación:

Itot = Io + Iq + Idte + Idd + Ie

A cada uno de estos se lo define de la siguiente manera (utilizando la terminología ITU):

  • Io — debilitaciones causadas por el grado total de la intensidad del NON-grado óptimo y/o el alto ruido de circuito.

  • Índice de inteligencia — debilitaciones causadas por el tipo PCM que cuantifica la distorsión.

  • Idte — debilitaciones causadas por el eco del hablante.

  • Idd — dificultades de la comunicación del discurso causadas por los tiempos de transmisión de un sentido largos (retardo).

  • IE — debilitaciones causadas por el equipo especial, particularmente codecs del low-bit-rate de la NON-forma de onda.

Cuando el Cisco IOS Software calcula el Itot, ignora el Io y el índice de inteligencia como siendo insignificante y fija el Idte a 0. El valor Idd se deriva de la siguiente tabla que proviene de G.113:

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

El IE es normalmente un valor fijo, dependiendo solamente del tipo de códec. El G.113 especifica los valores para el codecs usado típicamente por los gatewayes de Cisco tal y como se muestra en de la tabla siguiente:

Código Ie
G.711 0
G.729/G.729a 10

Sin embargo, porque este codecs se utiliza en un entorno de los paquetes de voz, el deterioro actual depende de la pérdida del paquete. Cuanto más alta sea la pérdida de paquete, mayor será el impedimento. La ingeniería de Cisco posee calidad de voz medida con PSQM (ITU P.861) en niveles de pérdida de paquetes discretos. La tabla siguiente muestra a valores de distorsión de voz los niveles de pérdida del paquete en relación con para el codecs dado:

% de pérdida del paquete 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

Como se esperaba, G.729 es más susceptible a la pérdida del paquete que G.711.

La calidad de la voz depende de la percepción y las expectativas humanas. Las expectativas del nivel de servicio de usuarios de teléfono celular son más bajas que las de los usuarios de líneas fijas. Tomamos en cuenta esto al calcular el Icpif reduciendo el Itot por el factor humano A. de la expectativa. La fórmula para esto es:

Icpif = Itot - A

G.113 también provee factores de expectativa para las redes de voz típicas. Vea la tabla siguiente:

Método de acceso a la red por voz Factor esperado A
PSTN de línea fija convencional 0
Área local inalámbrica (teléfono sin cable) 5
Inalámbrico de área ancha (teléfono celular) 10
Satélite 20

G.113 también tiene una tabla que traza un mapa entre el valor Icpif y la calidad de voz. Se muestra en la tabla siguiente:

Método de acceso a la red por voz Factor esperado A
5 Muy bueno
10 Bien
20 Adecuado
30 Caso restrictivo
45 Caso excepcionalmente restrictivo
55 Usuarios probablemente a quejarse fuertemente

Un valor cero para Icpif para una llamada es una puntuación perfecta. Éste debería ser nuestro destino para las redes VoIP.

En una red de voz tradicional, el diseñador calcularía el presupuesto total de desperfectos.

Por ejemplo, Io = 0; Índice de inteligencia = 0; Idte = 0; Idd = 3; IE = 7, que da el Itot = 10.

Si el usuario accede a la red desde un teléfono inalámbrico, el factor máximo de expectativa que puede sustraerse es 5 y, por lo tanto, el resultado final es:

Icpif = Itot - A = 10 - 5 = 5

Según la tabla anterior, los usuarios probablemente perciban una muy buena calidad de voz.

Este documento analiza una solución que utiliza el valor Icpif para controlar la calidad de la voz en lugar de emplearlo con fines de planificación.

Administración de la Calidad de la Voz con CVM y Telemate

Las secciones siguientes discuten cómo manejar la Calidad de voz con el CVM y el Telemate:

Limitaciones

A pesar de que la solución propuesta tiene ciertas limitaciones, aparentemente no existen otras herramientas de ampliación disponibles. Entre las limitaciones conocidas se encuentran:

  • Solamente las llamadas a través de una gateway están sujetas al control de calidad. No es posible medir las llamadas de IPhone a IPhone. La gateway no ve estas llamadas y el CallManager actualmente no admite G.113.

  • El cálculo de Icpif toma en cuenta sólo la pérdida y el retraso de paquetes. La generación de eco no se incluye en los cálculos Icpif. En consecuencia, una llamada puede presentar un eco severo y aún así recibir una puntuación lcpif perfecta.

  • La Calidad de voz se mide solamente en la dirección del IPhone-a-gateway. El valor Icpif en una red de voz en paquetes suele ser asimétrico en las dos direcciones. Todo problema de red unidireccional QoS en la dirección de gateway a teléfono IP no se verá reflejado en el valor lcpif calculado por el gateway.

  • Por lo general, los problemas en la calidad de voz son más un problema a través de un WAN. La solución propuesta se adapta mejor a un entorno con gateways centralizados, ya que las llamadas provenientes de IPhones que se encuentran en ubicaciones remotas deben cruzar la WAN para poder acceder a los gateways. Si se distribuyen los gatewayes (es decir, cada sitio remoto es mantenido por un gateway local), después la mayoría de las llamadas del gateway no cruzarán WAN. Las llamadas VoIP a través de WAN estarán principalmente IPhone-a-IPhone, y éstas no son visibles al gateway.

Configuración de gateway

Como parte de la solución propuesta, todas las gateway deben configurarse para la recolección CRD:

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

Todos los gatewayes deben también tener la característica del desvío del QoV habilitada. Esta función está desactivada de manera predeterminada.

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

Esta función se activa por par de marcado VoIP al agregar lo siguiente:

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

Cuando se completa una llamada, el gateway calcula el impedimento total (ltot) para esa llamada. Entonces resta el esperar-factor configurado del Itot para llegar el valor Icpif real. Si este número excede el umbral Icpif, después se envía un desvío del QoV. La duración de las llamadas debe ser de 10 segundos para que la gateway calcule el valor de Icpif de la llamada.

Veamos un ejemplo en el que la configuración de la gateway es la siguiente:

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

Asuma que una llamada completa con un valor del Itot de 20. El gateway entonces resta un factor de la espera de 5 de este número, dando un valor Icpif de 15. Porque 15 es más entonces 10, el gateway genera un SNMP trap del QoV.

Globalmente, es necesario habilitar las trampas QoV para que sean enviadas a CRM:

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

Tenga en cuenta que los gateways de voz generan trampas de SNMP en el link ascendente/descendente cada vez que se configura o se cierra una llamada. Esto puede ascender a un enorme número de desvíos en el gateway de alta densidad. Asegúrese de desactivar estas trampas agregando el siguiente comando:

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

Arquitectura de CVM y Telemate

El CVM y el Telemate son aplicaciones totalmente separadas. Como el nombre lo indica, CVM es un producto desarrollado por Cisco. El Telemate, por otra parte, es un producto de terceros que las ventas de Cisco liaron con el CVM.

CVM realiza una variedad de funciones. Las dos funciones que utilizaremos son:

  • Recopilación de registros de detalles de llamadas (CDR) de los gateways a través de SNMP.

  • Recepción de la calidad del SNMP traps de la Voz (QoV) de los gatewayes.

Después de recolectar la información, CVM da formato a los datos y los pasa a Telemate a través del intercambio de archivo simple. Luego, Telemate procesa esta información y la almacena en una base de datos de Microsoft SQL. El resultado final es una base de datos con una lista de llamadas con sus detalles respectivos, incluyendo el valor Icpif. Luego, es posible ejecutar varios informes utilizando la base de datos, incluidos informes de QoV.

El informe Telemate QoV que nos interesa es el "Paquete de llamadas de voz con trampas de calidad del servicio". Este informe proporciona una lista de todas las llamadas para las cuales el puerto de enlace generó una trampa QoV. No estamos interesados en las llamadas individuales; bastante, estamos interesados en la identificación de los sitios, eventualmente, que tienen un porcentaje medio antedicho de las llamadas con la Calidad de voz. Para lograr esto, Telemate debe ser capaz de categorizar las llamadas por sitio. Esto se discute en la siguiente sección.

Directorio Telemate

Al llenar el directorio Telemate con datos acerca de qué extensiones residen en cada sitio, podemos usar Telemate para categorizar las llamadas por sitio.

El directorio Telemate tiene una jerarquía de cinco capas, con los siguientes niveles:

  • Nivel 1 - Empresa

  • Nivel 2 - División

  • Nivel 3 - Departamento

  • Nivel 4: usuario

  • Nivel 5: Extensión

Puede asociar múltiples extensiones a un usuario.

Idealmente, quisiéramos que cada llamada en el informe del QoV fuera enumerada con el nombre del departamento. Podríamos utilizar el nombre del departamento para representar un sitio determinado. Esto permite que clasifiquemos las llamadas por el departamento/el sitio. Pero debido a que las extensiones pueden asociarse únicamente con los usuarios, debemos alcanzar esto de una manera un tanto complicada. Básicamente, nosotros creamos un usuario falso por sitio y hacemos que el nombre de este usuario sea el del sitio o código del sitio. Luego, se le asignan al usuario falso todas las extensiones para ese sitio particular. Por lo tanto, podemos clasificar las llamadas por usuario, que posteriormente equivale a la clasificación por sitio.

Para el propósito del informe de QoV, no nos importan los tres niveles superiores de la jerarquía del directorio y a estos pueden asignárseles cualquier valor arbitrario.

Para esta implementación, hay 200 sitios con 45,000 extensiones asignadas, si bien no todas están necesariamente en uso. El directorio contiene tan a 200 usuarios falsos y asocian a cada usuario falso al rango de las Extensiones para su sitio. La población del directorio sería manualmente una tarea imposible así que hacemos esto semiautomático generando a archivo CSV con una línea por la extensión, y entonces utilizamos la función de importación de Telemate para importar el archivo en el directorio. Cada línea en esto archivo CSV tiene el formato siguiente:

Company,Division,Department,User,Extension

También se realiza automáticamente la generación del archivo CSV mediante la ejecución de una secuencia de comandos shell UNIX. Esta secuencia de comandos considera a un archivo simiente como la entrada. Este archivo simiente lista los sitios y los rangos de internos asociados. Cada línea en el archivo simiente tiene este formato:

site_name,extention_start,extension_end

La secuencia de comandos shell es muy simple y es similar a lo siguiente:

#--------------------------- 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 ------------------------

Si se asume que el script sí mismo está nombrado “make_dir” y que el archivo simiente está llamado “seedfile.csv”, el archivo de la importación CSV telemate_dir.csv es creado ejecutando el siguiente comando en el prompt de Unix:

unix$ make_dir seedfile.csv > telemate_dir.csv

El archivo de salida telemate_dir.csv luego se importa al Telemate. Consulte la documentación de Telemate para obtener instrucciones detalladas sobre cómo hacer esto.

Informes

Durante la ejecución de un informe Telemate, es posible seleccionar el destino de salida. Para informes largos, se recomienda realizar el archivo en formato CSV. Puede entonces manipular el informe en Excel, donde se verá como se muestra debajo:

Duración Nº marcado Ubicación Fecha Hora ‘Sitio’ Ext.
0:00:57 3-573-7783 10.200.16.33 10/05/2000 0.701215278 BLM 37569
0:00:57 3-573-7783 10.200.16.33 10/05/2000 0.701215278 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 0.839201389 BMC 34270
0:00:23 3-577-1770 10.200.16.33 10/05/2000 0.839201389 BMC 34270
0:00:11 4-566-5302 10.132.16.33 10/05/2000 7:05:33PM COR (Clases de restricciones) 42791
0:00:32 4-567-0417 10.132.16.33 10/05/2000 5:29:51PM COR (Clases de restricciones) 42805
0:00:32 4-567-0417 10.132.16.33 10/05/2000 5:29:51PM COR (Clases de restricciones) 42805
0:00:36 4-232-8545 10.132.16.33 10/05/2000 0.737581019 COR (Clases de restricciones) 42823
0:00:36 4-232-8545 10.132.16.33 10/05/2000 0.737581019 COR (Clases de restricciones) 42823
0:00:39 4-472-5011 10.132.16.33 10/05/2000 5:59:23PM COR (Clases de restricciones) 46578
0:00:39 4-472-5011 10.132.16.33 10/05/2000 5:59:23PM COR (Clases de restricciones) 46578
0:00:28 4-236-7687 10.132.16.33 10/05/2000 7:17:51PM COR (Clases de restricciones) 46578
0:00:17 6-867-9766 10.132.16.35 10/05/2000 4:08:02 p.m. GIS 64197
0:00:17 6-867-9766 10.132.16.35 10/05/2000 4:08:02 p.m. GIS 64197
0:00:30 6-868-6889 10.132.16.35 10/05/2000 6:15:48 p.m. GIS 68549
0:00:30 6-868-6889 10.132.16.35 10/05/2000 6:15:48 p.m. GIS 68549
0:01:26 6-876-5223 10.132.16.35 10/05/2000 0.798877315 HAH 68369
0:01:26 6-876-5223 10.132.16.35 10/05/2000 0.798877315 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 0.82587963 KIB 49252
0:00:44 4-387-1333 10.132.16.33 10/05/2000 0.82587963 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:04 p.m. KIB 49263
0:00:17 4-387-1344 10.132.16.33 10/05/2000 4:33:04 p.m. KIB 49263
0:00:31 6-367-5103 10.132.16.35 10/05/2000 8:44:46 p.m. LEV 64233
0:00:31 6-367-5103 10.132.16.35 10/05/2000 8:44:46 p.m. LEV 64233
0:00:30 6-368-9088 10.132.16.35 10/05/2000 0.674375 LEV 64247
0:00:30 6-368-9088 10.132.16.35 10/05/2000 0.674375 LEV 64247
0:00:38 4-570-2450 10.132.16.33 10/05/2000 4:08:26 p.m. LHT 43636
0:00:38 4-570-2450 10.132.16.33 10/05/2000 4:08:26 p.m. LHT 43636

Utilice la función "subtotales" de Excel para contar el número de llamadas incorrectas por usuario/sitio. Luego, cree una macro de Excel para semi automatizar los subtotales. Ver el siguiente ejemplo:

Duración Nº marcado Ubicación Fecha Hora ‘Sitio’ Ext.
        Recuento BCM 5  
        Conteo BMC 3  
        Contador de COR 8  
        Conteo de GIS 4  
        Cuenta HAH 3  
        Cuenta JVL 3  
        Cuenta KIB 11  
        Cuenta de LEV 4  
        Cuenta LHT 2  
        Gran cuenta 43  

La columna del sitio ahora contiene el número de malas llamadas a/desde ese sitio. La columna de Ubicación del informe es la dirección IP del otro extremo del tramo de VoIP y proviene del registro CDR de la gateway. En un entorno del CallManager (CCM), la señalización y los puntos extremos de los media son dos IP Addresses distintos. La dirección IP enumerada es el terminal de señalización (es decir, el CallManager). Se envió un DDTS (CSCds23283) para solicitar un botón que permita que el registro CDR registre la dirección IP de medios. Esto permitiría que las llamadas incorrectas sean ordenadas por subred. Esto proporciona una mejor granularidad ya que normalmente habría múltiples subredes por sitio. Si sólo algunas de estas subredes están experimentando problemas QoV, entonces éstos se pueden identificar.

Recomendamos que usted configura al programador Telemate para funcionar con automáticamente el informe "Llamadas de Voz de Paquetes con Trampas de Calidad de Servicio" una vez al día. Los informes completos pueden enviarse por correo electrónico al personal de operaciones seleccionado. Estos miembros del personal entonces hacen una auditoría del QoV del diario para las últimas 24 horas. Los informes deben ser archivados al menos por un mes para que cualquier deterioro en la Calidad de voz (QoV) pueda ser correlacionado con cualquier cambio en la red realizado en ese periodo.

Nota: La versión de Telemate 4.7 o más adelante se requiere para que el señalar trabaje correctamente con los gatewayes que actúan en un entorno de CallManager. Las versiones anteriores del Telemate asumen que las extensiones locales están siempre en el lado de los CRISOLES del gateway. En un entorno CallManager, las extensiones locales (teléfonos IP) se encuentran en el lado de VoIP de la gateway. Como consecuencia, las versiones anteriores del Telemate consiguen confusas y los informes están de valor límite.


Información Relacionada


Document ID: 13940