Códigos de resposta SIP: o guia completo de 1xx, 2xx, 3xx, 4xx, 5xx e 6xx

Toda chamada SIP termina em um dos aproximadamente trinta códigos de status, e o código é o sinal mais confiável que você tem sobre o que realmente aconteceu. Uma chamada que falha com 486 Busy Here diz algo completamente diferente de uma que falha com 503 Service Unavailable, mesmo que o chamador ouça o mesmo tom de ocupado rápido em ambos os casos. Ler o código é a primeira coisa que qualquer engenheiro de voz faz quando uma chamada não se completa, e a diferença entre adivinhar uma falha e encontrá-la geralmente se resume a saber o que cada código significa e qual comportamento ele aciona no restante da rede.

Este artigo é a referência para todo código de resposta SIP que você provavelmente encontrará em produção. Cobrimos as seis classes (1xx provisório, 2xx sucesso, 3xx redirecionamento, 4xx erro de cliente, 5xx erro de servidor, 6xx falha global), os códigos específicos dentro de cada classe, o comportamento de retransmissão e retentativa que cada um deve acionar, e como um Session Border Controller normaliza códigos de resposta entre fornecedores que discordam sobre qual código enviar. Para os fundamentos do protocolo, Fundamentos de sinalização SIP cobre os papéis, cabeçalhos e arquitetura.

As seis classes de códigos de resposta

Os códigos de resposta SIP seguem a mesma estrutura de seis classes do HTTP, definida na RFC 3261. O primeiro dígito identifica a classe, os dois dígitos restantes identificam o código específico dentro da classe. A classe é a peça mais importante porque controla como o restante da rede deve reagir: se deve continuar aguardando, tentar novamente por um caminho diferente, desistir completamente ou tratar a chamada como concluída.

1xx Provisional confirmam que a solicitação está sendo processada. Não são finais, não encerram a transação e não são confirmadas. O user agent do chamador para de retransmitir a solicitação quando um 1xx chega, mas a chamada ainda não está resolvida.

2xx Success indicam que a solicitação foi bem-sucedida. Para um INVITE, 2xx significa que a chamada foi atendida e um ACK deve seguir para completar o handshake de três vias. 2xx é a única classe que estabelece um diálogo.

3xx Redirection direcionam o chamador a tentar um URI diferente. A solicitação original não teve sucesso, mas a resposta carrega um cabeçalho Contact apontando para um local alternativo onde a chamada deve ser retentada.

4xx Client Failure indicam que a solicitação em si teve um problema que o chamador pode corrigir: sintaxe incorreta, autenticação ausente, um endpoint ocupado, um número que não existe. A solicitação não deve ser retentada sem alterações no mesmo destino.

5xx Server Failure indicam que a solicitação era sintaticamente válida, mas o servidor não conseguiu cumpri-la. Diferente de 4xx, a mesma solicitação pode ter sucesso contra um servidor diferente, então 5xx é a classe que tipicamente aciona o avanço de rota para um caminho secundário.

6xx Global Failure indicam que a solicitação não pode ser cumprida por nenhum servidor, em nenhum lugar. Um código 6xx interrompe tentativas de fork em proxies, encerra hunt groups paralelos e diz ao chamador para não tentar rotas alternativas.

Respostas provisórias 1xx

Respostas provisórias mantêm a transação SIP ativa enquanto a rede determina o que fazer em seguida. Na maioria dos casos não possuem corpo, nunca acionam ACK e servem principalmente para interromper a retransmissão e informar o chamador que algo está acontecendo. Uma chamada não pode ser concluída apenas com um 1xx; uma resposta final (2xx a 6xx) deve sempre seguir.

100 Trying é enviado pelo próximo hop SIP no momento em que aceita o INVITE para processamento. É estritamente hop-by-hop, nunca aparece na tela do chamador como um evento e existe por um único motivo: dizer ao user agent upstream para parar de retransmitir o INVITE enquanto o próximo hop faz seu trabalho. Se você não vê nenhum 100 Trying em um trace UDP, está diante de um problema de transporte antes de estar diante de um problema SIP.

