Como ler um trace SIP: guia prático

Um trace SIP é o único registro honesto do que sua rede de voz realmente fez. CDRs mentem por omissão, dashboards atrasam e relatos de usuários finais são de segunda mão. O trace é de primeira mão, byte por byte. Mesmo assim, a maioria dos engenheiros abre um e fica olhando 8.000 linhas de tráfego UDP por meia hora antes de encontrar a mensagem que explica a falha, quando um leitor metódico chega lá em 3 minutos.

Este guia é um fluxo de trabalho para profissionais, não uma referência de protocolo. Ele pressupõe que você já sabe o que é um INVITE e o que significa um 486. Se não sabe, o artigo complementar SIP call flow explicado passo a passo percorre cada mensagem de uma chamada típica, e Códigos de resposta SIP: guia completo cobre cada código em detalhe. O que este artigo aborda é tudo que acontece entre “abrir a captura” e “encontrei a causa raiz”: de onde vêm os traces, as ferramentas que os tornam legíveis, o método de 4 passos que leva você à mensagem decisiva rapidamente, os padrões a reconhecer primeiro e como empacotar suas descobertas em um ticket que a operadora vai realmente atender.

O que um trace SIP realmente é

A expressão “trace SIP” é usada para 3 coisas diferentes, e confundi-las é o que mais desperdiça tempo no início de uma investigação. Um PCAP completo é cada byte no fio, incluindo cabeçalhos TCP/UDP, RTP, RTCP e qualquer outra coisa compartilhando a mesma interface; é o que tcpdump e Wireshark produzem. Um trace somente SIP é o mesmo dado filtrado até as mensagens SIP, frequentemente armazenado como um stream HEP em um banco de dados central, capturado pelo logger interno de um SBC ou exportado do Wireshark com os frames não-SIP removidos. Um log SIP é uma representação textual que uma aplicação produziu a partir de sua própria stack SIP, tipicamente com timestamps e cabeçalhos decodificados, mas sem os pacotes subjacentes; útil para estado, mas não para patologia em nível de protocolo.

Para a maioria das falhas, o trace somente SIP é o artefato certo: ele captura cada mensagem de sinalização, permite correlacionar entre pernas e evita a penalidade de tamanho dos pacotes de áudio. Para problemas de mídia (áudio unidirecional, fala entrecortada, DTMF in-band ausente), você precisa do PCAP completo porque é o único lugar onde o RTP realmente existe. Para “não consigo dizer o que o SBC fez”, o trace interno do próprio SBC é imbatível, porque mostra a mensagem como o SBC a recebeu em uma perna, as modificações aplicadas no meio e a mensagem como saiu na outra perna, tudo em um único arquivo.

O corolário é que quando alguém lhe entrega um trace e pede para olhar, a primeira pergunta é “que tipo de trace, e de onde no caminho?” Uma exportação somente SIP de um softswitch nunca vai mostrar um problema de RTP ausente, por mais tempo que você olhe para ela.

Onde capturar e com o quê

Escolher o ponto de captura importa mais do que escolher a ferramenta. Capture onde o problema é suspeito, não onde é conveniente. Se a operadora insiste que a chamada saiu da rede dela corretamente, capture na interface do SBC voltada para a operadora e prove a mensagem que chegou. Se uma chamada de Teams Direct Routing está falhando no ringback, capture na perna do SBC voltada para o Teams e veja o que o Teams enviou.

No Linux, o tcpdump é o motor de captura padrão e grava PCAPs que qualquer ferramenta consegue ler. Um comando típico para um SBC movimentado é tcpdump -i any -s 0 -w trace.pcap, que captura tanto SIP UDP quanto TLS, além da faixa RTP que o SBC está configurado para usar. O flag -s 0 desabilita o truncamento de snaplen para que pacotes completos sejam gravados; sem ele, um INVITE de 1.500 bytes é cortado em 96 bytes e o corpo fica faltando. No próprio SBC, a captura nativa é quase sempre preferível: ela vê a mensagem na camada de aplicação, não apenas no fio, o que significa que SIP criptografado já está descriptografado e a correlação de pernas B2BUA é automática.

Wireshark é o padrão GUI, e apesar da curva de aprendizado íngreme, é o visualizador mais poderoso quando você conhece 3 menus. sngrep é a ferramenta certa quando você só tem SSH e um terminal; sua interface ncurses mostra tráfego SIP ao vivo e diagramas de escada sem precisar copiar um PCAP de volta para seu laptop. HOMER é a resposta certa para retenção e busca em toda a infraestrutura: cada SBC e proxy envia SIP via HEP para um nó de captura central, e uma única interface web permite encontrar uma chamada de ontem por número de telefone, IP ou Call-ID. O ProSBC vem com um trace SIP integrado, um recurso de captura Wireshark ao vivo e pontuação MOS por chamada, tornando o próprio SBC o primeiro ponto de captura para qualquer chamada que o tenha atravessado.

