Résumé

  • Une réponse 2xx à REFER acceptait le traitement de l’instruction et, dans le contrat original, créait un abonnement implicite ; elle ne constatait pas la réussite de la requête référée.
  • Les NOTIFY, la requête déclenchée et l’observation finale avaient des vies distinctes. Se désabonner n’annulait pas l’action, et des abonnements issus d’un fork ne devaient pas être fusionnés.

L’exemple d’Alice, Bob et Carol donne à REFER l’allure d’un transfert téléphonique accompli en une étape. Alice demande à Bob de joindre Carol. Mais RFC 3515 ne disait jamais que la réponse de Bob prouvait la présence de Carol. Il séparait l’ordre, son acceptation, la tentative, les rapports d’avancement et le résultat.

Publié en avril 2003 sur le Standards Track, le RFC définit la méthode REFER, l’en-tête Refer-To et le paquet d’événements refer. La requête doit contenir exactement une valeur Refer-To. Le destinataire contacte la ressource désignée selon le mécanisme ordinaire du type d’URI : une nouvelle INVITE pour un URI SIP, un autre protocole pour un autre schéma.

Un corps pouvait accompagner REFER, mais la spécification ne lui attribuait aucun sens propre. Le récepteur pouvait l’interpréter selon son Content-Type. Cette limite empêchait de transformer n’importe quelle charge utile en commande normalisée par simple présence dans REFER.

Avant d’agir, le destinataire vérifiait forme, capacité, authentification et politique. Pour une requête bien formée, il devait chercher l’approbation de l’utilisateur ou satisfaire cette étape par une politique configurée. Si aucune autre réponse finale ne s’imposait, le contrat de 2003 exigeait 202 Accepted avant expiration de la transaction REFER.

Le terme « Accepted » fermait une question étroite : le destinataire prenait en charge le traitement de REFER. Il ne disait pas que l’INVITE nouvelle avait obtenu un 200 final, qu’une ressource HTTP avait répondu, que des médias circulaient ou qu’une conversation avait commencé. La requête référée pouvait même ne pas encore être émise.

Dans RFC 3515, un 2xx créait aussi un abonnement implicite à l’événement refer. Le destinataire envoyait des NOTIFY parce que l’issue ne tenait pas dans la réponse initiale. L’abonnement était donc une voie d’observation, pas une décoration de la transaction.

Le premier NOTIFY pouvait arriver avant la fin de REFER. L’émetteur devait accepter cet ordre apparent : les nouvelles commençaient pendant que l’échange d’instruction se terminait. Un état pending pouvait se limiter à SIP/2.0 100 Trying. Ce message constatait une attente, pas un contact réussi.

Chaque NOTIFY portait Event: refer et un corps message/sipfrag commençant par une Status-Line SIP. Le code décrivait l’action référée au moment du rapport. Chaque corps était un état complet, non un delta exigeant toutes les notifications précédentes.

Une implémentation minimale pouvait employer 100 pour l’attente, 200 pour une réussite annoncée, 503 pour un échec ou 603 si l’approbation était finalement refusée après acceptation de REFER. Ce dernier cas suffit à démontrer la frontière : une instruction acceptée peut encore conduire à une action refusée.

Deux réponses 200 ne devaient pas être confondues. Le destinataire d’un NOTIFY renvoyait 200 OK pour accuser réception de cette transaction NOTIFY. Ce 200 ne validait ni le code placé dans le sipfrag ni le résultat de la requête référée. Une vue qui réduit les deux lignes à « succès SIP » détruit la causalité.

Pour une action SIP, le notifier pouvait inclure davantage de la réponse originale. Cela pouvait faciliter le débogage, mais RFC 3515 avertissait de graves conséquences de sécurité. Des en-têtes, une topologie ou des détails non destinés au referrer pouvaient fuiter. Une preuve plus riche n’est sûre que si son audience est autorisée.

Pour une ressource non SIP, l’état devait néanmoins être traduit en Status-Line SIP. Le code devenait donc le récit d’un adaptateur. Il ne conservait pas forcément les identifiants, effets ou reçus natifs du protocole, encore moins une conséquence physique.

L’abonnement avait sa propre durée. REFER ne portait pas d’expiration d’abonnement. Le destinataire la choisissait, l’annonçait dans le premier NOTIFY et devait normalement prévoir plus de temps que l’action référée. Le referrer pouvait rafraîchir ou terminer cette observation.

Mais arrêter de regarder n’arrêtait pas d’exécuter. RFC 3515 précise qu’un désabonnement ou le rejet d’un NOTIFY ne demande pas d’abandonner la requête référée. Le destinataire ne devait pas envoyer CANCEL uniquement parce que le referrer avait clos son abonnement. Contrôle de la télémétrie et contrôle de l’opération restaient distincts.

Le fork rendait cette séparation visible à plusieurs branches. Un REFER dans un dialogue existant ne forkait pas. Hors dialogue, il pouvait être accepté par plusieurs agents, chacun créant son abonnement. L’émetteur devait gérer ces états séparément et ne pas les fusionner. Un 200 sur une branche et un 503 sur une autre décrivaient deux tentatives, pas une moyenne.

L’autorisation restait décisive. Un REFER pouvait faire contacter à un agent une ressource SIP, HTTP ou autre, éventuellement protégée depuis un emplacement de confiance. Une politique qui acceptait aveuglément transformait le destinataire en intermédiaire d’accès. Il fallait donc restreindre Refer-To, authentifier l’émetteur et obtenir une autorisation adaptée.

Les mises à jour ont modifié le canal sans abolir la frontière. RFC 4488 a permis de demander la suppression de l’abonnement implicite. RFC 7614 a défini des abonnements explicites. RFC 7647 a clarifié REFER avec le cadre d’événements de RFC 6665, tandis que d’autres textes ont affiné syntaxe et pratiques de transfert. Pour lire une trace, il faut savoir quel contrat était négocié.

Les couches de réalité de Heng Lu éclairent le dessin. Le 202 est un reçu symbolique d’acceptation d’une responsabilité. Le NOTIFY est le rapport d’un notifier dans un abonnement. La requête référée appartient à son protocole. Média, parole humaine et résultat métier exigent encore d’autres observations. Aucun message correct ne fabrique les reçus de la couche suivante.

RFC 3515 n’affaiblissait donc pas la délégation ; il lui donnait plusieurs journaux. L’ordre pouvait être accepté avant la tentative, le suivi pouvait finir avant l’action, et plusieurs branches pouvaient aboutir différemment. Le REFER était accepté. La réussite restait un fait à établir ailleurs.

Sources