180 Ringing é a resposta provisória ponta a ponta do endpoint de destino indicando que o destinatário está sendo alertado. Este é o código que faz o telefone do chamador reproduzir ringback local. Algumas operadoras e PBXs preferem gerar ringback elas mesmas, enviando 183 Session Progress com early media, o que permite injetar anúncios de rede (número indisponível, por favor aguarde) antes mesmo de a chamada ser atendida.

181 Call Is Being Forwarded é uma resposta provisória de cortesia indicando que a chamada foi redirecionada para um endpoint diferente. Raramente é usada em redes modernas porque o encaminhamento geralmente é tratado de forma transparente por redirecionamento 3xx ou por um SBC que reescreve o destino.

182 Queued informa ao chamador que o destino aceitou a chamada, mas a colocou em fila, tipicamente em um contact center onde todos os agentes estão ocupados. É uma forma de manter o diálogo ativo sem tocar enquanto o chamador aguarda.

183 Session Progress é a resposta provisória mais importante depois de 100 e 180. Indica progresso e, criticamente, pode carregar um corpo SDP que estabelece early media antes de a chamada ser atendida. Operadoras usam 183 com early media para reproduzir anúncios, tons de ringback ou atrasos pós-discagem in-band. Early media mal configurada é uma fonte comum de reclamações de áudio unidirecional, porque o chamador ouve o anúncio da operadora, mas o endpoint chamado nunca vê um caminho de mídia até o 200 OK.

Respostas provisórias confiáveis (PRACK, definido na RFC 3262) estendem esta classe com confirmações para que mensagens 1xx não se percam em links com perda. PRACK é obrigatório para algumas interconexões (notavelmente Microsoft Teams Direct Routing em certas configurações) e opcional em outros cenários.

Respostas de sucesso 2xx

Respostas de sucesso são curtas e consequentes. Um 2xx para um INVITE estabelece um diálogo, o que significa que o estado de roteamento deve ser mantido em cada intermediário até a chamada terminar com BYE.

200 OK é a resposta de sucesso para praticamente toda solicitação SIP. Para um INVITE, significa que a chamada foi atendida e o corpo da resposta contém a resposta SDP do destinatário que completa a negociação de mídia. Para um BYE, confirma que o diálogo foi encerrado. Para um CANCEL, confirma o cancelamento em si, separadamente do 487 Request Terminated que será enviado para o INVITE original. Para um OPTIONS, retorna os métodos e codecs suportados pelo respondente, que é como funciona o monitoramento keepalive SIP.

202 Accepted indica que a solicitação foi aceita para processamento, mas o resultado ainda não é conhecido. É mais comumente visto como a resposta a uma solicitação REFER durante transferência de chamada: o destinatário da transferência confirma que tentará a transferência e reportará o progresso através de mensagens NOTIFY dentro do diálogo.

O comportamento definidor de qualquer resposta 2xx a INVITE é que ela deve ser confirmada com ACK, e o ACK é ponta a ponta. Diferente de toda outra solicitação, o ACK para um 2xx viaja em sua própria transação e deve percorrer o mesmo caminho Record-Route do INVITE original. Esquecer que o Record-Route existe é uma fonte comum de tickets “a chamada atende mas cai imediatamente” na análise de trace.

Respostas de redirecionamento 3xx

Respostas de redirecionamento dizem ao chamador para tentar um URI diferente. A resposta inclui um ou mais cabeçalhos Contact nomeando o novo destino, e o user agent do chamador (ou o intermediário que gerencia o redirecionamento em seu nome) deve retentar a solicitação contra esses Contacts.

300 Multiple Choices lista vários destinos possíveis e permite ao chamador escolher. É raro em produção porque a maioria dos user agents SIP não apresenta múltiplas opções ao usuário; a chamada ou tem sucesso contra o primeiro Contact ou falha.

301 Moved Permanently indica que o destinatário tem um novo endereço permanente e os caches devem ser atualizados para refletir isso. É incomum em redes de voz, mas aparece em cenários de registro.

