Résumé

  • RFC 5239 centralise l’état de la conférence et le graphe de signalisation, sans confondre le focus, le serveur de contrôle, l’arbitrage des ressources, le mélangeur et la notification.
  • Un dossier opposable doit relier demande, identité, autorisation, version de l’objet, exécution et visibilité propre à chaque observateur. Un reçu isolé ne prouve que sa surface de contrôle.

Le bouton qui résumait trop

Alice demande de rendre Bob muet. Le serveur de contrôle vérifie son rôle et les règles attachées à l’objet de conférence. S’il l’autorise, l’état de Bob est modifié afin que son média ne soit plus mélangé. Le service de notification peut informer Bob et Carol, selon leurs droits. Enfin, le mélangeur doit produire le comportement attendu.

L’interface peut condenser toute la séquence en un état vert. L’architecture ne le permet pas. L’acceptation de la requête ne prouve pas l’autorisation ; l’autorisation ne prouve pas la mutation ; la mutation ne prouve pas l’application au flux ; une notification ne prouve que ce qu’un destinataire était autorisé à connaître.

Le focus n’est pas le gouvernement entier

Le focus entretient une relation de signalisation distincte avec chaque participant. Le graphe d’appel forme donc une étoile. Cette centralité décrit le rendez-vous des sessions, non la propriété de toutes les décisions.

Autour de l’objet partagé, RFC 5239 distingue serveur de contrôle de conférence, serveur de contrôle de parole, un ou plusieurs focus et service de notification. Ce sont des entités logiques ; plusieurs peuvent habiter le même logiciel. Leur cohabitation ne rend pas leurs actes équivalents. Même dans un seul processus, l’audit doit identifier l’auteur de chaque décision.

Le graphe média peut d’ailleurs être central, distribué ou hybride. Une signalisation en étoile ne démontre donc pas que chaque paquet audio ou vidéo a traversé le même mélangeur.

L’objet décrit ; la politique autorise

L’objet de conférence représente successivement un modèle, une réservation, une conférence active ou terminée. Les politiques fixent les droits, permissions et limites applicables à ses opérations. Le protocole porte la demande ; les composants d’exécution produisent ses effets.

Les identifiants gardent eux aussi des sujets distincts. L’URI du focus sert à la signalisation. L’XCON-URI désigne l’objet. L’identifiant d’utilisateur vaut dans le système de conférence et peut varier selon le rôle. Fusionner ces clés facilite l’affichage mais détruit la capacité d’attribuer une action.

L’héritage ajoute une autre dimension. Une réservation provient d’un modèle ; une barre latérale descend d’une conférence parente ; des valeurs imposées par le parent limitent les modifications locales. Un instantané ne dit pas si une valeur vient du modèle, d’une contrainte, d’un remplacement local ou d’un changement privilégié. Il faut conserver la lignée des versions.

Avoir la parole ne garantit pas le son

Le contrôle de parole attribue un droit temporaire sur une ressource. Le BFCP actuel précise qu’un titulaire de ce droit n’empêche pas automatiquement d’autres participants d’utiliser la ressource. Le droit et son exécution restent séparés.

« Parole accordée » prouve donc une décision d’arbitrage. Cela ne prouve ni que le mélangeur a admis l’audio, ni qu’il a exclu une autre source, ni que tous les destinataires ont reçu le bon mix. Inversement, un média audible sans reçu BFCP peut révéler un contournement, une lacune, ou simplement une conférence qui n’utilise pas ce mécanisme.

Une notification est une vue autorisée

RFC 5239 permet qu’un utilisateur soit public, anonyme ou caché. Un modérateur peut voir une identité invisible aux participants ordinaires. Les notifications sont filtrées par rôle, politique et confidentialité.

L’absence de Bob dans la vue de Carol ne prouve pas son absence du système. Deux notifications différentes peuvent être toutes deux exactes. Sans l’identité de l’observateur, son rôle, la version de politique et la règle de divulgation, il est impossible de distinguer retard, confidentialité, censure et erreur.

Six reçus pour une décision

Pour chaque opération sensible, il faut conserver la demande et sa cible, la méthode d’authentification, le rôle et la règle d’autorisation, les versions avant et après, le composant d’exécution, puis la vue remise à chaque observateur. Les horloges et les correspondances d’identifiants permettent seules de réunir ces pièces.

RFC 5239 ne documente aucun incident ni produit. Il fournit une grammaire d’architecture. La discipline de Lu Heng ajoute une règle : le code en fonctionnement et ses conséquences valent davantage que le titre « hôte », « focus » ou « serveur central ». Un état commun peut coordonner. Il ne doit pas effacer la responsabilité.

Sources