Résumé

  • Dans la RFC 5366, le 200 de l’INVITE initial établit trois faits seulement : la conférence a été créée, l’UAC demandeur y participe et le serveur a compris la liste. Il ne certifie le sort d’aucun autre URI.
  • La liste appartient à l’opération envoyée à l’URI de fabrique. L’URI de conférence retourné dans Contact désigne une autre ressource ; une liste placée dans un re-INVITE n’a pas de sémantique définie et l’extension requise y provoque un 420.
  • Demande d’invitation, authentification, décision du focus, dialogue individuel, négociation média et observation par le paquet d’événements de conférence sont des reçus distincts.

Trois faits, pas un groupe constitué

La RFC 5366 cherchait à raccourcir la création d’une conférence ad hoc. Au lieu de créer d’abord une salle, d’attendre son adresse, puis de demander l’ajout des premiers participants, le client peut remettre au serveur la liste initiale dans le même INVITE que celui qui crée la conférence.

Cette économie d’aller-retour rend le 200 trompeusement riche. L’organisateur voit une réponse positive à une requête qui contenait plusieurs noms. Une interface peut alors afficher « conférence créée avec huit participants ». Le protocole n’a pourtant confirmé que la création, l’entrée du demandeur et la compréhension syntaxique et fonctionnelle de la liste.

Le verbe « comprendre » ne signifie pas « exécuter intégralement ». Le serveur sait qu’il a reçu une liste de destinataires et sait comment traiter cette partie. Il peut encore normaliser les entrées, écarter des données supplémentaires, échouer à générer une invitation, recevoir un refus ou appliquer une règle d’admission qui rejette une personne authentifiée.

La création elle-même ne peuple pas la conférence. Une salle vide, hormis son créateur, satisfait encore la portée du 200. La preuve doit donc conserver séparément l’INVITE de fabrique, la réponse, l’URI de conférence obtenu, le résultat du dialogue du créateur et une opération par cible normalisée.

Pour chaque cible, il faut pouvoir répondre à des questions plus précises : une invitation a-t-elle été produite ? À quel instant ? Vers quelle identité normalisée ? Quel point terminal a répondu ? Quelle identité le focus a-t-il authentifiée ? Quelle règle a décidé l’admission ? Un dialogue a-t-il été établi ? Des médias utilisables ont-ils suivi ?

Une réponse initiale ne peut remplir ces colonnes. Elle peut seulement ouvrir la chaîne.

Le succès de l’organisateur n’est pas celui des invités

L’INVITE initial peut transporter deux corps dans un multipart : une description de session et une liste d’URI. Ils voyagent ensemble, mais ils ne commandent pas la même réalité.

Le SDP participe à l’échange offre-réponse entre l’UAC créateur et le serveur de conférence. La liste demande au serveur d’entreprendre des opérations vers d’autres personnes. Si l’audio du créateur est négocié, rien n’est encore dit sur les codecs, le chiffrement, la connectivité ou l’accessibilité d’un invité.

Le serveur crée ensuite des INVITE sortants. Chaque dialogue a sa propre transaction, sa propre authentification, sa propre offre-réponse et son propre résultat. Une personne peut sonner sans répondre. Une autre peut répondre depuis un terminal redirigé. Une troisième peut s’authentifier correctement mais ne pas être autorisée à rejoindre cette conférence ou à utiliser la vidéo.

Il est donc dangereux de recopier le statut du créateur sur les lignes d’invités. Le modèle de données devrait exprimer au moins : demandé, normalisé, tentative émise, réponse provisoire, réponse finale, identité authentifiée, admission décidée, dialogue établi, médias négociés, présence observée et départ.

Toutes les plates-formes n’observent pas chaque transition. Ce n’est pas une raison pour les remplacer par une valeur positive. L’inconnu est une information ; le succès hérité d’une autre transaction est une invention.

Une adresse fabrique, une adresse conférence

Le mécanisme s’appuie sur deux ressources. L’INVITE initial vise l’URI d’une fabrique de conférences. La réponse fournit l’URI de la conférence nouvellement créée dans Contact, avec l’indication que cette ressource est le focus.

Cette différence d’adresse est une différence de pouvoir. La fabrique accepte l’extension recipient-list-invite pour créer une conférence avec une liste initiale. L’URI retourné gère un dialogue déjà établi. La RFC ne lui attribue pas la même opération de liste dans un re-INVITE.

Une découverte de capacité doit donc être qualifiée par l’URI interrogé. Si OPTIONS montre l’option sur la fabrique, la preuve est « cette ressource a annoncé cette extension à cet instant ». Elle ne devient pas « le produit accepte des listes dans tout INVITE ». Le nom d’hôte commun ne suffit pas à transférer la capacité.

La situation inverse est tout aussi importante. Quand l’URI de conférence refuse l’extension, on ne peut pas conclure que le serveur ne connaît pas la RFC 5366. Il peut appliquer précisément la frontière prévue : la fabrique sait créer à partir d’une liste ; la conférence existante ne sait pas interpréter cette même liste dans un re-INVITE.

Les inventaires qui stockent une fonctionnalité au niveau d’une marque ou d’un cluster perdent cette nuance. Il faut enregistrer l’URI, la méthode, l’état du dialogue, le moment de la découverte et les options retournées. Une capacité est un fait adressé, non une qualité abstraite d’un logiciel.

Le re-INVITE ne relance pas la liste