302 Moved Temporarily é de longe o 3xx mais útil em produção. O chamador deve retentar a solicitação contra o URI no cabeçalho Contact apenas para esta chamada, sem armazenar o novo endereço em cache. Integrações de prevenção de fraude e STIR/SHAKEN frequentemente retornam 302 para redirecionar uma chamada de um trunk group para outro com base em pontuação em tempo real. Sistemas de roteamento de menor custo usam 302 para direcionar uma chamada a uma operadora diferente sem que o endpoint de origem saiba que a rota mudou.

305 Use Proxy instrui o chamador a retentar através de um proxy específico. Quase nunca é visto em redes de operadoras em produção.

380 Alternative Service sugere que a chamada deve ser tentada através de um serviço completamente diferente (por exemplo, um protocolo diferente). É ocasionalmente usado quando um endpoint SIP não pode aceitar uma chamada, mas conhece um serviço relacionado que pode.

O ponto prático sobre respostas 3xx é que nem todo dispositivo as trata da mesma forma. Um proxy SIP ou B2BUA geralmente consome o 3xx ele mesmo, retenta a solicitação em nome do chamador e ou tem sucesso com um 200 OK ou retorna um código de falha diferente ao chamador original. Um user agent simples sem essa lógica simplesmente falhará a chamada quando não conseguir seguir o redirecionamento. Esta é uma das razões mais comuns pelas quais chamadas “funcionam do SBC mas falham do endpoint” durante testes.

Respostas de falha de cliente 4xx

A classe 4xx cobre tudo o que está errado com a solicitação em si. A solicitação não terá sucesso se retentada sem alterações no mesmo destino, mas pode ter sucesso se o chamador corrigir o problema (adicionar credenciais, corrigir o URI, alterar o método) ou escolher um destino diferente.

Autenticação e autorização

401 Unauthorized é enviado por um UAS que requer que o chamador se autentique antes de processar a solicitação. A resposta carrega um cabeçalho WWW-Authenticate com um realm e um nonce, e o chamador deve retentar a mesma solicitação com um cabeçalho Authorization contendo o digest. Provedores de SIP trunking e PBXs que requerem registro desafiam novos INVITEs com 401.

407 Proxy Authentication Required é o mesmo conceito, mas emitido por um proxy intermediário em vez do endpoint final. O desafio aparece em um cabeçalho Proxy-Authenticate e a resposta volta como Proxy-Authorization. A causa mais comum de “registro funciona mas chamadas falham” é uma incompatibilidade de realm no desafio 407 entre o SBC e o provedor upstream.

403 Forbidden significa que o chamador está identificado e autenticado, mas não tem permissão para fazer esta solicitação. Gatilhos comuns incluem chamadas de um IP que não está na ACL da operadora, tentativa de discar um número fora da faixa atribuída ou falha na atestação STIR/SHAKEN. 403 é final e o chamador não deve retentar sem alterar algo primeiro.

Problemas de endereço e método

400 Bad Request indica que a solicitação estava malformada: um cabeçalho obrigatório ausente, um URI sintaticamente inválido, um corpo não analisável. Algumas operadoras retornam 400 quando recebem um cabeçalho que consideram não conforme, que é uma das razões pelas quais a normalização SIP é uma função fundamental do SBC.

404 Not Found significa que o URI de destino não existe no servidor que respondeu. Em produção, 404 é sobrecarregado: um verdadeiro “número não existe” retorna 404, mas o mesmo acontece com uma falha de ACL em algumas plataformas, e alguns serviços de prevenção de fraude usam 404 para indicar “nenhuma fraude detectada, avance para o próximo caminho.” No ProSBC, o comportamento padrão de parar a chamada no 404 é comumente substituído por “continue call” especificamente para que os códigos de retorno de prevenção de fraude alimentem corretamente a lógica de rota.

