Guia de troubleshooting VoIP: problemas comuns, diagnóstico de primeira passagem e onde investigar em seguida

Quando um cliente reporta que o VoIP está com problema, os primeiros dez minutos definem o tom do restante do chamado. A decisão certa raramente é começar a alterar configurações. O correto é capturar evidências suficientes para isolar onde a falha reside e então aplicar a menor correção possível. Este guia é a visão executiva do troubleshooting VoIP: os sintomas que operadores encontram com mais frequência, o passo diagnóstico que isola cada um rapidamente e os guias complementares aprofundados para quando um sintoma exigir uma investigação detalhada.

A estrutura é deliberadamente orientada por sintomas. O artigo mapeia cada sintoma às suas causas mais prováveis, à única evidência que confirma ou descarta cada uma e aos caminhos de correção que resolvem a chamada.

A primeira passagem de 5 minutos

Antes de alterar qualquer configuração, capture as evidências. Reconfigurar antes de uma compreensão profunda da causa raiz pode gerar mais tempo de inatividade.

As cinco informações a coletar primeiro são: quando a chamada foi feita (timestamp com precisão de segundo), a direção (entrada ou saída da perspectiva do operador), os números de origem e destino, se transcodificação foi necessária e o erro exato que o usuário viu ou ouviu. Se o usuário “simplesmente não ouviu nada”, esse é um problema diferente de “ouviu tom de ocupado rápido”, que é diferente de “a chamada conectou e depois caiu após vinte segundos.”

O próximo passo é isolar a falha ao longo de quatro eixos. Foi uma falha de sinalização (a chamada nunca conectou) ou uma falha de mídia (a chamada conectou, mas o áudio falhou)? A falha aconteceu no lado de origem do SBC ou no lado de destino? Foi uma chamada on-net (entre dois terminais que o operador controla) ou off-net (para um destino externo)? E foi um caso isolado, um padrão intermitente ou uma falha sistemática afetando todas as chamadas?

A pergunta mais diagnóstica neste estágio é quase sempre: isso funcionava antes? Se sim, a próxima pergunta é o que mudou. Uma rotação de certificado, uma atualização de regra de roteamento, uma mudança de operadora upstream, um push de política de firewall ou uma atualização de software são a causa de uma parcela desproporcional de incidentes VoIP. O log de mudanças geralmente encontra o problema mais rápido que o rastreamento.

Sintoma 1: chamadas não conectam

A chamada falha antes mesmo do áudio ter uma chance. Sem toque, sem atendimento, sem mídia.

As causas mais prováveis são uma falha de sinalização SIP (o INVITE nunca recebe um 200 OK), um registro que não aconteceu ou expirou (o terminal não pode ser alcançado porque não está registrado), uma ACL ou regra de fraude bloqueando o IP de origem ou o número chamado, uma regra de roteamento que não corresponde ao padrão discado ou uma falha de handshake TLS em um tronco criptografado.

O primeiro passo diagnóstico é ler o código de resposta SIP no INVITE com falha. Uma resposta 4xx significa que a requisição teve um problema do lado do cliente (autenticação, permissão, formato, codec). Uma resposta 5xx significa que o servidor não conseguiu processar a requisição mesmo sendo válida (timeout, erro interno, sem recursos). Uma resposta 6xx é uma recusa global que deve ser tratada como final. Para o catálogo completo, consulte a referência complementar de fundamentos de sinalização SIP; os padrões que mais se repetem em operações reais estão abaixo.

Um 403 Forbidden quase sempre significa controle de acesso. Ou as credenciais falharam na autenticação, ou uma regra de fraude colocou o destino na lista negra. Um 404 Not Found geralmente significa que o número discado não correspondeu a nenhuma regra de roteamento. Um 408 Request Timeout significa que o próximo salto não respondeu, frequentemente porque o peer está inacessível na rede ou parou de enviar OPTIONS. Um 488 Not Acceptable Here tipicamente aponta para incompatibilidade de codec, onde o SDP recebido não ofereceu nenhum codec que o lado de destino aceita. Um 503 Service Unavailable significa, especificamente, que o próximo salto não está aceitando chamadas neste momento. Isso frequentemente indica sobrecarga no próximo salto, embora não seja necessariamente o caso, podendo ser uma suposição perigosa durante a investigação de problemas.

Sintoma 2: problemas de conexão de áudio, sem áudio e áudio unidirecional

A chamada sinalizou com sucesso (200 OK foi retornado, ACK foi enviado), mas o áudio está ausente em uma ou ambas as direções. Os usuários tipicamente descrevem como “eu consigo ouvir eles, mas eles não me ouvem” ou “a chamada conecta, mas fica muda.”

