Call Center Problemas

Carlos Alberto Stahelin
Monitoramento, Análise e Diagnóstico de Problemas

de Sistema VOIP em um Call Center
São José – SC
Fevereiro / 2014
Monografia sob o tı́tulo “Monitoramento, Análise e Diagnóstico de Problemas de Sistema
VOIP em um Call Center”, defendida por Carlos Alberto Stähelin e aprovada em 28 de fevereio
de 2014, em São José, Santa Catarina, pela banca examinadora assim constituı́da:
Prof. Eraldo Silveira e Silva , Dr.

Orientador
Prof. Deise Monquelate Arndt , M.

IFSC
Maicon Pereira, Eng.

Departamento de Soluções Integradoras - Intelbras
Agradecimentos
Agradeço a Deus, por acompanhar cada passo da minha vida. Dedico todo o resultado
deste trabalho para minha mãe Rita Cassia de Souza Stähelin e meu pai Aldori Luiz Stähelin,
vocês também são responsáveis por essa conquista, pela educação que me proporcionaram e
pelo incentivo para que eu pudesse estudar. Agradeço a Thaise Klein pelo companheirismo
e apoio incondicional. Agradeço aos meus amigos pelas palavras de incentivo. Agradeço a
minha empresa pela oportunidade de implantar o projeto. Obrigado Prof. Dr. Eraldo Silveira e
Silva, por todo o seu comprometimento e profissionalismo. Por fim, agradeço a todo o núcleo
de telecomunicações do IFSC pela formação por mim recebida.
Resumo
O mercado corporativo está cada vez mais voltado ao uso de tecnologias VoIP como solução
de telefonia. O VoiP (Voice over Internet Protocol) surgiu na década de 90 e tem sido ampla-
mente difundido nos meios corporativos. Diversas empresas do mundo vem realizando grandes
investimentos em desenvolvimento e implantação de sistemas VOIP, tendo como foco a redução
de custos com a telefonia.
O aumento na oferta do acesso a internet com maior capacidade e confiabilidade, aliado a
popularização do SIP trunking (sistema que permite que linhas PBX usem VoIP fora da rede da
empresa com a mesma conexão da Internet) estão impulsionando o crescimento no número de
empresas que adotam o VOIP. Embora os sistemas VoIP tenham evoluindo muito nos últimos
anos, a qualidade do serviço ainda exige cuidados durante o planejamento e implantação. Pro-
blemas como atraso, variação de atraso e perdas de pacotes, podem influenciar negativamente
na qualidade de um sistema VoIP, que deve na sua essência, ter a mesma qualidade que um
sistema analógico ou digital.
O objetivo desse trabalho é implantar e avaliar uma ferramenta de monitoramento de uma
rede VoIP corporativa. Ao contrário de uma análise de uma rede com foco em dados, serão
elaborados testes voltados exclusivamente para a qualidade de serviço VoIP. A ferramenta esco-
lhida foi o VoIPmonitor, que disponibiliza além dos testes básicos de desempenho de rede, uma
série de informações voltadas ao controle e monitoração de ligações. O estudo de caso realizado
foi sobre um Call Center corporativo já implantado, que possui um cenário amplo com diversas
variantes.
Abstract
The corporate market is increasingly focusing on the use of technologies such as VoIP te-
lephony solution. The (VoiP Voice over Internet Protocol) has emerged in the 90s and has
been widely spreaded on corporate media. Companies around the world has made great invest-
ments in development and deployment of VOIP systems, with a focus on cost reduction of the
telephony services.
The increase of the provision of internet access with greater capacity and reliability, cou-
pled with the popularity of SIP trunking system (which allows use VoIP PBX lines outside
the corporate network with the same internet connection) are driving the growth in number of
companies adopting VoIP. Although VoIP systems have evolved considerably in recent years,
the quality of service still requires care during planning and implementation. Problems such as
delay, delay variation and packet losses can negatively influence the quality of a VoIP system,
which should in essence be the same quality as an analog or digital system.
The aim of this study is to implement and evaluate a tool for monitoring an enterprise VoIP
network. Unlike an analysis of a network with a focus on data, oriented tests will be developed
exclusively for the quality of VoIP service The chosen tool was the VoIPmonitor, which features
beyond basic testing network performance , a variety of information aimed at controlling and
monitoring connections . The case study was about a corporate Call Center already deployed,
which has a large scene with several variants
Sumário
Lista de Figuras
Lista de Tabelas
1 Introdução p. 10
1.1 Motivação do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 10
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11
1.3 Organização do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11
2 Fundamentação Teórica p. 12
2.1 Conceitos básicos em VOIP e Call Centers . . . . . . . . . . . . . . . . . . p. 12
2.1.1 Conceitos em VOIP . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12
2.1.2 Conceitos em Call Centers . . . . . . . . . . . . . . . . . . . . . . . p. 15
2.2 Métricas de Qualidade de Serviço em VOIP . . . . . . . . . . . . . . . . . . p. 17
2.2.1 Métricas associadas à qualidade da voz . . . . . . . . . . . . . . . . p. 17
2.2.2 Métricas/Parâmetros associados ao Gerenciamento de Sessão . . . . p. 21
2.3 Técnicas de Monitoramento de Voz . . . . . . . . . . . . . . . . . . . . . . p. 22
2.3.1 Monitoração Ativa . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22
2.3.2 Monitoração Passiva . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
2.4 VoiPMonitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
2.5 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28
3 Planejamento e Implantação do Sistema de Monitoramento p. 29

3.1 Estrutura de Rede e do Call Center . . . . . . . . . . . . . . . . . . . . . . . p. 29
3.1.1 O Sistema de Call Center e o Atendente . . . . . . . . . . . . . . . . p. 32
3.2 Análise do Fluxo de Ligações no Sistema . . . . . . . . . . . . . . . . . . . p. 32
3.3 Determinação do Posicionamento e Quantidade de Sondas Passivas . . . . . p. 38
3.3.1 O Funcionamento do VoiPMonitor e o Relacionamento com a Po-

sicão das Sondas . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38
3.3.2 Determinação da Quantidade de Sondas . . . . . . . . . . . . . . . . p. 40
3.4 Implantação do Sistemas de Monitoramento . . . . . . . . . . . . . . . . . . p. 42
3.4.1 Implantação das Sondas . . . . . . . . . . . . . . . . . . . . . . . . p. 42
3.4.2 Implantação da Base de Dados . . . . . . . . . . . . . . . . . . . . . p. 44
3.4.3 Implantação da WebGUI . . . . . . . . . . . . . . . . . . . . . . . . p. 45
3.5 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
4 Operação do Sistema e Avaliação do Funcionamento p. 47
4.1 Análise de Dados e Geração de Relatórios . . . . . . . . . . . . . . . . . . . p. 47
4.2 Detecção de Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53
4.3 Análise da Predição de MOS com o VoIPmonitor . . . . . . . . . . . . . . . p. 55
4.4 Uso de Geradores de Alertas . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58
4.5 Avaliação da Ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59
4.6 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 60
5 Conclusões Finais e Perspectivas de Trabalhos Futuros p. 61
Anexo I - Procedimentos de Instalação p. 63
Referências Bibliográficas p. 67
Lista de Figuras
2.1 Pilha de Transporte Pacotes usados pelo VoiP (JESZENSKY, 2004) . . . . . p. 13
2.2 Estruturas Call Center (fonte:Autoria Própria) . . . . . . . . . . . . . . . . . p. 15
2.3 Classificação Métodos de Medição (SILVA, 2006) . . . . . . . . . . . . . . . p. 17
2.4 Métodos baseados em: (a)Parâmetros, (b) Sinais, (c) Comparação (SILVA,
2006). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18
2.5 Gráfico atraso x modelo E. (ITU-T G.114) . . . . . . . . . . . . . . . . . . . p. 21
2.6 Monitoração Ativa (AGRAWAL et al., 2006) . . . . . . . . . . . . . . . . . p. 23
2.7 Monitoração Passiva (AGRAWAL et al., 2006) . . . . . . . . . . . . . . . . p. 24
2.8 Captura Sondas Passivas (FERREIRA, 2006) . . . . . . . . . . . . . . . . . p. 25
2.9 Arquitetura VoIP Monitor (MONITOR, 2013) . . . . . . . . . . . . . . . . . p. 26
2.10 Coleta de dados: módulo Sniffer (MONITOR, 2013) . . . . . . . . . . . . . p. 26
3.1 Estrutura a ser monitorada (fonte:Autoria Própria) . . . . . . . . . . . . . . . p. 30
3.2 Etapas e sessões VoIP (fonte:Autoria Própria) . . . . . . . . . . . . . . . . . p. 34
3.3 Fluxo de Ligações (fonte:Autoria Própria) . . . . . . . . . . . . . . . . . . . p. 37
3.4 Análise Básica (fonte: Autoria Própria) . . . . . . . . . . . . . . . . . . . . p. 39
3.5 Posicionamento Sondas (fonte:Autoria Própria) . . . . . . . . . . . . . . . . p. 41
3.6 Tela de Cadastro das Sondas . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
3.7 Sondas Cadastradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
4.1 Sessões SIP - Função CDR . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48
4.2 Detalhe Sessão SIP - Função Detalhes CDR . . . . . . . . . . . . . . . . . . p. 48
4.3 Detalhe Sessão SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49
4.4 Cabeçalho SIP - Legs by CID . . . . . . . . . . . . . . . . . . . . . . . . . . p. 50

4.5 Relatório por perı́odo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51
4.6 Relatório por perı́odo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52
4.7 Sniffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53
4.8 Chamadas Ativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53
4.9 Ligação com Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56
4.10 Ferramenta para Cálculo de MOS ITU-T G107 . . . . . . . . . . . . . . . . p. 57
4.11 Interface de Configuração de Alertas . . . . . . . . . . . . . . . . . . . . . . p. 58

Lista de Tabelas
2.1 Escala Opinião de Teste Subjetivo (HARDY, 2003) . . . . . . . . . . . . . . p. 18
2.2 Critérios para avaliação (HARDY, 2003) . . . . . . . . . . . . . . . . . . . . p. 19
2.3 Classificação de ligações conforme modelo E (SILVA, 2006) . . . . . . . . . p. 20

10
1 Introdução
Este documento visa apresentar o projeto de conclusão do Curso Superior de Tecnologia

em Sistemas de Telecomunicações do IFSC - Câmpus São José. Trata-se do planejamento e
implantação sistemática de um monitoramento do sistema VoIP (Voice over Internet Protocol)
de um Call Center, apoiada em uma ferramenta profissional. Ao final pretende-se avaliar a
ferramenta e apontar relatórios práticos que possam vir a ser utilizadas de forma rotineira no
sistema em estudo. Na sequência são apresentadas as motivações para o trabalho e a organização
do texto do documento.
1.1 Motivação do Trabalho
O Mercado corporativo está cada vez mais voltado ao uso de tecnologias VoIP como solução
de telefonia. O VoIP surgiu na década de 90 e tem sido amplamente difundido. Diversas
empresas do mundo vêm investindo pesado em desenvolvimento e implantação de sistemas
VoIP, tendo como foco a redução de custos com a telefonia. O aumento na oferta do acesso à
Internet com maior capacidade e confiabilidade ajuda a impulsionar o crescimento no número
de empresas que adotam o VoIP.
É importante que os alunos e profissionais oriundos do curso de Tecnologia de Sistemas

de Telecomunicações que atuam na área, estejam alinhados com a evolução do mercado e suas
melhores práticas.
O proponente deste trabalho atua em um cargo intimamente ligado a um sistema VoIP,

sendo responsável pela infraestrutura de TI de um Call Center, onde todo o tráfego de ligações
é baseado em VoIP. O Call Center em questão é um sistema extremamente robusto, contando
inclusive com a distribuição fı́sica pelo Brasil.
Devido ao tamanho do sistema e o valor agregado que o Call Center representa ao negócio
da empresa, torna-se necessário aplicar, de forma sistemática, técnicas de monitoração da quali-
dade das ligações e de outros parâmetros, a fim de manter e garantir a “saúde” da operação, bem
1.2 Objetivos 11
como diagnosticar e propor soluções para problemas, além de propor melhorias na operação do
sistema.
Devido aos fatores citados e a falta de um sistema que os atenda, o proponente decidiu
estruturar o seu trabalho de conclusão de curso em torno de uma proposta que consiga atender
ás demandas acima.
1.2 Objetivos
O objetivo geral do trabalho é realizar de forma planejada e sistemática, o monitoramento

do sistema VoIP de um Call Center corporativo. A partir deste monitoramento pretende-se
identificar problemas e apontar soluções estruturais e de procedimento.
São considerados objetivos especı́ficos:
• Analisar os fluxos de ligações do Call Center;
• Planejar de implantação das sondas do sistema, considerando os aspectos topológicos do

sistema monitorado;
• A implantação de todo o sistema de monitoramento;
• A análise do dados com foco no monitoramento da voz;
• A geração de relatório de diagnóstico de problemas e soluções possı́veis.
1.3 Organização do texto
Este documento está estruturado da seguinte maneira: no capı́tulo 1(um) temos a motivação
do trabalho, bem como informações gerais sobre o texto. No capı́tulo 2 (dois) é apresentada a
fundamentação teórica necessária, que servirá como base para a estruturação das atividades. O
capı́tulo 3 (três), é dedicado ao planejamento e implantação do sistema de monitoramento, onde
também são apresentados os estudos elaborados para implantação do sistema. Já o capı́tulo 4
(quatro) apresenta uma análise dos dados coletados durante a monitoração do Call Center, além
de uma avaliação geral da ferramenta de monitoração adotada.
12
2 Fundamentação Teórica
Na sequência serão apresentados conceitos e tecnologias relacionadas com o trabalho de-