O fluxo de trabalho de leitura em 4 passos

Toda sessão produtiva de leitura de traces segue os mesmos 4 passos na mesma ordem. Pular um passo geralmente deixa você adivinhando.

Passo 1: delimite ao dialog que interessa

Um PCAP típico de SBC de uma janela de 5 minutos pode conter centenas de dialogs. Tentar ler o arquivo de ponta a ponta é o erro mais comum. Filtre agressivamente. Se você tem o Call-ID, filtre diretamente: no Wireshark, sip.Call-ID == "[email protected]". Se só tem um número de telefone, sip.from contains "+15145551234" or sip.to contains "+15145551234" vai levá-lo ao ponto em poucos segundos. Com um pacote do dialog em mãos, clique com o botão direito e “Follow” a conversa SIP para extrair a troca inteira em sua própria janela.

Se a chamada atravessou um Agente de Usuário Back-to-Back (B2BUA), esse passo lhe dá apenas uma perna. A perna complementar tem um Call-ID diferente. Você pode encontrá-la correlacionando as duas por tempo e número de telefone, pelo cabeçalho Contact que o SBC inseriu, ou consultando o trace interno do SBC onde a relação está registrada explicitamente.

Passo 2: classifique a fase da falha

Antes de ler qualquer mensagem em detalhe, decida qual fase da chamada quebrou. As 3 opções são: estabelecimento (qualquer coisa desde o INVITE inicial até o ACK final confirmando a conexão), meio da chamada (após a sessão de mídia estar totalmente estabelecida, mas antes de um desligamento intencional) e encerramento (BYE e sua resposta). Falhas de estabelecimento são de longe as mais comuns, e o diagrama de escada indica a fase instantaneamente: se você nunca vê um 200 OK para o INVITE, está no estabelecimento; se vê 200 OK seguido de RTP e depois um BYE mais cedo que o esperado, está no meio da chamada; se o BYE acontece no momento certo mas a chamada consta como falha no Registro de Detalhe de Chamada (CDR), está no encerramento ou contabilização pós-chamada.

Passo 3: leia o cabeçalho ou código decisivo

Falhas de estabelecimento se resolvem em uma de 3 coisas quase sempre: o código de resposta final, o corpo SDP do 200 OK (ou sua ausência) e os cabeçalhos de autenticação em qualquer 401 ou 407. Um 488 Not Acceptable Here aponta para o SDP; um segundo 401 ou 407 consecutivo, ou um 407 seguido de nenhum segundo INVITE, aponta para uma incompatibilidade de autenticação ou credenciais; um 408 sem nenhuma resposta provisória aponta para transporte. Falhas de meio de chamada se resolvem no cabeçalho Reason do BYE ou na sua ausência, no timing do RTP e em quaisquer re-INVITEs intermediários. Falhas de encerramento são incomuns; quando acontecem, a numeração CSeq e os tags From/To indicam se você está olhando para o mesmo dialog que o CDR acredita ter encerrado.

Passo 4: confirme na mídia se necessário

Se o trace diz que a chamada conectou mas o usuário não ouviu nada, a sinalização SIP é inocente e o RTP é o culpado. Abra Telephony, RTP, Stream Analysis no Wireshark, selecione o stream da perna em questão e observe a contagem de pacotes, jitter e delta. Zero pacotes recebidos com pacotes enviados diferentes de zero é áudio unidirecional causado por um problema de NAT. Pacotes estáveis com rajadas de delta acima de 60ms é jitter causado por buffering em algum ponto anterior. Um stream que roda por 2 segundos e para é um media gateway que travou no meio da chamada. A sinalização parece normal nos 3 casos.

Wireshark na prática

Três menus carregam quase todo o peso analítico: VoIP Calls, Flow Sequence e a barra de display filter. Todo o resto é decoração.

Telephony, VoIP Calls varre a captura em busca de dialogs SIP e H.323 e os lista em uma tabela com horário de início, duração, status e codec. Esse é o primeiro lugar onde ir em qualquer PCAP novo porque indica em 5 segundos quantas chamadas estão no arquivo, quais tiveram sucesso e quais falharam. Selecionar uma chamada e clicar em “Flow Sequence” gera um diagrama de escada mostrando cada mensagem SIP e stream RTP em ordem cronológica, com timestamps e direção das setas. Essa visão sozinha resolve a maioria das perguntas “o que aconteceu nessa chamada”.

O display filter é a alavanca que transforma capturas de 8.000 pacotes em capturas de 30. Os filtros que valem cada tecla digitada:

• sip mostra apenas pacotes SIP.
• sip.Call-ID == "..." isola um dialog.
• sip.Method == "INVITE" lista cada tentativa de chamada no arquivo.
• sip.Status-Code >= 400 lista cada falha.
• rtp mostra apenas pacotes RTP; rtcp mostra os relatórios de qualidade.
• tcp.analysis.retransmission revela retransmissões TCP quando SIP roda sobre TCP.
• frame.time >= "2026-05-25 14:30:00" recorta por tempo absoluto quando você sabe aproximadamente quando a falha aconteceu.

Para análise RTP, Telephony, RTP, RTP Streams lista cada stream de áudio que o Wireshark detectou, com contagem de pacotes, jitter, pacotes perdidos e estimativas MOS derivadas dessas métricas. Clicar com o botão direito em um stream e escolher “Analyze” fornece os valores de jitter e delta por pacote; “Play Streams” decodifica o áudio quando o codec é G.711, que é a forma mais rápida de confirmar se o áudio que chegou era realmente inteligível.

sngrep quando você só tem um terminal

Quando a única coisa entre você e o SBC é uma sessão SSH, sngrep é a ferramenta certa. Execute sngrep sem argumentos e ele captura SIP ao vivo de todas as interfaces; execute sngrep -I trace.pcap e ele abre um arquivo capturado anteriormente. A interface mostra uma lista de dialogs no topo, um diagrama de escada para o dialog selecionado na parte inferior e permite pressionar Enter em qualquer mensagem para ver os cabeçalhos completos. Todo o fluxo de trabalho acima (delimitar, classificar, decidir sobre o cabeçalho decisivo) funciona no sngrep tão bem quanto no Wireshark, e a vantagem de latência de trabalhar diretamente no SBC é significativa quando a alternativa é copiar um PCAP de vários gigabytes por uma WAN.

A única limitação é mídia. O sngrep é exclusivamente de sinalização, então quando uma investigação RTP é necessária, você ainda precisa recorrer a um PCAP. A maioria dos fluxos de trabalho em produção usa ambos: sngrep para triagem rápida no SBC, Wireshark para análise mais profunda após a identificação de uma chamada específica.

5 padrões para reconhecer antes de ler cabeçalhos

A maioria das falhas em produção corresponde a uma de 5 assinaturas de trace. Reconhecer a assinatura primeiro economiza o tempo que você gastaria lendo cada cabeçalho em sequência.

A tempestade de retransmissão aparece como requisições SIP idênticas repetidas com o mesmo parâmetro branch e intervalos crescentes (500ms, 1000ms, 2000ms, 4000ms, 8000ms, 16000ms, 32000ms antes de Timer B disparar). Significa que o próximo salto nunca enviou uma resposta provisória. Ou o próximo salto está fora do ar, ou um firewall está descartando silenciosamente a requisição, ou o próximo salto recebeu mas não consegue rotear.

O descarte por Timer B aos 32 segundos é a consequência da tempestade de retransmissão. O user agent de origem desiste exatamente 32 segundos após o primeiro INVITE e retorna 408 Request Timeout para a aplicação. Chamadas que “tocam por 32 segundos e depois falham” sem nunca alcançar o terminal chamado são quase sempre esse padrão.

O loop de autenticação aparece como INVITE, 401 Unauthorized (ou 407 Proxy Authentication Required), segundo INVITE com cabeçalho Authorization, seguido imediatamente por um segundo 401 ou 407 consecutivo. O destinatário está rejeitando a credencial digest. Quase sempre uma string de realm incompatível entre o SBC e o provedor upstream, ou uma diferença de relógio que invalida o nonce.

A incompatibilidade de codec aparece como INVITE com uma oferta SDP listando vários codecs, 488 Not Acceptable Here, sem mídia. Os dois lados não conseguiram concordar em um codec. Ou a oferta SDP lista codecs que o destinatário não suporta, ou o destinatário está configurado para aceitar apenas um codec que o originador não ofereceu. A capacidade de transcodificação de um SBC bem configurado oculta esse problema de ambos os lados.

O áudio unidirecional com sinalização limpa aparece como uma sequência INVITE-200-ACK completa, RTP fluindo em uma direção, nenhum RTP na outra e um BYE 30 a 90 segundos depois quando um lado desiste. O trace SIP é inocente. A causa é quase sempre um problema de NAT na linha c= do SDP, um firewall assimétrico ou um caminho de mídia que nunca abriu de fato em um dos lados.

Traces criptografados e o arquivo key-log

Uma chamada rodando sobre TLS na porta 5061 não é legível no Wireshark sem chaves de descriptografia. Existem 3 maneiras de recuperar a legibilidade. A primeira é capturar em um SBC que descriptografa o SIP na camada de aplicação, o que torna a criptografia invisível para a ferramenta de trace. A segunda é capturar no fio e descriptografar depois usando um arquivo TLS key-log, configurado pela variável de ambiente SSLKEYLOGFILE em um cliente que a suporte; o Wireshark lê o arquivo em Preferences, Protocols, TLS, “Pre-Master-Secret log filename”. A terceira é inspecionar o ponto intermediário não criptografado em um SBC B2BUA, que termina TLS no ingresso e pode reoriginar TLS no egresso; o trace do logger interno do SBC vê o texto claro no intervalo.