As quatro causas raiz mais prováveis são um firewall bloqueando o caminho RTP, um SDP anunciando o endereço IP ou faixa de portas errado, um problema de roteamento assimétrico onde o RTP vai em uma direção por um caminho e na outra direção por um caminho diferente, ou uma incompatibilidade de chave SRTP onde um lado não consegue descriptografar a mídia do outro.

O primeiro passo diagnóstico é capturar tanto sinalização quanto mídia na interface do SBC. Se pacotes RTP estão fluindo em apenas uma direção, o problema é bloqueio de firewall no lado que não está fluindo. Se o RTP não está fluindo de forma alguma, o problema está no SDP, geralmente um endereço IP privado anunciado onde um público era esperado, ou uma porta de mídia fora da faixa permitida pelo firewall. Se o RTP está fluindo em ambas as direções, mas o áudio está silencioso ou distorcido, o problema é criptografia ou negociação de codec.

Sintoma 3: problemas de qualidade de áudio

A chamada conecta, ambos os lados ouvem áudio, mas o áudio está ruim. Cortado, robótico, com falhas, eco, ou simplesmente abaixo do nível de qualidade de fala que o SLA do operador prometeu.

As causas prováveis são perda de pacotes (tipicamente qualquer valor acima de 1% se torna audível), jitter além do tamanho do buffer do receptor, latência ponta a ponta acima de 150 ms em um sentido, artefatos de transcodificação de codec (especialmente quando um codec de baixo bitrate está envolvido) ou eco de uma perna híbrida em algum ponto do caminho.

O primeiro passo diagnóstico é verificar a ferramenta de rastreamento de chamadas do SBC. Se o MOS está abaixo de 3,5, o codec é G.711 e a chamada tem mais que alguns segundos de áudio, a rede é a suspeita, não o SBC. A decomposição do MOS em seus componentes (jitter, perda de pacotes, latência) aponta para a camada específica que está falhando. Os limites completos, a metodologia de monitoramento por tronco e a arquitetura de métricas são cobertos no artigo complementar de melhores práticas de monitoramento VoIP, que deve ser a referência operacional para qualquer pessoa construindo uma prática de monitoramento de qualidade.

Em operações reais, três padrões produzem a maioria das reclamações de qualidade. Congestionamento WAN em uma rota de operadora específica, geralmente visível como picos de perda de pacotes em chamadas roteadas por aquele tronco enquanto outros troncos permanecem limpos. QoS que deveria estar aplicado, mas não está. E jitter buffers dimensionados para um perfil de rede diferente do que está em uso, muito pequenos (então o jitter se torna quedas audíveis) ou muito grandes (então a latência se torna audível).

Sintoma 4: chamadas caem durante a conversa

A chamada conectou, o áudio estava fluindo e então a chamada encerrou sem nenhuma das partes ter desligado. A descrição do usuário geralmente é “fomos cortados.”

As causas prováveis são expiração do timer de sessão sem renovação, uma falha de keepalive RTP fazendo um lado dar timeout na mídia, um binding NAT que expirou e derrubou o caminho, um BYE iniciado pelo peer disparado por detecção de silêncio (alguns PBXs encerram chamadas que acreditam ter terminado) ou uma instabilidade de rede em um tronco criptografado com TLS que quebrou o canal seguro.

A pergunta mais diagnóstica é exatamente quando a chamada encerrou. Se as chamadas consistentemente caem quase exatamente na mesma duração, a causa é um timer em algum ponto do caminho. Trinta e dois segundos geralmente aponta para um Session Refresh não sendo honrado. Se o tempo de queda é aleatório, a causa é orientada pela rede: um link instável, um reload transiente de firewall ou um evento de convergência BGP upstream.

Problemas de timer de sessão são o subconjunto mais comum de quedas durante a chamada e o mais fácil de corrigir a partir do SBC. A regra de normalização é inserir um header Session-Expires com um valor que o destino aceitará, ou remover o timer completamente em pernas que o tratam mal.

Sintoma 5: loops de registro ou terminais offline

O terminal está aparecendo como offline no painel de gerenciamento.

As causas prováveis são uma ACL bloqueando o tráfego de REGISTER (frequentemente porque uma regra de fraude confundiu re-registro legítimo com um ataque de varredura), incompatibilidade de credenciais após uma rotação de senha, um intervalo de keepalive NAT mais longo que o timeout do binding, tráfego de scanner ou ataque confundindo a lógica de detecção, ou um certificado TLS que expirou em qualquer um dos lados.

