Resumo

  • Na RFC 6665, Subscription-State: terminated encerra a assinatura, não declara genericamente que o recurso observado terminou ou desapareceu.
  • As razões descrevem futuros incompatíveis: deactivated pode indicar migração, timeout permite uma nova assinatura, invariant preserva um estado estável e somente noresource afirma que o estado do recurso deixou de existir.
  • Um registro defensável separa o ciclo da assinatura, o corpo com estado do recurso, a transação NOTIFY, a interpretação do pacote e a ação humana ou automática posterior.

Um indicador vermelho fundiu duas máquinas de estado

A palavra “terminated” convida a um erro gramatical. Ao lado de dispositivo, conta, chamada ou endereço, parece descrever o substantivo que a interface escolheu exibir. No cabeçalho da RFC 6665, o substantivo é a assinatura. Ao receber o valor, o assinante deve considerar aquela assinatura encerrada. A evidência é autoritativa, mas seu objeto é limitado.

O recurso monitorado segue outra máquina de estado, definida pelo pacote de eventos. É o pacote que diz se um corpo representa estado completo ou parcial, qual é o estado neutro e como interpretar a ausência de conteúdo. O arcabouço geral de eventos SIP não impõe uma ontologia única a presença, espera de mensagens, chamadas ou estados específicos de uma aplicação.

Uma relação de observação pode falhar enquanto o objeto continua saudável. O objeto pode desaparecer enquanto a notificação final da assinatura ainda está em trânsito. Quando o banco de dados reduz ambos os casos a encerrado=true, ele apaga justamente a distinção necessária para saber se mudou o mundo ou apenas a capacidade de vê-lo.

Sete razões abrem caminhos operacionais distintos

As razões de término da RFC 6665 têm efeito prático. deactivated pede que o cliente crie outra assinatura imediatamente; a migração entre nós notificadores é um uso central. probation adia a tentativa. rejected aponta uma mudança na política de autorização e desaconselha nova tentativa. timeout significa que a assinatura não foi renovada antes de expirar e admite reassinatura imediata. giveup informa que o notificador não conseguiu obter autorização a tempo.

A comparação entre noresource e invariant torna o limite incontornável. O primeiro diz que o estado monitorado do recurso já não existe. O segundo diz que esse estado não mudará no futuro previsível. Ambos desencorajam nova assinatura, mas um descreve ausência e o outro permanência. Uma única categoria “acabou” não consegue preservar os dois fatos.

A razão também pode estar ausente ou ser desconhecida. Nesse caso, o cliente pode voltar a assinar, respeitando retry-after. A lacuna não autoriza o observador a inventar noresource. Um parâmetro expires ligado ao estado encerrado tampouco ajuda: a RFC diz que ele não tem semântica nesse contexto e deve ser ignorado.

A notificação final pode não trazer o último valor do recurso

O cancelamento de uma assinatura usa SUBSCRIBE com Expires: 0. Um cancelamento bem-sucedido provoca um NOTIFY final, mas a RFC 6665 avisa que a solicitação pode conter ou não informações sobre o estado do recurso. O assinante precisa aceitar as duas formas.

Sem corpo, o sistema aprendeu que a relação terminou, não qual foi o último valor do recurso. Com corpo, ainda é preciso interpretar o tipo de mídia, as regras do pacote, a semântica de estado completo ou parcial e a versão. O cabeçalho de assinatura não empresta sentido aos bytes regidos por outra especificação.

O 200 enviado em resposta ao NOTIFY também prova menos do que muitas telas sugerem. Assim que a notificação for aceitável, o assinante deve responder; a transação não pode ficar aberta esperando uma pessoa. O 200 comprova processamento aceitável por um elemento SIP automatizado. Não é confirmação de leitura, anuência do operador nem conclusão de um fluxo posterior.

A confirmação de criação pode chegar fora da ordem aparente

É o primeiro NOTIFY que confirma a criação da assinatura. Uma resposta 2xx ao SUBSCRIBE diz que o pedido foi aceito e que um NOTIFY será enviado de imediato, mas a notificação pode chegar antes do término da transação SUBSCRIBE por reordenação, perda ou bifurcação de mensagens. Antes dela, o recurso deve ser tratado no estado neutro definido pelo pacote.