405 Method Not Allowed indica que o respondente não suporta o método SIP solicitado. A resposta inclui um cabeçalho Allow listando os métodos suportados, o que é útil para diagnóstico. Um REGISTER enviado a um servidor que apenas aceita INVITE retornará 405 com Allow listando INVITE, ACK, BYE e CANCEL.

415 Unsupported Media Type geralmente significa que o corpo SDP ofereceu um codec ou tipo de mídia que o respondente não consegue processar. A resposta inclui um cabeçalho Accept listando o que seria aceitável, permitindo ao chamador tentar novamente com uma oferta SDP mais restrita.

Timeout e estado do endpoint

408 Request Timeout é retornado quando a rede manteve a solicitação por tempo suficiente para que qualquer resposta razoável já deveria ter chegado. É gerado por intermediários quando nenhuma resposta downstream é recebida dentro do intervalo do timer SIP (Timer B, tipicamente 32 segundos para UDP), e informa ao chamador que o destino estava inacessível por algum motivo não especificado.

410 Gone indica que o endereço de destino existia, mas não está mais permanentemente em serviço. Algumas operadoras usam este código em vez de 404 para distinguir “sabemos que este número funcionava” de “este número é desconhecido.”

480 Temporarily Unavailable é enviado pelo endpoint chamado quando não quer atender a chamada neste momento, mas o endereço é válido. É a resposta padrão quando um timer de não atendimento expira (o telefone tocou e tocou e tocou) e a chamada é abandonada antes de ser atendida. 480 significa que a chamada chegou ao endpoint e o endpoint a rejeitou por sua própria política, o que é diferente de 408 onde a chamada nunca chegou tão longe.

484 Address Incomplete informa ao chamador que o número discado parece ser uma discagem parcial. O chamador deve coletar mais dígitos e retentar. É em grande parte um legado da discagem enbloc em gateways TDM-para-SIP.

486 Busy Here é a resposta “estou em outra chamada” do endpoint chamado. O diálogo termina imediatamente e o user agent do chamador tipicamente reproduz um tom de ocupado. 486 é um código de endpoint único: o destinatário está ocupado, mas um endpoint diferente para o mesmo usuário (uma segunda linha, um celular gêmeo) ainda pode estar acessível.

487 Request Terminated é a resposta a um INVITE que foi cancelado antes de ser atendido. É a contraparte SIP de uma solicitação CANCEL: quando Alice desliga enquanto ainda ouve ringback, o lado de Bob envia um 200 OK para o CANCEL em si e um 487 para o INVITE original. Interpretar incorretamente 487 como uma chamada falha em vez de uma chamada abandonada é uma fonte comum de métricas ASR (Answer-Seizure Ratio) incorretas em análise de CDR bruto.

488 Not Acceptable Here indica que o endpoint chamado entendeu a solicitação, mas não pode aceitar a sessão como oferecida, quase sempre devido a um problema de SDP: uma lista de codecs incompatível, um tipo de mídia que o endpoint não suporta, uma faixa de portas que não pode usar. É a falha de negociação de codec mais frequentemente vista entre operadoras que executam ordens de codec padrão diferentes.

491 Request Pending lida com uma condição de corrida onde ambos os lados de um diálogo enviam um re-INVITE quase ao mesmo momento. O lado perdedor retorna 491, aguarda um intervalo aleatório curto e retenta.

Respostas de falha de servidor 5xx

A classe 5xx é a aliada do solucionador de problemas: significa que a solicitação em si estava correta, mas o respondente não conseguiu cumpri-la, o que implica fortemente que um servidor diferente pode ter sucesso. A maioria dos comportamentos de avanço de rota e failover em produção é acionada por códigos 5xx.

500 Server Internal Error é o código genérico “algo está errado comigo.” O respondente aceitou a solicitação, mas encontrou um problema que não consegue descrever mais especificamente. 500 persistente de uma única operadora geralmente aponta para uma falha de software no switch dessa operadora.

501 Not Implemented indica que o método da solicitação é reconhecido, mas o servidor não o implementa. Um REFER enviado a uma operadora que não suporta transferência de chamada retornará 501.

