Gerenciando a qualidade de voz com o CVM e o Telemate

Introduction

Este documento descreve o uso do Gerenciador de Voz Cisco e do Telemate para gerenciar a qualidade de voz em uma rede VoIP. Todo o conteúdo se baseia em uma implementação de Telefonia IP real. Este documento se concentra na aplicação dos produtos e não no uso dos produtos. Você já deve estar familiarizado com CVM e Telemate e ter acesso à documentação necessária do produto. Consulte Informações Relacionadas para obter uma lista de documentação relacionada.

Ao mapear uma rede VoIP de grande escala, você deve ter as ferramentas necessárias para monitorar e relatar objetivamente uma qualidade de voz na rede. Confiar apenas no feedback do usuário não é adequado, porque ele é subjetivo e incompleto. O CVM, junto com o Telemate, pode fornecer parte dessa função. Ele relata a qualidade da voz usando o fator de planejamento de deficiência/defeito calculado (Icpif) calculado por um gateway do IOS para cada chamada. Isto permite que o gerenciador de rede identifique locais com má qualidade de voz e trabalhe com eles da maneira adequada.

Depois de identificar os sites problemáticos, talvez seja necessário usar outras ferramentas para solucionar possíveis problemas de QoS. Duas ferramentas são o IPM e o CSAA. Esses tópicos são discutidos em outro documento publicado em nosso site.

Prerequisites

Requirements

Os leitores deste documento devem estar cientes destes tópicos:

• Cisco Voice Manager e Telemate

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

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.

Visão geral de qualidade de voz

As seções a seguir fornecem uma visão geral das questões referentes à qualidade de voz:

• Medindo a qualidade de voz
• Visão geral do ITU G.113

Medindo a qualidade de voz

O padrão G.113 da ITU especifica como medir a qualidade da voz. Este método determina que você pode determinar a qualidade das chamadas de voz calculando o Icpif. Os gateways baseados em IOS calculam o valor de Icpif para cada chamada e o registram como parte do registro de CDR. Além disso, ele pode enviar uma interceptação de Qualidade de Voz (QoV) via SNMP se o valor Icpif de uma chamada exceder um valor predefinido. Isso significa que os gateways têm capacidades internas de medição da qualidade da voz. Tudo o que é necessário é coletar essas medidas e analisar os dados para identificar tendências.

A qualidade de voz VoIP é afetada principalmente pela QoS da rede. Portanto, a analise da chamada se concentrará na identificação dos problemas de qualidade de voz por site individual. Se os sites que têm um grande número de chamadas com baixa qualidade de voz puderem ser identificados, poderemos nos concentrar em quaisquer problemas de QoS no caminho de rede para e a partir desses sites.

Visão geral do ITU G.113

A seção a seguir é apenas uma breve visão geral. consulte o padrão G.113 para obter informações mais detalhadas.

A idéia geral por trás da G.113 é calcular um fator de defeito de cada equipamento ao longo do caminho de voz e, em seguida, adicioná-lo para obter o defeito total. Existem diferentes tipos de defeitos (ruído, retardo, eco etc) e a ITU (união de telecomunicação internacional) os divide em cinco categorias. Adicione-os para obter a Itot total de defeito:

Itot = Io + Iq + Idte + Idd + Ie

Cada um desses defeitos é definido da seguinte forma (usando a terminologia ITU):

• Io—defeitos causados por ruído geral de alta intensidade e/ou de alto circuito não otimizado.

• Iq — defeitos causados pelo tipo PCM que quantificam a distorção.

• Idte: defeitos causados pelo eco do locutor.

• Idd — dificuldades de comunicação de fala causadas por longos tempos de transmissão unidirecional (atraso).

• Ie—defeitos causados por equipamentos especiais, em particular codecs de taxa de bits baixa não-forma de onda.

Quando o software Cisco IOS calcula a Itot, ele ignora Io e Iq como sendo insignificante e configura a Idte como 0. O valor Idd deriva da tabela a seguir, que é proveniente de G.113:

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

Normalmente Ie é um valor fixo, dependendo apenas do tipo de codec. G.113 especifica os valores para codecs tipicamente usados pelos gateways Cisco como mostrado na tabela a seguir:

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