senvolvido. Inicialmente são apresentados conceitos básicos em VoIP e Call Centers. As
métricas para avaliação de sistemas VoIP são então exploradas. Fatores da rede que impactam
na qualidade do sistema são revistos. Na sequência são descritas técnicas de monitoramento
passivo e ativo e a ferramenta VoIP monitor, que foi usada no trabalho, é apresentada.
2.1 Conceitos básicos em VOIP e Call Centers
2.1.1 Conceitos em VOIP
Um sistema VoIP permite a realização de sinalização, controle e implementação de sessões

de voz, tal como na telefonia convencional, utilizando como infraestrutura uma rede IP. Um
diferencial em relação a telefonia convencional é que a mesma se utiliza de uma rede baseada
em comutação de circuitos onde existem circuitos dedicados para a comunicação enquanto as
redes IP são baseadas em comutação de pacotes.
Os problemas de retardo, jitter, perdas de pacotes e disponibilidade de banda impactam

diretamente a qualidade do sistema e, neste sentido, os protocolos usados no VoIP, associados a
técnicas de QoS em redes IP, devem ser usados de forma consistente.
Arquitetura VOIP
Um sistema VoIP não é um sistema de estrutura simples e com poucas variáveis, mas sim
um conjunto de protocolos, softwares e hardwares, que juntos desempenham um papel cada
vez mais importante nas telecomunicações. Historicamente o VoIP teve diversos formatos e
protocolos, tudo sempre impulsionado pela intenção de igualar a qualidade de uma ligação
VoIP à uma ligação via telefonia fixa.
Na Figura 2.1 é apresentada uma arquitetura de um sistema VoIP em função das tecnologias
2.1 Conceitos básicos em VOIP e Call Centers 13
hoje disponı́veis (JESZENSKY, 2004).
Figura 2.1: Pilha de Transporte Pacotes usados pelo VoiP (JESZENSKY, 2004)
Durante a evolução dos sistemas VoIP, novas técnicas, protocolos e serviços foram sur-
gindo, enquanto outros se tornaram obsoletos. Na sequência são resumidos alguns protocolos
importantes para o entendimento de uma estrutura VoIP
O Protocolo H.323
A Recomendação H.323 da ITU-T é uma das primeiras recomendações a especificar a

implementação de conferências multimı́dias, em redes de dados. Ela especifica uma série de
protocolos, métodos e elementos de rede necessários para estabelecer uma conexão multimı́dia
entre dois usuários (JESZENSKY, 2004). O H.323 usa tanto TCP (Transport Control Protocol)
quanto UDP (User Datagram Protocol) como transporte. Os sinais de controle e dados usam
TCP porque devem ser recebidos na ordem que eles foram enviados e não podem ser perdidos.
Já o fluxo de áudio e vı́deo usa o UDP. Por padrão, os terminais H.323 devem suportar o codec
G.711 para codificação de áudio e o codec H.261 para vı́deo, sendo o suporte aos outros padrões
opcional. O H323 é um protocolo relativamente antigo, que está atualmente sendo substituı́do
pelo SIP (Session Initiation Protocol).
O Protocolo de Sinalização SIP
O SIP é um protocolo de sinalização que permite estabelecer, terminar e modificar sessões

de comunicação. O SIP foi definido na RFC 2543 (ROSENBERG et al., 2002) em março
de 1999 e revisado em junho de 2002 pela IETF (textitInternet Engineering Task Force). É
um protocolo de sinalização baseado em dois outros protocolos largamente utilizados na inter-
net: HTTP (HipertText Transport Protocol),utilizado na navegação web e SMTP (Simple Mail
Transport Protocol) usado no envio de e-mails.
O SIP é um protocolo textual e tem caracterı́stica cliente-servidor, onde os clientes efetuam

requisições e os servidores que retornam uma resposta. Em geral esta arquitetura faz uso do
protocolo RTP (Real Time Protocol) para o transporte de dados em tempo real (FERREIRA,
2006). Como o próprio nome já ressalta, o SIP é um protocolo de gerenciamento do estabe-
lecimento, manutenção e término de sessão e baseia-se fundamentalmente em transações, que
podem ser entendidas como uma requisição/resposta.
A partir da troca de mensagens, ou seja, o processo de sinalização, as partes podem es-

tabelecer uma sessão multimı́dia. Estas mensagens são baseadas em texto, o que facilita sua
implementação. Através do SIP podemos criar sessões multimı́dias ponto a ponto ou con-
ferência, podendo ser aplicado em uma única rede ou entre diversos segmentos de rede. A ar-
quitetura do SIP consegue tratar redirecionamentos, encaminhamentos, endereços de domı́nio,
temas essenciais quando tratamos de aplicações em rede corporativa.
O SIP possibilita a mobilidade ao usuário, através de um login e senha ele consegue se

conectar a um servidor de qualquer rede ou subrede.
Os protocolos RTP e RTCP
A comunicação propriamente dita, associada a uma sessão estabelecida pelo SIP, é reali-
zada pelo protocolo RTP (textitReal-time Transfert Protocolo) tendo o RTCP (textitReal-time
Transfert Control Protocol) como protocolo de auxı́lio ao funcionamento da comunicação.
O RTP e o RTCP são protocolos que atuam na camada de transporte, onde são amplamente
utilizados em sistemas VoiP. O RTP (Protocolo de Tempo Real) foi inicialmente definido na
RFC 1889 (GROUP et al., 1996), e determina um formato de pacote padrão para o envio de
áudio e vı́deo pela Internet. O RTP roda sobre o UDP. Já o RTCP é definido pela RFC 3550
(SCHULZRINNE et al., 2003), onde é descrito para funcionar em conjunto com o RTP (KU-
ROSE J.; ROSS, 2006).
Na prática o RTP fica responsável pela entrega da mı́dia, enquanto o RTCP envia pacotes
de controle aos participantes da conexão. A função principal do RTCP é fornecer informações
sobre a qualidade dos serviços oferecidos pelo RTP.
Os Codecs
São dispositivos de hardware ou software, que codificam/decodificam sinais. Na telefo-

nia IP os codecs são usados para converter um sinal de voz analógico para digital. Os codecs
influenciam na qualidade do som, na largura de banda necessária e no processamento dos equi-
pamentos envolvidos. Cada dispositivo VoIP normalmente suporta vários codecs diferentes,
que quando conversam com outro, negociam previamente o codec que irão usar. Os exemplos
mais utilizados hoje são: G.723, G.711A, G.711u, G.729a (KUROSE J.; ROSS, 2006). Vale
lembrar que alguns codecs requerem pagamento de royalties para a sua utilização num produto
ou programa.
2.1.2 Conceitos em Call Centers
Um Call Center baseia-se em uma estrutura fı́sica integrada a recursos humanos, que viabi-
lizam um canal de comunicação entre uma empresa e seus clientes/possı́veis clientes. Existem
diversos formatos de operações em um Call Center, sendo que um dos principais é o relaciona-
mento através de ligações telefônicas.
Atualmente os Call Centers se utilizam amplamente de sistemas VoiP para gerenciar suas
ligações. Um Call Center é geralmente formado pelos componentes mostrados na Figura 2.2 e
descritos a seguir.
Figura 2.2: Estruturas Call Center (fonte:Autoria Própria)
• Usuários – clientes ou possı́veis clientes de uma empresa, com necessidade de um contato

telefônico;
• PA (ponto de atendimento)- local na estrutura fı́sica, provido de um ponto telefônico,

onde os agentes atendem os usuários;
• Atendente – pessoas responsáveis por prestar o atendimento para os usuários;
• URA (unidade de resposta audı́vel) – elemento de Call Center geralmente usado em

operações receptivas, responsável por pré-atender as ligações e oferecer aos usuários
opções para seleção. As opções geralmente estão atreladas a grupos de agentes, res-
ponsáveis por determinado tipo de serviço ou informação. Para selecionar a opção dese-
jada o usuário digita uma tecla de seu telefone, que por sua vez envia um sinal multifre-
quencial para a URA. Através da opção digitada o cliente é encaminhado ao DAC;
• DAC (distribuidor automático de chamadas) – formado por um conjunto de agentes ou

PA‘s, o DAC é responsável por distribuir as ligações. O DAC geralmente é atrelado a um
sistema de gerenciamento, que permite o monitoramento a gravação e o agendamento de
ligações, entre outras tarefas.
No exemplo citado, todo o trafego de ligações entre a URA, DAC e Agentes são via VoiP.
Essas podem ser gerenciadas por um ou mais sistemas, uma vez que podemos ter todos os
elementos do Call Center integrado em um único equipamento, ou cada um deles sendo um
equipamento diferente.
Nas atividades de um Call Center, faz-se o uso de alguns termos que servem como indica-
dores ou pontos de controle, abaixo alguns deles:
• Chamadas Recebidas- quantidade de ligações telefônicas recebidas;
• Chamadas Originadas- quantidade de ligações telefônicas realizadas;
• Hora de maior movimento- Horário do dia ou conjunto de dias em que se tem o maior
fluxo de ligações, comum ser mais controlado em Call Centers receptivos;
• Taxa de Abandono- nas operações receptivas, representa o percentual de chamadas que

foram abandonadas pelos usuários antes do seu atendimento sobre o total de chamadas
recebidas pelo Call Center;
• Talk Time: é o tempo de conversação do agente com o usuário em uma chamada;
• Wait Time: nas operações receptivas, é o tempo que os clientes esperam para ter sua
chamada atendida, ou seja, é o Tempo de Fila;
• Warp Time: tempo entre o fim de uma ligação e a liberação do agente para receber/fazer
outra. Geralmente é o tempo em que o agente cadastra as informações da ligação em um
software de CRM (textiCustomer Relationship Management);
2.2 Métricas de Qualidade de Serviço em VOIP 17
• Tempo médio de operação (TMO): é o tempo médio em que um agente fica em talk
mais o tempo em Warp.
2.2 Métricas de Qualidade de Serviço em VOIP
Um dos primeiros aspectos no monitoramento/análise de um sistema VoIP é definir se uma

ligação está com a qualidade boa ou não. Para apoiar nesse processo, pode-se contar com
alguns métodos de avaliação. Nesta seção serão discutidas métricas para a qualidade da voz em
especı́fico e métricas associadas ao estabelecimento/gerenciamento de sessão.
2.2.1 Métricas associadas à qualidade da voz
A grosso modo, os métodos de avaliação estão separados em dois grupos: métodos subje-
tivos, baseados na avaliação de pessoas através da audição, e os métodos objetivos, baseados
em modelos matemáticos (SILVA, 2006). Os métodos objetivos podem ser intrusivos ou não
intrusivos . Os métodos objetivos intrusivos são aqueles que podem ser baseados em parâmetros
ou em sinais, já os objetivos não intrusivos são aqueles baseados na comparação. A Figura 2.3
apresenta um mapa da classificação dos métodos.
Figura 2.3: Classificação Métodos de Medição (SILVA, 2006)
Conforme comentado temos métodos baseados em parâmetros, sinais e comparação. Abaixo

a Figura 2.4 que segundo (SILVA, 2006) mostra a forma de coleta das informações para cada
método.
Figura 2.4: Métodos baseados em: (a)Parâmetros, (b) Sinais, (c) Comparação (SILVA, 2006).
Abaixo descreveremos dois modelos de avaliação de uma ligação, o MOS (Mean Opinion
Scores) e outro chamado de Modelo E.
Mean Opinion Scores (MOS)
É uma das medidas subjetivas mais utilizadas hoje. Segue recomendações da ITU-T P.800,
ITU-TP830 1996 e também se baseia no ACR (Absolut Category Rating) (HARDY, 2003).
O método MOS baseia-se na opinião de pessoas treinadas, que escutam o áudio, da ligação,
avaliam qualidade e atribuem uma nota de 1 à 5, o MOS é a média dessas avaliações. O peso
das notas está na tabela 2.1:
Tabela 2.1: Escala Opinião de Teste Subjetivo (HARDY, 2003)
Segundo (HARDY, 2003) as notas obedecem aos critérios apresentados na tabela 2.2:
Tabela 2.2: Critérios para avaliação (HARDY, 2003)
Sendo o MOS um método subjetivo, tendo como parâmetro a opinião de avaliadores, alguns
cuidados devem ser tomados para uma melhor assertividade nos testes. O ideal é que seja usado
vários avaliadores, assim o resultado não fica tendenciado de acordo com o critério de um ava-
liador mais crı́tico ou não. Os testes subjetivos como o MOS possuem algumas desvantagens,
elas impulsionaram a procura por outras formas de avaliação mais precisas (SILVA, 2006).
Modelo E
O Modelo E é um método de avaliação de qualidade de voz objetivo não intrusivo (SILVA,

2006), tendo suas recomendações oficializadas através da ITU-T G.107 (BERGSTRA; MID-
DELBURG, 2003). É um método que avalia separadamente alguns pontos, tendo como re-
sultante um fator escalar denominado de Fator R. O Fator R é calculado como base seguinte
fórmula (HARDY, 2003):
R = Ro–Is–Id–Ie–A
Onde segundo (SILVA, 2006):
• Ro é a relação sinal ruı́do. O padrão é 94,77;
• Is é o fator de degradação devido a quantização da voz. Valor padrão é 1,41;
• Id é a degradação causada pelo atraso, podendo assumir valores tı́picos de 0 a 60;
• Ie é a distorção no sinal devido aos codecs, perda de pacotes, e buffers de reprodução e

