Résumé

  • Un REFER multiple contient une référence vers une liste. Son destinataire accepte la commande, normalise les cibles et crée une requête SIP distincte pour chacune ; la réponse initiale ne résume pas ces transactions.
  • La RFC 5368 recommande norefersub et Refer-Sub: false. Elle éteint volontairement l’abonnement implicite qui, pour un REFER ordinaire, transporte des états message/sipfrag, car ce canal ne sait pas représenter plusieurs résultats.
  • Le dossier probant doit garder la référence Content-ID, la garantie d’absence de bifurcation, la valeur Refer-Sub renvoyée, chaque transaction fille et l’observation propre au service. La RFC 8262 a ensuite précisé si la référence vise une partie MIME ou le corps complet.

La réponse précédait ce qu’elle demandait

La séquence d’exemple est sans ambiguïté. Un modérateur envoie au serveur de conférence un REFER qui désigne plusieurs participants. Le serveur répond 202 Accepted. Après cette réponse, il envoie un BYE à chaque cible.

La proposition prouvée par le 202 est donc limitée. Le destinataire du REFER a accepté de traiter la commande dans le cadre qu’il connaît. Il n’a pas encore démontré que chaque dialogue ciblé existe, que le BYE a été émis, que le réseau l’a livré, que l’agent distant l’a accepté ni que la conférence a retiré le participant.

Ce découpage n’est pas un détail de code d’état. Il détermine la forme du registre. Une ligne parent peut porter l’identité de l’émetteur, la requête reçue, la politique appliquée et la réponse. Elle ne doit pas porter par héritage le succès de trois lignes enfants dont les événements se produisent plus tard.

Dans une interface d’exploitation, « accepté » doit donc rester attaché au REFER. Le terme « terminé » exige un objet : transaction fille terminée, état de conférence observé, service obtenu ou action humaine confirmée. Sans objet, le mot agrège des faits que le protocole a séparés.

Le canal habituel a été supprimé consciemment

Avec une cible unique, REFER crée normalement un abonnement implicite à l’événement refer. Les NOTIFY associés transportent un fragment SIP qui renseigne l’émetteur sur la transaction déclenchée. Cette mécanique suppose qu’un fil d’état correspond à une opération cible identifiable.

La liste casse cette hypothèse. Plusieurs cibles peuvent suivre des trajectoires incompatibles : refus, redirection, temporisation, succès provisoire ou fin de dialogue. Aucun statut unique ne conserve à la fois l’identité de la cible, l’ordre et la phase de chaque transaction.

La RFC 5368 ne fabrique pas une moyenne. Elle recommande à l’émetteur d’exiger norefersub et de demander Refer-Sub: false. Le destinataire devrait accepter cette suppression, renvoyer Refer-Sub: false dans son 200 et ne pas créer l’abonnement implicite.

L’absence de NOTIFY est alors le comportement convenu. Elle ne signifie ni « aucun problème » ni « toutes les cibles ont réussi ». Un système qui clôt les opérations parce qu’il n’a reçu aucune erreur transforme un silence contractuel en preuve positive.

La solution appartient au service. Dans une conférence, un abonnement à l’état de conférence peut montrer la composition observée. Dans une autre application, il faut un événement, un journal d’exécution ou une API différente. L’important est de nommer ce canal avant de supprimer l’ancien.

La négociation se lit dans les deux sens

L’émetteur peut proposer Refer-Sub: false; seul le retour du destinataire prouve qu’il l’a accordé. Si la réponse 2xx omet le champ ou le renvoie à true, l’abonnement implicite est créé selon le comportement ordinaire.

Une trace qui conserve uniquement la requête raconte donc une intention, pas le contrat obtenu. À l’inverse, une réponse 200 isolée ne permet pas de savoir si multiple-refer et norefersub étaient exigés, vers quelle liste pointait Refer-To ni quelle méthode devait être produite.

Require: norefersub a aussi un coût explicite. Un destinataire qui ne connaît pas l’extension répond 420. Ce rejet prouve une incompatibilité de mécanisme à cette ressource et à cet instant. Il ne prouve pas que les cibles auraient refusé l’opération ni que l’application entière est incapable d’exécuter une commande équivalente autrement.

Une reprise automatique qui retire simplement norefersub change le contrat d’observation. Elle peut rétablir un abonnement implicite dont le modèle reste inadéquat pour plusieurs transactions. La reprise doit donc choisir en même temps comment les résultats seront distingués.

La suppression exigeait une requête non bifurquée