No entanto, como esses codecs são usados em um ambiente de voz de pacote, o defeito real depende da perda de pacote. Quanto mais alta a perda de pacotes, maiores os danos. A engenharia da Cisco mediu a qualidade da voz com PSQM (ITU P.861) em níveis discretos de perda de pacotes. A tabela a seguir mostra os valores de distorção de voz relativos aos níveis de perda de pacotes para determinados codecs:

% de perda de pacote	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 esperado, o G.729 é mais susceptível à perda de pacotes do que o G.711.

A qualidade de voz depende muito da percepção e expectativa humana. As expectativas de nível de serviço de usuários de telefone celular são menores em relação àquelas de usuários de linha fixa. Temos isso em conta ao calcular o Icpif reduzindo a Itot pelo fator de expectativa humana A. A fórmula para isso é:

Icpif = Itot - A

O G.113 também fornece fatores de expectativa para redes de voz típicas. Veja a seguinte tabela:

Método de acesso à rede de voz	Aguardar fator A
PSTN de linha fixa convencional	0
Área local Wireless (telefone sem fio)	5
Ampla área sem fio (telefone celular)	10
Satélite	20

O G.113 também tem uma tabela que faz o mapeamento entre o valor lcpif e a qualidade de voz. Ele é mostrado na tabela a seguir:

Método de acesso à rede de voz	Aguardar fator A
5	Muito bom
10	Bom
20	Adequado
30	Caso limitante
45	Limitando casos excepcionalmente
55	Usuários que provavelmente se queixarão fortemente

Um valor de lcpif zero para uma chamada é um número perfeito. Esse deve ser nosso destino para redes VoIP.

Na rede de voz tradicional, o projetista calcularia o orçamento total do defeito.

Por exemplo, Io = 0; Iq = 0; Idte = 0; Idd = 3; Ie = 7, que dá Itot = 10.

Se o usuário estiver acessando a rede a partir de um telefone sem fio, o fator máximo de expectativa que pode ser diminuído é 5; então o resultado final é:

Icpif = Itot - A = 10 - 5 = 5

De acordo com a tabela anterior, os usuários provavelmente perceberão a qualidade da voz como sendo muito boa.

Este documento descreve uma solução que usa o valor Icpif para monitorar a qualidade de voz em vez de usá-lo para fins de planejamento.

Gerenciando a qualidade de voz com o CVM e o Telemate

As seções a seguir discutem como gerenciar a qualidade de voz com CVM e Telemate:

• Limitações
• Configuração de gateway
• Arquitetura Telemate e CVM
• Diretório Telemate
• Relatórios

Limitações

Embora a solução proposta tenha algumas limitações, parece não haver nenhuma outra ferramenta dimensionável disponível. As limitações conhecidas incluem:

• Somente as chamadas por meio de um gateway estão sujeitas ao controle de qualidade. Você não pode medir as chamadas de Iphone para Iphone. O gateway não vê essas chamadas e o CallManager atualmente não suporta G.113.

• O cálculo de Icpif leva em consideração somente a perda e retardo de pacotes. Eco não está incluído nos cálculos Icpif. Por isso, uma chamada pode sofrer bastante eco e ainda obter uma pontuação Icpif perfeita.

• A qualidade da voz é medida somente na direção de telefone IP para gateway. O valor Icpif em uma rede de voz de pacote de informações provavelmente será assimétrico nas duas direções. Nenhum problema de QoS de rede unidirecional no sentido gateway-para-IPhone será refletido no valor Icpif calculado pelo gateway.

• As questões de qualidade de voz geralmente são mais problemáticas em uma WAN. A solução discutida se encaixa melhor em um ambiente com gateways centralizados, como chamadas de IPhones em estações remotas para atravessar a WAN para acessar os gateways. Se os gateways forem distribuídos (ou seja, cada local remoto é atendido por um gateway local), a maioria das chamadas de gateway não cruzará a WAN. As chamadas de VoIP através da WAN serão principalmente de IPhone para IPhone, e não são visíveis para o gateway.

Configuração de gateway

Como parte da solução proposta, todos os gateways precisam ser configurados para a coleta de CDR.

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

Todos os gateways também devem ter o recurso de interceptação QoV ativado. Este recurso é desativado como padrão.

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

Esse recurso é ativado por peer de discagem de VoIP, adicionando o seguinte:

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

