Resumo

  • O RFC 5263 obriga o agente de presença a aguardar a resposta final ou o timeout do NOTIFY parcial anterior antes de enviar outro ao mesmo Request-URI; isso serializa transações, não confirma um estado durável no observador.
  • Um recibo defensável vincula assinatura, versão e corpo do NOTIFY à resposta SIP, ao processamento XML, às impressões antes e depois, à confirmação de armazenamento e à exposição posterior.

Um documento antigo foi descartado e ainda recebeu resposta

O observador recebeu uma versão igual à que já mantinha. Pelas regras de processamento, tratou o documento como falha do agente e o descartou sem aplicar a diferença. A camada SIP ainda precisava concluir a transação de modo apropriado.

Visto do emissor, a troca podia terminar normalmente. Visto do estado local, nada mudou. Se o registro institucional guardar apenas a resposta final, ele transformará um descarte deliberado em prova de atualização.

O problema não é o código SIP. É a ausência da decisão local no recibo. A comparação de versão, o ramo escolhido e a impressão mantida precisam acompanhar a transação.

A resposta final governa a fila

O agente não deve enviar novo NOTIFY parcial ao mesmo Request-URI até receber a resposta final do anterior ou até a transação expirar. A regra impede que várias mudanças dependentes avancem sem uma fronteira de ordem.

No mecanismo geral de eventos SIP, uma notificação considerada aceitável normalmente recebe 200. A transação não deve durar além do processamento automatizado necessário, e o assinante não pode esperar uma resposta do usuário para encerrá-la.

Logo, o retorno serve à fila e à máquina de estados do protocolo. Não foi projetado como confirmação humana, recibo de leitura ou garantia universal de commit da aplicação.

A sequência pertence a uma assinatura

Para admitir notificações parciais, o observador anuncia application/pidf-diff+xml e application/pidf+xml. Pode atribuir preferências, mas a política local do agente participa da escolha.

A primeira notificação no formato parcial traz estado completo e inicia o contador em um. O valor pertence à assinatura. Uma renovação não o reinicia; o encerramento da assinatura o faz.

Portanto, versão e resposta precisam ser vinculadas a Request-URI, Call-ID, tags, diálogo, CSeq e hash do corpo. Um número solto não identifica a transição. Um 200 solto não identifica o estado que deveria resultar dela.

Sucesso de envio não observa persistência

O agente avança a versão em relação ao documento parcial anteriormente enviado com sucesso ao mesmo observador. Depois da resposta final ou do timeout, ganha condição para seguir.

Esse histórico é forte para a superfície de envio: mensagem emitida, transação encerrada, janela seguinte liberada. Ele não observa se o parser terminou, se o patch encontrou a base certa, se a gravação sobreviveu a uma falha ou se o consumidor posterior leu a nova impressão.

Quando tudo funciona, os fatos ficam próximos no tempo. Quando há disputa, a proximidade desaparece como prova. Cada estágio precisa de seu próprio responsável e evento observável.

Salto de versão exige recuperação, não otimismo

Uma diferença exatamente uma versão acima pode ser aplicada à cópia completa e faz o contador avançar. Uma versão igual ou menor deve ser descartada. Uma versão mais de uma unidade acima indica perda presumida; o observador deveria renovar para obter estado completo ou encerrar a assinatura.

O mesmo código de resposta na borda não descreve essas três consequências. Aplicar, descartar e abandonar a cadeia são decisões diferentes sobre o estado local.

O recibo precisa guardar a versão esperada, a recebida, a decisão e o hash resultante. Sem isso, a telemetria do emissor atribui ao destinatário um resultado que não viu.

O erro de processamento pode ficar restrito ao observador

Se o corpo parcial falhar durante o processamento, o RFC 5263 orienta renovar a assinatura. O observador também pode retirar o formato parcial do próximo SUBSCRIBE e voltar ao funcionamento com documentos completos.

O texto reconhece que dificilmente é razoável sinalizar esse erro ao notificador, mesmo quando a origem está no processamento do lado notificador. Assim, o agente pode enxergar uma sequência limpa de finais enquanto o observador abandona silenciosamente o caminho incremental.

Ausência de erro no emissor não é evidência de aplicação bem-sucedida no receptor.

Trocar o tipo preserva o contador e apaga o conteúdo

Se o agente muda o Content-Type dentro da assinatura, o observador descarta a informação de presença recebida antes, exceto o contador. Esse valor permanece porque uma volta ao formato parcial deve continuar a numeração.

O resultado é uma continuidade numérica sobre uma descontinuidade de representação. Um log com versões e respostas não mostra qual cópia foi eliminada, qual documento completo virou a nova base e quando a camada posterior passou a utilizá-lo.

Um estado completo enviado durante renovação cria novo ponto de apoio. Não prova retrospectivamente o destino das diferenças anteriores.

Segurança do transporte não é aplicação durável

O RFC 5263 herda preocupações de confidencialidade, integridade, autenticidade, replay e negação de serviço. Recomenda TLS no contexto original e permite S/MIME; o RFC 8996 atualizou a dependência ao descontinuar TLS 1.0 e 1.1.

Uma injeção pode simular lacuna e provocar pedido de estado completo. Impedir isso é essencial. Ainda assim, uma mensagem autêntica pode falhar no parser, no patch, no armazenamento ou na exposição.

Proveniência criptográfica e encerramento SIP pertencem à cadeia de evidências, mas não substituem a confirmação do estado local.

O recibo de estado do observador

Para decisões com consequências, preserve:

  • presentity, observador, Request-URI, assinatura, diálogo e pacote de evento;
  • tipos aceitos, preferências e escolha local do agente;
  • Call-ID, tags, CSeq, tipo, bytes, hash e hora do NOTIFY;
  • versão da assinatura e valor anterior esperado;
  • código e hora da resposta SIP, timeout ou repetição;
  • resultado do parser e erro de processamento;
  • hash do documento completo anterior e resultado do patch;
  • hash reconstruído, contador local e confirmação de armazenamento;
  • renovação, fallback, troca de formato e novo documento completo;
  • identidade, hash e hora da exposição a jusante; e
  • apresentação, tentativa de contato, entrega e resultado humano ou de serviço.

O recibo não enfraquece o 200. Ele impede que uma prova de fluxo se passe por prova de estado.

Sources