Resumo

  • Cada endpoint da RFC 3435 tinha uma única NotifiedEntity, mas ela só escolhia o destino dos comandos iniciados pelo gateway; respostas continuavam voltando à origem de cada comando.
  • A tomada por um agente reserva não oferecia resolução de conflito entre agentes, transferência completa de estado nem prova de mídia contínua. Auditoria, limpeza, alcance, autoridade e resultado eram recibos distintos.

O próximo destino, não a história inteira

Imagine um gateway que perde contato com seu controlador. Um agente reserva fornece uma nova NotifiedEntity, e o próximo Notify já tem endereço. Ainda faltam as decisões de conexão guardadas no agente antigo, a regra para sua eventual volta e a observação de que o áudio realmente continuou.

A RFC 3435, de janeiro de 2003, documentou essa fronteira. O texto simples, o registro do RFC Editor, a página no Datatracker, o histórico, as referências e as erratas provam o documento, não uma implantação.

O MGCP separava inteligência de chamada e função de mídia. A RFC 2705, substituída, supunha sincronização entre agentes sem defini-la. A RFC 2805 reunia requisitos gerais; a RFC 3015 descrevia Megaco/H.248, indicada pela nota do IESG como caminho baseado em padrões. A RFC 3435 era Informativa, não evidência de adoção universal.

Uma associação com limites

O último valor explícito de NotifiedEntity permanecia no endpoint; sem ele, valia o provisionado. Se ambos faltassem e o valor fosse vazio, condição desaconselhada, a origem do último comando não auditor virava o destino. Uma auditoria isolada não mudava o ponteiro.

As respostas, porém, eram enviadas à origem do comando independentemente da entidade notificada. Comandos podiam chegar de qualquer origem. Por isso, destino dos comandos do gateway, origem de uma solicitação, resposta e autoridade do controlador não eram equivalentes. A linguagem da RFC 2119 e a gramática da RFC 2234 precisavam o fio, não criavam legitimidade.

Um nome DNS podia resolver para várias interfaces ou máquinas. O gateway tentava alternativas e não dependia da ordem das respostas. Isso aumentava o alcance, mas não provava que as máquinas compartilhavam conexões, eventos ou política. DNS, disponibilidade, identidade lógica e réplica de estado exigiam provas próprias.

O conflito declarado

Após retransmissões, recuo exponencial, novos endereços e limites T-MAX e T-HIST, o endpoint podia ficar disconnected. Um agente reserva então apresentava novo destino. O texto pressupunha que agente antigo e reserva se comunicariam e sincronizariam, mas dizia que não havia resolução de conflito de transferência entre agentes separados. AuditEndpoint mostrava o valor atual; não reconstruía toda decisão nem julgava o controlador legítimo.

Ao saber da desconexão, o agente podia auditar o endpoint ou apagar todas as conexões. Auditoria procurava reconciliar; apagar convergia pela destruição. Um sucesso de RestartInProgress não provava áudio intacto. A RFC 3661 esclareceu códigos de retorno sem transformá-los em resultados humanos.

A RFC 3991 acrescentou redirecionamento e reset; a RFC 3992 definiu lockstep limitado. Os registros IANA de pacotes MGCP e LocalConnectionOptions coordenam vocabulário, não comprovam operação.

O limite que permanece

A leitura posterior de Heng Lu sobre camadas de realidade impede que o ponteiro herde autoridade ausente. A primazia do código em execução separa desenho e efeito, e a especificação inicial mínima mostra como um núcleo comum coordena destino sem resolver tudo. São aplicações editoriais retrospectivas.

O ponteiro era necessário para enviar o próximo comando. A continuidade precisava ainda de autorização, sincronização, regra de conflito e observação da mídia.

Fontes