Ao se completar uma chamada, o gateway calcula o defeito total (ltot) para essa chamada. Em seguida, subtrai o fator de expectativa configurado da Itot para chegar ao valor Icpif real. Se esse número exceder o limite Icpif, uma armadilha de QoV será enviada. As chamadas devem durar menos de 10 segundos para que o gateway possa calcular o valor lcpif da chamada.

Examinaremos um exemplo, em que a configuração do gateway é a seguinte:

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

Suponha que uma chamada seja concluída com um valor Itot de 20. Em seguida, o gateway subtrai um fator esperado de 5 desse número, dando um valor Icpif de 15. Como 15 é mais que 10, o gateway gera uma interceptação SNMP QoV.

No âmbito global, é necessário ativar os desvios do QoV para serem enviados para o CVM:

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

Esteja ciente de que os gateways de voz geram desvios de SNMP de enlace superior/enlace inferior sempre que uma chamada for configurada ou cair. Isso pode significar um número enorme de armadilhas em um gateway de alta densidade. Certifique-se de desabilitar essas armadilhas adicionando o seguinte comando:

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

Arquitetura Telemate e CVM

CVM e Telemate são aplicativos completamente separados. Como o nome indica, o CVM é um produto desenvolvido pela Cisco. O Telemate, por outro lado, é um produto de terceiros que a Cisco vende junto com o CVM.

O CVM executa uma variedade de funções. As duas funções que serão usadas são:

• Coletando Registros de detalhes da chamada (CDR) dos gateways via SNMP.

• Recebendo interceptações SNMP de Qualidade de Voz (QoV) dos gateways.

Depois de coletar essas informações, o CVM formata os dados e os transfere para Telemate através de um simples compartilhamento de arquivos. Em seguida, o Telemate processa esses dados e os armazena em um banco de dados do Microsoft SQL. O resultado final é um banco de dados com uma lista de chamadas com seus respectivos detalhes, incluindo o valor Icpif. É possível executar vários relatórios no banco de dados, incluindo relatórios de QoV.

O relatório de QoV do Telemate no qual estamos interessado é o "Packet Voice Calls with Quality of Service Traps" (Chamadas de voz de pacotes com desvios de qualidade do serviço). Esse relatório lista todas as chamadas para as quais o gateway gerou uma armadilha QoV. Não estamos interessados nos convites individuais; em vez disso, estamos interessados em identificar os sites, se houver, que têm uma porcentagem acima da média de chamadas com qualidade de voz. Para alcançar isso, Telemate precisa ser capaz de categorizar as chamadas por site. Esse tópico é abordado na seção a seguir.

Diretório Telemate

Ao preencher o diretório Telemate sabendo quais extensões residem em quais estações, podemos usar o Telemate para categorizar as chamadas por estação.

O diretório Telemate é uma hierarquia de cinco camadas, com os seguintes níveis:

• Nível 1 - Empresa

• Nível 2 – Divisão

• Nível 3 - Departamento

• Nível 4 - Usuário

• Nível 5 - Extensão

Você pode associar vários ramais a um usuário.

Idealmente, gostaríamos que cada chamada no relatório de QoV fosse listada com o nome do departamento. Podemos, então, usar o nome do departamento para representar uma estação específica. Isso nos permite classificar chamadas por departamento/site. Mas como as extensões podem ser associadas somente a usuários, temos que chegar a isso de uma maneira ligeiramente desajeitada. Basicamente, nós criamos um usuário fictício por site e adotamos o nome desse usuário como o nome do site ou o código do site. Então, todas as extensões para aquele site específico são atribuídas a este usuário fictício. Podemos então classificar as chamadas por usuário, o que equivale a classificá-las por site.

Para a finalidade do relatório de QoV, não levamos em consideração os primeiros três níveis da hierarquia de diretórios, que podem receber qualquer valor arbitrário.

Para esta implementação, existem 200 sites com 45.000 extensões atribuídas apenas, apesar de que nem todas estão necessariamente em uso. Portanto, o diretório contém 200 usuários fictícios e cada usuário fictício está associado ao intervalo de ramais para seu site. Preencher manualmente o diretório seria uma tarefa impossível, portanto, fazemos isso semiautomaticamente, gerando um arquivo CSV com uma linha por ramal, e então usamos o recurso de importação Telemate para importar o arquivo para o diretório. Cada linha neste arquivo CSV tem o seguinte formato:

Company,Division,Department,User,Extension