SRTP segue o mesmo princípio. A troca de chaves acontece no corpo SDP (SDES, onde a chave mestra está embutida em texto plano dentro da mensagem SIP) ou via DTLS-SRTP no caminho de mídia. Com SDES, um trace SIP não criptografado mais a captura RTP correspondente fornecem tudo que você precisa para decodificar o áudio. Com DTLS-SRTP, sem key log não há decodificação, e a captura interna do SBC é novamente o caminho de menor resistência.

A pegadinha B2BUA: uma chamada, dois traces

Um SBC B2BUA divide uma única chamada em dois dialogs SIP completamente independentes. A perna de ingresso tem seu próprio Call-ID, From-tag, To-tag, contador CSeq e cadeia Via; a perna de egresso tem valores diferentes para cada um desses campos. Para o Wireshark, as duas pernas são dialogs sem relação que simplesmente compartilham uma janela de tempo e um número de telefone.

Ler um trace B2BUA corretamente significa correlacionar as pernas explicitamente. Os sinais que as vinculam são o cabeçalho Contact que o SBC insere (o mesmo endereço do SBC aparece em ambas as pernas), o timing (o INVITE da segunda perna sempre segue o INVITE da primeira em poucos milissegundos) e os números de telefone nos URIs From e To. A fonte mais limpa de correlação, quando disponível, é o log do próprio SBC, que registra os Call-IDs de ingresso e egresso lado a lado e despeja ambas as pernas em um único arquivo de trace. Uma captura feita em uma perna isoladamente vai induzir ao erro qualquer investigador não familiarizado com a arquitetura, porque metade da chamada parece estar faltando.

O mesmo princípio se aplica à manipulação de cabeçalhos SIP: um cabeçalho que existe na perna de ingresso pode ter sido reescrito, adicionado ou removido antes de aparecer na perna de egresso. Se um sistema downstream alega que nunca recebeu um cabeçalho que você pode ver no trace de ingresso, o trace de egresso é o que resolve a discussão.

Empacotando evidências para um ticket de operadora

Metade do tempo gasto em um trace SIP é para outra pessoa: a operadora abrindo um ticket P2, a equipe de suporte do fornecedor da plataforma, o administrador de firewall que precisa de provas de que seu dispositivo está descartando tráfego. O formato da evidência determina se o ticket será atendido hoje ou ficará na fila por uma semana.

O artefato certo é um PCAP filtrado contendo apenas o dialog em questão. No Wireshark, o fluxo de trabalho é File, Export Specified Packets, com “Marked packets only” ou “Displayed packets” selecionado após um display filter ter reduzido a visão a um único Call-ID. O arquivo resultante geralmente tem poucos centenas de kilobytes, abre sem problemas em qualquer ferramenta que entende SIP e não contém nada que o destinatário não precise.

Um bom anexo de ticket inclui 3 coisas. Primeiro, o PCAP filtrado para um dialog. Segundo, uma anotação em texto plano nomeando o salto suspeito, a mensagem suspeita e o comportamento suspeito, na forma “INVITE no pacote 47 contém codec G.729 no SDP; a resposta 488 no pacote 49 indica que a operadora não o aceitou; favor confirmar se G.729 é suportado neste trunk.” Terceiro, o horário, fuso horário e ID do CDR da chamada, para que o destinatário possa correlacionar com seus próprios logs sem adivinhar.

Anonimize quando apropriado. Números de telefone e endereços IP em traces reais de clientes são rotineiramente dados regulados, e um PCAP encaminhado a terceiros carrega tudo que a captura original viu. Ferramentas como tcprewrite e os próprios plugins de anonimização do Wireshark podem substituir números e endereços sem quebrar a estrutura da mensagem SIP.

Perguntas frequentes

Conclusão

Ler um trace SIP é principalmente sobre delimitar agressivamente, classificar a fase da falha antes de ler qualquer cabeçalho e reconhecer as 5 assinaturas comuns para que a mensagem decisiva seja a terceira ou quarta que você olha, não a quadringentésima. A ferramenta que você usa importa menos do que a disciplina do fluxo de trabalho. Wireshark em uma estação de trabalho, sngrep em um SBC, o trace integrado do próprio SBC e uma implantação HOMER central para retenção leem todos os mesmos dados subjacentes, e um operador confiante transita entre eles dependendo se a questão imediata é sobre mídia, sinalização, histórico ou disputa com fornecedor.