O primeiro passo diagnóstico é extrair os logs do SBC para o terminal afetado. O log mostrará as tentativas de registro e como o SBC respondeu. Um desafio 401 seguido de um 200 OK bem-sucedido é o padrão saudável. Um 401 seguido de outro 401 indica que o SBC rejeitou o registro completamente. Identificar a causa raiz deve ser feito no nível do registrar. Se o SBC é o registrar, esses logs serão informativos. Se o SBC não é o registrar, os logs do SBC dirão apenas parte da história.

O guia complementar de prevenção de ataques SIP DoS cobre em detalhes a fronteira entre padrões de registro legítimos e ataques de varredura, e é a referência a usar ao ajustar os limites.

Sintoma 6: falhas de DTMF

A chamada conecta com boa qualidade de áudio, mas o IVR não consegue ler os dígitos que o chamador está pressionando.

As causas prováveis são uma incompatibilidade de modo DTMF (um lado está enviando tons de áudio in-band, o outro espera telephone-events RFC 2833 ou mensagens SIP INFO), transcodificação de codec removendo o DTMF durante o trânsito, ou uma incompatibilidade de payload type no payload RTP de telephone-event (um lado usando payload type 101, o outro esperando 96).

O primeiro passo diagnóstico é capturar a mídia e verificar que o que está sendo enviado corresponde ao que deveria ser enviado. Se o usuário pressiona um dígito e o rastreamento mostra um pacote telephone-event RFC 2833 com o número correto, o problema está downstream. Se o rastreamento mostra tons de áudio in-band, mas o destino negociou RFC 2833, essa é a incompatibilidade. Um SBC B2BUA com unidade de transcodificação pode normalizar entre modos DTMF por perna, o que geralmente é a correção mais rápida para ambientes mistos.

Um caso específico que vale destacar: codecs de baixo bitrate (qualquer um com compressão agressiva) podem remover o DTMF in-band completamente. Se o caminho inclui uma transcodificação e a origem está enviando tons in-band, a chamada não consegue transportar DTMF de forma confiável. A correção é negociar telephone-events RFC 2833 ponta a ponta, ou manter o caminho em G.711 se o DTMF precisa permanecer in-band.

Sintoma 7: falhas de fax

Fax é extremamente sensível a perda de pacotes, jitter e escolha de codec. As causas prováveis são transcodificação agressiva de codec quebrando o protocolo T.30, perda de pacotes acima do limite de tolerância do fax (geralmente em torno de 0,5%), ausência de negociação T.38 quando ambos os lados suportam, ou um jitter buffer consumindo os tons de handshake V.21 no início da sessão de fax.

O primeiro passo diagnóstico é identificar se o caminho é relay T.38 ou passthrough G.711. O T.38 demodula o sinal de fax em um protocolo digital sobre UDPTL, que tolera bem perda e jitter. O passthrough G.711 transporta os tons analógicos de fax dentro do codec de voz, o que é frágil sob qualquer perda. Se o caminho tentou negociar T.38, mas voltou para G.711, a renegociação SDP geralmente mostra o motivo. O guia complementar de Fax sobre IP e T.38 cobre o caminho diagnóstico completo, o perfil de codec seguro para fax e as configurações de SBC que tornam o fax confiável.

Sintoma 8: chamadas não alcançam o destino especificado

A maioria das chamadas funciona, mas um número, prefixo ou operadora específica consistentemente rejeita chamadas.

As causas prováveis são uma rejeição do lado da operadora (caller ID não está na lista branca, nível de atestação muito baixo, bloqueio geográfico), uma incompatibilidade de formato de número (E.164 versus nacional versus local, ou dígitos extras no header From), uma regra de mapeamento por NAP ausente para o novo destino, ou um problema de atestação STIR/SHAKEN onde chamadas assinadas com nível inferior a A estão sendo bloqueadas pela operadora de destino.

O diagnóstico mais útil é identificar o tronco SIP ou NAP pelo qual a chamada com falha passou e então re-rotear por um alternativo. Se a chamada funciona no tronco alternativo, a normalização, atestação ou lógica de roteamento do tronco original é o problema. Se ainda falha no alternativo, o lado de destino está rejeitando com base em algo na chamada (caller ID, atestação, lista de bloqueio).