Après établissement du dialogue, un re-INVITE sert notamment à modifier les caractéristiques des médias échangés entre le demandeur et le serveur. La RFC 5366 précise qu’aucune sémantique n’est alors attachée à un corps recipient-list. Le client ne devrait pas en mettre.

Si le client en place un tout en exigeant recipient-list-invite, la ressource conférence suit le traitement normal des extensions non prises en charge : elle répond 420 Bad Extension et nomme l’option dans Unsupported. Ce reçu est précis. Il ne dit pas que la conférence est détruite, ni que les médias existants ont échoué, ni que la fabrique a perdu sa capacité.

Un moteur de reprise peut aggraver l’erreur. Retirer Require puis renvoyer le même corps ne lui donne pas soudain un sens. Réadresser le re-INVITE à la fabrique peut créer une autre conférence au lieu de modifier la première. Répéter à l’identique peut produire une boucle de 420 qui ressemble à une panne de disponibilité alors qu’il s’agit d’une faute de portée.

La récupération doit changer d’opération de manière explicite. Pour ajouter des participants après la création, le client choisit l’un des mécanismes de contrôle de conférence prévus par RFC 4579. S’il veut une nouvelle conférence, il retourne volontairement à la fabrique. Le journal doit nommer ce choix et ne pas le dissimuler comme un simple retry.

Ce cas rappelle qu’une extension n’est pas seulement un format que le parseur reconnaît. Son sens dépend de la méthode, de la ressource et de la phase du protocole.

Être nommé n’accorde pas l’admission

Le serveur devrait tenter d’ajouter les personnes de la liste. La tentative reste subordonnée au focus, qui applique les règles de la conférence : qui peut rejoindre, sous quelle identité, avec quel rôle et quels médias.

La ligne de liste exprime la demande du créateur. Elle n’est pas un justificatif présenté par l’invité. L’identité qui répond à l’INVITE peut différer de l’adresse demandée en raison d’une redirection, d’un compte partagé ou d’un appareil intermédiaire. Le focus doit authentifier le principal qu’il admet, pas simplement faire confiance au texte reçu de la fabrique.

Une bonne trace conserve quatre valeurs sans les écraser : l’organisateur authentifié, l’URI inscrit dans la liste, le point terminal qui répond et le principal finalement admis. Elle lie aussi la version de politique, la décision et le motif. Sans cela, une enquête ne peut distinguer erreur d’adressage, redirection légitime, refus d’utilisateur et rejet d’autorisation.

Les règles de média forment encore une autre autorité. L’admission à la conférence ne garantit pas la vidéo ; un dialogue établi ne garantit pas un flux audio utilisable. L’offre-réponse fixe des paramètres, tandis que le transport et la restitution fournissent leurs propres observations.

Cette séparation compte lorsque la présence d’une personne est utilisée pour établir un quorum, un consentement ou une responsabilité. Le fait d’avoir figuré dans la liste ne prouve aucune de ces choses.

Le paquet de conférence observe après coup

Pour connaître le statut des autres utilisateurs, la RFC 5366 oriente le client vers les mécanismes généraux de conférence, notamment le paquet d’événements défini par RFC 4575. C’est un meilleur observateur que la réponse de fabrique, car il décrit l’état de la conférence après les tentatives.

Il ne faut pas en faire un oracle absolu. Une notification représente un état à une version et à un instant. Elle peut être complète ou partielle. Une souscription peut connaître une coupure. Une personne peut partir juste après l’émission. Le document peut attester ce que le focus déclarait, non ce que chaque humain entendait ou comprenait.

Pour exploiter ce flux, le système conserve l’identité de la souscription, l’URI de conférence, le numéro de version, la nature complète ou partielle du document, l’heure de réception et la continuité depuis la base précédente. Une mise à jour partielle sans base valide ne reconstitue pas une liste complète.

Il devient alors possible de comparer trois ensembles sans les confondre : les personnes demandées dans la liste initiale, les opérations et décisions du focus, puis les participants observés dans l’état. Leurs différences expliquent le fonctionnement réel : cible ignorée, invitation refusée, admission tardive, ajout extérieur ou départ.

Une liste comprise peut avoir été réduite

Le format RFC 4826 offre des listes hiérarchiques et des références relatives à XCAP. Le service de conférence de RFC 5366 n’a besoin que d’une liste plate. Le client devrait fournir cette forme, et la fabrique peut écarter les informations supplémentaires.

La compréhension du corps ne garantit donc pas la conservation de toute intention implicite. Il faut archiver les octets soumis, la version du parseur, la liste normalisée, les éléments rejetés ou ignorés et le motif. La comparaison utile porte sur ce que le client a envoyé et ce que le serveur a réellement utilisé.

Les attributs de copie et d’anonymisation règlent la vue remise aux destinataires. Leur logique détaillée appartient à RFC 5364 et à l’article consacré à la projection de visibilité. Dans la présente chaîne, l’historique diffusé n’est ni la liste source ni la preuve de présence actuelle.

Limite de l’enquête

Les sources gelées établissent les textes normatifs, les rôles SIP, le vocabulaire enregistré et les modèles de conférence. Elles ne démontrent le comportement actuel d’aucun produit, fournisseur ou conférence réelle. Les messages de la RFC sont des exemples, non des captures réseau, et les scénarios décrits ici sont des tests d’audit, non des incidents allégués.

La conclusion reste donc limitée mais forte : le 200 de la fabrique possède une autorité précise. L’étendre aux invités, aux médias ou à l’état futur revient à transformer un reçu local en croyance globale.