Resumo

  • A fábrica pode criar a conferência, aceitar o criador e entender a lista em uma única transação. O 200 não informa se qualquer outro destinatário recebeu convite, foi autenticado, admitido ou conectado.
  • Depois da criação, o servidor deve tentar acrescentar os alvos. A inclusão no XML expressa intenção do criador; a autoridade para admitir continua no focus e depende da identidade e da política.
  • O URI da fábrica aceita a lista no INVITE inicial. O URI da conferência retornado em Contact é outro recurso; a mesma lista em re-INVITE não tem semântica definida e, quando exigida, produz 420.

A fila começou depois da resposta

O ganho de RFC 5366 é temporal. O usuário não precisa criar a conferência, esperar o endereço e só então enviar pedidos de inclusão. Ele entrega o conjunto inicial no primeiro INVITE para que o servidor possa começar o trabalho assim que a sala existir.

Isso não torna o trabalho síncrono. A resposta ao criador pode chegar antes das respostas dos convidados. Alguns ainda podem estar tocando; outros podem exigir autenticação; um domínio pode estar indisponível; uma política pode impedir a admissão. O protocolo não prende a transação inicial à conclusão de todos esses ramos.

O 200 confirma que a conferência foi criada, o UAC criador está nela e o servidor entendeu a lista. A fila de operações individuais continua aberta. Um painel que encerra todas as linhas nesse instante substitui tarefas assíncronas por uma suposição.

O registro deve representar o ponto de bifurcação. Preserve a solicitação à fábrica, a impressão digital da lista, o URI de conferência retornado e o diálogo do criador. Para cada URI normalizado, abra uma operação com estado próprio: ainda não tentado, INVITE gerado, resposta provisória, resposta final, autenticação, política, admissão, diálogo e mídia.

Se o servidor não produzir uma tentativa para um elemento, a lacuna precisa aparecer. Se a tentativa existir e falhar, ela não deve ser confundida com uma linha nunca processada. Ambas diferem de uma pessoa que entrou e saiu antes de o organizador consultar o estado.

O nome na lista era um alvo, não uma credencial

A lista foi composta por alguém. Mesmo quando o criador está autenticado e autorizado a usar a fábrica, sua escolha não concede ao destinatário todos os direitos dentro da conferência.

O focus governa a admissão. Conferências podem limitar quem entra, qual papel recebe e quais mídias pode usar. Para aplicar essas regras, o focus precisa autenticar o participante potencial. O URI escrito pelo criador ajuda a localizar um alvo; não garante quem responderá.

Encaminhamento, contas compartilhadas e múltiplos dispositivos criam divergências legítimas. A identidade do criador, o URI solicitado, o terminal que respondeu e o principal autenticado podem ser quatro valores diferentes. Apagar os valores intermediários impede explicar o que ocorreu.

Uma trilha robusta mantém essas identidades ligadas, não fundidas. Registra também a versão da política e o motivo da decisão. Assim, uma recusa do usuário não vira falha de autorização, uma falha de autenticação não vira ausência e uma redireção legítima não vira substituição silenciosa.

As regras de URI-list de RFC 5363 acrescentam autenticação e autorização do cliente e disciplina de opt-in. Elas controlam o poder de transformar uma requisição pequena em muitos convites. Ainda assim, uma lista que o criador tem permissão para usar não concede admissão automática aos alvos.

«Tentou acrescentar» precisa de recibo

Depois de criar a conferência, o servidor deveria tentar acrescentar os participantes como se a adição tivesse sido solicitada por um dos mecanismos de RFC 4579. A norma não diz que a lista é uma transação atômica em que todos entram ou ninguém entra.

Por isso, um contador de sucesso requer denominadores claros. Quantos alvos foram recebidos? Quantos sobreviveram à normalização? Quantos geraram INVITE? Quantos responderam? Quantos foram autenticados e admitidos? Quantos estabeleceram diálogo? Quantos apareceram no estado da conferência?

Cada número mede uma superfície diferente. O primeiro pertence ao pedido. O segundo, ao parser. O terceiro, ao executor. O quarto, à sinalização remota. O quinto, ao focus. O sexto, ao diálogo. O sétimo, ao observador de estado.

O próprio verbo “convidar” pode ocultar isso. Para o organizador, talvez signifique colocar um nome na lista. Para o servidor, gerar um INVITE. Para o destinatário, receber uma chamada. Para a governança, oferecer uma oportunidade real de participar. Um campo único não atende a todos.

Recibos por alvo permitem retries responsáveis. Se não houve tentativa, o sistema pode retomá-la sem fingir que a primeira ocorreu. Se houve rejeição explícita, repetir automaticamente pode contrariar a pessoa. Se houve admissão e o diálogo caiu, a ação correta não é reenviar toda a lista.