L’abonnement implicite avait une seconde fonction : rendre visibles les dialogues créés quand un REFER bifurque. La RFC 4488 n’autorise Refer-Sub: false que si l’émetteur peut être certain que la requête ne sera pas forkée.

L’exemple de la RFC 5368 emploie une adresse globalement routable d’agent utilisateur afin d’établir cette propriété. Cette adresse fait partie du raisonnement. Elle lie la réponse à l’entité qui exécutera la liste et empêche que plusieurs branches silencieuses se cachent derrière une seule commande.

Dans une architecture moderne, une entrée de service stable n’est pas automatiquement une preuve de non-bifurcation. Il faut distinguer répartition interne vers un seul propriétaire et remise protocolaire à plusieurs agents indépendants. Le journal devrait garder l’URI de requête, la route, le fondement de la non-bifurcation, la branche de réponse et l’identité du destinataire.

Refer-To pointait vers un objet précis

Le champ Refer-To contient une URL cid:. La liste se trouve dans le corps du message. La référence unit donc l’instruction de contrôle à un ensemble exact d’octets.

Cette union est vérifiable seulement si l’on conserve l’identifiant, le type de contenu, la disposition, les limites MIME, le hachage du corps et les réécritures des intermédiaires. Une passerelle qui déplace une partie sans corriger Content-ID peut laisser une référence valide en apparence mais sans cible cohérente.

La RFC 8262 a corrigé une ambiguïté importante. Des exemples de la RFC 5368 étiquetaient et référençaient un corps complet alors que les règles antérieures spécifiaient la référence à une partie. Les implémenteurs avaient lu l’exemple comme une autorisation. Le texte ultérieur permet explicitement de viser une partie ou le corps complet, avec un Content-ID MIME ou SIP.

La leçon documentaire est forte : un exemple illustre un mécanisme, mais ne crée pas toujours son autorité normative. Lors d’un audit historique, il faut connaître la version de règle appliquée et l’objet exact résolu par cid:.

Une liste ne donnait pas le même sens à toutes les méthodes

Le format peut contenir des attributs de contrôle de copie. Ils ont une fonction pour certaines invitations, où la visibilité des destinataires a un sens. Ils n’en ont pas nécessairement pour un BYE au milieu d’un dialogue.

La RFC exige donc que le destinataire comprenne l’application et refuse les méthodes qu’il ne comprend pas. Il n’est pas un amplificateur neutre. Il authentifie l’émetteur, vérifie son autorisation, applique les règles d’adhésion et décide si la méthode est valide dans le contexte de chaque cible.

Le support du symbole multiple-refer ne remplace aucune de ces décisions. L’enregistrement IANA coordonne un nom. Il ne prouve ni l’activation locale, ni l’autorité de l’émetteur, ni l’existence des dialogues, ni les résultats.

La normalisation des doublons est également distincte. Une liste soumise peut comporter deux écritures qui désignent la même cible ; le service doit éviter les requêtes dupliquées selon les règles applicables. Il faut donc conserver la liste reçue, l’ensemble effectif et les raisons de fusion.

L’état de conférence était une autre observation

Pour une conférence, la RFC propose le paquet d’événements de conférence comme source de résultats. Cette source décrit l’état que le focus représente à un moment et dans une version donnés. Elle ne transforme pas la réponse au REFER en preuve différée.

Une notification peut être complète ou partielle, arriver en retard ou suivre une interruption d’abonnement. La disparition d’un participant après un BYE est une observation utile, mais elle ne suffit pas à reconstruire le chemin causal. Le participant peut être parti seul, un autre contrôleur peut l’avoir retiré ou l’observateur peut avoir manqué une transition.

Le rapprochement doit maintenir quatre plans : demande, transactions produites, réponses des cibles et état métier observé. Les écarts entre plans sont précisément ce qu’un opérateur doit examiner.

Frontière de preuve

Après un REFER multiple réussi, la formulation défendable est la suivante : un destinataire déterminé a accepté une commande déterminée, dont la référence Content-ID se résolvait vers une liste effective déterminée, sous un accord d’abonnement déterminé. Rien de plus n’est acquis.

Le dossier garde l’identité et l’autorisation de l’émetteur ; la preuve de non-bifurcation ; les octets du REFER ; l’objet visé par cid: ; les listes soumise et normalisée ; la valeur Refer-Sub renvoyée ; une ligne par requête fille ; les réponses ou délais ; l’observation du service avec version et heure ; enfin le résultat humain ou commercial séparé.

Cette granularité protège l’efficacité du mécanisme sans attribuer à son accusé de réception une autorité qu’il n’a jamais reçue.