Monitoramento de VoIP: como medir a qualidade da chamada em telefonia IP

Autor: Pedro Tebaldi PM do KeepGreen

Publicado ago/2026

O painel do link está verde. O switch do andar não registra descarte. Ainda assim, o diretor comercial liga para a TI reclamando que a conversa com o cliente picotou três vezes na mesma tarde.

Essa cena se repete porque a maioria das empresas monitora o transporte, não a conversa. No entanto, disponibilidade do circuito e latência média dizem pouco sobre o que o ouvido humano percebe. Vale destacar que voz é uma aplicação de tempo real: ela falha por motivos que um gráfico de banda nunca revela.

Este guia mostra como medir a chamada de ponta a ponta. Você vai ver as métricas de rede que degradam o áudio e os indicadores de sinalização que quase ninguém acompanha. Por fim, um fluxo de diagnóstico aponta se a culpa é da sua rede, do fornecedor de link ou da operadora.

O que é monitoramento de VoIP e por que ele não é monitoramento de rede

Monitoramento de VoIP é o acompanhamento contínuo da qualidade das chamadas de voz sobre IP. Ele cobre três frentes: as métricas de rede que carregam o áudio, a sinalização SIP que estabelece a chamada e a qualidade percebida pelo usuário. Essa percepção vira número no MOS ou no fator R.

Em resumo, ele mede a conversa, não apenas o circuito.

A confusão entre os dois custa caro na operação. Um circuito pode fechar o mês dentro da meta de disponibilidade contratada e ainda assim produzir chamadas ruins todos os dias. Ou seja, a média mensal esconde exatamente as variações de milissegundos às quais a voz reage.

Voz é a aplicação menos tolerante da rede corporativa. Ela não retransmite pacote perdido, não espera o buffer encher nem aceita atraso acumulado. Por isso, ela costuma denunciar primeiro um problema que o restante da infraestrutura ainda absorve em silêncio.

As três camadas de uma chamada de voz sobre IP

Antes de tudo, entenda que toda ligação atravessa três camadas independentes. Quando você separa as três, o diagnóstico deixa de ser adivinhação.

A primeira é o transporte: os pacotes RTP que carregam o áudio entre os pontos. Nessa camada vivem latência, jitter e perda de pacotes.

Em seguida vem a sinalização: as mensagens SIP que registram o ramal, convidam o destino, negociam o codec e encerram a sessão. Uma chamada pode ter transporte impecável e mesmo assim nunca completar.

Por fim, existe a percepção: o que o usuário de fato ouviu. Ela não se deduz das outras duas de forma direta. Isto é, o codec escolhido, o cancelamento de eco e o buffer de recepção também interferem no resultado.

Cada camada pede um método de coleta próprio. Da mesma forma, cada uma aponta para um responsável diferente quando o problema aparece.

Métricas de rede que derrubam a chamada

O áudio viaja em pacotes pequenos, emitidos em cadência fixa, tipicamente a cada 20 milissegundos. Três fenômenos quebram essa cadência, a saber: o atraso de trânsito, a variação desse atraso e o descarte de pacotes pelo caminho.

O único limiar de atraso com norma internacional atrás dele vem da recomendação G.114 da ITU-T. Ela afirma que atrasos fim a fim abaixo de 150 ms preservam a interatividade para a maioria das aplicações. Além disso, ela fixa 400 ms como teto de planejamento de rede.

Cabe ressaltar um ponto que a maior parte do conteúdo sobre o tema ignora: esses 150 ms são o atraso “boca a ouvido”, não o RTT do ping. O tempo de codificação, o enfileiramento e o buffer de recepção entram na mesma conta.

Por que o jitter machuca mais do que a latência média

O terminal de voz precisa reproduzir um pacote a cada 20 ms, sempre. No entanto, a rede entrega em intervalos irregulares. Por isso, o receptor usa um buffer de compensação para reordenar e espaçar a saída.

Esse buffer resolve um problema criando outro. Ele acrescenta atraso ao caminho, ou seja, consome parte do orçamento de 150 ms que a G.114 recomenda preservar. Dessa forma, quanto maior o jitter, mais fundo o buffer precisa ser.

Chega um ponto em que o equipamento escolhe entre dois males: atrasar demais ou descartar o pacote que chegou tarde. Nos dois casos o usuário percebe. Por isso, uma rede com latência baixa mas instável soa pior do que uma rede lenta e constante.

Vale destacar ainda que o RTP roda sobre UDP justamente para não retransmitir. Se você conhece a diferença entre os dois protocolos de transporte, entende por que o pacote perdido em voz simplesmente não volta.

Nesse sentido, controlar o descarte na origem vale mais do que qualquer ajuste feito no terminal do usuário.

MOS e fator R: como transformar percepção em número

MOS é a nota de 1 a 5 atribuída à qualidade percebida da voz. Fator R é a escala de 0 a 100 do modelo E. Esse método de planejamento da ITU-T combina atraso, perda, eco e codec em um índice único. Assim, as ferramentas de mercado calculam o R e convertem o resultado em MOS estimado.

A tabela abaixo traz as faixas oficiais, conforme a definição de categorias de qualidade da recomendação G.109.

A própria norma acrescenta uma nota importante: conexões com fator R abaixo de 50 não são recomendadas. Ou seja, a escala prática de operação vive entre 50 e 100, não entre 0 e 100.

Um alerta necessário: o MOS isolado não diagnostica coisa alguma. Ele informa que a chamada foi ruim, jamais o motivo. Em resumo, ele serve para priorizar investigação e para conversar com a diretoria, jamais para substituir a análise por camada.