A mídia do criador não se espalha pelos convidados

O INVITE inicial pode transportar SDP e lista em multipart. A oferta e a resposta estabelecem a sessão entre criador e servidor. O corpo de lista inicia operações para terceiros.

Embora os corpos compartilhem a mesma mensagem, não compartilham resultado. Cada INVITE de saída abre outro diálogo e outra negociação. Codec, endereço de transporte, política de mídia, contexto criptográfico e conectividade podem variar.

Uma pessoa pode ser admitida apenas para áudio. Outra pode estabelecer sinalização sem receber RTP. Uma terceira pode receber mídia mas não reproduzi-la. O 200 da fábrica e o SDP do criador não respondem a essas questões.

O monitoramento precisa separar diálogo e mídia. Salve a impressão digital do SDP por relação, a decisão do focus, os parâmetros escolhidos e as observações de tráfego. Onde não houver telemetria de reprodução, não use “ouviu” como sinônimo de “negociou”.

Essa distinção também protege acessibilidade. Uma reunião pode estar tecnicamente ativa enquanto um participante não consegue usar o meio necessário. Agregar tudo sob a saúde do criador transforma uma falha individual em invisibilidade estatística.

A fábrica e a sala aceitam operações diferentes

O primeiro INVITE vai ao URI da fábrica. O servidor devolve em Contact o URI da conferência criada, identificado como focus. Depois disso, re-INVITEs vão para a conferência, não para a fábrica.

O suporte a recipient-list-invite pertence ao recurso de criação. OPTIONS pode revelar essa capacidade na fábrica. Não autoriza concluir que qualquer URI no mesmo host aceita a extensão.

RFC 5366 não atribui semântica a uma lista dentro do re-INVITE. O cliente não deveria enviá-la. Se envia e exige a extensão, o URI da conferência responde 420 Bad Extension e aponta a opção em Unsupported.

Esse 420 pode ser prova de separação correta, não de produto quebrado. Ele não apaga a conferência, não derruba necessariamente o diálogo anterior e não contradiz a capacidade da fábrica. Explica que o pedido chegou ao recurso ou à fase errada.

Retirar Require e repetir não cria sentido. Trocar o destino pela fábrica pode criar outra sala. A recuperação deve selecionar explicitamente um mecanismo de adição a conferência existente, uma nova criação ou apenas uma renegociação de mídia.

O inventário de capacidades deve armazenar URI, método, tempo e estado do diálogo. Um selo global de compatibilidade é insuficiente para orientar automação.

O estado observado não é a lista devolvida com atraso

Para saber o estado dos demais usuários, RFC 5366 aponta mecanismos gerais como o pacote de eventos de conferência de RFC 4575. Essa fonte observa o focus depois das tentativas; não amplia retroativamente o significado do 200.

Notificações têm versão e podem ser completas ou parciais. Uma atualização parcial depende de uma base válida. Uma lacuna na assinatura não pode ser preenchida copiando a lista inicial.

O tempo altera o conjunto. Um convidado pode entrar depois de uma nova tentativa. Alguém não listado inicialmente pode ser adicionado por outro método. Uma pessoa observada numa versão pode sair antes da seguinte.

Mantenha três conjuntos: solicitado, processado pelo focus e observado. A diferença entre eles explica fila, política e mudança temporal. Forçá-los a coincidir remove justamente a informação que a operação precisa.

Mesmo um membro presente no documento de estado não prova atenção humana ou mídia útil. É uma afirmação do focus sobre o estado que ele representa.

A lista plana pode descartar detalhes

O formato de RFC 4826 oferece hierarquia e referências relativas ao XCAP. A conferência de RFC 5366 necessita apenas de uma lista plana. O cliente deveria evitar recursos extras, e a fábrica pode descartar informação além do necessário.

Logo, “lista entendida” não equivale a “estrutura inteira preservada”. Guarde bytes originais, versão do parser, conjunto normalizado, descartes e operações geradas. Sem isso, o cliente e o servidor podem falar de listas diferentes usando o mesmo identificador.

Os atributos de cópia e anonimização controlam a história mostrada a cada destinatário. Seu mecanismo pertence à análise de RFC 5364. Aqui, basta não confundir história projetada, lista de intenção e membros efetivos.

Limite da pesquisa

As fontes congeladas estabelecem texto normativo, papéis e vocabulário registrado. Não demonstram a implementação atual de fornecedor algum, uma conferência real, incidente ou taxa de adoção. Os fluxos do RFC são exemplos, não captura de rede.

A conclusão legítima é sobre autoridade: a lista pede, o servidor tenta, o focus decide, o diálogo conecta e o estado observa. Nenhum desses verbos herda automaticamente o resultado do anterior.