Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Convenciones

Descripción General de Calidad de la Voz

Medición de la Calidad de la Voz

Descripción general de ITU G.113

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

Limitaciones

Configuración de gateway

Arquitectura de CVM y Telemate

Directorio Telemate

Informes

Información Relacionada

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. Informa sobre la calidad de voz mediante el uso del factor de planificación de discapacidad/discapacidad calculada (Icpif) calculado por una gateway 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 publicado en nuestro sitio web.

Prerequisites

Requirements

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.

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.

Convenciones

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

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

- Descripción general de ITU G.113

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 indica que puede determinar la calidad de las llamadas 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 trampa de calidad de voz (QoV) a través de SNMP si el valor Icpif de una llamada supera un valor preestablecido. Esto significa que las gateways tienen incorporada la capacidad de medir la calidad de la voz. Todo lo que hace falta es recopilar estas mediciones y analizar los datos para identificar cualquier tendencia.

La calidad de voz VoIP se ve afectada principalmente por la QoS de red. 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 siguiente sección es sólo una breve descripción general; consulte la norma G.113 para obtener información más 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. Agréguelos para obtener el total de la insuficiencia Itot:

Itot = Io + Iq + Idte + Idd + Ie

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

- Io: impedimentos causados por la clasificación general de ruido no óptima y/o ruido de circuito alto.

- Iq: impedimentos causados por el tipo PCM que cuantifica la distorsión.

- Idte: impedimentos causados por el eco del lector.

- Idd: dificultades de comunicación de voz causadas por largos tiempos de transmisión unidireccional (retraso).

- Ie: impedimentos causados por equipos especiales, en particular códecs de baja velocidad de bits sin forma de onda.

Cuando el software Cisco IOS calcula Itot, ignora Io y Iq como insignificantes y establece Idte en 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

Normalmente, Ie es un valor fijo, dependiendo sólo del tipo de códec. G.113 especifica los valores para los códecs que suelen utilizar las gateways de Cisco, como se muestra en la siguiente tabla:

Code

Ie

G.711

0

G.729/G.729a

10

Sin embargo, debido a que estos códecs se utilizan en un entorno de voz de paquete, el deterioro real 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 siguiente tabla muestra los valores de distorsión de voz relativos a los niveles de pérdida de paquetes para los códecs dados:

% 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 de paquetes 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. Esto se tiene en cuenta al calcular el Icpif mediante la reducción del Itot por el factor de expectativa humana A. 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 siguiente tabla:

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

Es probable que los usuarios se quejen enérgicamente

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; Iq = 0; Idte = 0; Idd = 3; Ie = 7, que da 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

En las secciones siguientes se explica cómo gestionar la calidad de voz con CVM y Telemate:

- Limitaciones

- Configuración de gateway

- Arquitectura de CVM y Telemate

- Directorio Telemate

- Informes

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. El 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 sólo se mide en la dirección 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 puertas de enlace (es decir, cada sitio remoto recibe el servicio de un gateway local), la mayoría de las llamadas de puerta de enlace no cruzarán la WAN. Las llamadas VoIP a través de la WAN serán principalmente de IPhone a IPhone y no son visibles para el 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 gateways también deben tener habilitada la función de trampa de QoV. 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. A continuación, resta el factor de espera configurado de Itot para llegar al valor Icpif real. Si este número excede el umbral Icpif, se envía una trampa de 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

Suponga que una llamada se completa con un valor Itot de 20. A continuación, la puerta de enlace resta un factor de espera de 5 de este número, lo que proporciona un valor Icpif de 15. Debido a que 15 es más de 10, el gateway genera una trampa SNMP 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 suponer un enorme número de trampas 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

CVM y Telemate son aplicaciones completamente independientes. Como el nombre lo indica, CVM es un producto desarrollado por Cisco. Telemate, por otra parte, es un producto de terceros que Cisco vende junto con 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.

- Capturas SNMP de calidad de voz (QoV) recibidas desde las puertas de enlace.

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, incluido 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 nos interesan las llamadas individuales; más bien, estamos interesados en identificar los sitios, si los hay, que tienen un porcentaje de llamadas superior a la media con 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.

Lo ideal es que cada llamada del informe de QoV aparezca con el nombre del departamento. Podríamos utilizar el nombre del departamento para representar un sitio determinado. Esto nos permite ordenar las llamadas por departamento/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. Así que el directorio contiene 200 usuarios ficticios y cada usuario ficticio está asociado con el rango de extensiones para su sitio. Rellenar el directorio manualmente sería una tarea imposible, por lo que lo hacemos semiautomáticamente mediante la generación de un archivo CSV con una línea por extensión y, a continuación, utilizamos la función de importación de Telemate para importar el archivo en el directorio. Cada línea de este archivo CSV tiene el siguiente formato:

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

Suponiendo que la secuencia de comandos se denomina 'make_dir' y que el archivo simiente se denomina 'seedfile.csv', el archivo CSV de importación telemate_dir.csv se crea ejecutando el siguiente comando en la indicación 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:

Duration

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

16:23:20

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:

Duration

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 Sitio ahora contiene el número de llamadas incorrectas hacia/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 de CallManager (CCM), los terminales de medios y de señalización son dos direcciones IP distintas. La dirección IP enumerada es el punto final 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.

Le recomendamos que configure el programador de Telemate para ejecutar 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 realizan una auditoría diaria de QoV durante 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: Se requiere la versión 4.7 o posterior de Telemate para que los informes funcionen correctamente con gateways que funcionan en un entorno de CallManager. Las versiones anteriores de Telemate suponen que las extensiones locales siempre están en el lado POTS del gateway. En un entorno CallManager, las extensiones locales (teléfonos IP) se encuentran en el lado de VoIP de la gateway. Como resultado, las versiones anteriores de Telemate se confunden y los informes tienen un valor limitado.

Información Relacionada

- Soporte de productos de Comunicaciones Unificadas

- Troubleshooting de Cisco IP Telephony

- Soporte Técnico y Documentación - Cisco Systems