A camada que quase ninguém mede: a sinalização SIP

Sinalização SIP é o conjunto de mensagens que registra ramais, estabelece sessões e encerra chamadas. Quando ela falha, o usuário não reclama de áudio ruim: ele simplesmente não consegue ligar.

Por outro lado, a maioria das ferramentas de mercado ignora essa camada por completo. Como resultado, uma classe inteira de incidentes fica invisível no painel.

Existe padrão para isso desde 2011. A RFC 6076 do IETF define as métricas de desempenho fim a fim para telefonia baseada em sessões. Vale destacar que adotar os nomes da norma evita indicadores caseiros e facilita a conversa com fornecedores.

Os mais úteis no dia a dia são cinco. SER mede a proporção de sessões estabelecidas com sucesso por tentativa. SEER refina a conta ao excluir respostas causadas pelo próprio usuário, como ocupado ou recusa. Em seguida, ISA conta as tentativas que morreram por falha interna do proxy.

Além disso, SRD mede o tempo entre o INVITE e a primeira resposta indicativa, ou seja, quanto o usuário espera até ouvir o chamamento. RRD faz o mesmo para o registro do ramal. Um RRD que sobe no fim da tarde costuma denunciar saturação, não defeito.

O que os códigos de resposta SIP entregam de graça

Cada tentativa frustrada carrega um código de retorno que já é meio diagnóstico. Por isso, instrumente contadores por código, por tronco e por hora.

Um 403 aponta credencial ou permissão de rota. O 408 indica que a requisição morreu sem resposta, cenário típico de firewall ou de rota assimétrica. Já o 480 costuma revelar ramal sem registro ativo. Por fim, o 503 quase sempre significa capacidade esgotada do outro lado.

Coleta ativa e coleta passiva: como medir cada camada

A coleta ativa gera chamadas sintéticas em intervalos regulares e mede o resultado. Ela responde pela disponibilidade de ponta a ponta, funciona de madrugada quando não há tráfego real e permite comparar rotas. Em contrapartida, ela mede a chamada de teste, não a do usuário.

A coleta passiva observa o tráfego real sem interferir. Os relatórios RTCP e RTCP-XR trazem jitter, perda e o próprio fator R calculado pelo terminal. Ao mesmo tempo, o espelhamento de porta captura a sinalização. Os registros de chamada (CDR) fecham a conta por ramal, por rota e por período.

O gateway, o SBC e o PABX completam o quadro por consulta SNMP: canais em uso, temperatura, uso de CPU e status de tronco. Nesse sentido, a análise de tráfego da rede mostra com quem a voz está competindo quando o link satura.

Em suma, as duas abordagens se complementam. Um ponto de partida barato combina uma sonda contínua contra o SBC com uma captura de sinalização no gateway.

# Linha de base contra o SBC: 300 amostras em janela de 1s
ping -c 300 -i 1 10.0.0.10

# Sinalizacao do tronco em tempo real (porta SIP padrao)
sngrep -d eth0 port 5060

Como descobrir se a culpa é da sua rede, do link ou da operadora

O diagnóstico fica simples quando você mede os trechos separadamente. Compare sempre o segmento interno (ramal até o SBC) com o segmento externo (SBC até a operadora). Dessa forma, o trecho que degrada isolado entrega o responsável.

Dois detalhes fecham a investigação. Primeiro, a voz precisa de segmentação lógica própria na rede local, com marcação de prioridade coerente do acesso até a borda. Sem isso, o backup noturno compete de igual para igual com a chamada do comercial.

Segundo, guarde histórico do circuito. Quando a suspeita recai sobre o provedor, medição independente do link contratado transforma reclamação em evidência para a mesa de negociação.

Alertas de voz sem afogar o plantão

Um tronco corporativo processa milhares de chamadas por dia. Alertar a cada chamada com MOS ruim gera centenas de notificações e treina a equipe a ignorar todas. Portanto, o alerta precisa nascer agregado.

Três ajustes resolvem a maior parte do ruído. Agregue por rota ou por tronco, nunca por chamada isolada. Use percentil em vez de média, porque a média dilui o problema de uma minoria barulhenta. Por fim, exija persistência: três janelas consecutivas ruins valem alerta, uma sozinha não vale.

Ajuste também a linha de base por horário. O comportamento normal das 3h da manhã não é o mesmo das 10h. Definir limiares de alerta com contexto importa mais em voz do que em qualquer outro serviço. O motivo é simples: o volume de chamadas varia muito ao longo do dia.

Conclusão

Em síntese, monitorar telefonia IP não é acrescentar mais um gráfico ao painel de rede. É reconhecer que a chamada tem três camadas independentes e que cada uma responde a um dono diferente quando falha.

Comece pelo mais barato. Instrumente os relatórios RTCP que seus terminais já produzem, ative contadores de código SIP por tronco e crie uma sonda sintética contra o SBC. Depois disso, pense em ferramenta especializada. Com essas três fontes você já responde às perguntas que hoje ficam sem resposta na reunião de crise.

Acima de tudo, ancore os limiares em norma. O atraso tem número na G.114, a qualidade percebida tem faixa na G.109 e a sinalização tem métrica na RFC 6076. Quem discute com o fornecedor apoiado em referência pública sai da conversa com prazo, não com promessa.

Se a sua operação depende de voz para vender, atender ou socorrer, vale estruturar essa medição antes do próximo incidente. Fale com um especialista da OpServices para desenhar o monitoramento das três camadas no seu ambiente.