A requisição está mal formada: erro de sintaxe, cabeçalho obrigatório faltando ou valor inválido.
Causas, como depurar e proxies
Causas prováveis
- Cabeçalho obrigatório ausente (Via, From, To, Call-ID, CSeq, Max-Forwards).
- SDP ou cabeçalho alterado por um ALG de roteador (SIP ALG) e corrompido.
- Content-Length que não bate com o corpo, comum em mensagens fragmentadas por UDP.
Como depurar
- A frase da resposta ou o cabeçalho Warning costumam dizer qual campo está errado (por exemplo, "Missing CSeq").
- Compare a mensagem que saiu de um lado com a que chegou do outro: se mudou no caminho, desligue o SIP ALG do roteador.
- No Kamailio, sanity_check() do módulo sanity mostra o motivo no log.
- No Wireshark, filtre por sip.Status-Code == 400 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
41 Temporary failure
O destino final (registrador ou UA) exige autenticação. A resposta traz WWW-Authenticate com o desafio (realm e nonce); o cliente deve repetir a requisição com Authorization.
Causas, como depurar e proxies
Causas prováveis
- Normal no primeiro REGISTER ou INVITE: o 401 é o desafio, e a requisição seguinte deve passar.
- Se o 401 se repete depois do Authorization: usuário, senha ou realm errados.
- Nonce expirado ou relógio errado, gerando novo desafio com stale=true.
Como depurar
- Ver um 401 sozinho não é erro. Erro é a segunda tentativa, com Authorization, também receber 401 ou 403.
- Confira o username e o realm do Authorization contra o que o servidor espera (auth user pode ser diferente do ramal).
- No Asterisk, pjsip set logger on e a mensagem "Failed to authenticate"; no FreeSWITCH, sofia global siptrace on.
- No Wireshark, filtre por sip.Status-Code == 401 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. Num forking, o proxy junta os desafios WWW-Authenticate de todas as ramificações numa única resposta.
Causa Q.850 em gateways (RFC 3398)
21 Call rejected
Reservado para uso futuro pelo RFC 3261. Alguns provedores usam para indicar falta de crédito.
Causas, como depurar e proxies
Causas prováveis
- Conta pré-paga sem saldo, em provedores que adotam o código.
Como depurar
- Verifique saldo ou bloqueio na conta do provedor; a frase costuma explicar.
- No Wireshark, filtre por sip.Status-Code == 402 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
21 Call rejected
O servidor entendeu a requisição e se recusa a atendê-la. Autenticar de novo não resolve.
Causas, como depurar e proxies
Causas prováveis
- Trunk: IP de origem não liberado no provedor, ou número de origem (From/P-Asserted-Identity) não pertence à conta.
- Destino bloqueado (internacional, 0900) ou conta suspensa.
- Credencial certa mas sem permissão, ou bloqueio por ACL e fail2ban.
Como depurar
- Leia a frase e o Warning: muitos provedores dizem o motivo ("Invalid caller ID", "IP not allowed").
- Compare From, P-Asserted-Identity e o IP de origem com o que o provedor cadastrou.
- No Asterisk, confira permit/deny e identify do endpoint; no Kamailio, os módulos permissions e pike.
- No Wireshark, filtre por sip.Status-Code == 403 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
21 Call rejected
O usuário ou número pedido não existe no domínio do Request-URI.
Causas, como depurar e proxies
Causas prováveis
- Ramal não registrado ou inexistente.
- Trunk: formato do número errado (falta de DDD, 0, +55) ou rota inexistente no provedor.
- Contexto ou dialplan errado no PABX que recebe a chamada.
Como depurar
- Olhe o Request-URI do INVITE: é ele que o servidor procura, não o To.
- No Asterisk, o log mostra "extension not found in context"; confira o context do endpoint. No FreeSWITCH, o dialplan XML; no Kamailio, lookup("location").
- No Wireshark, filtre por sip.Status-Code == 404 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
1 Unallocated number
O método é conhecido, mas não é permitido para este endereço. A resposta deve trazer o cabeçalho Allow com os métodos aceitos.
Causas, como depurar e proxies
Causas prováveis
- Enviar SUBSCRIBE, MESSAGE ou REFER a um servidor que não aceita esses métodos.
- REGISTER enviado a um proxy que não é registrador.
Como depurar
- Leia o Allow da resposta.
- No Wireshark, filtre por sip.Status-Code == 405 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
63 Service or option unavailable
O recurso só consegue responder com conteúdo que não está na lista Accept da requisição.
Causas, como depurar e proxies
Causas prováveis
- Cabeçalho Accept restrito demais, por exemplo em SUBSCRIBE de presença.
Como depurar
- Compare o Accept da requisição com os formatos que o servidor oferece.
- No Wireshark, filtre por sip.Status-Code == 406 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
79 Service or option not implemented
407 Proxy Authentication Required
#Igual ao 401, mas quem exige autenticação é um proxy no caminho. A resposta traz Proxy-Authenticate e o cliente repete com Proxy-Authorization.
Causas, como depurar e proxies
Causas prováveis
- Normal no primeiro INVITE para provedores e PABX que autenticam chamadas.
- Repetido depois da resposta: senha, usuário ou realm errados.
Como depurar
- Como no 401, só é erro se a segunda tentativa (com Proxy-Authorization) também falhar.
- O ACK do 407 é obrigatório e vai na mesma transação; o INVITE seguinte tem o mesmo Call-ID e CSeq maior.
- No Kamailio, proxy_challenge() (módulo auth) e proxy_authorize() (módulo auth_db).
- No Wireshark, filtre por sip.Status-Code == 407 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. Normalmente gerado pelo próprio proxy. Num forking, o proxy junta os Proxy-Authenticate de todas as ramificações.
Causa Q.850 em gateways (RFC 3398)
21 Call rejected
Não houve resposta final a tempo. Pode vir do servidor (o destino não respondeu) ou ser gerada localmente pela pilha SIP, sem nada chegar pela rede, quando o temporizador da transação (Timer B ou F, 32 s com T1 padrão) estoura.
Causas, como depurar e proxies
Causas prováveis
- Destino desligado, fora de alcance ou com registro velho no registrador.
- Firewall ou NAT descartando os pacotes; resposta voltando para porta errada.
- Proxy com Timer C estourado numa ramificação sem resposta.
Como depurar
- Procure no pcap se o 408 veio pela rede. Se não veio, foi a sua própria pilha que desistiu: o problema é que nada respondeu.
- Siga as retransmissões do INVITE (intervalos de 0,5 s, 1 s, 2 s...). Se só um lado aparece no trace, o pacote se perde no caminho.
- Em registros por UDP atrás de NAT, use keep-alive (qualify no Asterisk, NAT ping no Kamailio) para manter o mapeamento aberto.
- No Wireshark, filtre por sip.Status-Code == 408 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy gera 408 para a ramificação quando o Timer C (mais de 3 minutos) estoura sem resposta final; se só houve provisória, ele manda CANCEL.
Causa Q.850 em gateways (RFC 3398)
102 Recovery on timer expiry
O recurso existia, mas não está mais disponível, e não há endereço novo conhecido.
Causas, como depurar e proxies
Causas prováveis
- Número desativado ou portado sem redirecionamento.
Como depurar
- Use 404 quando não se sabe se o número existiu; 410 diz que existiu e foi retirado.
- No Wireshark, filtre por sip.Status-Code == 410 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
22 Number changed
412 Conditional Request Failed
#Um PUBLISH condicional falhou: a etag enviada em SIP-If-Match não corresponde a nenhum estado publicado (expirou ou é desconhecida).
Causas, como depurar e proxies
Causas prováveis
- Refresh de PUBLISH depois de a publicação já ter expirado no servidor de presença.
Como depurar
- Compare o SIP-If-Match com o SIP-ETag da última resposta 200 ao PUBLISH. A correção é publicar de novo sem SIP-If-Match.
- No Wireshark, filtre por sip.Status-Code == 412 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
413 Request Entity Too Large
#O corpo da requisição é maior do que o servidor aceita.
Causas, como depurar e proxies
Causas prováveis
- SDP enorme com muitos codecs e candidatos ICE.
- Corpos multipart grandes (SIP-I, ISUP encapsulado).
Como depurar
- Veja se há Retry-After: indica condição temporária.
- Reduza a lista de codecs oferecidos.
- No Wireshark, filtre por sip.Status-Code == 413 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
127 Interworking, unspecified
414 Request-URI Too Long
#O Request-URI é maior do que o servidor consegue interpretar.
Causas, como depurar e proxies
Causas prováveis
- Parâmetros demais adicionados ao URI por algum elemento do caminho.
Como depurar
- Copie o Request-URI do INVITE e veja o que está sendo acrescentado a cada salto.
- No Wireshark, filtre por sip.Status-Code == 414 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
127 Interworking, unspecified
415 Unsupported Media Type
#O tipo do corpo (Content-Type) ou a codificação (Content-Encoding) não é suportado. A resposta deve listar o que é aceito em Accept, Accept-Encoding ou Accept-Language.
Causas, como depurar e proxies
Causas prováveis
- Corpo multipart/mixed ou application/isup para quem só entende application/sdp.
- MESSAGE com tipo de conteúdo não suportado.
Como depurar
- Leia o Accept da resposta e compare com o Content-Type enviado.
- No Wireshark, filtre por sip.Status-Code == 415 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
79 Service or option not implemented
416 Unsupported URI Scheme
#O esquema do Request-URI (sips:, tel:, outro) não é suportado pelo servidor.
Causas, como depurar e proxies
Causas prováveis
- Mandar sips: ou tel: para um servidor que só aceita sip:.
Como depurar
- Confira o início do Request-URI e a configuração de transporte e TLS do destino.
- No Wireshark, filtre por sip.Status-Code == 416 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
127 Interworking, unspecified
417 Unknown Resource-Priority
#A requisição exige tratamento de prioridade (Require: resource-priority), mas o servidor não entende o namespace ou o valor do cabeçalho Resource-Priority.
Causas, como depurar e proxies
Causas prováveis
- Chamadas de prioridade (governo, emergência) passando por equipamento sem suporte ao namespace usado.
Como depurar
- A resposta pode trazer Accept-Resource-Priority com os valores aceitos.
- No Wireshark, filtre por sip.Status-Code == 417 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
O cliente exigiu uma extensão (em Require ou Proxy-Require) que o servidor não suporta. A resposta lista as não suportadas no cabeçalho Unsupported.
Causas, como depurar e proxies
Causas prováveis
- Require: 100rel, timer ou outra extensão enviada a quem não a implementa.
Como depurar
- Leia o Unsupported da resposta. Em vez de exigir (Require), anuncie a extensão em Supported.
- No Asterisk, opções como 100rel e timers do endpoint controlam isso.
- No Wireshark, filtre por sip.Status-Code == 420 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
127 Interworking, unspecified
O servidor só atende se o cliente usar uma extensão, listada no Require da resposta.
Causas, como depurar e proxies
Causas prováveis
- Servidor que exige 100rel (PRACK) ou timer (sessão com refresh) e o cliente não declarou suporte.
Como depurar
- Habilite no cliente a extensão pedida no Require e declare-a em Supported.
- No Wireshark, filtre por sip.Status-Code == 421 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
127 Interworking, unspecified
422 Session Interval Too Small
#O intervalo de sessão (Session-Expires) pedido é menor que o mínimo do servidor. A resposta traz Min-SE com o valor mínimo.
Causas, como depurar e proxies
Causas prováveis
- Session-Expires configurado baixo demais (abaixo de 90 s, o mínimo do RFC 4028, ou do valor do provedor).
Como depurar
- Leia o Min-SE da resposta e reenvie com Session-Expires igual ou maior.
- No Asterisk, timers_min_se e timers_sess_expires do endpoint.
- No Wireshark, filtre por sip.Status-Code == 422 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
O tempo de expiração pedido (no REGISTER ou SUBSCRIBE) é curto demais. A resposta traz Min-Expires.
Causas, como depurar e proxies
Causas prováveis
- Telefone configurado para registrar a cada poucos segundos para manter o NAT aberto.
Como depurar
- Leia o Min-Expires e ajuste o expires do cliente. Para NAT, prefira keep-alive a registros curtos.
- No Asterisk, minimum_expiration do AOR.
- No Wireshark, filtre por sip.Status-Code == 423 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
127 Interworking, unspecified
424 Bad Location Information
#A informação de localização enviada (cabeçalho Geolocation ou corpo PIDF-LO) está mal formada ou não satisfaz o servidor.
Causas, como depurar e proxies
Causas prováveis
- Chamadas de emergência com localização inválida ou ilegível.
Como depurar
- O cabeçalho Geolocation-Error da resposta traz o código e o motivo.
- No Wireshark, filtre por sip.Status-Code == 424 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Rejeita um alerta de chamada de emergência não interativa (mensagem CAP) tão mal formado que não é possível decidir que resposta dar a ele.
Causas, como depurar e proxies
Causas prováveis
- Sensores ou sistemas automáticos enviando alerta CAP inválido a um centro de emergência.
Como depurar
- O cabeçalho AlertMsg-Error da resposta detalha o problema.
- No Wireshark, filtre por sip.Status-Code == 425 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
O servidor exige o cabeçalho Identity (assinatura da identidade de quem liga, base do STIR/SHAKEN) e ele não veio ou não está num formato suportado.
Causas, como depurar e proxies
Causas prováveis
- Rede que só aceita chamadas assinadas e o originador não assina.
Como depurar
- Confira se o serviço de autenticação (que assina) está ativo e se o Identity sai na chamada.
- No Wireshark, filtre por sip.Status-Code == 428 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
429 Provide Referrer Identity
#O destino de uma REFER (transferência) exige a identidade de quem transferiu num Referred-By válido e assinado, e ele não veio.
Causas, como depurar e proxies
Causas prováveis
- Transferência entre domínios com política de segurança mais rígida.
Como depurar
- Veja o Referred-By da REFER e do INVITE gerado.
- No Wireshark, filtre por sip.Status-Code == 429 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
No mecanismo SIP Outbound, o proxy de borda não consegue mais usar a conexão (flow) com o UA. A resposta vai para o proxy ou registrador anterior, que pode tentar outro flow.
Causas, como depurar e proxies
Causas prováveis
- Conexão TCP ou TLS com o telefone caiu e o UA ainda não se registrou de novo.
Como depurar
- Procure o parâmetro reg-id e o +sip.instance no REGISTER e o ob no Contact.
- No Wireshark, filtre por sip.Status-Code == 430 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. Não deve chegar ao UA: é tratado pelo proxy que recebe, tentando outro flow do mesmo usuário.
433 Anonymity Disallowed
#O destino recusa chamadas anônimas (sem identificação de quem liga).
Causas, como depurar e proxies
Causas prováveis
- Chamador com Privacy: id ou From anonymous para quem bloqueia chamadas anônimas.
Como depurar
- Confira From, P-Asserted-Identity e o cabeçalho Privacy enviados.
- No Wireshark, filtre por sip.Status-Code == 433 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
O serviço de verificação não conseguiu obter a credencial (certificado) indicada no parâmetro info do cabeçalho Identity.
Causas, como depurar e proxies
Causas prováveis
- URL do certificado inacessível, fora do ar ou com erro de DNS.
Como depurar
- Copie a URL do parâmetro info e teste o acesso a partir do verificador.
- No Wireshark, filtre por sip.Status-Code == 436 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
437 Unsupported Credential
#O verificador obteve a credencial do Identity, mas não a aceita (autoridade certificadora não confiável, algoritmo não suportado). Antes se chamava "Unsupported Certificate".
Causas, como depurar e proxies
Causas prováveis
- Certificado emitido por CA que o verificador não confia.
Como depurar
- Confira a cadeia do certificado e o algoritmo da assinatura do PASSporT.
- No Wireshark, filtre por sip.Status-Code == 437 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
438 Invalid Identity Header
#Nenhum cabeçalho Identity da requisição tem uma assinatura válida.
Causas, como depurar e proxies
Causas prováveis
- Assinatura quebrada porque algum elemento do caminho alterou From, To ou Date.
- Tentativa de falsificar o número de origem.
Como depurar
- Compare os campos assinados (origem, destino, data) com os que chegaram. Um SBC reescrevendo o número quebra a assinatura.
- No Wireshark, filtre por sip.Status-Code == 438 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
439 First Hop Lacks Outbound Support
#O registrador suporta SIP Outbound, mas o primeiro proxy por onde o UA está se registrando não suporta.
Causas, como depurar e proxies
Causas prováveis
- UA com outbound ativado (reg-id e Supported: outbound) atrás de um proxy de borda sem suporte.
Como depurar
- O UA pode registrar de novo sem outbound ou por outro proxy de saída.
- No Wireshark, filtre por sip.Status-Code == 439 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
440 Max-Breadth Exceeded
#O proxy não pode fazer forking porque o limite de ramificações paralelas (cabeçalho Max-Breadth) acabou.
Causas, como depurar e proxies
Causas prováveis
- Forking em cascata entre vários proxies; proteção contra amplificação.
Como depurar
- Siga o valor de Max-Breadth a cada salto e revise as regras de forking.
- No Wireshark, filtre por sip.Status-Code == 440 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Um INFO chegou com um Info Package que o destino não aceita na sessão. A resposta traz Recv-Info com os pacotes aceitos.
Causas, como depurar e proxies
Causas prováveis
- DTMF por SIP INFO enviado a quem não negociou esse pacote.
Como depurar
- Compare o Info-Package do INFO com o Recv-Info trocado no INVITE e na resposta.
- Prefira DTMF por RFC 4733 (telephone-event) quando os dois lados suportam.
- No Wireshark, filtre por sip.Status-Code == 469 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
O relay (por exemplo, uma lista de distribuição) precisa do consentimento do destinatário antes de encaminhar. A resposta traz Permission-Missing com os destinos sem permissão.
Causas, como depurar e proxies
Causas prováveis
- Serviços de lista ou conferência que aplicam o framework de consentimento contra spam.
Como depurar
- Leia Permission-Missing para saber quais destinos ainda não autorizaram.
- No Wireshark, filtre por sip.Status-Code == 470 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
480 Temporarily Unavailable
#O destino existe mas não pode atender agora: desligado, não registrado, em não perturbe ou sem responder. A frase pode variar ("User not registered", "No answer") e o Retry-After pode indicar quando tentar.
Causas, como depurar e proxies
Causas prováveis
- Ramal sem registro ativo no momento.
- Não perturbe (DND) ou tempo de toque esgotado.
- Em operadoras, número fora de área ou aparelho desligado.
Como depurar
- Leia a frase e o cabeçalho Reason (RFC 3326), que pode trazer a causa Q.850 original da rede.
- Confira se o destino está registrado: no Asterisk, pjsip show contacts; no FreeSWITCH, sofia status profile internal reg; no Kamailio, kamctl ul show.
- No Wireshark, filtre por sip.Status-Code == 480 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
18 No user responding
481 Call/Transaction Does Not Exist
#A requisição faz parte de um diálogo ou transação que o destino não conhece. Típico de BYE, re-INVITE ou CANCEL que não casam com nada.
Causas, como depurar e proxies
Causas prováveis
- BYE ou re-INVITE com Call-ID, From-tag ou To-tag diferentes dos do diálogo (algum elemento reescreveu os cabeçalhos).
- CANCEL que chegou depois de a transação do INVITE já ter acabado.
- Um lado reiniciou ou o diálogo expirou (session timer) e o outro continua mandando requisições.
Como depurar
- Compare Call-ID, From-tag e To-tag do BYE com os do INVITE e do 200. No Wireshark, filtre sip.Call-ID == "valor".
- Confira se o BYE foi para o Contact e pela rota (Record-Route) certos.
- Num CANCEL, o Via branch tem de ser igual ao do INVITE.
- No Wireshark, filtre por sip.Status-Code == 481 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
41 Temporary failure
O servidor percebeu que a requisição voltou a ele (laço de roteamento).
Causas, como depurar e proxies
Causas prováveis
- Duas rotas apontando uma para a outra (PABX manda para o provedor, que devolve ao PABX).
Como depurar
- Leia os Via da requisição: o mesmo endereço aparecendo duas vezes mostra o laço.
- Revise as rotas de saída e de entrada dos dois lados.
- No Wireshark, filtre por sip.Status-Code == 482 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
25 Exchange routing error
O Max-Forwards chegou a zero antes do destino: a requisição passou por saltos demais.
Causas, como depurar e proxies
Causas prováveis
- Laço de roteamento que o servidor não detectou como 482.
- Max-Forwards inicial baixo demais.
Como depurar
- Conte os Via e veja o Max-Forwards inicial (o padrão é 70).
- No Wireshark, filtre por sip.Status-Code == 483 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
25 Exchange routing error
O número ou endereço está incompleto. Usado em discagem sobreposta (overlap): o servidor espera mais dígitos.
Causas, como depurar e proxies
Causas prováveis
- Número discado sem todos os dígitos.
- Plano de numeração do PABX esperando mais dígitos.
Como depurar
- Confira o Request-URI e o padrão do dialplan que deveria casar com ele.
- No Wireshark, filtre por sip.Status-Code == 484 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
28 Invalid number format
O endereço é ambíguo: casa com mais de um destino. A resposta pode listar as opções no Contact.
Causas, como depurar e proxies
Causas prováveis
- Busca por nome ("joao@empresa") com vários usuários possíveis.
Como depurar
- Leia os Contact e use um endereço mais específico.
- No Wireshark, filtre por sip.Status-Code == 485 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
1 Unallocated number
O destino foi contatado, mas está ocupado e não aceita outra chamada neste terminal. Pode haver outros terminais do mesmo usuário livres (compare com 600).
Causas, como depurar e proxies
Causas prováveis
- Usuário em outra ligação sem chamada em espera.
- Recusa manual em alguns telefones.
- Limite de canais do trunk ou do ramal atingido.
Como depurar
- Confira o limite de chamadas do ramal ou do trunk (no Asterisk, device_state_busy_at; no FreeSWITCH, limit).
- Num forking, o 486 de um terminal não impede que outro atenda.
- No Wireshark, filtre por sip.Status-Code == 486 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
17 User busy
O INVITE foi encerrado por um CANCEL (ou BYE) antes de ser atendido. É a resposta normal quando quem liga desiste.
Causas, como depurar e proxies
Causas prováveis
- Quem ligou desligou antes do atendimento.
- Proxy com forking cancelou as outras ramificações porque uma atendeu.
- Tempo de toque esgotado no PABX de origem.
Como depurar
- Não é erro por si só. Para saber por que houve CANCEL, leia o Reason do CANCEL (por exemplo, SIP;cause=200;text="Call completed elsewhere").
- A ordem esperada: CANCEL, 200 ao CANCEL, 487 ao INVITE e ACK do 487.
- No Wireshark, filtre por sip.Status-Code == 487 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
A oferta de mídia (SDP) não é aceitável por este destino: nenhum codec em comum, tipo de mídia ou criptografia não suportados.
Causas, como depurar e proxies
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/AVP.
- re-INVITE de T.38 (fax) para quem não suporta.
Como depurar
- Compare as linhas m= e a=rtpmap do SDP da oferta com os codecs permitidos no destino.
- Leia o cabeçalho Warning: os códigos 304 (tipo de mídia), 305 (formato) e 370 (banda) dizem o motivo.
- No Asterisk, allow/disallow e media_encryption do endpoint; no FreeSWITCH, codec-prefs e o log "incompatible destination".
- No Wireshark, filtre por sip.Status-Code == 488 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Causa Q.850 em gateways (RFC 3398)
Definida pelo Warning (31 Normal, unspecified por padrão)
O servidor não entende o pacote de eventos do cabeçalho Event (do SUBSCRIBE ou PUBLISH). A resposta traz Allow-Events com os pacotes aceitos.
Causas, como depurar e proxies
Causas prováveis
- Telefone assinando presence, dialog ou message-summary (BLF, correio de voz) em servidor sem suporte.
Como depurar
- Compare o Event do SUBSCRIBE com o Allow-Events da resposta.
- No Asterisk, confira se o ramal monitorado tem hint no dialplan.
- No Wireshark, filtre por sip.Status-Code == 489 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
Já existe uma transação pendente no mesmo diálogo, por exemplo os dois lados mandando re-INVITE ao mesmo tempo (glare).
Causas, como depurar e proxies
Causas prováveis
- Hold, retomada ou mudança de codec disparados pelos dois lados juntos.
- re-INVITE enviado antes de a oferta anterior ser respondida.
Como depurar
- O RFC manda esperar um tempo aleatório e tentar de novo: de 2,1 a 4 s se você gerou o Call-ID, de 0 a 2 s se não.
- Procure dois INVITE com o mesmo Call-ID e CSeq cruzados no trace.
- No Wireshark, filtre por sip.Status-Code == 491 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
O corpo veio cifrado (S/MIME) e o destino não tem a chave para decifrá-lo.
Causas, como depurar e proxies
Causas prováveis
- Uso de S/MIME, raro na prática.
Como depurar
- Confira o certificado usado na cifragem e se o destino tem a chave privada correspondente.
- No Wireshark, filtre por sip.Status-Code == 493 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.
494 Security Agreement Required
#O servidor exige um acordo de mecanismo de segurança (cabeçalhos Security-Client, Security-Server e Security-Verify) antes de seguir.
Causas, como depurar e proxies
Causas prováveis
- Redes IMS exigindo IPsec ou TLS negociado com o P-CSCF.
Como depurar
- Leia o Security-Server da resposta e confira se o cliente envia Security-Client e Require: sec-agree.
- No Wireshark, filtre por sip.Status-Code == 494 e abra o fluxo em Telefonia > Fluxos VoIP.
Em proxies
Final. O proxy guarda a resposta e só repassa se for a melhor entre todas as ramificações (forking) quando nenhuma der 2xx ou 6xx.