502 Bad Gateway significa que o servidor recebeu uma resposta inválida de um servidor downstream. Em uma cadeia de SBCs e proxies, 502 do upstream geralmente significa que o downstream retornou algo que não pôde ser analisado ou que violou o contrato.

503 Service Unavailable é o cavalo de batalha do failover. Informa ao chamador que o servidor está temporariamente sobrecarregado ou em manutenção e que a mesma solicitação deve ser retentada em outro lugar. A maioria dos rate-limiting do lado da operadora retorna 503 quando um limite de sessão é atingido, que é exatamente o sinal que o SBC do chamador precisa para avançar para um trunk de backup.

504 Server Time-out indica que o servidor não recebeu uma resposta oportuna de um servidor do qual dependia. É o equivalente em sistema encadeado do 408.

505 Version Not Supported indica que a versão SIP na linha de solicitação não é suportada. Efetivamente uma peça de museu: SIP 2.0 é a única versão implantada há duas décadas.

A razão pela qual códigos 5xx são importantes para o design de rotas é que quase sempre justificam avanço de rota. Um SBC corretamente configurado deve mapear respostas 5xx recebidas de qualquer operadora individual em uma decisão “tente a próxima rota”, enquanto respostas 4xx geralmente não devem avançar (a solicitação em si foi rejeitada, retentá-la contra uma operadora diferente raramente terá sucesso). A exceção é o caso do 404 sobrecarregado mencionado anteriormente.

Respostas de falha global 6xx

Uma resposta 6xx é a forma mais forte de “não” no SIP. Informa ao chamador que a solicitação não pode ser cumprida por nenhum servidor em nenhum local, então o avanço de rota e o forking paralelo devem parar. Em uma configuração de hunt group ou balanceamento de carga que normalmente tentaria vários destinos em sequência, um 6xx recebido de qualquer um deles encerra toda a busca.

600 Busy Everywhere significa que o usuário chamado está ocupado em todos os endpoints que registrou. Diferente de 486 Busy Here, que é por endpoint, 600 é por usuário. Um proxy que está fazendo fork de um INVITE para um telefone de mesa, um celular gêmeo e um softphone parará o fork no momento em que qualquer um deles retornar 600.

603 Decline indica que o destinatário rejeitou afirmativamente a chamada (pressionou o botão de rejeição). O chamador não deve retentar. 603 também é comumente usado por serviços de prevenção de fraude para indicar “esta chamada deve ser bloqueada”; nesse contexto, o SBC deve encerrar a chamada em vez de avançar para uma rota de backup. O padrão do ProSBC de “continue call” no 603 é explicitamente substituído em implantações integradas com prevenção de fraude, para que um 603 do serviço de pontuação interrompa corretamente a chamada.

604 Does Not Exist Anywhere informa ao chamador que o endereço de destino não está em serviço em nenhum lugar da rede que respondeu. É raro no SIP moderno porque 404 efetivamente absorveu seu caso de uso.

606 Not Acceptable é a contraparte de falha global do 488 Not Acceptable Here. Indica que a sessão descrita na solicitação não pode ser aceita por nenhum servidor, frequentemente porque o codec ou os parâmetros de sessão estão completamente fora do que a rede respondente suporta.

Na prática, respostas 6xx são mais raras que 4xx e 5xx. Quando você encontrar uma, trate-a como autoritativa: a solicitação não terá sucesso em nenhum caminho de retentativa.

Lendo códigos de resposta em um trace de produção

O comportamento de retransmissão e retentativa vinculado a cada classe é o que determina como uma chamada SIP realmente se comporta em produção. Memorizar os códigos é a parte fácil; prever como o restante da rede reage a cada um é a habilidade mais difícil, e é a diferença entre solucionar problemas e adivinhar.