Há pelo menos três relógios: o das requisições e respostas, o da criação, renovação, expiração e término da assinatura, e o das mudanças do recurso narradas pelo pacote. Um quarto relógio pertence ao observador que recebe, analisa e mostra a mensagem. Ordenar tudo pelo momento de captura e chamar o último registro de “verdade” pode inverter causa e efeito.

Uma trilha útil guarda chave local da assinatura, Call-ID e tags, valor de Event, destino, CSeq do NOTIFY, cabeçalho integral, razão, intervalo de nova tentativa, instante de recebimento, resultado de autenticação e resposta. Em separado, registra presença do corpo, tipo de mídia e resumo criptográfico, versões do pacote e do analisador, atributo completo ou parcial e valor derivado pela aplicação.

Um usage pode terminar enquanto o dialog continua

A RFC 6665 define assinatura como estado de aplicação associado a um dialog. A RFC 5057, de Robert Sparks, mostra por que associação não é identidade. Vários dialog usages podem compartilhar estado do dialog e ainda ter ciclos de vida independentes. Em uma transferência, um invite usage e um subscription usage podem estar no mesmo dialog; a assinatura termina enquanto o invite permanece.

Trabalhos posteriores tornaram a superfície de controle mais precisa. A RFC 7621 esclarece o uso de GRUUs para dirigir pedidos à instância pretendida do agente de usuário. A RFC 7647, de Sparks e Roach, trata das assinaturas implícitas criadas por REFER e do reaproveitamento problemático de dialogs. Melhor endereçamento e estrutura mais limpa reduzem a dúvida sobre qual usage produziu um evento; não transformam terminated em uma declaração sobre o recurso.

Por isso, “sessão encerrada” também é um rótulo perigoso. Assinatura, dialog, dialog usage, chamada, instância notificadora e recurso definido pelo pacote estão relacionados, mas não são sinônimos. Cada um precisa de identidade e estado sucessor próprios.

Roach preservou o limite, não a conclusão de uma implantação

Publicada em julho de 2012 no Standards Track, a RFC 6665 substituiu a RFC 3265. Adam Roach é o único autor nominal de ambas. O perfil atual do IETF registra sua participação desde 1998, o cargo de Applications and Real-Time Area Director entre 2017 e 2020 e presidências anteriores de XCON, SIPCORE e NETVC. A página lista 23 RFCs e nenhum papel ativo em 22 de abril de 2026.

Esses fatos demonstram contribuição aos padrões, não controle sobre uma implantação. A correspondência de razões, a política de temporizadores e o rótulo exibido pertencem ao produto e aos operadores. O nome de Roach fornece procedência ao arcabouço; não certifica uma implementação nem converte estado de assinatura em prova do recurso.

O pacote de evidências precisa responder a cinco perguntas

Identidade: qual dialog, pacote, alvo e chave local formam a assinatura? Ciclo de vida: qual estado, razão, regra de expiração e instante foram observados? Recurso: existia corpo, qual pacote o interpretou, e quais resumo e versão foram preservados? Custódia de transporte: qual notificador, autenticação, transação e resposta? Ação: o sistema tentou novamente, esperou, migrou, alertou ou encerrou um caso, segundo a regra de quem?

Separar não prejudica a automação. Um timeout pode abrir um incidente de lacuna de monitoramento sem matar o recurso. Um deactivated pode permanecer pendente até o primeiro NOTIFY da assinatura sucessora. Um noresource pode exigir confirmação da aplicação antes de uma medida irreversível. Uma razão ausente pode ser apresentada honestamente como desconhecida.

Operadores precisam de um estado compacto; essa objeção é legítima. O estado compacto deve dizer o que o protocolo provou: assinatura encerrada, razão conhecida ou não, evidência do recurso presente ou ausente. O vermelho continua útil se a legenda não prometer mais do que o pacote entregou.

Fontes