A geração do arquivo CSV também é realizada de forma semi-automática por meio da execução de um script de shell Unix. Esse script pega um arquivo de alimentação como entrada. Esse arquivo de seed lista os sites e os intervalos de extensão associados. Cada linha no arquivo de seed tem este formato:

site_name,extention_start,extension_end

O próprio shell script é muito simples e parecido com este:

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

Supondo que o próprio script seja chamado 'make_dir' e que o arquivo seed seja chamado 'seedfile.csv', o arquivo import CSV telemate_dir.csv é criado executando o seguinte comando no prompt do Unix:

unix$ make_dir seedfile.csv > telemate_dir.csv

O arquivo de saída telemate_dir.csv é importador para Telemate. Consulte a documentação do Telemate para obter instruções detalhadas de como fazer isso.

Relatórios

Quando estiver executando um relatório do Telemate, você pode selecionar o destino de saída. Para relatórios grandes, recomendamos que o arquivo seja criado no formato CSV. Em seguida, é possível manipular o relatório no Excel, onde ele aparecerá assim:

Duration	Nº discado	Local	Data	Tempo	Local	Ext.
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	19:05:33	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	17:42:07	COR	42823
0:00:36	4-232-8545	10.132.16.33	10/05/2000	17:42:07	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	18:15:48	GIS	68549
0:00:30	6-868-6889	10.132.16.35	10/05/2000	18:15:48	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	16:23:20	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	19:49:16	KIB	49252
0:00:44	4-387-1333	10.132.16.33	10/05/2000	19:49:16	KIB	49252
0:01:14	4-389-4299	10.132.16.33	10/05/2000	16:07:10	KIB	49254
0:01:14	4-389-4299	10.132.16.33	10/05/2000	16:07:10	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	16:08:26	LHT	43636
0:00:38	4-570-2450	10.132.16.33	10/05/2000	16:08:26	LHT	43636

Use o recurso "subtotais" do Excel para contar o número de chamadas incorretas por usuário/site. Em seguida, crie uma macro do Excel para semi-automatizar a totalização. Veja o seguinte exemplo:

Duration	Nº discado	Local	Data	Tempo	Local	Ext.
				Contagem BCM	5
				BMC Count	3
				Contagem de COR	8
				Contagem GIS	4
				Contagem HAH	3
				Contagem JVL	3
				Contagem de KIB	11
				Contagem de LEV	4
				Contagem LHT	2
				Contagem Grand	43

A coluna Site agora contém o número de chamadas incorretas de/para esse site. A coluna Location (Local) no relatório é o endereço IP da outra extremidade do segmento VoIP e provém do registro CDR do gateway. Em um ambiente do CallManager (CCM), a sinalização e os terminais de mídia são dois endereços IP distintos. O endereço IP listado é o terminal de sinalização (ou seja, o CallManager). Um DDTS (CSCds23283) foi enviado para solicitar um botão que permite ao registro de CDR gravar o endereço IP da mídia. Isso permitiria a classificação de chamadas inválidas pela sub-rede. Isto proporciona uma melhor granularidade, pois normalmente haveria diversas sub-redes por localização. Se somente algumas dessas sub-redes estiverem enfrentando problemas de QoV, será possível identificá-los.

Recomendamos que você configure o agendador Telemate para executar automaticamente o relatório "Packet Voice Calls with Quality of Service Traps" uma vez por dia. Relatórios completos podem ser enviados por e-mail para o staff operacional selecionado. Esses membros da equipe fazem uma auditoria diária de QoV nas últimas 24 horas. Os relatórios devem ser arquivados por pelo menos um mês de forma que qualquer deterioração no QoV possa ser correlacionada com qualquer alteração na rede por volta desse horário.

Observação: o Telemate versão 4.7 ou posterior é necessário para que os relatórios funcionem corretamente com gateways que operam em um ambiente CallManager. Versões anteriores do Telemate presumem que as extensões locais estão sempre no lado POTS do gateway. Em um ambiente do CallManager, as extensões locais (IPhones) estão no lado do VoIP do gateway. Como resultado, versões anteriores do Telemate ficam confusas e os relatórios têm valor limitado.

Informações Relacionadas

• Suporte ao produto Unified Communications
• Troubleshooting da Telefonia IP Cisco
• Suporte Técnico e Documentação - Cisco Systems