No transporte UDP, o user agent do chamador retransmite o INVITE em um backoff exponencial (Timer A, começando em 500ms) até que uma resposta provisória ou final chegue. O 100 Trying que o próximo hop envia de volta é o que para a retransmissão. Se você vê o mesmo INVITE sete vezes em um trace sem resposta, está diante de um problema de acessibilidade de transporte, não de um problema SIP; o próximo hop nem está processando a solicitação. Transporte TCP e TLS não retransmitem porque a camada de transporte lida com a entrega, então uma chamada travada em TCP parece completamente diferente em um trace de uma chamada travada em UDP.

Respostas finais a um INVITE sempre requerem ACK. A forma do ACK depende da resposta: um ACK para um 2xx é ponta a ponta e viaja em sua própria transação, enquanto um ACK para 3xx a 6xx é hop-by-hop e faz parte da transação INVITE original. Um ACK ausente após 200 OK é a razão mais comum para sintomas de “a chamada atende mas cai após alguns segundos”, porque o endpoint chamado encerrará o diálogo quando suas retransmissões do 200 OK não forem confirmadas.

Respostas provisórias nunca requerem ACK. Um 1xx que fica sem resposta não causa nenhum dano por si só, mas um 1xx seguido de silêncio (nenhuma resposta final, nenhuma provisória adicional) é um forte sinal de que algo downstream parou de processar. PRACK é a exceção em ambientes que o habilitam: um 1xx confiável (um 1xx com cabeçalho Require: 100rel) precisa ser confirmado com PRACK.

A interação entre 4xx e 5xx determina o avanço de rota. Um script de roteamento de SBC bem projetado trata 5xx como “tente a próxima rota”, trata a maioria dos 4xx como “pare, esta chamada não pode ter sucesso” e aplica substituições por código para os casos confusos do mundo real (404 usado como liberação de fraude, 503 usado como rejeição de capacidade de uma operadora saudável, 603 usado para bloquear uma chamada fraudulenta). Acertar essas substituições é o que faz a diferença entre uma implantação com 5% de chamadas falhadas-mas-retentáveis e uma com 0,1%.

Como um SBC normaliza códigos de resposta entre dialetos

Cada operadora e cada fornecedor de PBX retorna códigos de resposta ligeiramente diferentes para a mesma condição subjacente. Uma operadora envia 503 quando um limite de sessão é atingido; outra envia 486. Um PBX retorna 480 quando um usuário está desconectado; outro retorna 404. Os endpoints downstream dessas inconsistências geralmente não são inteligentes o suficiente para tratá-los como equivalentes, então chamadas falham que deveriam ter avançado, e chamadas que deveriam ter parado avançam e acumulam minutos contra destinos fraudulentos.

Esta é a parte da interoperabilidade SIP onde um SBC prova seu valor. Um SBC B2BUA como o ProSBC vê a resposta na perna de entrada e gera uma resposta nova na perna de saída, o que significa que pode reescrever o código, alterar qual decisão de roteamento ele aciona e adicionar ou remover cabeçalhos Reason conforme necessário. O recurso Reason Cause Mapping permite que cada NAP (trunk group) substitua o comportamento padrão por código: 404 pode ser configurado para “continue call” para que a resposta de liberação de um serviço de pontuação de fraude avance para a próxima rota; 603 pode ser configurado para “stop call” para que a resposta de bloqueio do mesmo serviço realmente pare; 302 pode ser configurado para “process call routing” para que um redirecionamento de roteamento de menor custo seja consumido pelo SBC em vez de encaminhado upstream; 503 pode ser configurado para “continue call” em uma primária saudável para que uma rejeição de capacidade faça failover de forma limpa.

O mesmo mecanismo trata a tradução de dialetos de fornecedores na direção mais simples. Um 503 Service Unavailable downstream pode ser traduzido para um 486 Busy Here upstream quando o sistema upstream lida melhor com 486. Um 488 Not Acceptable Here pode ser normalizado para um 415 Unsupported Media Type quando um PBX mais antigo espera 415. Um X-header proprietário de fornecedor carregando informações adicionais de causa pode ser removido, ou, inversamente, um cabeçalho Reason com um valor de causa Q.850 pode ser injetado ao fazer bridge de um gateway TDM para que a operadora SIP upstream veja o contexto completo de falha PSTN.