compensação de jitter;
• A corresponde a quanta degradação o usuário está disposto a aceitar frente as vantagens

do uso de determinada solução. Este fator varia de 0 a 20.
O Fator R pode variar numa faixa de 0 a 100 sendo que, conforme modelo MOS, cada faixa
de valor equivale a uma classificação conforme mostrado na tabela 2.3.
Tabela 2.3: Classificação de ligações conforme modelo E (SILVA, 2006)
De acordo com Ferreira (FERREIRA, 2006), o MOS pode ser relacionado com o Fator R
através da seguinte fórmula:
-
MOS = 1 + 0.035R + 7 × 10 6 × R(R − 60)(100 − R)
Fatores que impactam a sinalização e a Voz
Em um sistema baseado em IP, a voz é extremamente sensı́vel a uma série de fatores. Uma
série de requisitos devem ser obedecidos para termos uma ligação com qualidade. Conforme
o tema desse trabalho e como requisito para que seja realizado o monitoramento de um sis-
tema VoIP, é importante salientar alguns fatores e problemas já conhecidos, que influenciam na
qualidade do sinal de voz. Alguns destes fatores são (FERREIRA, 2006) :
• Perda de Pacotes - como os pacotes na rede carregam os dados referentes à voz, é natural
que a perda deles cause degradação da voz. Com relação à perda elas podem acontecer
de maneira isolada, que é quando uma quantidade pequena de pacotes é perdida sendo
possı́vel, através de algoritmos de ocultação de perda, a reconstituição do sinal de maneira
satisfatória. A dificuldade aparece quando temos a perda frequente de pacotes, dessa
forma a degradação do sinal aumenta, muitas vezes impossibilitando a reconstituição do
sinal de voz (AGRAWAL et al., 2006).
• Atraso ou Delay - é o tempo em que um pacote percorre a rede, de um ponto origem

até o seu destino. O atraso dos pacotes podem não afetar a qualidade da voz, mas geram
desconforto pela falta de sincronismo de uma ligação. Na ITU-T G.114 temos algumas
recomendações sobre o atraso, onde atrasos de 0 a 150 ms são considerados aceitáveis,
de 200 a 400 ms merecem atenção e acima de 400 ms são considerados inaceitáveis por
degradar demais o sinal de voz. Na ITU-T G.114 temos o gráfico mostrado na Figura 2.5,
que relaciona o atraso ao modelo E já descrito no trabalho.
Figura 2.5: Gráfico atraso x modelo E. (ITU-T G.114)
• Jitter ou Variação de atraso – o jitter trata-se de uma variação no tempo de atraso dos
pacotes. O jitter possui diversas causas, porém um dos pontos mais relevante é a questão
da bufferização e o enfileiramento de pacotes nos equipamentos que constituem a rede de
dados. O textitjitter geralmente é tratado no receptor através de buffer, onde os dados são
armazenados por um tempo, para depois serem reproduzidos. Se o pacote chegar após o
tempo de espera, ele é descartado.
• Eco – é a nomenclatura usada para quando um usuário escuta sua própria voz após falar. O
eco pode ser acústico ou elétrico. Eco acústico é aquele que ocorre apenas em ambientes
analógicos, onde o sinal da recepção afeta o áudio do microfone, nestes casos não há
tratamento. Já o eco elétrico é causado principalmente por circuitos de hı́bridas, os quais
fazem a integração da transmissão e recepção no mesmo meio fı́sico, além disso, a falta
de casamento de impedâncias dos circuitos dos equipamentos também podem causar o
eco. Existem algumas técnicas para tratar o eco acústico, das quais citamos o uso de
supressores e canceladores de eco. Os supressores de eco são dispositivos que atenuam o
retorno de um sinal transmitido, já os canceladores de eco geralmente encontram-se em
circuitos digitais e subtraem o sinal recebido do transmitido.
2.2.2 Métricas/Parâmetros associados ao Gerenciamento de Sessão
No que diz respeito ao sistema VoIP, é importante também medir outras variáveis associadas
ao estabelecimento/gerenciamento e término de sessão. Pode-se citar:
2.3 Técnicas de Monitoramento de Voz 22
• Call setup time - tempo entre o envio de um INVITE e o recebimento de um 200 OK.
• Call tear-down time - tempo entre um envio de um BYE e o recebimento de um 200 OK,
confirmando a desconexão.
Outros parâmetros podem ser de interesse de uma análise com fins de diagnóstico: o tempo
de sinalização para atualização de CODECs, o número aceitável de chamadas em andamento e
espera, entre outros tempos de interesse. A identificação de problemas de segurança e intrusão
podem também ser apoiadas na mediação de números seguidos de INVITEs ou BYEs dentro
de um intervalo de tempo definido.
2.3 Técnicas de Monitoramento de Voz
A monitoração de uma rede é algo complexo que requer alguns cuidados. É grande o nu-
mero de variáveis que devem ser levadas em conta. Somente através de um plano de monitoração,
montado de a partir de uma necessidade, conseguimos obter efetividade e assertividade.
O planejamento do monitoramento de um sistema VoIP, deve incluir a definição de estrutu-

ras dos pontos e parâmetros de sensoriamento.
Os problemas já mencionados, como atraso, jitter e perda de pacote merecem atenção espe-
cial e devem ser monitorados de forma consistente. Dois tipos de monitoramento podem existir:
monitoração ativa e a monitoração passiva.
2.3.1 Monitoração Ativa
A monitoração ativa é considerada um método intrusivo, onde sondas ativas são espalha-
das pela rede. O objetivo é que as sondas originem e recebam ligações entre si, a fim de medir
e emitir relatórios sobre a qualidade da rede (SILVA, 2006). As sondas nada mais são do que
softwares que geram um tráfego, configurado a partir de parâmetros pré-determinados.
No sistema de monitoração ativo, pode existir a Figura de um NOC( Network Operations

Center). É do NOC a reponsabilidade de gerenciar a inicialização da troca de informações
entre as sondas, bem como captar e concentrar os relatórios por elas emitidos (AGRAWAL et
al., 2006). Abaixo temos a Figura 2.6, com uma ilustração de uma monitoração usando sondas
ativas:
Figura 2.6: Monitoração Ativa (AGRAWAL et al., 2006)
É importante comentar que a utilização de uma monitoração ativa, gera um trafego extra de
dados na rede e que sua implantação requer cuidados nesse sentido.
Na prática, para iniciar um teste, o NOC localiza duas sondas ativas e repassa um arquivo
com informações como: número de chamadas a serem realizadas, duração das chamadas, tempo
entre as chamadas e o codec a ser utilizado. Uma vez recebidos os dados, as sondas iniciam o
processo utilizando o SIP e o RTP para efetuar as ligações. Assim que finalizam os testes as
sondas encaminham os relatórios para o NOC.
Para uma melhor assertividade, as sondas devem estar configuradas com o mesmo servidor
NTP (Network Time Protocol), assim é inserido o horário no campo timestamp do payload do
RTP, que é usado para posterior análise.
2.3.2 Monitoração Passiva
A monitoração passiva baseia-se na instalação de sondas de monitoração na rede VoIP, de

forma que essas coletem informações do fluxo de voz e gerem alguns relatórios. Neste método
de monitoração, as sondas não geram tráfego de dados, seu papel é capturar os pacotes que
estão passando na rede, analisá-los e reportar as informações ao NOC. A Figura 2.7 ilustra um
exemplo de estrutura usando monitoração passiva:
Figura 2.7: Monitoração Passiva (AGRAWAL et al., 2006)
As sondas são estrategicamente posicionadas nos pontos em que o tráfego de ligações é

maior. Uma boa opção é colocar a sonda para monitorar o trafego que entra e sai do PABX IP
do sistema VoIP.
Uma sonda passiva deve conseguir identificar, abrir e registrar dados dos cabeçalhos dos
protocolos VoIP(AGRAWAL et al., 2006). Após isso, ela deve repassar ao NOC o conjunto
de informações. Cabe ao NOC correlacionar as informações recebidas das sondas, identificar
fluxos de uma mesma sessão VoIP e em seguida calcular as métricas da qualidade da ligação.
Sondas passivas agrupam os dados capturados em dois grupos, conforme ilustração na Fi-
gura 2.8: dados referentes aos registros SIP e dados referentes aos registros RTP (AGRAWAL
et al., 2006).
• Registros SIP: monitoração das sessões baseadas nos campos to, from e call id, contidas
nos pacotes SIP, onde quando iniciada uma conexão ela passa a ser monitorada até a
finalização, incluindo suas mensagens (200 OK, BYE, etc);
• Registro RTP: monitoração das sessões baseadas nos campos src ip, porta src, dst ip,
porta dst, timestamp e SSRC.
2.4 VoiPMonitor 25
Figura 2.8: Captura Sondas Passivas (FERREIRA, 2006)
Muitas das informações adquiridas em uma monitoração passiva, podem estar ligadas ao
campo timestamp do protocolo RTP. Para que o NOC consiga calcular questões como jitter,
atraso, etc., de maneira precisa, é necessário que as sondas estejam com os horários precisa-
mente sincronizados. Uma das opções mais fáceis é fazer com que todas as sondas utilizem o
mesmo servidor NTP.
É importante comentar, que para a monitoração passiva acontecer é necessário que os dados
não estejam criptografados, caso isso ocorra podemos não conseguir fazer com que as sondas
passivas abram os pacotes para a análise (SILVA, 2006).
2.4 VoiPMonitor
O VoIPMonitor (MONITOR, 2013) é uma ferramenta de monitoração de rede, que utiliza o

método de monitoração passiva. A ferramenta é constituı́da de dois módulos. O módulo Sniffer
captura os pacotes de rede, sendo um módulo open source (código aberto). O outro módulo é
um aplicativo Web (WebGUI) que faz o gerenciamento do primeiro módulo, sendo esse último
licenciado.
O VoIPMonitor foi desenvolvido com foco em monitoração de redes VoIP, sendo assim, está
preparado para analisar os protocolos SIP, RTP, RTCP, entre outros. Através do VoiPMonitor é
possı́vel avaliar as principais métricas de qualidade de voz (Jitter, MOS, etc), cujas medidas são
realizadas com base na a ITUT-G.107 e outras. A arquitetura do VoIPMonitor está estruturada
conforme ustra a Figura 2.9:
2.4 VoiPMonitor 26
Figura 2.9: Arquitetura VoIP Monitor (MONITOR, 2013)
Conforme apresentado na Figura 2.9, o módulo Sniffer faz a captura dos pacotes e enca-
minha as informações via TCP para uma base de dados MySQL. Devido a essa arquitetura o
VoIPMonitor possibilita que sejam instalados diversos módulos Sniffer, sendo que todos podem
gravar suas informações em um mesmo banco de dados.
Existem algumas formas para colocar o VoiPMonitor na rede, porém talvez a mais fácil seja
espelhar a porta de um switch ou roteador, para a porta em que o servidor com o VoIPMonitor
estiver conectado. Uma vez que o servidor que possui o Sniffer instalado, comece a receber
todo o tráfego de dados em sua placa de rede, ele inicia a coleta das informações. A Figura 2.10
mostra o ponto em que os dados são coletados.
Figura 2.10: Coleta de dados: módulo Sniffer (MONITOR, 2013)

2.4 VoiPMonitor 27
Conforme Figura a 2.10, o Sniffer lê os dados no Ring Buffer do kernel e armazena as
informações temporariamente no seu próprio buffer, denominado VM Buffer. É do VM Buffer
que as informações são direcionadas para o banco MySQL. As informações lidas pelo Sniffer
são direcionadas para a tabela chamada CDR(Call Detail Rrecords) do MySQL. O WebGUI
utiliza a Tabela CDR, entre outras, para poder gerenciar as informações.
Através do módulo WebGUI, podemos monitorar as métricas de qualidade de voz, bem

como ter dados de todas as ligações. A ferramenta possibilita que sejam configurados alertas
enviados via e-mail, para quando alguma métrica esteja fora de uma valor pré-determinado.
Além disso, a ferramenta Web disponibiliza uma série de facilidades para monitoração de um
sistema VoIP.
Abaixo, listamos as facilidades do WebGUI descritos no site oficial da ferramenta, essas

informações serão importantes para quando formos definir a metodologia de monitoração:
• Filtros abrangentes permitindo pesquisar no banco de dados CDR por IP, tel. números,
parâmetros qualitativos (perda / delay / MOS), codecs, grupos;
• Identificação de ataques;
• Localiza sessões de chamadas por callerid ou qualquer cabeçalho SIP personalizado;
• Gráficos e tabelas;
• Baixar PCAP, WAV, T.38 FAX PDF;
• Detalhamento de pacotes SIP capturados, similar ao wireshark;
• Gerenciar os filtros do módulo Sniffer;
• Envio de relatórios por e-mail;
• Gerador de alerta com base em vários critérios;
• Recurso de agrupamento baseado em endereços IP, últimos códigos de resposta SIP, co-
decs;
• Grupos de e-mail, para gerenciar o envio de relatórios ou alertas;
• Resumo das chamadas ao vivo, com filtros;
• Painel de bordo para a rápida visão geral dos últimos dados;

