Resumo

  • O RFC 5239 centraliza estado e sinalização, sem transformar foco, servidor de controle, arbitragem de floor, mixer e notificação numa autoridade única.
  • Uma apuração confiável liga solicitação, identidade, autorização, versão do objeto, execução e visão de cada observador. Um registro isolado prova apenas o seu plano.

O silêncio que continha várias decisões

Alice pede que Bob seja silenciado. O servidor de controle verifica se seu papel e as políticas do objeto permitem a operação. Se a resposta for positiva, o estado de Bob passa a indicar que sua mídia não deve entrar na mistura. O serviço de notificações informa quem tiver direito. O mixer ainda precisa realizar a alteração.

O painel pode condensar tudo em um ícone. A evidência não. Aceitar o pedido não comprova autorização; autorizar não comprova gravação; alterar o objeto não comprova efeito no áudio; notificar comprova somente a visão liberada para aquele destinatário.

O foco não é o governo inteiro

O foco mantém uma relação de sinalização com cada participante, formando uma estrela. Isso explica a coordenação das chamadas. Não demonstra que o foco criou políticas, alterou todos os objetos, concedeu floors, processou mídia ou decidiu cada divulgação.

O RFC 5239 separa servidor de controle da conferência, servidor de floor, focos e serviço de notificação em torno do objeto compartilhado. São entidades lógicas e podem morar no mesmo processo. A proximidade física não apaga a responsabilidade lógica. Um executável que acumula funções ainda deve registrar em qual papel agiu.

O grafo de mídia pode ser central, distribuído ou híbrido. Sinalização central, portanto, não prova que todo áudio ou vídeo passou pelo mesmo mixer.

O objeto registra estado; a política limita mudanças

O objeto acompanha blueprint, reserva, ativação e conclusão. As políticas definem direitos, permissões e limites. O protocolo leva comandos; componentes de execução realizam consequências.

Os identificadores não são intercambiáveis. A URI de conferência identifica o foco no protocolo de chamada. A XCON-URI identifica o objeto. O identificador de usuário vale dentro do sistema e pode refletir papéis distintos. Colapsar essas chaves simplifica a tela e enfraquece a atribuição.

Também é preciso guardar herança. Reservas podem nascer de blueprints, sidebars dependem do pai e valores impostos pelo pai podem bloquear mudanças locais. Um instantâneo não revela se o valor veio do modelo, de uma restrição, de uma substituição ou de uma operação privilegiada posterior.

Receber o floor não garante o áudio

Floor é uma permissão temporária para usar um recurso. O BFCP atual alerta que possuir o floor não torna os demais tecnicamente incapazes de usar o recurso associado. Direito e aplicação continuam separados.

“Floor concedido” comprova arbitragem. Não comprova que o mixer aceitou a fonte certa, rejeitou outra ou entregou o resultado a todos. Mídia audível sem floor pode indicar contorno, lacuna de implementação ou uma conferência que não usa esse mecanismo. A auditoria deve unir permissão, associação do recurso e comportamento observado.

A notificação é uma vista autorizada

Uma pessoa pode aparecer como pública, anônima ou oculta. Um moderador pode enxergar identidade vedada aos demais. As notificações são filtradas por papel, política e privacidade.

Bob ausente da lista de Carol não prova que esteja fora da conferência. Duas vistas divergentes podem estar corretas. Sem observador, papel, versão da política e regra de divulgação, não é possível distinguir privacidade, atraso, censura e erro.

Reconstruir autoridade com fatos executados

Para cada operação sensível, preserve seis recibos: solicitante e alvo; método de autenticação; papel e regra de autorização; versões anterior e posterior do objeto; componente que executou o efeito; e conteúdo mostrado a cada observador. Relógios alinhados e mapas de identificadores unem a cadeia.

O RFC 5239 não relata produto, incidente ou adoção. Ele oferece uma gramática. A disciplina de Lu Heng acrescenta o teste: autoridade deve ser encontrada em ações atribuíveis e efeitos do código em execução, não em rótulos como anfitrião, foco ou servidor central.

Fontes