Códigos de resposta SIP: como diagnosticar chamadas que não completam
Entenda o que respostas como 403, 404, 408, 480, 486, 488 e 503 realmente indicam e como localizar a falha entre PABX IP, SBC, tronco SIP, interconexão e rede de destino.
A resposta mostra como um elemento SIP tratou a solicitação, mas não identifica sozinha a causa-raiz.
É preciso descobrir se o código veio do PABX, SBC, operadora, gateway ou rede de destino.
Horário, Call-ID, número chamado, SDP, rota e mensagens anteriores completam a análise.
Quando uma chamada SIP não completa, o código de resposta costuma ser o primeiro dado consultado. Ele é indispensável, mas precisa ser interpretado dentro do fluxo de sinalização. Um 403 Forbidden, por exemplo, informa que um servidor entendeu a solicitação e decidiu recusá-la; não revela, isoladamente, se a recusa ocorreu por política do tronco, origem não autorizada, formato de numeração ou bloqueio aplicado mais adiante na rota.
Em ambientes corporativos, a mesma chamada pode atravessar PABX IP, SBC, proxies, plataforma da operadora, gateways e interconexões com redes STFC ou móveis. O diagnóstico correto depende de localizar qual elemento gerou a resposta e de correlacioná-la com as mensagens anteriores e posteriores do mesmo diálogo.
Como as respostas SIP se organizam
O SIP agrupa suas respostas por classes. O primeiro algarismo oferece uma leitura inicial do resultado, mas a análise operacional deve considerar o código completo e o método ao qual ele responde.
- 1xx — respostas provisórias: indicam que a solicitação foi recebida e continua em processamento. Exemplos frequentes são
100 Trying,180 Ringinge183 Session Progress. - 2xx — sucesso: informam que a solicitação foi aceita. Para um
INVITE, o resultado normalmente é200 OK, seguido doACK. - 3xx — redirecionamento: apontam outro local ou alternativa para alcançar o usuário.
- 4xx — falha associada à solicitação: incluem autenticação, permissão, endereço, disponibilidade e parâmetros não aceitos.
- 5xx — falha de servidor: indicam que um servidor não conseguiu processar uma solicitação aparentemente válida.
- 6xx — falha global: representam uma recusa que, em princípio, não depende apenas daquele servidor ou local específico.
Receber 200 OK e enviar ACK confirma o estabelecimento do diálogo SIP, mas a mídia RTP ainda pode falhar por NAT, firewall, endereço anunciado no SDP, roteamento, portas bloqueadas ou incompatibilidade de codecs.
Códigos mais úteis no diagnóstico corporativo
| Código | Significado | Leitura inicial | O que verificar |
|---|---|---|---|
| 401 | Unauthorized | O servidor de destino exige autenticação. | Usuário, senha, realm, nonce e novo envio com credenciais. Em registros SIP, o desafio pode fazer parte do fluxo normal. |
| 403 | Forbidden | O servidor entendeu a solicitação, mas recusou seu atendimento. | Permissões do tronco, IP autorizado, origem apresentada, bloqueios, política antifraude e destino permitido. Repetir a mesma requisição sem alteração tende a não resolver. |
| 404 | Not Found | O usuário ou domínio não foi localizado pelo servidor que respondeu. | Formato do número, domínio, Request-URI, plano de discagem, portabilidade e tabela de roteamento. |
| 407 | Proxy Authentication Required | Um proxy exige autenticação antes de liberar o acesso. | Credenciais configuradas para o proxy, realm e comportamento do PABX diante do desafio. |
| 408 | Request Timeout | Não foi possível produzir uma resposta dentro do tempo esperado. | Alcance do destino, DNS, conectividade, firewall, perda de pacotes, temporizadores e ausência de resposta de um próximo salto. |
| 480 | Temporarily Unavailable | O destino é conhecido, mas está temporariamente indisponível. | Registro do ramal, encaminhamento, modo não perturbe, cobertura, dispositivo desligado ou ausência de localização válida. |
| 486 | Busy Here | O destino foi alcançado, mas não pode aceitar outra chamada naquele momento. | Estado do ramal, chamadas simultâneas, filas, encaminhamentos, limites de canal e tratamento de ocupado. |
| 488 | Not Acceptable Here | A sessão foi recusada porque algum aspecto da oferta não foi aceito. | Codecs, SDP, DTMF, criptografia, perfil de mídia, endereços anunciados e compatibilidade entre os equipamentos. |
| 503 | Service Unavailable | O servidor está temporariamente incapaz de processar a solicitação. | Sobrecarga, manutenção, próximo salto indisponível, capacidade do tronco, failover e presença do cabeçalho Retry-After. |
Por que o mesmo código pode ter causas diferentes
Os códigos definem o resultado protocolar observado por um elemento SIP, não uma taxonomia universal de falhas de negócio. Operadoras, SBCs e plataformas podem aplicar políticas próprias para transformar eventos internos em respostas SIP. Além disso, gateways que interligam SIP e ISUP precisam mapear causas entre protocolos, o que pode reduzir ou alterar o nível de detalhe disponível no lado SIP.
Por isso, dois incidentes que terminam em 503 Service Unavailable podem ter origens distintas: indisponibilidade real do servidor, ausência de rota utilizável, falha em um próximo salto ou uma condição temporária de capacidade. O código delimita a investigação, mas o ponto de geração e o histórico da chamada determinam o próximo teste.
Sequência prática para investigar uma falha
- Identifique a transação: filtre os registros pelo Call-ID e confirme o horário, origem, destino e método que recebeu a resposta.
- Localize quem respondeu: examine Via, Record-Route, IPs de origem e destino e a posição da mensagem no fluxo.
- Leia a sequência completa: respostas provisórias, desafios de autenticação, CANCEL, ACK e retransmissões mudam a interpretação do código final.
- Compare a numeração: valide Request-URI, From, To, P-Asserted-Identity, prefixos, código de área, formato nacional ou internacional e regras de portabilidade.
- Revise o SDP quando houver mídia: confira codecs, endereços, portas, direção da mídia e atributos exigidos por cada lado.
- Correlacione os sistemas: confronte o trace do PABX com registros do SBC, CDRs e evidências da operadora antes de atribuir a falha a um único elemento.
Dados que devem acompanhar um chamado técnico
- Data, horário e fuso da tentativa.
- Número de origem e número de destino.
- Call-ID completo da sessão.
- Código SIP e endereço de quem respondeu.
- Fluxo SIP ou captura PCAP, quando disponível.
- Indicação de falha total, intermitente ou por rota.
- Exemplo de chamada bem-sucedida para comparação.
- Alterações recentes em PABX, SBC, firewall ou tronco.
Conclusão
Uma resposta SIP deve ser tratada como evidência de uma etapa do fluxo, e não como diagnóstico definitivo. A análise ganha precisão quando combina o significado normativo do código, o elemento que o gerou, a sequência completa da sinalização e o contexto da rota telefônica. Essa abordagem reduz tentativas por suposição e acelera a separação entre falhas de configuração, autenticação, numeração, capacidade, interoperabilidade e rede.
Transforme o código em uma investigação objetiva
Antes de alterar rotas ou credenciais, preserve o trace da chamada, identifique o ponto exato de geração da resposta e compare a sinalização com uma chamada válida. Esse conjunto de evidências torna a interação entre empresa, integrador e operadora muito mais eficiente.