2.5 Conclusão 28
• Gerenciamento de usuários, permitindo definir os usuários que podem ver apenas uma
parte das chamadas com base em números de telefone IP ou outros parâmetros;
• Ouvir ligações diretamente de GUI WEB.
2.5 Conclusão
Neste capı́tulo foram apresentados alguns conceitos básicos de Call Center e monitora-
mento VoIP. Foram apresentados alguns termos, parâmetros para medição da qualidade de voz e
algumas técnicas de monitoramento passivo e ativo de um sistema VoIP. Tais conceitos servirão
como apoio ao entendimento deste trabalho. A ferramenta VoIPMonitor também foi apresen-
tada uma vez que ela foi implantada no Call Center. No capı́tulo seguinte é descrito o processo
de implantação do sistema.
29
3 Planejamento e Implantação do
Sistema de Monitoramento
Este capı́tulo é dedicado ao planejamento e implantação do sistema de monitoração VoIP

de um Call Center. Inicialmente será feito um detalhamento da estrutura do Call Center e da
rede na qual ele está inserido, além disso também temos uma análise da sessões de comunicação
que são realizadas normalmente. A partir da análise de fluxos e da estrutura do sistema a ser
monitorado é então realizada a determinação da quantidade e a localização das sondas passivas
do sistema. Por último, são apresentados os procedimentos de implantação do sistema e a
conclusão do capı́tulo.
3.1 Estrutura de Rede e do Call Center
O sistema de Call Center usado como base para o estudo, possui uma estrutura de servi-
dores descentralizada, ou seja, não tem um único servidor com todos os serviços e sim vários
servidores, cada um com um papel diferente. A estrutura do Call Center e da rede na qual ele
está inserido é mostrada na Figura 3.1.
3.1 Estrutura de Rede e do Call Center 30
Figura 3.1: Estrutura a ser monitorada (fonte:Autoria Própria)
Todos os servidores do Call Center ficam concentrados em um mesmo local, na matriz da

empresa. Já a estrutura de PA’s é segmentada, ficando a maior parte dela na matriz e o restante
na filial da empresa em outro estado.
Para a interligação entre a matriz e a filial é usado um link MPLS (Multiprotocol Label
Switching). O funcionamento do link MPLS é monitorado pela informática da empresa e possui
um contrato de SLA (service level agreement) com a operadora. Dessa forma tem-se um link
de qualidade, onde em caso de problemas a correção é rápida.
O sistema de Call Center está totalmente inserido na rede de dados corporativo da empresa.
Na matriz, o tráfego de dados do sistema de Call Center é separado logicamente por duas vlans.
Uma das vlans é especı́fica para o trafego VoIP, nela estão conectados apenas os dispositivos
VoIP que se relacionam com o Call Center. Todo o trafego de dados referente aos demais
serviços da rede trafegam na outra vlan.
Na filial os pacotes de voz e dados trafegam em uma mesma rede. Os pacotes de voz são
priorizados, tanto na rede interna da empresa quanto no link MPLS, através de QoS.
As ligações dos clientes chegam ao sistema do Call Center basicamente de 2 formas:
• R2 Digital: são ligações que chegam através de links R2 digital, conectados aos PABX’s
(Centrais telefônicas) que integram o sistema. As chamadas de clientes que chegam via
3.1 Estrutura de Rede e do Call Center 31
R2 na filial, são convertidas em VoIP pelo PABX da filial e encaminhadas para a URA do
Call Center. Ao chegar na URA a ligação oriunda da filial recebe o mesmo tratamento
das demais ligações.
• VoIP: existem alguns parceiros da empresa (distribuidores, revendas, escritórios, etc.)

que possuem ramais VoIP conectados ao PABX da empresa. Esse ramais podem aces-
sar o Call Center através de um número especı́fico, nestes casos o PABX da empresa
encaminha a chamada para a URA via VoIP.
O sistema de telefonia VoIP da empresa é muito mais complexo do que o mostrado na

Figura 3.1, porém para a elaboração desse trabalho acadêmico, a empresa liberou apenas o
acesso a rede que envolve diretamente o Call Center. A proposta foi ativar a monitoração
no sistema do Call Center, caso o resultado fosse positivo seria estudado a possibilidade de
expandir o sistema para monitorar toda a empresa. Dessa forma, a seguir iremos detalhar um
pouco mais a fundo os elementos do Call Center.
O Call Center base do estudo é composto pelos seguintes elementos:
• Uma URA: faz o atendimento das chamadas e vocaliza os segmentos de atendimento para
que os clientes selecionem o desejado. Após o cliente digitar a opção desejada a URA
encaminha a chamada para os servidores de telefonia. A URA possui uma faixa de ramais
configurados, onde troncos dos servidores de telefonia se autenticam usando o SIP. Cada
opção disponibilizada para o cliente é atrelada a um ramal da URA, onde um tronco do
servidor de telefonia se autentica, que por sua vez é atrelado a um DAC, assim acontece
a amarração entre a URA e o servidor de telefonia.
• Dois Servidores de Telefonia: servidores com software proprietário de um terceiro. No

servidor temos um Asterisk com uma faixa de ramais configurados, onde os ATA‘s das
PA‘s se registram via SIP. Este é o elemento responsável por: monitorar o status dos
atendentes, distribuição das chamadas, fila de espera, relatórios gerenciais, etc. O Call
Center estudado possui 2 servidores de telefonia, ambos com exatamente as mesmas
funções. A necessidade de dois servidores é devido a uma limitação máxima de PA’s por
servidor (máximo 36 PA), uma limitação repassada pelo fornecedor.
• Um Banco de Dados: servidor com software proprietário de um terceiro, onde todas

as informações geradas/administradas pelos servidores de telefonia ficam armazenadas,
incluindo as gravações das ligações.
3.2 Análise do Fluxo de Ligações no Sistema 32
• Sessenta e Três PA’s: o Sistema possui 63 posições de atendimento, sendo 56 na matriz

e 7 na filial. Cada PA possui um ATA que é configurado para autenticar-se via SIP nos
servidores de telefonia. Além disso, nos computadores das PA’s temos um aplicativo
proprietário de um terceiro (mesma empresa responsável pelos servidores de telefonia e
banco de dados), responsável pela interação entre o atendente e o sistema de telefonia, é
nele que o atendente gerencia atividades como: login no sistema do Call Center, pausa
nas ligações, coloca o cliente na fila de espera, etc.
3.1.1 O Sistema de Call Center e o Atendente
Todo atendente tem um cadastro no servidor de banco de dados. No cadastro é especificado

o DAC ao qual ele está atrelado.
Toda a PA é composta por um computador, um ATA, um headset, mobı́lia e estrutura de

rede de dados. Conforme já mencionado, nos computadores das PA‘s temos um aplicativo que
gerencia a interação entre o atendente e o sistema do Call Center. Para vincular o ATA da PA ao
aplicativo de telefonia, existe um parâmetro dentro do aplicativo de telefonia onde se determina
o ramal configurado no ATA da PA correspondente.
Ao iniciar a jornada de trabalho o atendente acessa o aplicativo através de seu login e senha.
No momento do login, o aplicativo passa ao servidor de telefonia o ramal do ATA da PA em
que o atendente está. O servidor por sua vez encaminha uma chamada para o ramal, assim o
atendente atende a ligação no seu headset e o processo de login é concluı́do. Neste momento o
servidor de telefonia coloca a chamada entre ele e o atendente em uma sala de conferência. A
chamada fica estabelecida até o final da jornada de trabalho do atendente.
Quando o servidor de telefonia recebe uma chamada, ele verifica os atendentes livres do
respectivo DAC. Feito isso, ele inclui a ligação na sala de conferência do atendente. O atendente
assim inicia o atendimento.
O atendente não recebe o sinal de campainha no headset da PA referente a nova ligação. A

sinalização é feita pelo aplicativo em que ele está logado, através de um POP UP que “explode”
na tela do computador.
3.2 Análise do Fluxo de Ligações no Sistema
Iniciando a estruturação do sistema de monitoramento, o primeiro estudo elaborado foi

referente ao fluxo de ligações do Call Center.
É importante entender que toda a ligação que chega no sistema de Call Center tem o mesmo
comportamento. A ligação entra no sistema e recebe um pré-atendimento da URA, esta vocaliza
algumas opções e o cliente digita via teclado do telefone a opção desejada. De acordo com a
opção escolhida pelo cliente a URA encaminha a ligação para o servidor de telefonia, este
verifica os atendentes logados e encaminha a ligação para o atendente.
Com base nessas informações, na topologia a ser monitorada e no resultado da análise do

fluxo de ligações, chegamos a um diagrama que ilustra etapas das ligações e as sessões VoIP do
Call Center. Tal diagrama é ilustrado na Figura3.2
É importante salientar que neste trabalho uma conexão via SIP é considerado uma“Sessão
VoIP”,ou seja, toda conexão iniciada com INVITE e finalizada com BYE, além de todas as
demais mensagens que contribuem para o estabelecimento e controle da conexão.
Em seguida descreveremos cada etapa enumerada do diagrama. Por convenção estamos

iniciando com o Login do atendente.
1. Login Atendente: o atendente efetua o login no aplicativo de telefonia instalado no

computador da PA, através de seu usuário e senha. O aplicativo de telefonia envia uma
mensagem para o servidor de telefonia, indicando o usuário e o ramal do ATA. Estas
informações são configuradas no aplicativo de telefonia de acordo com ATA da PA, que
está solicitando o login.
2. Inı́cio de Ligação: ao identificar um pedido de login, o servidor de telefonia envia um

INVITE via SIP para o ramal VoIP indicado no processo de login. O atendente identifica
o sinal de campainha no headset ligado ao ATA e atende a ligação (envio 200 OK via
SIP). Neste momento o atendente já está em uma sessão VoIP com o Servidor.
3. Sala Conferência: no momento do Login, o sistema de telefonia abre uma sala de con-
ferência e aloca o atendente nela. A partir desse momento, toda vez que houver a neces-
sidade de encaminhar uma ligação para um atendente, o sistema irá na verdade alocar o
cliente na mesma sala de conferência que está o atendente. A estrutura baseada em sala
de conferência faz com que durante um dia de trabalho o atendente estabeleça apenas
uma sessão VoIP, mesmo atendendo diversas ligações de clientes.
4. Fluxo áudio entre atendente e servidor de telefonia: durante um dia de trabalho, o ser-
vidor de telefonia e o atendente trocam as mensagens de voz em uma única sessão VoIP,
através de RTP. Após o estabelecimento da sessão VoIP, quando um atendente não está
conectado a um cliente, o atendente escuta apenas ruı́do branco. Não há como distinguir
entre uma ligação e outra, já que a identidade da chamada se mantém a mesma do login.
3.2 Análise do Fluxo de Ligações no Sistema
34
Figura 3.2: Etapas e sessões VoIP (fonte:Autoria Própria)

5. Cliente Origina Chamada: cliente origina a ligação, podendo chegar na URA de duas
formas, via R2 Digital ou via VoIP
6. Mensagem pré-atendimento: independente da forma que a ligação chegou a URA, ela

sempre recebe um pré-atendimento. No pré-atendimento a URA vocaliza uma mensagem
com as opções de atendimento e solicita que o cliente selecione a opção desejada.
7. Discagem opção desejada: uma vez que o cliente já identificou a opção desejada, ele
precisa indicar a URA qual seria esta opção. Para selecionar a opção o cliente sempre terá
que digitar uma tecla (2 à 9) no teclado do telefone. A informação da opção selecionada
pode chegar na URA de 2 formas: se for uma ligação via R2 Digital irá chegar via MF e
se for uma chamada via VoIP deve chegar via RFC 2833(há o cuidado de configurar com
esta opção, os equipamentos que encaminham ligações ao Call Center).
8. Encaminhamento de Chamada: na URA temos ramais VoIP configurados para a interligação

com o servidor de telefonia. Troncos VoIP do servidor de telefonia se autenticam nos ra-
mais VoIP da URA. A cada opção final da URA há um ramal VoIP atrelado, dessa forma
a URA encaminha a ligação para esse ramal, que por sua vez entra no tronco do servidor
de telefonia. O servidor de telefonia recebe a ligação, identifica o tronco que entrou a
ligação, verifica e seleciona um atendente livre para atender essa chamada (se não houver
livre, segura a ligação na fila até que alguém fique livre), e aloca o cliente na sala de
conferência do atendente.
9. Fluxo de áudio entre URA e servidor de telefonia: no momento em que o servidor de

