Problemas de Qualidade de Chamadas VoIP: Como Diagnosticar as Cinco Áreas de Falha e Corrigi-las

Quando um cliente reporta uma chamada ruim, a primeira informação útil é saber que tipo de ruim. Uma chamada que nunca se conectou é um problema de sinalização. Uma chamada que se conectou mas não teve áudio é um problema de caminho de mídia. Uma chamada que se conectou, teve áudio em ambas as direções e ainda assim soou mal é o que este artigo aborda: um problema de qualidade de áudio, onde todas as camadas abaixo do áudio parecem estar funcionando e o resultado audível ainda é ruim.

Reclamações sobre qualidade de áudio quase sempre se resolvem em uma única causa subjacente: uma das cinco áreas de qualidade está falhando ao longo do caminho da chamada. Cada área deixa uma assinatura diferente nas estatísticas de mídia por chamada, cada uma soa diferente para o ouvinte e cada uma tem sua própria correção. A disciplina diagnóstica consiste em associar o sintoma à área e então aplicar a correção que trata aquela causa específica.

Este artigo continua de onde o guia de troubleshooting VoIP mais amplo termina e aprofunda em cada área. Para o lado operacional de detectar esses problemas antes dos assinantes, o guia de melhores práticas de monitoramento VoIP é a referência complementar.

O que “áudio ruim” realmente significa: as cinco áreas

Uma reclamação de “a chamada soou mal” quase sempre se resolve em um dos cinco problemas de qualidade distintos. Tratá-los como separados é a diferença entre um diagnóstico que funciona e um diagnóstico que altera configurações aleatoriamente até o próximo ticket chegar.

As cinco áreas são perda de pacotes, jitter, atraso unidirecional, artefatos de codec e transcoding, e eco. Cada uma tem uma assinatura audível diferente, um rastro de evidências diferente em RTCP e CDR, e um caminho de remediação diferente. Mais de uma área pode falhar na mesma chamada, mas na prática operacional uma área é quase sempre a contribuidora dominante, e corrigi-la traz a chamada de volta à qualidade aceitável por si só.

O restante deste artigo percorre cada área em ordem: o que produz a falha, como ela soa, como confirmá-la a partir das evidências disponíveis e o que realmente mudar.

Área 1: Perda de pacotes

Voz é em tempo real. Não há retransmissão. Um pacote que não chega a tempo está perdido, e o receptor precisa sintetizar um substituto ou reproduzir silêncio naquele intervalo. Qualquer perda sustentada acima de aproximadamente 1 por cento se torna audível, e acima de 3 por cento a chamada fica difícil de acompanhar.

A assinatura audível consiste em palavras cortadas, lacunas curtas de silêncio, estalos ocasionais ou artefatos de início, e uma sensação “robótica” conforme o PLC tenta preencher. Os assinantes descrevem como “a chamada ficava cortando” ou “a cada poucos segundos eu perdia uma palavra.”

A primeira evidência a ser lida é o relatório do receptor RTCP de cada lado, ou a porcentagem de perda equivalente no Registro de Detalhe de Chamada (CDR) por chamada do SBC. Se a perda está acima de 1 por cento em uma direção e próxima de zero na outra, o caminho na direção afetada pela perda é o suspeito. Se a perda é bilateral, ambas as direções compartilham um salto congestionado, geralmente em algum ponto no meio do caminho da operadora.

As causas se agrupam em um conjunto pequeno na operação real. Congestionamento WAN em uma rota específica da operadora é a mais comum, e geralmente aparece como picos de perda durante o horário comercial em chamadas roteadas por aquele tronco enquanto outros troncos permanecem limpos. Microbursts em um link com excesso de assinaturas produzem o mesmo resultado audível mas com rajadas de perda curtas demais para aparecer em médias, visíveis apenas em PCAP. Incompatibilidades de MTU e fragmentação IP tendem a destruir tamanhos específicos de pacotes sistematicamente. Instabilidade de rota no caminho BGP upstream produz janelas de perda breves mas severas que recorrem. Wi-Fi no lado da LAN é sua própria fonte de perda e quase nunca é visível a partir do SBC.

