Resumo

  • O RFC 3326 carregou em Reason a causa protocolar que produziu uma solicitação, permitindo explicar um CANCEL, BYE ou mensagem autorizada sem alterar seu processamento SIP.
  • A causa podia ser criada, traduzida e copiada por vários elementos; por isso, protocolo, valor, texto, extensão, origem, tabela de mapeamento e integridade formavam recibos separados.

A ponte não era a origem do acontecimento

Uma central telefônica podia enviar uma mensagem ISUP de liberação a um gateway. O gateway então criava um CANCEL no lado SIP. Sem informação adicional, o endpoint via apenas a ordem de interromper o toque. Com Reason, o gateway conseguia transportar a causa Q.850 recebida da rede telefônica.

O ganho era real: uma ação SIP deixava de chegar completamente separada do evento externo que a provocara. Mas o gateway também passava a ser tradutor. O valor final podia ter sido copiado, mapeado ou gerado segundo uma regra local. A presença da causa não demonstrava que o último emissor observara diretamente a falha nem que a tradução preservara todos os detalhes.

RFC 3398 descreveu a correspondência entre ISUP e SIP. RFC 6432 permitiu que respostas SIP, salvo 100 Trying, levassem causas Q.850 em Reason. RFC 8606 acrescentou location quando a localização de liberação do ISUP estivesse disponível. Essa localização identifica uma parte ampla da rede, como rede local, de trânsito ou remota; não revela o endereço físico nem a identidade de quem chama ou atende.

Para tratar o valor como evidência, uma operação precisa conservar o REL original, o identificador e a versão do gateway, a tabela aplicada, a mensagem SIP resultante e qualquer alteração posterior. Uma captura no endpoint é o último elo, não a cadeia inteira.

O mesmo CANCEL podia encerrar duas histórias

O caso mais simples do RFC 3326 não exigia outra rede. Um proxy bifurcava um INVITE para vários dispositivos. Quando um deles atendia com 200 OK, o proxy enviava CANCEL aos demais. Se o chamador desistisse antes de alguém atender, esses dispositivos também receberiam CANCEL. Em ambos os casos, o telefone parava de tocar.

O histórico visível não deveria ser idêntico. Uma chamada atendida em outro aparelho não é necessariamente perdida. A desistência pode ser. A operação CANCEL descrevia o que fazer; não carregava sozinha o motivo da decisão. Um Reason com causa SIP 200 e a ideia de chamada concluída em outro lugar permitia ao aparelho escolher uma apresentação mais fiel.

O campo também servia a BYE. Um cliente que recebesse uma oferta inaceitável numa resposta 200 poderia confirmar adequadamente e encerrar a sessão com causa SIP 488. Um controlador de terceiros que encontrasse B ocupado poderia terminar o diálogo de A com um BYE contendo 486. O fato visto em um diálogo chegava como explicação a outro.

Reason podia aparecer em qualquer solicitação dentro de um diálogo, em qualquer CANCEL e em respostas cujo código autorizasse expressamente sua presença. O contêiner era comum; as causas continuavam pertencendo a seus protocolos.

Informação para serviço não era comando de protocolo

Clientes e servidores podiam ignorar Reason. O RFC declarou que o campo não afetava o processamento protocolar. CANCEL continuava válido sem ele, e BYE encerrava mesmo que o receptor desconhecesse o valor. Essa escolha preservou interoperabilidade com implementações antigas e simples.

Ao mesmo tempo, aplicações podiam usar a informação para interface, diagnóstico e serviço. Logo, uma causa era opcional no plano de protocolo, mas podia produzir consequências para pessoas. É preciso registrar não só a mensagem recebida, mas se o consumidor leu, ignorou, rejeitou ou substituiu o valor.

A sintaxe começava por protocol. SIP e Q.850 formavam espaços numéricos diferentes. Guardar apenas cause elimina a chave que dá significado ao número. O parâmetro text é útil para leitura humana, porém pode variar por idioma ou fabricante e não deve substituir o par estruturado.

O RFC original aceitava vários valores apenas se cada um tivesse protocolo distinto. O RFC 9366 atualizou a regra: pode haver repetição de um protocolo registrado quando esse protocolo define o significado da multiplicidade. Se não definir, continua existindo no máximo um valor por protocolo. Uma lista válida sintaticamente não oferece uma política universal de combinação.

O registro de parâmetros SIP da IANA é, portanto, parte do contexto. Ele delimita nomes de protocolo e parâmetros conhecidos. Um coletor que aceite qualquer token mas descarte a versão da interpretação pode parecer flexível e ainda assim perder semântica.

Copiar preservava contexto e afastava a testemunha

Quando um proxy recebia CANCEL com Reason e gerava novo CANCEL para o próximo salto, deveria copiar o campo. A ação atravessava a rede acompanhada de seu motivo. Sem a regra, o endpoint final voltaria a adivinhar a diferença entre atendimento em outra ramificação e abandono.

Mas cada cópia distancia a declaração do evento. O proxy que aparece como remetente pode apenas repetir seu vizinho. Se um intermediário remover Reason, alterar text ou converter uma causa, a última captura não identifica a mudança. Registros precisam marcar valores observados, criados, traduzidos e retransmitidos.

O risco ganhou importância no problema HERFP. Uma falha final numa ramificação de INVITE podia ficar retida enquanto outras ramificações continuavam. O Reason foi considerado candidato a encapsular resultado final numa resposta provisória. Se alguém falsificasse ou removesse essa informação, o cliente poderia deixar de atualizar a solicitação anterior e a sessão poderia não ser estabelecida. O RFC recomendou proteção de integridade adequada.

Integridade não torna o significado verdadeiro por decreto. Uma verificação bem-sucedida mostra que bytes protegidos não mudaram entre pontos definidos. Não confirma o evento no mundo, a honestidade do primeiro emissor ou a correção da tabela. Sem proteção, o valor ainda pode orientar diagnóstico, mas exige menor confiança e mais corroboradores.

History-Info no RFC 7044 e o mecanismo Diversion registrado no RFC 5806 preservam aspectos de redirecionamento. Eles não substituem Reason. Uma lista de alvos não é a causa que disparou BYE; um código de liberação não descreve toda a rota. Sistemas maduros ligam as camadas sem fundi-las.

O legado do RFC 3326 é a separação disciplinada entre fazer e explicar. O protocolo podia concluir a operação mesmo sem a explicação. Quando a explicação sobrevivia, ela melhorava a memória do sistema—desde que a rede também preservasse quem a criou, como a traduziu e quem decidiu acreditar nela.

Fontes