Causas Q.850

Q.850 cause 88 (Incompatible destination): o que significa

Resposta curta: Q.850 cause 88 (Incompatible destination) indica que o destino recebeu um pedido de chamada com atributos de compatibilidade que ele não consegue atender, como o tipo de terminal ou a taxa de dados. É comum ao misturar voz, fax e dados. Confira o tipo de chamada enviado, a portadora pedida e que terminal está ligado no número.

Causa 88 na referência
Causa88
Nome oficial (ITU-T Q.850)Incompatible destination
ClasseMensagem inválida (81 a 95)
Resposta SIP pela RFC 3398SIP 503 Service Unavailable

Como o Monitor trata a causa 88

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.

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 88 na prática?

A Q.850 cause 88, Incompatible destination, indica que o equipamento de destino recebeu um pedido de chamada com compatibilidade de camada baixa, compatibilidade de camada alta ou outros atributos, como taxa de dados, que ele não consegue atender. Diferente da cause 65, que fala de portadora não implementada, a 88 aponta um descasamento entre o que a chamada pede e o tipo de terminal no destino. Pertence à classe de mensagens inválidas da Q.850. Pela RFC 3398 (seção 7.2.4.1), a causa 88 vira SIP 503 Service Unavailable, então do lado SIP ela se confunde com falhas de capacidade. Ela chega na REL do ISUP, no DISCONNECT do ISDN e num Reason: Q.850;cause=88 (RFC 6432). No Asterisk, ${HANGUPCAUSE} fica em 88, e o CDR mostra hangupcause 88 quando grava o campo.

Quando ela aparece

  • Chamada de dados ISDN (64 kbit/s sem restrição) para um telefone analógico ou um destino só de voz.
  • Chamada de voz para uma linha configurada só para fax ou dados.
  • Gateway ISDN que repassa uma compatibilidade de camada alta (HLC) que o terminal de destino não aceita.
  • Terminais ISDN antigos com configuração específica, como fax grupo 4 ou videofone.
  • Gateways SIP-ISDN que montam o SETUP com uma portadora diferente da esperada pelo destino.

Como diagnosticar

  1. Num E1 ISDN, ative pri set debug on span 1 e leia no SETUP os campos Bearer Capability, Low Layer Compatibility e High Layer Compatibility.
  2. Confirme com o dono do número que tipo de terminal está ligado nele.
  3. No gateway SIP-ISDN, verifique como ele preenche a portadora: muitos têm opção para forçar voz (speech) ou áudio de 3,1 kHz.
  4. No Asterisk com DAHDI, a variável de canal TRANSFERCAPABILITY define a portadora das chamadas de saída; confirme o valor usado.
  5. No sngrep, veja se o 503 veio com Reason: Q.850;cause=88, para separá-lo de um 503 por falta de capacidade.

O que mandar para a operadora

  • Data, hora e fuso das tentativas.
  • Números A e B e o tipo de chamada pretendido (voz, fax, dados).
  • Call-ID, a resposta SIP/2.0 503 Service Unavailable e o Reason com cause=88.
  • O trace do SETUP com o Bearer Capability, se a chamada sai por E1 ISDN.
  • O pedido para confirmar o tipo de terminal provisionado no número de destino.

Perguntas frequentes

Por que a cause 88 vira SIP 503 e não 488?

Porque é o que a tabela da RFC 3398 define: a cause 88 vira SIP 503 Service Unavailable, enquanto a cause 65 vira 488. Na prática, isso faz um problema de compatibilidade parecer um problema de capacidade no lado SIP. Só o cabeçalho Reason com cause=88, ou o trace TDM, mostra o motivo real.

A cause 88 aparece em troncos SIP puros?

Raramente. Ela nasce em redes com sinalização ISDN ou ISUP, onde a chamada carrega atributos de compatibilidade. Num tronco SIP, você normalmente a vê quando a chamada atravessa um gateway para a rede TDM e o destino lá rejeita os atributos. Se o trecho for todo SIP, o comum é um 488 com Warning.

Saiba disso antes dos seus clientes

O Monitor liga para cada circuito de voz o dia todo e entrega cada falha com o código SIP e a causa Q.850 como prova.