Os caminhos de correção seguem aproximadamente esta ordem. Verifique se a marcação DSCP está sendo aplicada na interface do SBC e se a marcação é realmente respeitada por cada salto intermediário. Muitos operadores descobrem durante uma investigação de qualidade que o DSCP foi configurado anos atrás e uma atualização de roteador em algum ponto do caminho parou de respeitá-lo. Redirecione as chamadas afetadas por um tronco alternativo para confirmar que a perda é específica do caminho, não da plataforma como um todo. Se o SBC suportar, habilite correção de erro antecipada (FEC) no segmento voltado para a rede com perdas. Analise a carga no link upstream e desvie tráfego não-voz se voz e transferência em massa compartilham uma fila. Para perda por Wi-Fi, a única correção real é Ethernet cabeada nos aparelhos afetados, o que é uma conversa com a equipe de LAN e não uma mudança no SBC.

Uma nota específica sobre o comportamento de codecs sob perda. O G.711 (PCM) envia amostras de áudio brutas e não comprimidas e não possui PLC nativo incorporado ao padrão do bitstream, então quando um pacote é perdido, um trecho de áudio bruto é perdido com ele. O G.729 e codecs preditivos similares incluem mecanismos de PLC que tentam manter a continuidade do sinal de fala quando quadros são perdidos.

Área 2: Jitter

Se perda de pacotes trata de pacotes que nunca chegam, jitter trata de pacotes que chegam na hora errada. Codecs de voz enviam um pacote a cada 20 milissegundos (no ptime típico de 20 ms), e o receptor os espera nessa cadência. Quando o tempo entre chegadas varia, o jitter buffer do lado receptor absorve a variação até seu tamanho configurado e então descarta pacotes atrasados ou estica o áudio para esperá-los.

A assinatura audível é um áudio oscilante e instável com dropouts ocasionais, às vezes descrito como “robótico” ou “debaixo d’água.” Frequentemente coexiste com perda de pacotes em baixo nível, pois um jitter buffer que excedeu sua capacidade descarta os pacotes atrasados, que aparecem como perda no relatório RTCP.

A evidência a ser lida é o campo de jitter no relatório do receptor RTCP e no CDR. Qualquer valor abaixo de 20 ms é confortável para quase qualquer buffer. Entre 20 e 50 ms, a qualidade percebida depende fortemente da configuração do buffer. Acima de 50 ms, o MOS cairá abaixo de 3,5 para a maioria dos codecs independentemente do ajuste do buffer.

As causas diferem das causas de perda de pacotes, o que faz parte do motivo pelo qual as duas áreas se separam claramente. Profundidade de fila variável em um salto intermediário é a maior fonte: um roteador que prioriza voz quando sua fila é curta mas ignora prioridade quando a fila enche. Escalonamento de Qualidade de Serviço (QoS) inconsistente em um salto virtualizado produz o mesmo efeito dentro de um hypervisor. Starvation de CPU em um PBX, SBC ou media gateway virtualizado introduz jitter mesmo quando a rede subjacente está limpa, pois os pacotes ficam na pilha de rede do host aguardando tempo de vCPU. Roteamento assimétrico onde as duas metades da chamada seguem caminhos diferentes pode produzir jitter unidirecional que o relatório RTCP bidirecional dificulta atribuir.

O jitter buffer em si é frequentemente um contribuidor para a qualidade percebida, em ambas as direções. Subdimensionado, ele descarta pacotes atrasados e produz dropouts audíveis. Superdimensionado, ele adiciona latência que o ouvinte então experimenta como Área 3 (atraso unidirecional) e reporta como um problema separado em um ticket subsequente. A maioria dos receptores modernos utiliza jitter buffers adaptativos que se redimensionam dentro de limites configurados. Um buffer adaptativo não ficará simplesmente em seu teto de 200 ms; ele se ajusta ao jitter real observado e tende a oscilar em torno de 60 a 80 ms, a profundidade inicial mais alguma margem. O teto de 200 ms é um limite, não um alvo, e latência desnecessária só aparece quando o buffer está mal ajustado ou o algoritmo sobrecarrega o buffer agressivamente.