telefonia recebe e trata uma ligação da URA, ele começa a trocar mensagens de áudio via
RTP com a URA, independente da ligação ter sido atendida pelo atendente ou não. Se
a ligação for atendida as mensagens terão a conversa entre o cliente e o atendentes, caso
contrário as mensagens serão compostas pela música da fila de espera. Aqui é importante
destacar que a cada ligação estabelecida entre a URA e o servidor de telefonia, uma nova
sessão VoIP é estabelecida, divergindo do lado do atendente em que durante todo o dia de
trabalho é estabelecido apenas uma sessão VoIP.
10. Desconexão da Ligação: a desconexão pode ser solicitada tanto pelo atendente quanto
pelo cliente. Do lado do cliente, assim que ele coloca o telefone no gancho todos os sis-
temas trocam as mensagens necessárias e finalizam as chamadas. Já do lado do atendente
a desconexão pode ser feita através do aplicativo de telefonia. Se o atendente colocar
o headset no gancho todo o sistema sofrerá uma desconexão, gerando a necessidade de
efetuar novamente o procedimento de login.
11. Logof do Atendente: ao final de sua jornada de trabalho diária, o atendente executa o
logoff no aplicativo de telefonia. Através do logof, a sessão VoIP entre o atendente e o
servidor de telefonia é encerrada e o atendente para de receber ligações.
Fazendo uma análise aos passos que acabamos de explicar e ao cenário a ser monitorado,
podemos concluir que:
• Todas as ligações que entram no Call Center, obrigatoriamente passam pelas etapas de 5
à 10.
• Cada ligação tem pelo menos duas sessões VoIP: uma entre URA e Servidor de telefonia,
outra entre o servidor de telefonia e o Atendente.
• Quando a ligação chega na URA via VoIP são 3 sessões, além as duas já citadas, tem uma
terceira entre o PABX da empresa e a URA.
• O atendente fica durante toda sua jornada de trabalho, com uma ligação estabelecida com
o servidor de telefonia.
• Há apenas uma sessão VoIP por dia, para cada atendente.
• Temos um fluxo contı́nuo de pacotes RTP entre o servidor de telefonia e o atendente, ou

seja, há um consumo de banda independente se o atendente está falando com um cliente
ou não.
• Não temos os parâmetros da qualidade das ligações de um atendente independentes umas

das outras, e sim a análise do conjunto de ligação do dia de trabalho.
Ainda para poder entender melhor o fluxo de ligações do Call Center , foi elaborado o
diagrama mostrado na Figura 3.3
Figura 3.3: Fluxo de Ligações (fonte:Autoria Própria)
O diagrama apresenta os componentes por onde passam as ligações do Call Center, estando
dividido em dois blocos macros: bloco 1 e bloco 2. O bloco 1 representa as entradas de ligações,
já o bloco 2 representa os componentes internos do Call Center.
O bloco 1 está subdividido em 1A e 1B. O sub-bloco 1A mostra a entrada de ligações a

partir de links R2 Digital, através desses links o Call Center recebe cerca de 95% das ligações,
transformando este o bloco de entrada mais importante do sistema.
O sub-bloco 1B representa as ligações que Call Center recebe via VoIP. Verificamos que
independe da origem, as ligações que o Call Center recebe via VoIP sempre chegam por in-
termédio do PABX da Empresa. O PABX da empresa recebe as ligações e encaminha via SIP
para a URA do Call Center, sem qualquer tipo de tratamento. O bloco 1B representa cerca de
5% das ligações que chegam ao Call Center.
O bloco 2 também está subdividido, sendo 2A, 2B e 2C. Todos os blocos têm um elemento
em comum que é a URA, visto que toda ligação sempre passa primeiro por ela. Além da URA,
os sub-blocos 2A e 2B também compartilham o servidor de telefonia 1.
O sub-bloco 2A representa as ligações atendidas pelo Call Center local da matriz. Este é o
sub-bloco mais significante do Call Center, tendo aproximadamente 46 PA‘s atreladas a ele e
atendendo cerca de 80% das ligações.
O sub-bloco 2B representa as PA’s do Call Center localizadas na Filial. Na filial temos 7

3.3 Determinação do Posicionamento e Quantidade de Sondas Passivas 38
PA‘s usando exatamente a mesma estrutura do sub-bloco 2A, porém com o aporte da estrutura
de interligação via MPLS entre a matriz e a filial. O sub-bloco 2B é responsável por atender
cerca de 8% das ligações do Call Center.
O sub-bloco 2C usa o servidor de telefonia 2, esta é a única questão que o diferencia entre
o sub-bloco 2A. Conforme já comentado a necessidade de dois servidores de telefonia se dá
devido a limitações de PA‘s por servidor, porém o funcionamento de ambos é exatamente o
mesmo. No sub-bloco 2C temos cerca de 10 PA‘s, sendo ele responsável por atender aproxima-
damente 12% das ligações do Call Center.
Estruturado e entendido o diagrama de blocos, fica mais fácil identificar as sessões VoIP de
cada sub-bloco e consequentemente de todo o sistema.
Com base nos dados apresentados até agora, já é possı́vel elaborar o planejamento de
implantação das sondas e de toda a estrutura de monitoramento.
3.3 Determinação do Posicionamento e Quantidade de Son-

das Passivas
No capı́tulo 2.3 foi feito um embasamento teórico sobre técnicas de monitoramento, dentre
elas a monitoração passiva. Uma monitoração passiva é realizada basicamente por uma sonda
que coleta e reporta informações. Já no capı́tulo 2.4, foi feito um detalhamento da ferramenta
VoiPMonitor, cujo método de análise da qualidade VoIP é baseado em sondas passivas.
Tendo como princı́pio esses dois fundamentos, a seguir será abordado o estudo e a implantação
do sistema de monitoramento.
3.3.1 O Funcionamento do VoiPMonitor e o Relacionamento com a Po-

sicão das Sondas
Além de todas as caracterı́sticas do VoiPMonitor já citadas nos capı́tulos anteriores, há algu-
mas situações evidenciadas durante o processo de instalação do sistema, que afetam diretamente
o conceito da ferramenta.
O VoiPMonitor classifica e armazena, apenas os pacotes referente aos protocolos envolvidos

em uma sessão VoIP (SIP, RTP, RTCP, etc). Essa caracterı́stica é um dos pontos fortes da
ferramenta, uma vez que uma das grandes dificuldades de diagnosticar problemas na qualidade
do serviço VoIP, é a quantidade de pacotes que circulam na rede e dificultam a monitoração.
Estudando a documentação e funcionamento do VoiPMonitor, ficou evidenciado que sua

monitoração é baseada em cada sessão VoIP. Os parâmetros monitorados (MOS, Jitter, perda
de pacote, etc) são calculados a cada sessão VoIP estabelecida. Caso uma camada telefônica
envolva mais de uma sessão VoIP, não tem-se um único relatório com os dados ligação e sim
um conjunto de relatórios, que irá variar de acordo com a quantidade de sessões estabelecidas.
Para explicar melhor essa caracterı́stica do VoiPMonitor, será explorado o exemplo mos-
trado na Figura 3.4. A Figura não tem relação com o sistema do Call Center base deste estudo,
trata-se de exemplo de sistema simplificado com dois ramais VoIP e um PABX IP. Fica definido
que toda troca de mensagem entre o ponto A e C precisam passar pelo ponto B.
Figura 3.4: Análise Básica (fonte: Autoria Própria)
No exemplo da Figura 3.4, quando o ramal A liga para o ramal C, é identificado o registro
de duas sessões VoIP: uma entre o ponto A e o ponto B e a outra entre o ponto B e o ponto C.
Caso este cenário fosse monitorado com o VoiPMonitor, terı́amos 2 relatórios separados, um
para cada sessão. Note-se que a separação em sessões diferentes é inerente ao comportamento
de um sistema B2BUA (Back to Back User Agent) tal como o Asterisk.
A caracterı́stica de monitoração por sessão, é um ponto muito importante durante o plane-

jamento de instalação das sondas. Um dos principais fatores a ser considerado na decisão do
posicionamento de uma sonda, é a “área de cobertura” das sessões da rede VoIP.
No exemplo citado, o melhor posicionamento de uma sonda seria na porta de um switch,

com o espelhamento da porta de rede do servidor, uma vez que os pacotes das 2 sessões trafegam
neste ponto.
Outro fator muito importante a ser considerado no VoiPMonitor, é a questão do armazena-

mento dos dados. Conforme já viso anteriormente uma sonda do VoiPMonitor coleta os dados e
salva em uma base MYSQL. Durante a implantação do sistema, evidenciamos que apenas uma
parte dos dados são enviados para o banco, a outra parte fica armazenada em uma pasta local da
sonda. Resumidamente, os parâmetros medidos são calculados e salvos no banco, já na pasta
local ficam os áudios das ligações e alguns gráficos montados pelo sistema. De certa forma, essa
questão ajuda no desempenho do banco de dados, diminuindo a quantidade de dados enviados
à ele.
Quando trabalhamos com um sistema com mais de uma sonda, temos a opção de salvar
todos os dados em um único banco de dados. A informação citada no último paragrafo, afeta
diretamente na implantação de sistemas nessa topologia, uma vez que outras configurações
precisam ser feitas para termos acessos a todos os dados.
Com base em todas as informações relatadas sobre o VoiPMonitor, podemos concluir que
durante o planejamento da instalação do sistema, existem algumas etapas de extrema importância
para o sucesso no monitoramento:
• Fazer uma análise detalhada do fluxo das ligações, considerando as possı́veis “rotas” e o
volume das ligações.
• Com base nos fluxos de ligações, definir o melhor posicionamento das sondas
• Analisar a topologia ideal para a estrutura de monitoração: sondas isoladas ou integradas,

onde instalar o WebGUI, etc.
• Garantira os recursos para armazenar os dados coletados pelas sondas.
3.3.2 Determinação da Quantidade de Sondas
Até o momento o trabalho explorou toda a fundamentação sobre as sondas de monitora-

mento, além de apresentar o estudo sobre aos fluxos de ligações do Call Center a ser monito-
rado. Assim pode-se partir para a estruturação do sistema.
Os primeiros pontos de decisão, são a quantidade e o posicionamentos das sondas. Com

base no estudo do fluxo de ligações, evidenciamos que basicamente as sessões VoIP do Call
Center estão concentradas em 3 pontos.
1. URA: toda ligação passa pela URA, portanto ela é um elemento do Call Center onde
tem-se grande concentração de sessões VoIP.
2. Servidor de Telefonia 1: conforme o estudo do fluxo de ligações mostra, o servidor de

telefonia 1 também tem grande volume de sessões VoIP. O servidor de telefonia 1 recebe
todas as sessões encaminhadas pela URA, além das sessões com os ATA’s nele autentica-
dos.
3. Servidor de Telefonia 2: o servidor de telefonia 2 também, concentra um número razoável

do sessões VoIP. A exemplo do servidor de telefonia 1 ele recebe todas as sessões enca-
minhadas pela URA, além das sessões com os ATA’s nele autenticados.
Com base em tudo que já foi dito, foi optado por um sistema de monitoramento formado
por 3 sondas passivas, dispostas conforme Figura 3.5.
Figura 3.5: Posicionamento Sondas (fonte:Autoria Própria)
A Figura 3.5 ilustra o posicionamento das 3 sondas, bem como a “área de cobertura” das
sessões VoIP de cada uma delas. A Figura foi elaborada de forma didática e desconsidera vários
elementos da rede.
A Sonda 1 coleta os dados das sessões entre o PABX da fábrica e a URA, bem como toda
sessão entre a URA e os servidores de telefonia 1 e 2.
A sonda 2 coleta dados das sessões entre o servidor de telefonia 1 e a URA, além das
sessões entre o servidor de telefonia 1 e os ATA’s nele autenticados. Já a sonda 3 coleta dados
3.4 Implantação do Sistemas de Monitoramento 42
das sessões entre o servidor de telefonia 2 e a URA, e as sessões entre o servidor de telefonia 2
e os ATA’s nele autenticados.
Fazendo uma analogia com o diagrama de blocos apresentado na Figura 3.3, temos as
seguintes situações:
• Sonda 1 - Coleta os dados do sub-bloco 1B e parte do 2A, 2B e 2C.
• Sonda 2 - Coleta dados do sub-bloco 2A e 2B.
• Sonda 3 - Coleta dados do sub-bloco 2C.
Uma vez estabelecido o posicionamento das sondas, também é preciso definir a estrutura
de armazenamento de dados de cada uma delas. Por uma questão de facilidade de manunteção,
foi decidido que todas as sondas implantadas deveriam compartilhar o mesmo banco de dados.
A Sonda 1 é a sonda que mais captura dados, por isso decidimos que seu o banco de dados
seria onde as demais sondas gravariam as informações.
Devido ao fato de o banco de dados estar instalado no computador da sonda 1, também

instalamos nele o componente WebGUI do VoiPMonitor, para monitoração das chamadas.
Com essa estrutura estabelecemos uma convenção, de que a Sonda 1 funciona no regime
de mestre e as demais como escravas. Lembrando que isso foi apenas uma convenção que não
traduz o real funcionamento das sondas.
Através da implantação do sistema conforme planejamento e estruturação apresentada, con-

