Q.850 cause 102 (Recovery on timer expiry): o que significa

Resposta curta: Q.850 cause 102 (Recovery on timer expiry) indica que um procedimento de recuperação de erro começou porque um temporizador do protocolo expirou: alguma mensagem esperada não chegou a tempo. Em troncos SIP costuma ser um INVITE sem resposta, por firewall, NAT, SIP ALG ou pacote UDP grande demais. Siga a sinalização e veja onde ela para.

Como o Monitor trata a causa 102

Quando a operadora informa a causa Q.850 no cabeçalho Reason da resposta SIP, o Monitor a guarda junto com o código SIP em cada chamada de teste, e ela aparece na evidência do incidente, pronta para o chamado na operadora. Nas telas em português, a causa 102 aparece como: um temporizador do protocolo expirou.

Como qualquer falha, uma chamada de teste lida como Fora do ar é repetida 3 vezes, a cada 2 minutos, e só 4 falhas seguidas abrem um incidente.

O que significa a causa 102 na prática?

A Q.850 cause 102, Recovery on timer expiry, indica que um procedimento foi iniciado pela expiração de um temporizador, dentro dos procedimentos de tratamento de erro. Em outras palavras, um equipamento esperou uma mensagem que não veio e desistiu. Pertence à classe de erros de protocolo. Pela RFC 3398 (seção 7.2.4.1), a causa 102 vira SIP 504 Server Time-out (a RFC escreve “504 Gateway timeout”); no sentido inverso, o SIP 408 Request Timeout e o 504 voltam como 102. Em SIP, o temporizador típico é o Timer B do INVITE, de 64 vezes o T1, ou 32 segundos com o T1 padrão de 500 ms (RFC 3261). A causa chega na REL do ISUP e num Reason: Q.850;cause=102. No Asterisk, ${HANGUPCAUSE} fica em 102, e o CDR mostra hangupcause 102 quando grava o campo.

Quando ela aparece

• Firewall bloqueando a resposta da operadora ou o próprio INVITE de saída.
• NAT sem mapeamento para a porta SIP, ou SIP ALG do router alterando as mensagens.
• INVITE com SDP grande demais (muitos codecs) que passa do MTU, é fragmentado em UDP e tem um fragmento perdido.
• DNS do tronco resolvendo para um IP antigo da operadora.
• Servidor SIP intermediário que não responde e não manda nem 100 Trying.

Como diagnosticar

1. No sngrep, veja se o INVITE foi retransmitido várias vezes sem resposta: isso confirma que nada voltou.
2. Capture na interface externa com tcpdump -i any -s 0 -w chamada.pcap port 5060 para saber se o INVITE saiu e se alguma resposta chegou.
3. Desative o SIP ALG do router e confira as regras de NAT e firewall para os IPs da operadora.
4. Se o INVITE passa de cerca de 1.300 bytes, reduza os codecs oferecidos ou use TCP no tronco.
5. Confira o DNS do domínio do tronco e o IP para onde o INVITE está indo de fato.
6. No 3CX, o Activity Log com Verbose logging mostra se o tronco recebeu alguma resposta antes do timeout.

O que mandar para a operadora

• Data, hora e fuso das tentativas.
• Números A e B.
• Call-ID e o que você recebeu: nenhuma resposta, SIP/2.0 408 Request Timeout ou 504, com o Reason.
• O IP público de origem e o IP de destino para onde o INVITE foi enviado.
• O pcap mostrando as retransmissões do INVITE.

Perguntas frequentes

Por que a chamada demora cerca de 32 segundos antes de falhar com cause 102?

Porque o INVITE em SIP sobre UDP é retransmitido até o Timer B expirar, e o Timer B vale 64 vezes o T1. Com o T1 padrão de 500 ms, isso dá 32 segundos. Se nenhuma resposta final chega nesse intervalo, a transação falha, e o gateway informa a cause 102 para o lado da telefonia.

Uma chamada de teste real ajuda com falhas de timeout?

Ajuda, porque ela passa pelo mesmo caminho de sinalização de uma chamada comum e recebe a resposta SIP final, ou a falta dela. Uma falha é repetida antes de virar alerta, o que evita aviso por um pacote perdido isolado, e o alerta segue por e-mail e SMS.