Os caminhos de correção começam pelo próprio jitter buffer se o receptor estiver sob controle do operador. Defina limites adaptativos que correspondam ao perfil real do caminho medido ao longo de uma amostra representativa. Se o salto variável for identificável via traceroute ou telemetria por salto, aplique ou corrija QoS naquele salto. Se o SBC ou PBX é virtualizado e há suspeita de starvation de CPU, fixe as vCPUs e reserve memória, ou mova a carga de trabalho para hardware dedicado. Se o caminho cruza uma região conhecida de roteamento assimétrico (clientes empresariais com múltiplos provedores são o caso mais comum), ancorar a mídia no SBC divide a chamada em dois segmentos de rede distintos e gerenciáveis, o que isola o jitter em um segmento específico e impede que ele se acumule de ponta a ponta.

Área 3: Latência (atraso unidirecional)

O atraso fim a fim é a mais silenciosa das cinco áreas porque não necessariamente faz o áudio soar mal. O que ele faz é tornar a conversa inviável. Acima de 150 ms unidirecional, os participantes começam a falar por cima um do outro; acima de 250 ms unidirecional, a conversa parece uma chamada por satélite; acima de 400 ms, a fala normal é impossível. A ITU-T G.114 define esses limiares, e eles se aplicam ao caminho inteiro da boca ao ouvido, não apenas ao segmento do operador.

A assinatura audível não é distorção. O chamador e o chamado reportam pausas constrangedoras, fala sobreposta, repetições de “você está aí?” e uma sensação geral de que a conversa está fora de sincronia. Raramente descreverão o áudio em si como ruim.

A evidência a buscar é o campo de atraso unidirecional nas estatísticas de qualidade do SBC. O operador só enxerga e controla o segmento do caminho que cruza o SBC. Os segmentos restantes (processamento de codec no lado da LAN, reprodução do jitter buffer, caminho da operadora do lado distante) precisam ser estimados ou medidos separadamente.

As causas são amplamente aditivas. A distância geográfica contribui com atraso de propagação física (aproximadamente 1 ms por 100 km em fibra, mais se o caminho faz desvios de roteamento). Ciclos de codificação e decodificação adicionam 10 a 30 ms por passagem dependendo do codec, com cada salto de transcoding adicionando outro ciclo completo. O jitter buffer em si é um elemento de atraso, tipicamente 40 a 100 ms em um caminho bem ajustado e substancialmente mais se estiver superdimensionado. Segmentos de satélite adicionam 240 a 280 ms em cada direção. Acesso móvel (3G especialmente, mas LTE e 5G também) adiciona 50 a 150 ms no lado rádio que o operador cabeado não consegue reduzir.

Os caminhos de correção visam encurtar os contribuidores que o operador controla. Reduza saltos de transcoding ajustando a política de codec por NAP (Ponto de Acesso de Rede) para que o SBC negocie um codec comum quando possível, em vez de converter entre dois diferentes. Implante um SBC regional mais próximo da base de clientes para que o segmento do operador no caminho seja curto. Reajuste o jitter buffer se ele foi medido como o contribuidor dominante. Para um contact center hospedado atendendo chamadores em vários continentes, dividir o tráfego em múltiplos SBCs regionais é frequentemente o único caminho para um atraso conversacional aceitável.

Área 4: Artefatos de codec e transcoding

Às vezes a chamada tem condições de rede limpas, jitter normal, baixa perda, atraso unidirecional razoável, e o áudio ainda soa errado. O suspeito restante é o codec em si, ou a cadeia de codecs por onde o áudio passou.

As assinaturas audíveis variam. Codificação tandem através de um codec de baixo bitrate produz uma qualidade oca e processada que os assinantes descrevem como “metálica” ou “de telefone.” Colapso de wideband para narrowband produz uma queda súbita na fidelidade que é óbvia para qualquer pessoa que tenha ouvido o mesmo chamador em um caminho wideband anteriormente. Codecs CS-ACELP (família G.729) lidam bem com voz limpa e degradam acentuadamente com ruído de fundo, música em espera, sibilantes e qualquer sinalização in-band como tons de fax ou DTMF in-band.

A evidência está no SDP e no CDR. O trace de chamada do SBC mostra o codec negociado em cada segmento da chamada. Se o segmento de entrada é G.711, o segmento de saída é G.729, e um terceiro salto downstream recodifica de volta para G.711, são duas passagens tandem por um codec com perdas em uma única chamada. O campo MOS no CDR refletirá a perda acumulada mesmo que todas as outras métricas de qualidade estejam limpas. A comparação entre G.711 e G.729 aprofunda na aritmética de MOS por codec.