Se as falhas se agrupam em torno de mudanças regulatórias recentes, investigue a atestação. Várias grandes operadoras dos EUA rebaixam ou bloqueiam chamadas assinadas com nível inferior a A, e provedores que dependiam de um parceiro wholesale upstream para assinatura viram sua atestação efetiva cair. O guia de atestação STIR/SHAKEN nível A cobre o caminho operacional do nível C ao nível A e os requisitos da FCC para cada um.

Sintoma 9: problemas específicos de Teams Direct Routing

O Microsoft Teams Direct Routing tem seu próprio conjunto de padrões de falha porque os requisitos de SBC da Microsoft são rigorosos e inegociáveis. Falhas de heartbeat SIP OPTIONS, erros de handshake TLS, incompatibilidades de FQDN entre o certificado do SBC e o registrado no Teams Admin Center, e problemas de negociação SRTP são os mais comuns.

Uma verificação de primeira passagem é o status do SBC no Teams Admin Center. Se mostra offline, o heartbeat OPTIONS está falhando. A causa geralmente é um problema de handshake TLS (certificado expirado, certificado intermediário ausente ou a próxima mudança na lista de raiz de CA da Microsoft), ou um caminho de rede que caiu entre o SBC e a Microsoft. A atualização de certificado raiz de CA da Microsoft 2026 é o cenário de falha de curto prazo mais importante para verificar. Para os requisitos completos de Direct Routing e critérios de seleção de SBC, consulte a página de aprendizado sobre Teams Direct Routing.

O kit de ferramentas de diagnóstico

Quatro ferramentas cobrem a grande maioria do trabalho de troubleshooting VoIP, e um operador que tem todas as quatro prontas antes do primeiro chamado chegar resolve problemas várias vezes mais rápido do que um que precisa montá-las sob pressão.

O rastreamento de chamadas próprio do SBC é a primeira parada para qualquer questão de sinalização, gerando um ladder SIP por chamada mostrando cada mensagem trocada em ambas as pernas. A saída de CDR do SBC fornece o resumo pós-chamada, incluindo duração, codecs, MOS e causa de desligamento. Traps SNMP e um painel de monitoramento básico cobrem os padrões sistemáticos. E uma captura PCAP na interface do SBC, aberta no Wireshark, fornece a verdade bruta quando rastreamentos e CDRs discordam sobre o que aconteceu.

Quando escalar para sua operadora

Três sinais sugerem fortemente que o problema está upstream e não na infraestrutura do próprio operador. Múltiplos troncos de origem apresentam a mesma falha para a mesma faixa de destino. Múltiplos destinos em um único tronco falham ao mesmo tempo. O rastreamento SIP do SBC mostra a resposta de falha originando do lado da operadora (5xx, 6xx ou um longo atraso seguido de 408).

O pacote para entregar à operadora deve sempre incluir um rastreamento SIP cobrindo a chamada com falha da perspectiva do SBC, um PCAP da interface do SBC para o período relevante e um pequeno conjunto de exemplos concretos de chamadas (chamador, chamado, timestamp exato, duração, erro). Operadoras respondem muito mais rápido quando a solicitação inclui a evidência específica que precisam para encontrar a chamada em seus próprios logs. Chamados vagos que dizem “chamadas para o código de área 305 estão falhando” sem timestamps e exemplos de números ficam na fila.

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

O ProSBC é construído em torno da realidade operacional de que problemas de voz acontecem e precisam ser diagnosticados rapidamente. A pontuação MOS por chamada é calculada nativamente no SBC, sem necessidade de probe externo. A saída de CDR do ProSBC inclui o caminho de sinalização, causa de desligamento, codec em cada perna e campos de qualidade, em formatos texto e RADIUS. Captura de pacotes compatível com Wireshark em tempo real pode ser habilitada por chamada ou por NAP sem reiniciar nada. O rastreamento de chamadas SIP está disponível através da interface web de gerenciamento.

O motor de roteamento programável Ruby é o ponto de alavancagem para padrões de problemas sistêmicos. Quando uma operadora específica consistentemente envia headers malformados, artefatos de transcodificação ou códigos de resposta incomuns, um script de roteamento pode normalizar o padrão na camada do SBC em vez de exigir que cada PBX downstream o trate. O mesmo motor suporta integração de cadeia de filtros com TransNexus ClearIP, Neustar, SecureLogix e YouMail para as decisões de fraude, STIR/SHAKEN e scoring de reputação que afetam a completação de chamadas.

Para operadores que se encontram administrando uma prática de troubleshooting em vez de administrar seus negócios, o Serviço Gerenciado da TelcoBridges retira o trabalho de diagnóstico, mudanças de configuração e monitoramento contínuo das mãos do operador, mantendo visibilidade e controle totais com o cliente.