Qualidade em chamadas VoIP: como diagnosticar perda, jitter, latência, codec e eco
Antes de trocar rota, codec ou parâmetro no escuro, a operação precisa separar o sintoma dominante e confirmar a evidência técnica no CDR, RTCP, SIP trace ou PCAP.
Este artigo foi adaptado e ampliado a partir do material técnico “VoIP Call Quality Issues: Diagnosis and Fixes for Engineers”, da TelcoBridges, com contextualização da ZICTEC para operação de voz, SBC, interconexão SIP e suporte técnico.
Resumo executivo
Quando alguém diz que “a ligação ficou ruim”, a primeira resposta não deve ser trocar codec, mexer em jitter buffer ou culpar a operadora. A primeira resposta deve ser: qual tipo de ruim?
Uma chamada que não completa é um problema de sinalização ou roteamento. Uma chamada que completa, mas fica sem áudio, aponta para caminho de mídia, NAT, firewall ou RTP. Já uma chamada que completa, tem áudio nos dois sentidos e mesmo assim soa ruim entra no território de qualidade de mídia.
Nesse terceiro caso, a maior parte dos incidentes cai em cinco áreas: perda de pacotes, jitter, latência, codec/transcodificação e eco. Cada uma tem assinatura auditiva, evidência técnica e correção diferentes.
Primeiro: qual é o problema correto?
Em operação de voz, tentativa-e-erro custa caro. Alterar tudo ao mesmo tempo pode mascarar a causa raiz e criar novos sintomas. O caminho mais seguro é coletar a chamada afetada, ler os indicadores de mídia e separar a reclamação por categoria.
- Perda: pacotes RTP ausentes ou descartados.
- Jitter: pacotes chegam em cadência irregular.
- Latência: a conversa fica atrasada, mesmo com áudio limpo.
- Codec/transcodificação: a rede parece boa, mas a voz fica metálica, oca ou estreita.
- Eco: uma parte ouve a própria voz retornando.
1. Perda de pacotes
Voz é tempo real. Um pacote RTP que não chega no momento certo não será retransmitido a tempo de ser reproduzido. Acima de cerca de 1% de perda sustentada, a degradação já pode ser perceptível; acima de 3%, a chamada tende a ficar difícil de acompanhar.
O usuário descreve como áudio picotando, palavras cortadas, pequenos silêncios ou voz robótica. A evidência deve aparecer em RTCP, CDR de mídia do SBC ou análise RTP no Wireshark.
As causas mais comuns são congestionamento em rota de operadora ou WAN, QoS/DSCP não preservado, microbursts, MTU/fragmentação, flaps de rota ou problemas de LAN/Wi-Fi no endpoint.
A correção passa por validar marcação DSCP, confirmar se ela é respeitada em todos os saltos, testar rota/tronco alternativo, separar filas de voz de tráfego bulk e, quando o problema estiver no acesso local, corrigir a rede do endpoint.
2. Jitter
Jitter não é pacote perdido; é pacote fora de ritmo. Em chamadas com ptime típico de 20 ms, o receptor espera uma cadência regular. Quando a variação aumenta, o jitter buffer tenta absorver. Se não consegue, descarta pacotes atrasados e o sintoma pode parecer perda.
A assinatura audível costuma ser voz instável, subaquática, robótica ou com falhas intermitentes. Como referência prática, abaixo de 20 ms costuma ser confortável; entre 20 e 50 ms depende do buffer; acima de 50 ms a qualidade normalmente cai bastante.
Procure filas variáveis, QoS inconsistente, virtualização sem reserva de CPU, SBC/PBX com starvation de vCPU, assimetria de rota e jitter buffer mal dimensionado. Buffer pequeno demais gera drop; buffer grande demais vira latência.
3. Latência
Latência é diferente: o áudio pode estar limpo, mas a conversa fica ruim. As pessoas se interrompem, falam por cima uma da outra e sentem a chamada “atrasada”.
Acima de 150 ms unidirecional, o desconforto começa a aparecer. Acima de 250 ms, a conversa lembra chamada via satélite. Acima de 400 ms, a experiência tende a ser impraticável.
Os contribuintes são cumulativos: distância geográfica, rota real, codificação/decodificação, transcodificações, jitter buffer, acesso móvel e enlaces de longa distância. A correção vem de reduzir o que está sob controle da operação: transcodificação desnecessária, política de codec, posição regional do SBC e ajuste de buffer.
4. Codec e transcodificação
Às vezes perda, jitter e latência estão bons, mas o áudio ainda parece ruim. Nesse caso, o suspeito é o codec ou a cadeia de transcodificação.
A voz pode soar metálica, oca, estreita ou com queda clara de fidelidade. Música de espera, ruído de fundo, DTMF in-band e fax costumam sofrer mais em codecs comprimidos ou em cadeias com múltiplas conversões.
A evidência está no SDP, no SIP trace e no CDR: qual codec foi negociado em cada perna? Houve G.711 em uma ponta e G.729 na outra? A chamada passou por mais de um ponto de transcodificação?
O ideal é negociar codec comum sempre que possível, usar política por NAP/tronco e concentrar transcodificação em ponto controlado. Em rotas premium, G.711 fim a fim pode ser preferível à economia de banda quando a qualidade percebida é prioridade.
5. Eco
Eco é frequentemente confundido com rede ou codec, mas vive em outra camada. A parte afetada ouve a própria voz retornando, geralmente com atraso, enquanto a outra parte pode não perceber nada.
As causas clássicas são bordas analógicas, conversões 2 fios/4 fios, gateways TDM/IP, cancelador de eco desabilitado ou mal ajustado, headset ruim e viva-voz aberto. A latência pode tornar audível um eco que já existia em baixo nível.
A correção começa por identificar a perna que introduz a híbrida analógica ou o endpoint problemático, validar cancelador de eco, tail length, ERL/ERLE quando disponível e revisar mudanças recentes que tenham aumentado o atraso no caminho.
Fluxo prático de diagnóstico
- Coletar horário, origem, destino, rota, NAP/tronco e CDR da chamada.
- Ler perda, jitter, atraso unidirecional e MOS.
- Se perda estiver acima do aceitável, investigar caminho de rede e direção afetada.
- Se jitter estiver alto, investigar fila variável, QoS, virtualização e jitter buffer.
- Se atraso estiver alto, decompor distância, rota, codec, transcodificação e buffer.
- Se rede parece boa e MOS está baixo, revisar codec e transcodificação.
- Se uma parte ouve a própria voz, tratar como eco e procurar borda analógica ou endpoint.
- Quando CDR/RTCP não fecharem a conta, capturar PCAP no SBC e analisar RTP no Wireshark.
O que o SBC enxerga — e o que não enxerga
O SBC tem excelente visibilidade do que cruza suas interfaces: SIP, RTP, codec negociado, MOS, perda, jitter, atraso, CDR e PCAP. Mas ele não controla todo o caminho fim a fim.
Wi-Fi congestionado, softphone em notebook sobrecarregado, headset com cancelamento ruim, driver de áudio, rede da outra operadora e acesso móvel do usuário final podem estar fora da janela de medição direta do SBC.
Por isso, a função operacional do SBC é dupla: corrigir o que está sob seu controle e produzir evidência suficiente para escalar o que está fora dele. Um chamado com horário, CDR, direção afetada, rota, SIP trace e PCAP tem muito mais chance de avançar do que uma reclamação genérica de “áudio ruim”.
Como a ZICTEC pode apoiar
A ZICTEC atua em diagnóstico de redes de voz, SIP, SBC/ProSBC, interconexão, suporte operacional e preparação de evidências para RCA ou escalação entre operadoras. Em muitos casos, o primeiro passo é revisar rotas, NAPs, CDRs, política de codecs, arquitetura de SBC, exposição SIP e capacidade de captura/observabilidade.
Se a operação recebe reclamações recorrentes de áudio ruim, mas não consegue provar se a causa é rota, codec, jitter, endpoint ou operadora, o problema não é só qualidade: é falta de observabilidade operacional.
- Site: https://www.zictec.com.br
- WhatsApp: https://wa.me/554732300435
- Reunião: https://www.calendly.com/zictec/reuniao
Quer transformar reclamações de áudio em RCA com evidência?
A ZICTEC pode apoiar diagnóstico de qualidade VoIP, revisão de SBC/ProSBC, política de codecs, captura RTP, análise de CDR e escalação técnica com operadoras.