As causas decorrem de como a negociação SDP funciona. Quando cada lado oferece um codec em comum, a chamada prossegue sem transcoding. Quando as ofertas não se sobrepõem, o SBC precisa transcodificar, o que significa um ciclo completo de decodificação e recodificação para cada 20 ms de áudio durante toda a duração da chamada. Codificação tandem ocorre quando a mesma chamada é transcodificada novamente em um salto downstream, geralmente porque a política de outro operador força um codec diferente no próximo segmento. Colapso wideband acontece quando qualquer segmento narrowband está em algum ponto do caminho; Opus ou AMR-WB nos terminais não sobrevive a um segmento de trânsito G.711 no meio.

Os caminhos de correção se concentram na política de codec. Configure preferências de codec por NAP para que o SBC negocie um codec comum sempre que ambos os lados suportarem um, eliminando o salto de transcoding inteiramente. Para rotas premium onde a largura de banda não é a restrição, force G.711 fim a fim para evitar a perda perceptual de codecs comprimidos. Onde o transcoding é inevitável, empurre-o para um único ponto no caminho e impeça segmentos downstream de recodificar. Para caminhos móvel-para-IP, o guia de transcoding SBC AMR para G.711 cobre as considerações específicas de qualidade e DSP.

Área 5: Eco

Eco é a área com maior probabilidade de ser diagnosticada erroneamente como outra coisa. Os assinantes reclamam que ouvem a si mesmos, ou que a parte distante reporta ouvir a si mesma, e o primeiro instinto é frequentemente verificar métricas de codec ou rede. Nenhuma delas mostrará nada de errado, pois eco é um artefato do caminho de mídia que vive em uma camada diferente das quatro já cobertas.

A assinatura audível é o chamador ouvindo uma cópia atrasada de sua própria voz. Afeta apenas uma direção da chamada por vez: a parte cujo áudio está sendo ecoado de volta experimenta o problema, e a outra parte não. Eco que sempre esteve presente em níveis baixos se torna audível quando a latência no caminho aumenta, pois o ouvido humano para de perceber eco quando o atraso cai abaixo de aproximadamente 25 ms (o áudio se funde com a fala original) e começa a percebê-lo nitidamente acima de 50 ms.

A evidência é mais difícil de ler em RTCP e CDR. O MOS pode ou não refletir o eco, dependendo de se a estimação de qualidade por chamada inclui medição de eco. A evidência mais clara é a natureza unilateral da reclamação: a parte A ouve sua própria voz, a parte B não percebe nada errado, e as métricas para ambas as metades da chamada parecem normais.

As causas estão quase sempre no limite analógico. Uma conversão de 2 fios para 4 fios em um híbrido analógico produz eco elétrico que deveria ser cancelado por um cancelador de eco no gateway do lado do tronco. Quando o cancelador está ausente, mal ajustado ou com tail length insuficiente para o atraso do caminho, eco residual vaza. A outra fonte é eco acústico no terminal: um viva-voz aberto, um headset mal ajustado ou um aparelho segurado longe do ouvido, com o áudio do lado distante vazando de volta para o microfone local.

Os caminhos de correção começam com a identificação do segmento que introduz o híbrido. Gateways PSTN e fronteiras TDM-para-IP são os ofensores habituais. Verifique se o cancelador de eco está habilitado naquele segmento, se seu tail length está configurado para o atraso do caminho, e se as medições de ERL (Echo Return Loss) e ERLE (Echo Return Loss Enhancement) estão dentro de faixas aceitáveis. Se o eco só apareceu em chamadas que anteriormente estavam limpas, procure por uma mudança recente que adicionou latência ao caminho; o eco sempre esteve lá em níveis baixos e a nova latência o desmascarou. Para eco acústico, a única correção real é mudar a forma como o terminal é usado ou substituir o headset.

O fluxo de trabalho diagnóstico

Ler as cinco áreas em ordem fornece uma árvore de decisão confiável para qualquer reclamação ativa.