Este mesmo controle sobre códigos de resposta é o que torna a manipulação de cabeçalhos SIP e a arquitetura B2BUA a resposta certa para interconexões multi-fornecedor, Microsoft Teams Direct Routing, e qualquer ambiente onde três ou mais operadoras, dois ou mais fornecedores de PBX e uma plataforma UCaaS precisam se conectar pelo mesmo edge.

Referência rápida de solução de problemas

Os códigos que você verá com mais frequência na prática, o que realmente significam em produção e a primeira coisa a verificar quando cada um aparece:

401 / 407 (desafio de autenticação) significa que a solicitação precisa de credenciais. Se a retentativa com as credenciais ainda falhar, verifique se o realm no desafio corresponde ao que o chamador está configurado para autenticar, e se o algoritmo de digest SIP (MD5 ou SHA-256) é suportado em ambos os lados.

403 Forbidden após autenticação significa que uma ACL ou política está bloqueando a chamada. Verifique o IP de origem contra a ACL no respondente e verifique a atestação STIR/SHAKEN se a operadora exige níveis mínimos de atestação.

404 Not Found significa que o número não existe ou que o respondente está usando 404 como sinal de “sem correspondência”. Confirme que o número está provisionado e, se o respondente é um serviço de pontuação de fraude, que 404 está mapeado para “continue call” no SBC.

408 Request Timeout significa que nada downstream respondeu. Verifique a acessibilidade de transporte primeiro (a porta UDP/5060 está realmente aberta?) antes de assumir um problema em nível SIP.

480 Temporarily Unavailable significa que o endpoint existe e está recusando a chamada neste momento. Verifique o timer de não atendimento, o estado de não perturbe ou o status de registro do destino.

486 Busy Here significa que o endpoint chamado está em outra chamada. Se 486 aparece em escala em um único trunk, suspeite que limites de sessão estão sendo atingidos e a operadora está retornando 486 em vez do mais preciso 503.

487 Request Terminated não é uma falha: é a contraparte de um CANCEL. Filtre 487 das métricas de falha; reporte-o em chamadas abandonadas.

488 Not Acceptable Here é um problema de codec ou SDP. Compare a lista de codecs oferecidos com os codecs suportados pelo respondente e verifique se o SBC está forçando um codec que o downstream não suporta.

503 Service Unavailable na borda de um trunk quase sempre significa que a operadora está sobrecarregada ou fazendo rate-limiting. Confirme que o comportamento de avanço de rota do SBC está configurado para fazer failover no 503; se não estiver, esta é sua primeira correção.

603 Decline de um serviço de pontuação de fraude é uma decisão de bloqueio. Confirme que o Reason Cause Mapping do SBC para 603 está configurado como “stop call” nesse NAP para que o bloqueio realmente encerre a chamada.

Conclusão

Os códigos de resposta SIP são um vocabulário pequeno e estruturado que carrega praticamente todo sinal que um engenheiro de voz precisa para ler uma chamada. Seis classes, menos de trinta códigos em uso regular de produção e um conjunto consistente de regras sobre quais códigos acionam retransmissão, quais requerem ACK, quais justificam avanço de rota e quais encerram a chamada definitivamente. Os códigos em si são estáveis; o que varia entre implantações é qual código exato cada fornecedor retorna para qual condição subjacente, e essa variação é precisamente onde o mapeamento de códigos de resposta de um SBC faz o trabalho de fazer uma rede multi-fornecedor se comportar como um único sistema coerente.

Para engenheiros de voz construindo interconexões de SIP trunking, implantando Teams Direct Routing, ou solucionando problemas de chamadas falhas em um ambiente multi-operadora, fluência nestes códigos (o que cada um significa, qual comportamento aciona, quando uma operadora está usando-o idiomaticamente) é a base sobre a qual todo o resto é construído. O passo a passo do fluxo de chamada SIP complementar mostra os códigos no contexto de um trace completo; este artigo é o dicionário que você mantém aberto ao lado dele.