seguimos ter uma monitoração assertiva de todo o nosso sistema de Call Center.
3.4 Implantação do Sistemas de Monitoramento
No site do VoiPMonitor (http://www.voipmonitor.org/doc/Content) temos um guia de instalação

do sistema, porém para colocar o sistema proposto em operação foi necessário realizar algumas
etapas complementares. A seguir são listados alguns pontos importantes. Um detalhamento
completo dos comandos executados para a instalação do sistema está no anexo I.
3.4.1 Implantação das Sondas
Para a instalação das sondas foram utilizados computadores com hardware simples. Todas
as 3 sondas instaladas tem basicamente um processador Core2Duo, HD de 500GB e placa de
rede Onboard de 100MB, com esse hardware o sistema conseguiu “rodar” tranquilamente. O
sitema operacional escolhido para os computadores foi o Ubuntu versão 12.04 Desktop, onde
inclusive a interface gráfica foi ativada.
Nas 3 sondas foram instalados o módulo Sniffer do VoIPMonitor, porém apenas na sonda 1
foi instalado o WebGUI, ambos os módulos tiveram seus funcionamento detalhado no capı́tulo
2.
Todas as sondas e servidores foram conectados a um switch de grande porte. Para capturar
os dados foi realizado um espelhamento das portas conectadas a cada servidor (URA, servidor
de telefonia 1 e 2) para as portas das sondas 1, 2 e 3, organizadas conforme a Figura 3.5.
Com relação a instalação das sondas, foi verificado que um dos pontos cruciais é a configuração
do arquivo voipmonitor.conf, que no nosso caso é endereçado por /etc/voipmonitor.conf. Quando
aplica-se o VoIPMonitor em um cenário, onde tem-se uma sonda gravando os dados em um
banco de dados remoto, além das configurações básicas, existem outras especı́ficas para que
isso aconteça e nem tudo está explicado na documentação.
Considerando o cenário de monitoração proposto, na configuração do voipmonitor.conf é

chamado a atenção os parâmetros abaixo:
• id sensor =: neste parâmetro deve-se dar um ID para as Sondas, exemplo: id sensor = 3.

Para o sistema implantado foi importante garantir que cada sonda tivesse um ID Único, a
fim de poder identificar as informações de cada sonda do WebGUI.
• interface =: caso o computador onde o módulo Sniffer esteja instalado tenha mais de uma
placa de rede, é neste parâmetro que indica-se qual delas deve ser monitorada, exemplo:
interface = eth0.
• mysqlhost =: endereço IP do bando de dados Mysql, exemplo: mysqlhost = 192.168.0.10.
• mysqlusername =: parâmetro onde coloca-se o usuário do banco de dados no qual se

deseja conectar.
• mysqlpassword =: senha para acesso ao banco de dados.
• managerip =: IP configurado na interface de rede que está coletando os dados, mesma

interface na a qual está configurada no parâmetro interface.
Nas demais configurações, foram utilizadas o padrão do módulo Sniffer.

Uma vez as sondas configuradas e implantadas, houve a preocupação de acompanhar o

funcionamento delas. A principal preocupação foi analisar se o hardware utilizado seria o
suficiente para suprir as necessidades do sistema.
Conseguimos constatar que o processamento das máquinas não foi intensamente exigido
para o trafego de ligações do sistema, com isso conclui-se que a implantação das sondas foi
realizada com sucesso.
3.4.2 Implantação da Base de Dados
Durante execução do projeto, um dos pontos importantes foi a configuração e o funciona-

mento do banco de dados. O banco precisava lidar com a quantidade de requisições enviadas
pelas sondas, esse fato só poderia ser analisado após a implantação de todo o sistema. Para a
instalação do banco de dados nas sondas, foi utilizado o método automático do Ubuntu (apt-get
install mysql-server). A instalação do banco foi feita em todas as sondas, porém apenas a sonda
1 teve seu banco de dados populado com informações, tanto de suas capturas como das capturas
das sondas 2 e 3.
Com relação à configuração do banco de dados da sonda 1, foi necessário uma alteração
do arquivo my.conf localizado em /etc/mysql. A alteração constituiu-se em comentar a linha do
parâmetro “bind-address = 127.0.0.1”, com isso foi retirada a restrição de acesso ao banco de
um determinado IP, liberando o mesmo a ser acessado de qualquer computador. Outra alteração
realizada, foi liberação do usuário configurado nas sondas para acessar o banco de qualquer
rede. Por usar o usuário root para configurar as sondas, foi executado o seguinte comando no
console do textitmysql: GRANT ALL ON voipmonitor.* TO root@% “IDENTIFIED BY ”(senha
do usuario root);
Vale lembrar que analisando por uma ótica de segurança, as duas alterações realizadas
deixaram o banco de dados mais frágil. No entanto, essa não foi uma preocupação na hora da
implantação do sistema, em futuras implantações esse ponto pode ser revisto.
Uma vez o banco de dados em funcionamento, foi identificado que todas as sondas do
sistema de monitoramento estavam conseguindo acessar e gravar dados corretamente. Com
todo o sistema em funcionamento, voltou-se a questão do desenpenho do banco de dados. O
Curso Superior de Tecnologia em Sistemas de Telecomunicações, não aborda em sua unidade
curricular o estudo de banco de dados, por esse motivo essa questão teve que ser avaliada em
conjunto com outros profissionais.
Foi solicitado ao DBA da empresa em que o Call Center está instalado, que verificasse
como estava a performance do banco de dados. O resultado da análise mostrou que a quan-
tidade de requisições que acontecem simultaneamente ao banco de dados, é muito inferior a
capacidade disponı́vel, mesmo usando um hardware teoricamente simples.
Com o resultado positivo da análise, considerou-se concluı́da a instalação e configuração

do banco de dados.
3.4.3 Implantação da WebGUI
O módulo WebGUI do VoIPMonitor disponibiliza uma interface para interação entre o

usuário e os dados coletados pelo módulo Sniffer. O WebGUI pode ser instalado em qualquer
computador linux.
Na implantação do sistema de monitoração proposto, o WebGUI foi instalado no mesmo

computador da sonda 1. A decisão de instalá-lo nesse computador levou em consideração
que é na sonda 1, onde está o banco de dados em que todas as sondas do sistema gravam as
informações. Para a instalação do WebGUI foram seguidas as etapas disponı́veis no site do
VoIPMonitor (http://www.voipmonitor.org/doc/Content).
Um ponto muito importante é que quando instala-se o WebGUI em um computador e

deseja-se que ele monitore sondas remotas, estas devem estar devidamente configuradas para
que isso aconteça. Um parâmetro de configuração que merece atenção, para que a monitoração
remota seja realizada com sucesso é o managerip. A documentação do VoIPMonitor não deixa
claro o papel deste parâmetro e sem que ele esteja corretamente configurado a monitoração
remota fica comprometida. O parâmetro managerip foi detalhado na sessão 3.4.1.
Uma vez o sistema instalado, foi preciso configurar o ID dos sensores para que o WebGUI
pudesse separar os dados conforme o desejado. A Figura 3.6 mostra a tela de cadastro de uma
sonda, já a Figura e 3.7 mostra a lista de sondas cadastradas. Os IP’s envolvidos no sistema
foram omitidos.
3.5 Conclusões 46
Figura 3.6: Tela de Cadastro das Sondas
Figura 3.7: Sondas Cadastradas
Uma vez as sondas configuradas, teve-se como concluı́da a instalação do WebGUI
3.5 Conclusões
Neste capı́tulo foi apresentado o planejamento e a implantação do sistema de monitoração

VoIP de um Call Center. Foi apresentado o resultado da análise do cenário a ser monitorado e
do seu fluxo de ligações VoIP. Com base no resultado dos estudos elaborados, foi determinada
a estrutura/arquitetura do sistema de monitoramento. Também foram apresentados os procedi-
mentos para a implantação do VoIPMonitor, ferramenta usada como base para a monitoração
do sistema. Com base em todo o conteúdo deste capı́tulo, chegou-se a um sistema eficaz de
monitoramento para o cenário proposto. Com o sistema em funcionamento, pode-se partir para
a análise dos dados.
47
4 Operação do Sistema e Avaliação do

Funcionamento
Neste capı́tulo é apresentada uma análise inicial da operação do sistema de monitoramento

implantado no capı́tulo anterior. Com o sistema operando conseguiu-se identificar alguns pro-
blemas do Call Center e auxiliar na sua solução. Neste sentido, são discutidos alguns destes
casos detectados. Na sequência avalia-se a predição de MOS do VoiPMonitor. A possibilidade
de geração de alertas pelo sistema é discutida e, ao final do capı́tulo, é realizada uma avaliação
da ferramenta VoIPmonitor.
4.1 Análise de Dados e Geração de Relatórios
Uma vez o sistema de monitoração instalado, iniciou-se a análise dos dados. Inicialmente
foram exploradas as funções do módulo WebGUI, avaliando as informações apresentadas por
ele.
O VoIPMonitor tem uma ótima organização, tendo diversas forma de apresentar os dados
coletados. Neste trabalho acadêmico não serão abordadas todas as telas e funções do VoIP-
Monitor, caso haja o interesse, na página da ferramenta (http://www.voipmonitor.org/demo/ -
Usuário: admin, Senha: admin) existe um sistema demonstrativo onde é possı́vel explorar as
funcionalidades.
A seguir serão abordadas algumas das informações mais utilizadas na monitoração do sis-
tema proposto. Por questão de segurança e privacidade, todos os IP’s dos servidores e números
telefones dos clientes serão omitidos das figuras.
Na figura 4.1 temos alguns registros de sessões VoIP coletadas, esses registros ficam na aba
CDR do O VoIPMonitor. Cada sessão ganha um ID e também tem a identificação do sensor onde
ela foi coletada. É possı́vel identificar na figura 4.1 registros referentes a sessões das sondas 1
e 2, além de informações como: origem, destino, tempo de duração, MOS calculado para os
3 tipos de buffer, escutar o áudio da ligação, fazer o download no formato do wireshark dos
4.1 Análise de Dados e Geração de Relatórios 48
pacotes coletados, etc. A descrição de cada campo apresentado encontra-se na documentação

da ferramenta, localizada em http://www.voipmonitor.org/doc/Call Detail Record - CDR
Figura 4.1: Sessões SIP - Função CDR
Ao expandir os dados de uma sessão, temos todos os parâmetros coletados referentes a ela,
conforme mostrado na figura 4.2.
Figura 4.2: Detalhe Sessão SIP - Função Detalhes CDR
Na prática a função CDR mostrada na figura 4.1 e dDetalhes-CDR mostrada na figura

4.2 são usadas em conjunto. Quando há o relato de um problema, as primeiras informações
analisadas são os valores de MOS apresentados na função CDR. Através dos valores é possı́vel
fazer uma análise rápida para identificar em que parte sistema acontece o problema. Uma vez
identificado baixos valores de MOS, é preciso expandir a visualização da sessões para a função
Detalhes-CDR. É através da função Detalhes-CDR que identifica-se qual o parâmetro que está
comprometendo o MOS e consequentemente a qualidade da ligação. Uma vez avaliado os
parâmetros toma-se uma ação de acordo com o problema.
Além da visualização mostrada na figura 4.2, em uma sessão existem outros menus como:
SIP History, Legs by CID, Legs by header, chasts e map. Cada uma das opções traz uma
informação diferente.
Na monitoração do sistema proposto é bastante usado o SIP history, mostrado na figura 4.3.
Através do SIP history temos o diagrama com a troca de mensagens entre origem e destino,
essas informações são importante em casos onde investiga-se a queda de ligações.
Figura 4.3: Detalhe Sessão SIP
Outras duas funções que auxiliam na analise das sessões VoIP são: Legs by CID e Legs by
header. Através delas pode-se agrupar as sessões VoIP através de alguns parâmetros.
Na análise Legs by CID, as sessões são agrupadas pelos parâmetros from e TAG (EX: From:
(sip:42142958395@voipmonitor.org.de) ; tag = 99fc4be3). Esses parâmetros são encontrados
no cabeçalho dos pacotes SIP conforme figura 4.4, e correspondem ao número do chamador e
de identificação da ligação.
Figura 4.4: Cabeçalho SIP - Legs by CID
Na análise Legs by header, as sessões são agrupadas parâmetros Call ID (visı́vel na figura
4.4). Neste caso é acompanhado o Call ID das ligações, caso a mesma ligação seja transferida,
desviada, etc. todas as sessões referentes a ela serão agrupadas.
O objetivo desses agrupamentos é encontrar de forma rápida todas as sessões VoIP pode-
riam pertencer à mesma ligação.
Além de informações individuais de cada sessão, o VoiPMonitor também é capaz de agrupar

as informações em relatórios por perı́odos.
Através da interface mostrada na figura 4.5 é possı́vel escolher entre templates pré-configurados
ou montar relatórios especı́ficos, além da opção de seleção do perı́odo o qual deseja-se extrair
as informações.
Figura 4.5: Relatório por perı́odo
Como exemplo de relatório por perı́odo tem-se a figura 4.6, onde foram montados dois
relatórios diferentes: um com o volume total de ligações referentes ao mês de janeiro de 2014 e
o outro com a média do MOS no mesmo perı́odo. As baixas no volume de ligação são referentes
aos finais de semana, onde o Call Center tem menor demanda de ligações. Por outro lado, é nos
finais de semana que são registradas as melhores médias do MOS. Esses dados mostram que
com o aumento no tráfego de ligações, o MOS sofre degradação.
Figura 4.6: Relatório por perı́odo
Outra ferramenta muito utilizada na detecção de problemas é o sniffer disponibilizado no

VoIPMonitor. O sniffer tem funcionamento similar ao wireshark, diferenciando-se pela faci-
lidade em filtrar dados e principalmente por conseguir lidar com grandes volumes de dados.
Quando monitora-se uma rede com alto tráfego de dados com o wireshark é notável a dificulda-
des que ele possui, muitas vezes ficando sobrecarregado em pouco tempo. A figura 4.7 mostra
um pacote capturado com o sniffer do O VoIPMonitor
4.2 Detecção de Problemas 53
Figura 4.7: Sniffer
Também estão disponı́veis no VoIPMonitor uma série e analises online das ligações, uma
delas é a monitoração das sessões ativas mostrada na figura 4.8. Com essa função é possı́vel
avaliar as ligações online, podendo inclusive escuta-las.
Figura 4.8: Chamadas Ativas
4.2 Detecção de Problemas
Até a conclusão deste trabalho, o sistema de monitoramento ficou ativo por cerca de 90 dias.
Apesar do pouco tempo monitorando, o sistema foi capaz de identificar e auxiliar na solução de
4.2 Detecção de Problemas 54
várias situações.
A seguir serão apresentadas algumas situações, onde a ferramenta de monitoramento foi

ou é utilizada. Os problemas foram identificados e solucionados de maneira dinâmica, não foi
realizado o registro da data e hora em que ocorreram, por esse motivo não será apresentado os
dados da monitoração a cada situação descrita.
• Sistema de Call Center Derrubando Ligações
Foi identificada através da tela apresentada na figura 4.1 , que havia algumas ligações
com duração menor do que 5 segundos. Ao iniciar a investigação foi verificado através
da função apresentada na figura 4.3, que quando os servidores de telefonia recebiam uma
ligação, em que o cliente indevidamente digitava um MF, o servidor de telefonia não
conseguia tratar essas informações e mandava um desligamento (BYE) para a URA.
Diante da situação, entramos em contato com o fornecedor do servidor de telefonia e ele

resolveu. Segundo informações foi alterado o comportamento da leitura de MF, ignorando
a informação quando desnecessário.
• Falha no encaminhamento das Chamadas
Em determinado dia, o volume de transferências (clientes que digitam a opção não cor-
respondente ao assunto que desejam tratar) aumentou muito e os atendentes começaram
a reclamar de um possı́vel problema, pois os clientes informavam que haviam digitado a
opção correta. Pegou-se alguns casos de transferências e através da tela apresentada na
figura 4.1, evidenciou-se que o cliente digitou uma a opção correta, a URA encaminhou
para o DAC correspondente, porém o sistema de telefonia encaminhou a chamada para
atendentes de outro DAC.
O fornecedor do servidor de telefonia foi acionado e prontamente solucionou o problema.

A princı́pio o sistema teve alguns processos reiniciados, fazendo com o problema fosse
resolvido.
• Ligações encaminhadas à filial “Picotando“
Até o dia atual, teve-se duas quedas expressivas de qualidade das ligações encaminhadas
para a filial da empresa. Assim que os atendentes alertaram o fato, validamos na tela
apresentada na figura 4.1 que o MOS estava com valores baixos. Recorremos ao detalha-
mento das sessões apresentado na figura 4.2 e foi verificado que o Jitter da estava muito
elevado, além de algumas perdas de pacotes.
4.3 Análise da Predição de MOS com o VoIPmonitor 55
Nas duas situações foi acionada a informática da empresa, que identificou problemas
no link MPLS operadora. Foi aberto um chamado com a operadora, o SLA iniciou a
contagem porém o problema foi rapidamente resolvido nas duas situações, normalizado
as ligações.
• Ligações desconectadas indevidamente
Sempre houve casos no Call Center de clientes alegando, que os atendentes haviam desli-
gado a ligação sem prestar o devido atendimento. Até então, não conseguı́amos identificar
de maneira ágil se esse fato era verı́dico ou não, os relatórios oferecidos pelo sistema do
Call Center até mostram essa informação, porém não é algo rápido de identificar.
Com a função apresentada na figura 4.3, podemos acessar o registro da chamada de ma-
neira rápida e analisar os dados.
4.3 Análise da Predição de MOS com o VoIPmonitor
O VoIPMonitor traz diversas informações importantes e todas foram avaliadas, porém o

grande diferencial é o MOS. Através do estudo teórico realizado, o MOS foi considerado o me-
lhor parâmetro para mensurar a qualidade de voz, visto que considera o fator mais importante:
a experiência do ser humano.
Segundo documentação, no VoIPMonitor o MOS é calculado com base no Modelo E (des-

crito no capı́tulo 2), porém não segue a risca todas as regras, devendo ser considerado um
parâmetro para análises rápidas. Um dos pontos observados comparando a teoria do MOS e a
medição no VoIPMonitor, é que na teoria o MOS vai de 0 à 5, já no VoIPMonitor o máximo é
4,5.
Apesar de ser um ponto a ser avaliado, a diferença entre a teoria e a prática não influencia a
usabilidade da informação, na prática sempre que foi identificado uma ligação com o valor do
MOS baixo, identificou-se através dos demais parâmetros (perda de pacotes, atrasos, Jitter) que
a ligação realmente estava com problemas. Durante o estudo do VoIPMonitor foi verificado que
para a identificação rápida de problemas o melhor parâmetro a se observar era o MOS.
Na prática foi observado que os atendentes começam reclamar da qualidade das ligações
quando o MOS é inferior a 3. Essa constatação condiz com a teoria, onde temos que ligações
com MOS abaixo de 3 já apresentam alguns usuários insatisfeitos.
Trazendo um pouco do resultado obtido na monitoração, a figura 4.9 mostra os dados reais
de uma ligação com baixa qualidade. Neste caso o atendente recebeu a ligação e relatou difi-
culdades em entender o cliente. Foi solicitado ao atendente o número do cliente e através dele
localizou-se a ligação. Já num primeiro contato com o registro notou-se o baixo valor do MOS,
ao abrir os dados da ligação foi observado que haviam alguns problemas, dentre eles chamou a
atenção os seguintes pontos: o Jitter medido tanto pelo RTP como pelo RTCP estão elevados e
os valores do PDV registraram pacotes com mais de 300ms atraso.
Esta ligação foi recebida através de um ramal IP de um parceiro, foi entrado em contato
com o parceiro e constatou-se que a banda de dados que ele possuı́a não era suficiente para
realizar ligações VoIP.
Figura 4.9: Ligação com Problemas
Durante a fundamentação teórica encontramos na ITU-T G107, uma ferramenta que base-
ada em alguns parâmetros calcula o fator R do Modelo E e MOS, ambos detalhados no capı́tulo
2.
A ferramenta está disponı́vel em (http://www.itu.int/ITU-T/studygroups/com12/emodelv1/calcul.php)

e abre a possibilidade de cruzamento, entre o valor medido no VoIPMonitor e o valor calculado
via ferramenta da ITU-T. Na figura 4.10 é possı́vel visualizar a interface da ferramenta.
Figura 4.10: Ferramenta para Cálculo de MOS ITU-T G107
Conforme é possı́vel verificar, a ferramenta exige uma série de parâmetros para conseguir
chegar a um resultado. Foi realizada uma breve analise na ferramenta, onde notou-se que exis-
tem 2 parâmetros que influenciam fortemente no MOS, são eles:
• Mean One-Way Delay - A média de atraso do pacote em uma sentido da comunicação
• Packet-loss Probability - Probabilidade de perda de pacotes
Por falta de tempo, infelizmente não foi possı́vel explorar todos os parâmetros para chegar
a um modelo matemático, que fosse possı́vel relacionar o VoIPMonitor com a ferramenta. O
proponente deste trabalho acredita que esse poderia ser um tema a ser abordado em um trabalho
futuro.
4.4 Uso de Geradores de Alertas 58
4.4 Uso de Geradores de Alertas
Uma das funções do VoipMonitor é a geração de alertas. Uma das grandes dificuldades de
administrar um sistema VoIP de grande porte, é que algumas vezes o problema só é identifi-
cado no momento em que um usuário reclama da baixa qualidade da ligação. Muitas vezes os
usuários tem a falsa impressão, de que o problema é na rede da operadora telefônica, quando na
verdade é interno. Esse fato faz com que haja uma demora em reportar um problema.
Para poder agilizar a identificação de um problema, o VoipMonitor disponibiliza uma função

que envia via e-mails, alertas para relatar problemas no sistema. Através de uma interface de
configuração é possı́vel definir quais os parâmetros deseja-se monitorar, assim que eles saı́rem
da faixa pré-determinada é encaminhado um e-mail para o administrador do sistema.
A figura 4.11 mostra uma das telas de configuração de alertas. Através dela é permitido
configurar alertas baseados nos valores do MOS, perda de pacotes, jitter, Delay, tráfego RTP
em apenas um sentido da ligação e a falta de fluxo RTP.
Figura 4.11: Interface de Configuração de Alertas
A função de envio de alertas ainda não foi ativada no sistema de monitoramento pro-
posto. Para encaminhar os alertas o VoipMonitor precisa estar com acesso a internet. Por
uma estratégia da empresa onde o sistema foi implantado, neste momento os computadores res-
ponsáveis pelo monitoramento ainda não possuem acesso a rede externa. Todo o acesso externo
da empresa passa por uma rigorosa polı́tica de controle. Dentro da proposta descrita no capı́tulo
3, de implantar o sistema primeiramente na rede do Call Center e depois estudar a expansão do
monitoramento, também será discutido a liberação do acesso a rede externa.
4.5 Avaliação da Ferramenta 59
4.5 Avaliação da Ferramenta
Desde o inı́cio das atividades o VoIPMonitor mostrou-se uma ferramenta eficiente, porém
algumas dificuldades foram encontradas: Com relação a documentação algumas informações
não são detalhadas, porém através de algum esforço as dúvidas foram sanadas pela prática.
Na descrição da instalação deste trabalho foram detalhados todos os procedimentos necessários
para ativar o sistema. Avaliando a integração da ferramenta com o cenário proposto, o fato de
uma ligação ser identificada por mais de uma sessão VoIP prejudica a análise, já que não tem-se
um dado unificado.
No planejamento do sistema o grande desafio é definir a localização das sondas, uma vez o
fluxo de sessões VoIP identificado fica mas fácil tomar essa decisão.
Com relação a instalação, tanto o módulo WebGUI quanto módulo Sniffer são bastante
simples, desde que seus pré-requisitos sejam atendidos.
Na questão do desempenho de funcionamento, a ferramenta superou as expectativas. Mesmo

com poucos recursos de hardware a ferramenta conseguiu tratar uma quantidade expressiva de
dados. Durante a interação com o módulo WebGUI, em nenhum momento o sistema mostrou-se
”pesado“, mesmo com o volume de ligações recebidas no Call Center
No geral, mesmo ponderando as dificuldades iniciais, o VoIPMonitor é uma ferramenta

surpreendente. É uma ferramenta extremamente completa, com funções que não apenas mo-
nitoram, mas auxiliam a gestão de todo o sistema de uma maneira geral. A organização das
informações disponibilizada pelo módulo WebGUI, facilitam toda a análise dos dados. Com a
tabela das sessões VoIP mostrada na Figura 4.3 é possı́vel identificar os problemas de maneira
rápida, apenas analisando o MOS apresentado. Ao menor indı́cio de problemas, a ferramenta
disponibiliza diversos parâmetros que auxiliam a identificação e caracterização do problema,
sem contar que ela própria se encarrega de alertar possı́veis problemas.
Não foram realizados testes no sistema, para analisar o comportamento do sistema com um
fluxo de ligações maior do que o atual.
No decorrer desse trabalho não foi avalada outra ferramenta. Pela falta de tempo também
não foi possı́vel explorar todas as funções do VoIPMonitor, porém as funções exploradas nos
permite classificar a ferramenta como ótima.
4.6 Conclusões 60
4.6 Conclusões
Neste capı́tulo foi apresentada uma análise inicial da monitoração do cenário proposto. Foi
apresentado alguns dados obtidos através da ferramenta já implantada, onde inclusive foram
identificados alguns problemas. Ficou validado como sendo o MOS o parâmetro principal da
monitoração, informação enriquecida pela possibilidade de uma relação matemática entre a
ferramenta de monitoramento e a ITU-T. A função que alerta possı́veis problemas também foi
descrita, apesar de ainda não estar ativa no cenário proposto. Ao final o capı́tulo encerra com
uma avaliação positiva da ferramenta de monitoramento, ficando claro que algumas funções não
puderam ser exploradas devido ao curto tempo para realização deste trabalho.
61
5 Conclusões Finais e Perspectivas de

Trabalhos Futuros
Os objetivos iniciais do projeto foram alcançados. Como resultado deste trabalho, conseguiu-
se implantar um sistema de monitoramento VoIP eficiente em um Call Center real. Foram ex-
ploradas todas as etapas necessárias para que a implantação do sistema fosse bem sucedida,
inclusive com o detalhamento de estudos realizados.
A ferramenta VoIPMonitor, escolhida para monitorar o sistema, mostrou-se muito eficiente.

Através do parâmetro MOS, detalhado em todo o trabalho, pode-se chegar a análises rápidas
sobre a qualidade das ligações. Fica sendo o MOS o grande diferencial da ferramenta utilizada,
perante as demais ferramentas de monitoramento de rede. O trabalho mostra que é possı́vel
chegar a um monitoramento simplificado, mesmo em um sistema de grande porte.
O sistema de monitoramento proposto teve seis meses para realiar a análise de fluxo de da-
dos, estruturação, implantação e análise de resultados. Infelizmente alguns pontos importantes
não puderam ser abordados, porém ficam como sugestão para trabalhos futuros. Entre outras
opções podem ser colocados:
• Ativação do sistema de envio de alertas via e-mail, caso seja detectado um possı́vel pro-
blema;
• Elaboração de uma metodologia de análise de problemas, onde poderia ser descrito todos
os passos a serem seguidos, desde a constatação do problema até a solução, Um foco
especial poderia ser dado ao mapeamento de problemas do sistema Voip em problemas
da rede;
• Refinamento do procedimento de determninação da localização de sondas; e
• Estudo e implantação de um parâmetro capaz de computar o MOS combinado para sessões

com múltiplas legs.
5 Conclusões Finais e Perspectivas de Trabalhos Futuros 62
Devido aos resultados alcançados, será sugerido que o sistema de monitoração seja expan-
dido para toda a empresa.
63
Anexo I - Procedimentos de Instalação
Neste anexo será descrito a instalação detalhada do sistema, com alguns comentários no
decorrer das etapas.
Procedimento Sonda 1
Primeiramente foi utilizado o apt-get do Ubuntu para instalar uma série de pré-requisitos.
$apt-get -y install php5-gd php5-mysql php5 php5-cli apache2 libapache2-mod-php5 tshark

mtr mysql-server php5-mcrypt librsvg2-bin gsfonts
$cd /usr/src/
Após estar na pasta onde desejava-se fazer a instalação do sistema, foi realizado o download
e a descompactação do módulo Sniffer.
$wget –content-disposition http://www.voipmonitor.org/current-stable-sniffer-static-32bit.tar.gz
$tar xzf voipmonitor * .tar.gz
$cd voipmonitor *
O VoIPMonitor tem script para a instalação, com o camando abaixo ele foi executado.
$./install-script.sh
É necessário a criação manual de uma tabela do banco de dados.
$mysqladmin create voipmonitor
Como foi usado um único banco de dados para gravar as informações coletadas, foi ne-
cessário liberar o acesso remoto ao banco. Os próximos 3 comandos realizam a liberação.
$ vim /etc/mysql/my.cnf (comente linha com o comando: bind-address = 127.0.0.1)
$mysql -u root -p (insira a senha para acessar o mysql)
$GRANT ALL ON voipmonitor.* TO root@% “IDENTIFIED BY ”(senha do usuário

root)“; (caso queira controle de acesso deve ser configurado conforme desejado)
Anexo I - Procedimentos de Instalação 64
$ exit
Toda a configuração da sonda é feita no arquivo voipmonitor.conf conforme comandos

abaixo.
$vim /etc/voipmonitor.conf
Edite os seguintes parâmentos:
id sensor (escolha um ID para a Sonda, usado 1)
interface (identifique a interface de rede que receberá os pacotes, usado eth0)
managerip (coloque o IP que será usado no servidor, usado 10.1.49.21)
mysqlhost (IP onde está o banco mysql, usado 127.0.0.1)
mysqlusername (usuário do Mysql, usado root)
mysqlpassword (senha mysql, usado senha do root)
$/etc/init.d/voipmonitor start
Com o módulo Sniffer instalado, iniciou-se a instalação do módulo WebGUI. Da mesma

forma que o módulo Sniffer, iniciou-se com o download e a descompactação dos arquivos.
$cd /var/www
$wget http://www.voipmonitor.org/download-gui?version=latest&major=5&festry -O w.tar.gz
$tar xzf w.tar.gz
$mv voipmonitor-gui* voipmonitor
$cd voipmonitor
$rm -f index.html
Uma biblioteca do php5 também precisa ser instalada.
$wget http://voipmonitor.org/ioncube/x86 64/ioncube loader lin 5.3.so -O /usr/lib/php5/
20090626+lfs/ioncube loader lin 5.3.so
Cria-se uma pasta para armazenar as informações e da-se permissão total de acesso a ela.
$mkdir /var/spool/voipmonitor/
$chown www-data /var/spool/voipmonitor/
$chmod 777 /var/spool/voipmonitor/

O VoIPMonitor precisa de 3 arquivos adicionais, abaixo os comandos para utilizá-los.
$wget http://sourceforge.net/projects/voipmonitor/files/wkhtml/0.10.0 rc2/wkhtmltoimage-

x86 64 -O
/var/www/bin/voipmonitor/wkhtmltoimage-x86 64
$chmod 777 /var/www/bin/voipmonitor/wkhtmltoimage-x86 64
$wget http://sourceforge.net/projects/voipmonitor/files/wkhtml/0.10.0 rc2/
wkhtmltopdf-x86 64 -O /var/www/bin/voipmonitor/wkhtmltopdf-x86 64
$chmod 777 /var/www/bin/voipmonitor/wkhtmltopdf-x86 64
$wget http://voipmonitor.org/ioncube/x86 64/ioncube loader lin 5.3.so -O
/usr/lib/php5/20090626+lfs/ioncube loader lin 5.3.so
$echo zend extension =/usr/lib/php5/20090626+lfs/ioncube loader lin 5.3.so ¿
/etc/php5/apache2/conf.d/ioncube.ini
$chown -R www-data /var/www
Após executar esses comandos, reinicia-se o apache e pronto, o sistema já está instalado.
$/etc/init.d/apache2 restart
Procedimento Sonda 2 e 3
Os comandos a seguir traduzem os comandos realizados para instalar o módulo VoIPMo-

nitor, na sonda 2 e 3. Os comentário realizados no processo de instalação da sonda 1 também
servem para as demais sondas, porém nelas não foi instalado o módulo WebGUI.
$apt-get -y install php5-gd php5-mysql php5 php5-cli apache2 libapache2-mod-php5 tshark

mtr mysql-server php5-mcrypt librsvg2-bin gsfonts
$cd /usr/src/
$wget –content-disposition http://www.voipmonitor.org/current-stable-sniffer-static-32bit.tar.gz
$tar xzf voipmonitor * .tar.gz
$cd voipmonitor *
$./install-script.sh
$vim /etc/voipmonitor.conf Edite os seguintes parâmentos:

id sensor (escolha um ID para a Sonda, usado 2 e 3)
interface (identifique a interface de rede que receberá os pacotes, usado eth0)
managerip (coloque o IP que será usado no servidor, usado 10.1.49.21)
mysqlhost (IP onde está o banco mysql, usado 10.1.49.21)
mysqlusername (usuário do Mysql, usado root)
mysqlpassword (senha mysql, usado senha do root)
$/etc/init.d/voipmonitor start
67
Referências Bibliográficas
AGRAWAL, S. et al. Voip service quality monitoring using active and passive probes. In:
COMSWARE. [S.l.]: IEEE, 2006.
BERGSTRA, J. A.; MIDDELBURG, C. A. ITU-T Recommendation G.107 : The E-Model, a

computational model for use in transmission planning. [S.l.], 2003.
FERREIRA, D. M. e. a. Benefı́cios da utilização do session initiation protocol (sip) em

aplicações de comunicação multimı́dia para a saúde. [S.l.]: Wiley, 2006.
GROUP, A.-V. T. W. et al. RTP: A Transport Protocol for Real-Time Applications. IETF, jan.
1996. RFC 1889 (Proposed Standard). (Request for Comments, 1889). Obsoleted by RFC
3550. Disponı́vel em: <http://www.ietf.org/rfc/rfc1889.txt>.
HARDY, W. C. VoIP service quality: measuring and evaluating packet-switched voice. New
York: McGraw-Hill, 2003.
JESZENSKY, P. SISTEMAS TELEFONICOS. [S.l.]: MANOLE, 2004.
KUROSE J.; ROSS, K. REDES DE COMPUTADORES E A INTERNET: UMA NOVA

ABORDAGEM. [S.l.]: ADDISON WESLEY BRA, 2006.
MONITOR, V. voip monitor. 2013. Disponı́vel em: <VoIPmonitor:

http://www.voipmonitor.org>.
ROSENBERG, J. et al. SIP: Session Initiation Protocol. IETF, jun. 2002. RFC 3261
(Proposed Standard). (Request for Comments, 3261). Updated by RFCs 3265, 3853, 4320,
4916, 5393, 5621, 5626, 5630, 5922, 5954, 6026, 6141, 6665, 6878. Disponı́vel em:
<http://www.ietf.org/rfc/rfc3261.txt>.
SCHULZRINNE, H. et al. RTP: A Transport Protocol for Real-Time Applications. IETF, jul.
2003. RFC 3550 (INTERNET STANDARD). (Request for Comments, 3550). Updated by
RFCs 5506, 5761, 6051, 6222. Disponı́vel em: <http://www.ietf.org/rfc/rfc3550.txt>.
SILVA, V. Proposta de Metodologia para Avaliação de Redes de Voz sobre IP. [S.l.]:
ADDISON WESLEY BRA, 2006.

Call Center Problemas

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Call Center Problemas

Enviado por

Direitos autorais:

Formatos disponíveis

Carlos Alberto Stahelin

Monitoramento, Análise e Diagnóstico de Problemas

Prof. Eraldo Silveira e Silva , Dr.

Prof. Deise Monquelate Arndt , M.

Maicon Pereira, Eng.

1.1 Motivação do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 10

1.3 Organização do texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 11

2.1 Conceitos básicos em VOIP e Call Centers . . . . . . . . . . . . . . . . . . p. 12

2.1.1 Conceitos em VOIP . . . . . . . . . . . . . . . . . . . . . . . . . . p. 12

2.1.2 Conceitos em Call Centers . . . . . . . . . . . . . . . . . . . . . . . p. 15

2.2 Métricas de Qualidade de Serviço em VOIP . . . . . . . . . . . . . . . . . . p. 17

2.2.1 Métricas associadas à qualidade da voz . . . . . . . . . . . . . . . . p. 17

2.2.2 Métricas/Parâmetros associados ao Gerenciamento de Sessão . . . . p. 21

2.3 Técnicas de Monitoramento de Voz . . . . . . . . . . . . . . . . . . . . . . p. 22

2.3.1 Monitoração Ativa . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 22

2.3.2 Monitoração Passiva . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

3 Planejamento e Implantação do Sistema de Monitoramento p. 29

3.1.1 O Sistema de Call Center e o Atendente . . . . . . . . . . . . . . . . p. 32

3.2 Análise do Fluxo de Ligações no Sistema . . . . . . . . . . . . . . . . . . . p. 32

3.3 Determinação do Posicionamento e Quantidade de Sondas Passivas . . . . . p. 38

3.3.1 O Funcionamento do VoiPMonitor e o Relacionamento com a Po-

3.3.2 Determinação da Quantidade de Sondas . . . . . . . . . . . . . . . . p. 40

3.4 Implantação do Sistemas de Monitoramento . . . . . . . . . . . . . . . . . . p. 42

3.4.1 Implantação das Sondas . . . . . . . . . . . . . . . . . . . . . . . . p. 42

3.4.2 Implantação da Base de Dados . . . . . . . . . . . . . . . . . . . . . p. 44

3.4.3 Implantação da WebGUI . . . . . . . . . . . . . . . . . . . . . . . . p. 45

4 Operação do Sistema e Avaliação do Funcionamento p. 47

4.1 Análise de Dados e Geração de Relatórios . . . . . . . . . . . . . . . . . . . p. 47

4.2 Detecção de Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53

4.3 Análise da Predição de MOS com o VoIPmonitor . . . . . . . . . . . . . . . p. 55

4.4 Uso de Geradores de Alertas . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58

4.5 Avaliação da Ferramenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59

5 Conclusões Finais e Perspectivas de Trabalhos Futuros p. 61

Anexo I - Procedimentos de Instalação p. 63

2.1 Pilha de Transporte Pacotes usados pelo VoiP (JESZENSKY, 2004) . . . . . p. 13

2.2 Estruturas Call Center (fonte:Autoria Própria) . . . . . . . . . . . . . . . . . p. 15

2.3 Classificação Métodos de Medição (SILVA, 2006) . . . . . . . . . . . . . . . p. 17

2.5 Gráfico atraso x modelo E. (ITU-T G.114) . . . . . . . . . . . . . . . . . . . p. 21

2.6 Monitoração Ativa (AGRAWAL et al., 2006) . . . . . . . . . . . . . . . . . p. 23

2.7 Monitoração Passiva (AGRAWAL et al., 2006) . . . . . . . . . . . . . . . . p. 24

2.8 Captura Sondas Passivas (FERREIRA, 2006) . . . . . . . . . . . . . . . . . p. 25

2.9 Arquitetura VoIP Monitor (MONITOR, 2013) . . . . . . . . . . . . . . . . . p. 26

2.10 Coleta de dados: módulo Sniffer (MONITOR, 2013) . . . . . . . . . . . . . p. 26

3.1 Estrutura a ser monitorada (fonte:Autoria Própria) . . . . . . . . . . . . . . . p. 30

3.2 Etapas e sessões VoIP (fonte:Autoria Própria) . . . . . . . . . . . . . . . . . p. 34

3.3 Fluxo de Ligações (fonte:Autoria Própria) . . . . . . . . . . . . . . . . . . . p. 37

3.4 Análise Básica (fonte: Autoria Própria) . . . . . . . . . . . . . . . . . . . . p. 39

3.5 Posicionamento Sondas (fonte:Autoria Própria) . . . . . . . . . . . . . . . . p. 41

3.6 Tela de Cadastro das Sondas . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46

3.7 Sondas Cadastradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46

4.1 Sessões SIP - Função CDR . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48

4.2 Detalhe Sessão SIP - Função Detalhes CDR . . . . . . . . . . . . . . . . . . p. 48

4.3 Detalhe Sessão SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49

4.4 Cabeçalho SIP - Legs by CID . . . . . . . . . . . . . . . . . . . . . . . . . . p. 50

4.6 Relatório por perı́odo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52

4.8 Chamadas Ativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53

4.9 Ligação com Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 56

4.10 Ferramenta para Cálculo de MOS ITU-T G107 . . . . . . . . . . . . . . . . p. 57

4.11 Interface de Configuração de Alertas . . . . . . . . . . . . . . . . . . . . . . p. 58

2.1 Escala Opinião de Teste Subjetivo (HARDY, 2003) . . . . . . . . . . . . . . p. 18

2.2 Critérios para avaliação (HARDY, 2003) . . . . . . . . . . . . . . . . . . . . p. 19

2.3 Classificação de ligações conforme modelo E (SILVA, 2006) . . . . . . . . . p. 20