Comece com as evidências RTCP e CDR da chamada afetada. Leia quatro números: porcentagem de perda, jitter, atraso unidirecional (ou RTT dividido por dois) e MOS. Se a perda está acima de 1 por cento em qualquer direção, o problema é a Área 1 e o próximo passo é encontrar o caminho que a direção com perda percorre. Se o jitter está acima de 20 ms e tendendo a 50 ms, o problema é a Área 2 e o próximo passo é identificar o salto variável ou o jitter buffer mal ajustado. Se o atraso unidirecional está acima de 150 ms, o problema é a Área 3 e o próximo passo é decompor o atraso em seus contribuidores aditivos. Se todos os quatro números estão normais mas o MOS está abaixo de 3,5, o problema é a Área 4, e o trace da chamada mostrará a negociação de codec em cada segmento. Se a reclamação especifica que uma parte ouve a si mesma enquanto a outra não, e as demais métricas estão limpas, o problema é a Área 5, e o limite analógico na direção afetada é o suspeito.

Quando mais de uma área está acima do limiar, corrija o contribuidor dominante primeiro e remediça novamente. Uma chamada com 2 por cento de perda e 30 ms de jitter terá uma leitura melhor após a perda ser corrigida, mesmo que o jitter permaneça inalterado; perseguir ambos simultaneamente confunde as evidências.

Quando as evidências disponíveis não conseguem identificar conclusivamente uma área, a próxima escalada é um PCAP por chamada na interface do SBC durante o período da reclamação, aberto no Wireshark com as ferramentas de análise RTP. O PCAP é a verdade de referência quando CDR e RTCP discordam.

O que NÃO está no SBC

O SBC tem visibilidade sobre o segmento da chamada que cruza suas interfaces e muito pouca visibilidade sobre qualquer outra coisa. Esse limite importa por duas razões práticas.

Problemas de terminais no lado da LAN estão fora da janela de medição do SBC. Um aparelho em um link Wi-Fi congestionado, um softphone rodando em um laptop com CPU sobrecarregada, um headset com cancelamento de eco acústico degradado, ou um AGC mal configurado no terminal produzirão reclamações de qualidade que parecem não atribuíveis a partir do SBC. O SBC pode provar que a chamada estava limpa em sua interface; o próximo passo é com a equipe de LAN ou o fornecedor do terminal.

Caminhos de operadora do lado distante também estão fora da janela de medição. Se uma operadora downstream está descartando pacotes em seu núcleo, o SBC verá a perda no relatório RTCP de entrada mas não terá detalhes além disso. O melhor pacote para entregar a uma operadora downstream ao escalar um problema de perda na rede central é um PCAP de dupla ponta, ou uma captura feita exatamente na fronteira de ingresso/egresso do SBC. Tickets vagos ficam na fila; tickets com evidências concretas avançam mais rápido. Para a visão mais ampla de quando e como empacotar uma escalação, o guia de troubleshooting VoIP cobre escalação para operadoras em profundidade.

Como o ProSBC ajuda a resolver problemas de qualidade de chamadas VoIP mais rápido

O ProSBC é construído em torno da realidade operacional de que reclamações de qualidade chegam e precisam ser diagnosticadas rapidamente. O MOS por chamada é calculado nativamente no SBC, com os campos subjacentes de jitter, perda e atraso unidirecional expostos em cada registro CDR tanto para exportação texto quanto RADIUS. A decomposição em áreas é o que torna o fluxo de trabalho diagnóstico acima utilizável sem sondas externas ou ferramentas de síntese.

A captura de pacotes compatível com Wireshark pode ser habilitada por chamada ou por NAP sem reiniciar nada, o que significa que a evidência PCAP está disponível no momento em que um ticket chega. O trace de chamadas SIP mostra o codec negociado em cada segmento, revelando codificação tandem e incompatibilidades de codec que produzem reclamações da Área 4. O motor de roteamento API programável suporta política de codec por NAP, que é o ponto de controle prático para gerenciar saltos de transcoding em uma rede multi-operadora. Transcoding por hardware via Tmedia está disponível para ambientes onde qualidade de nível DSP em transcodes AMR, Opus ou G.729 é necessária em escala.

Para provedores que desejam a camada de dashboard sem construí-la por conta própria, o Monitoring as a Service traz as métricas de qualidade por chamada para um dashboard gerenciado com alertas em tempo real. Para operadores que querem o trabalho diagnóstico fora de suas mãos, o Managed Service inclui ProSBC+ com Alta Disponibilidade (HA) 1+1, suporte Nível 3 24×7, mudanças de configuração contínuas e monitoramento contínuo.