A chamada não completa, o telefone mostra “falha” e o log do PABX traz só um número: 403, 408, 488. Cada código de resposta SIP é uma pista sobre onde a chamada parou e por quê. Quem sabe lê-los troca horas de tentativa e erro por alguns minutos de captura.
Neste artigo você vai entender como os códigos são organizados, o que significam os que mais aparecem no dia a dia de PABX e SIP trunk, onde olhar para resolver cada um e como diagnosticar um caso real, passo a passo.
Se você ainda não conhece a estrutura das mensagens (requisição, resposta, cabeçalhos e SIP URI), vale ler antes Estrutura do Protocolo SIP e SIP URI.
Como ler um código de resposta SIP
Toda requisição SIP (INVITE, REGISTER, BYE, OPTIONS…) recebe uma ou mais respostas. Cada resposta tem um código de três dígitos e uma frase, a “reason phrase”, como em SIP/2.0 486 Busy Here. A frase é para pessoas e pode mudar de um fabricante para outro; quem decide o que fazer com a resposta é o número.
O primeiro dígito diz a classe. As respostas 1xx são provisórias e as de 2xx a 6xx são finais: encerram a transação. Num INVITE, é a primeira resposta final que diz o destino da chamada.
Um detalhe útil: o RFC 3261 manda tratar um código final desconhecido como o x00 da mesma classe. Um 499 que o seu telefone não conhece é tratado como 400; um 599, como 500. Por isso a classe já diz muito, mesmo quando o código é raro.
Antes de tudo: 401 e 407 não são erro
Esta é a confusão mais comum em quem começa a ler capturas. Ao ver um 401 Unauthorized ou um 407 Proxy Authentication Required no meio do fluxo, parece que a chamada falhou. Na maioria das vezes, não falhou: o servidor só pediu a senha.
O primeiro INVITE (ou REGISTER) vai sem credencial. O servidor responde com o desafio, que traz o realm e um nonce. O cliente confirma com ACK e repete a requisição com o cabeçalho Authorization (para 401) ou Proxy-Authorization (para 407), calculado a partir do usuário, da senha e do nonce. Se a credencial confere, a chamada segue normalmente.
O erro de verdade é quando a segunda tentativa, já com credencial, recebe 401, 407 ou 403 de novo. Aí confira:
Usuário de autenticação. Em muitos provedores ele é diferente do número ou do ramal.
Senha e realm. Um realm diferente do esperado faz o cálculo do hash dar errado mesmo com a senha certa.
Relógio e nonce. Nonce expirado gera um novo desafio com
stale=true; repetido em laço, indica problema de horário ou de configuração.
No Asterisk, ligue o log com pjsip set logger on e procure “Failed to authenticate”. No FreeSWITCH, use sofia global siptrace on.
Os códigos que mais derrubam chamadas
Para cada código, você vai ver o que ele quer dizer, as causas mais prováveis e onde olhar primeiro. Clique no título de cada um para abrir a ficha completa, com a causa Q.850 equivalente e o filtro do Wireshark, na tabela de códigos SIP da EDCA.
403 Forbidden
O servidor entendeu a requisição e se recusa a atendê-la. Diferente do 401, autenticar de novo não resolve: a credencial pode até estar certa, mas aquela chamada não é permitida. Causas prováveis:
No SIP trunk, o IP de origem não está liberado no provedor.
O número de origem (no From ou no P-Asserted-Identity) não pertence à conta.
Destino bloqueado (internacional, 0900), conta suspensa ou sem crédito.
Bloqueio por ACL ou por fail2ban depois de muitas tentativas.
Onde olhar: leia a frase e o cabeçalho Warning, porque muitos provedores escrevem o motivo (“Invalid caller ID”, “IP not allowed”). Compare o From, o P-Asserted-Identity e o IP de origem com o que o provedor tem cadastrado.
404 Not Found
O usuário ou número pedido não existe no domínio do Request-URI. Causas prováveis:
Ramal inexistente ou digitado errado.
No trunk, número no formato errado: falta de DDD, de 0 ou de +55, ou rota inexistente no provedor.
Contexto ou plano de discagem errado no PABX que recebe a chamada.
Onde olhar: olhe o Request-URI do INVITE (a primeira linha), porque é ele que o servidor procura, não o To. No Asterisk, o log mostra “extension not found in context”; confira o context do endpoint.
408 Request Timeout
Não houve resposta final a tempo. Atenção ao detalhe: o 408 pode vir pela rede, enviado por um servidor que desistiu de esperar o destino, ou ser gerado pela sua própria pilha SIP, sem que nada tenha chegado, quando o temporizador da transação estoura (32 segundos com os valores padrão). Causas prováveis:
Destino desligado, fora de alcance ou com registro velho no registrador.
Firewall ou NAT descartando os pacotes, ou a resposta voltando para a porta errada.
Transporte ou porta errados (UDP de um lado, TCP do outro; 5060 versus 5061).
Onde olhar: procure no pcap se o 408 chegou pela rede. Se não chegou, foi o seu equipamento que desistiu, e o problema é que nada respondeu. Siga as retransmissões do INVITE: se só um lado aparece na captura, o pacote se perde no caminho. O caso real mais abaixo é exatamente esse.
480 Temporarily Unavailable
O destino existe, mas não pode atender agora. A frase varia bastante (“User not registered”, “No answer”) e às vezes vem com Retry-After indicando quando tentar de novo. Causas prováveis:
Ramal sem registro ativo no momento.
Não perturbe ligado ou tempo de toque esgotado.
Na operadora, aparelho desligado ou fora de área.
Onde olhar: confira se o destino está registrado (no Asterisk, pjsip show contacts; no FreeSWITCH, sofia status profile internal reg) e leia o cabeçalho Reason, que pode trazer a causa Q.850 original da rede de telefonia.
486 Busy Here
O destino foi encontrado, mas está ocupado e não aceita outra chamada naquele terminal. “Here” é importante: outros terminais do mesmo usuário podem estar livres. Quando nenhum está, o código é 600 Busy Everywhere. Causas prováveis:
Usuário em outra ligação, sem chamada em espera.
Recusa manual em alguns modelos de telefone.
Limite de canais do trunk ou do ramal atingido.
Onde olhar: se ninguém estava em ligação, o suspeito é o limite de chamadas simultâneas. No Asterisk, confira device_state_busy_at do endpoint; no provedor, o número de canais contratados.
487 Request Terminated
O INVITE foi encerrado por um CANCEL antes de ser atendido. Não é um erro: é a resposta normal quando quem liga desiste, ou quando um grupo de toque cancela os outros telefones porque um deles atendeu. Causas prováveis:
Quem ligou desligou antes do atendimento.
Forking: um terminal atendeu e o proxy cancelou os demais.
Tempo de toque esgotado no PABX de origem.
Onde olhar: para saber por que houve o CANCEL, leia o cabeçalho Reason do próprio CANCEL, por exemplo SIP;cause=200;text="Call completed elsewhere".
488 Not Acceptable Here
A oferta de mídia, descrita no SDP do INVITE, não serve para o destino. A sinalização está certa; o problema é o que se quer transmitir. Causas prováveis:
Nenhum codec em comum, por exemplo só G.729 de um lado e só G.711 do outro.
Um lado exige SRTP (RTP/SAVP) e o outro só aceita RTP comum (RTP/AVP).
Re-INVITE para fax T.38 em quem não suporta.
Onde olhar: compare as linhas m= e a=rtpmap do SDP da oferta com os codecs permitidos no destino e leia o cabeçalho Warning: os códigos 304, 305 e 370 dizem se o problema é tipo de mídia, formato ou banda.
503 Service Unavailable
O servidor está temporariamente sem condições de atender: sobrecarga, manutenção ou falta de rota. Pode trazer Retry-After, e o cliente deve tentar outro servidor do mesmo domínio, se houver. Causas prováveis:
Trunk sem canais livres ou sem registro com o provedor.
Gateway ou servidor sobrecarregado ou em manutenção.
Erro de DNS ou de transporte ao enviar para o próximo salto. Muitas pilhas geram um 503 local nesse caso.
Onde olhar: como no 408, veja se o 503 chegou pela rede ou foi gerado pelo seu equipamento. Confira se o trunk está registrado e se o destino responde a OPTIONS (o qualify do Asterisk faz isso periodicamente).
Caso real: a chamada sai do PABX e morre em 32 segundos
Um cenário que aparece toda semana em quem instala PABX atrás de roteador: as chamadas de saída pelo SIP trunk não completam. O telefone fica mudo por cerca de meio minuto e o log registra 408 Request Timeout. O provedor jura que está tudo certo do lado dele.
Os endereços abaixo são fictícios: o PABX está em 10.0.0.10, atrás de um roteador com NAT cujo IP público é 203.0.113.10, e o provedor atende em 198.51.100.20 (faixas de documentação do RFC 5737).
1. O que a captura mostra
Com o sngrep ou o Wireshark no PABX, aparece o INVITE saindo, depois o mesmo INVITE de novo, e de novo, em intervalos que dobram: 0,5 s, 1 s, 2 s, 4 s… Nenhuma resposta, nem um 100 Trying. Aos 32 segundos, a própria pilha SIP do PABX desiste e gera o 408. Ele não veio da rede.
Esse é o comportamento do RFC 3261 sobre UDP: o INVITE é retransmitido a partir de 500 ms (o T1), dobrando o intervalo, até o Timer B estourar em 64 × T1, ou seja, 32 segundos.
2. O INVITE que saiu
INVITE sip:+5511955550123@sip.example.net SIP/2.0
Via: SIP/2.0/UDP 10.0.0.10:5060;branch=z9hG4bK3f7a91c2
Max-Forwards: 70
From: "Recepcao" <sip:+551133330100@sip.example.net>;tag=as7d3e21
To: <sip:+5511955550123@sip.example.net>
Call-ID: 4b1c9e2a7d@10.0.0.10
CSeq: 102 INVITE
Contact: <sip:+551133330100@10.0.0.10:5060>
User-Agent: PBX-Exemplo
Content-Type: application/sdp
Content-Length: 191
v=0
o=- 5521 5521 IN IP4 10.0.0.10
s=-
c=IN IP4 10.0.0.10
t=0 0
m=audio 14012 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=sendrecvColando essa mensagem no analisador de mensagens SIP da EDCA, aparecem três avisos:
Via com IP privado 10.0.0.10 e sem received/rport. Se a mensagem atravessa NAT, as respostas podem não voltar.
Contact com IP privado. Mesmo que a chamada fosse atendida, ACK, BYE e re-INVITE iriam para um endereço inalcançável.
SDP anunciando mídia em IP privado. Atrás de NAT, isso dá áudio mudo ou de um lado só.
3. Por que a resposta se perde
Sobre UDP, o servidor responde para o IP de onde o pacote veio, mas para a porta escrita no Via (aqui, 5060). O roteador, ao fazer NAT, trocou a porta de origem do INVITE, digamos para 40123. O provedor manda o 100 Trying para 203.0.113.10:5060, onde o NAT não tem nenhum mapeamento aberto, e o pacote é descartado. O PABX nunca ouve nada.
4. A correção
Use rport (RFC 3581). Com
;rportno Via, o servidor responde para a porta de onde o pacote realmente veio, e a resposta atravessa o NAT.Informe ao PABX o endereço externo. No Asterisk (PJSIP), configure
external_signaling_address,external_media_addresselocal_netno transport; no FreeSWITCH,ext-sip-ipeext-rtp-ipno profile. Assim Via, Contact e SDP saem com o IP público.Desligue o SIP ALG do roteador. Ele tenta reescrever as mensagens e costuma piorar o problema.
Mantenha o NAT aberto. Para registros por UDP, use keep-alive (o
qualifydo Asterisk) com intervalo menor que o tempo de expiração do NAT.
Depois do ajuste, capture de novo: o 100 Trying chega em milissegundos, o 180 Ringing aparece e o áudio passa a fluir nos dois sentidos.
Checklist de troubleshooting
Capture a sinalização nos dois lados, se possível: sngrep, Wireshark,
pjsip set logger onousofia global siptrace on.Ache a primeira resposta final do INVITE (código 200 ou maior). 100, 180 e 183 são só andamento.
Descubra quem gerou a resposta: ela chegou pela rede ou foi criada pelo seu equipamento? Os cabeçalhos Server e User-Agent dizem quem respondeu.
Leia a frase, o Warning e o Reason. Muitos provedores explicam ali o motivo da recusa.
Compare o Request-URI, o From, o P-Asserted-Identity e o IP de origem com o que o provedor espera.
Procure IPs privados no Via, no Contact e no SDP sempre que houver NAT no caminho.
Anote o Call-ID, o horário e o código. É o que o suporte do provedor vai pedir.
Ferramentas gratuitas para o diagnóstico
A tabela de códigos SIP traz todos os códigos do registro da IANA, com causas, como depurar, a causa Q.850 e o filtro do Wireshark. O analisador de mensagens SIP explica cabeçalhos, aponta problemas de NAT e desenha a escada da chamada. Os dois rodam no seu navegador: nada do que você cola é enviado.
Se você opera SIP trunk, leia também MP 1.396: o que muda para quem opera PBX e SIP trunk. Com a autenticação de chamadas, o número de origem enviado pelo PABX ganha ainda mais importância, e recusas por número de origem inválido já costumam aparecer como 403.
Quer aprender a ler capturas SIP?
No curso Introdução ao SIP e Wireshark básico para VoIP você aprende a estrutura das mensagens, o fluxo de uma chamada e como abrir capturas reais no Wireshark. O curso Troubleshooting de Rede e SIP com Wireshark para VoIP está em breve.