Résumé

  • Reason permettait à une requête SIP de conserver la cause protocolaire de son émission, de sorte que deux CANCEL identiques puissent produire des journaux et interfaces différents.
  • Le champ restait facultatif, pouvait être ignoré et ne modifiait pas le traitement SIP ; sa présence ne prouvait ni l’événement, ni son auteur initial, ni la fidélité de sa traduction.

Le silence ne disait pas si l’appel avait réussi

Lorsqu’un proxy distribuait un INVITE vers plusieurs appareils, la première branche qui répondait pouvait gagner. Le proxy envoyait alors CANCEL aux branches encore en train de sonner. Pour ces appareils, le résultat visible était le silence. Le même silence apparaissait si l’appelant abandonnait avant toute réponse.

Pourtant, l’interface ne devait pas nécessairement écrire la même histoire. Si une autre branche avait répondu, afficher un appel manqué serait trompeur. Si l’appelant avait renoncé, l’entrée pouvait être utile. La méthode CANCEL commandait l’arrêt, mais elle ne conservait pas à elle seule le fait qui avait provoqué la commande.

RFC 3326 définit Reason pour maintenir cette différence. Dans le premier scénario, le proxy pouvait ajouter à CANCEL une cause SIP 200 accompagnée de l’explication « appel terminé ailleurs ». L’appareil recevait toujours une annulation ordinaire ; il obtenait en plus le contexte permettant de choisir un affichage différent.

L’innovation ne consistait donc pas à multiplier les méthodes SIP selon chaque motif. Elle consistait à séparer l’action de sa causalité. Reason pouvait apparaître dans toute requête à l’intérieur d’un dialogue, dans tout CANCEL et dans les réponses dont le code autorisait explicitement sa présence. BYE pouvait ainsi expliquer qu’une offre reçue dans une réponse réussie était inacceptable, ou qu’un contrôleur tiers avait découvert l’occupation d’un autre participant.

Dans tous ces cas, un événement observé dans une branche, un dialogue ou un autre protocole provoquait une nouvelle requête. Le champ transportait un fragment de cette origine vers le lieu où l’action devenait visible.

L’explication pouvait être ignorée

La frontière la plus importante du texte est facile à manquer : clients et serveurs pouvaient ignorer Reason, et le champ n’avait aucun effet sur le traitement du protocole. CANCEL annulait avec ou sans lui. BYE terminait le dialogue même si le destinataire ne comprenait pas la cause.

Reason n’était donc pas un second moteur de contrôle. Il fournissait une information à l’interface, au service ou au diagnostic. Une capture prouve qu’une valeur était présente à cet endroit. Elle ne prouve pas qu’une autre branche avait réellement répondu, que l’émetteur final avait vu cet événement, que tous les intermédiaires avaient conservé la valeur ou que le destinataire l’avait utilisée.

La syntaxe protégeait une autre distinction. Chaque valeur commençait par un protocole. Une cause SIP était un code de réponse SIP ; une cause Q.850 appartenait à l’univers ISUP. Le même nombre n’avait pas automatiquement le même sens dans les deux espaces. Une base de données qui supprimait le protocole pour ne garder qu’un entier fabriquerait une ambiguïté irréversible.

Le paramètre text rendait la valeur lisible, mais ne remplaçait pas le code structuré. Les formulations humaines peuvent être traduites, abrégées ou modifiées. Pour conserver une preuve exploitable, il faut stocker séparément protocole, cause, texte et extensions.

Le RFC d’origine n’autorisait plusieurs valeurs que si chacune utilisait un protocole différent. RFC 9366 a ensuite autorisé plusieurs valeurs du même protocole lorsque l’enregistrement de ce protocole définit leur sens collectif. À défaut, l’unicité par protocole reste obligatoire. Une liste répétée ne possède donc pas de signification universelle ; le registre gouverne son interprétation.

Le passage entre réseaux ajoutait de la valeur et du doute

Les passerelles rendaient le mécanisme particulièrement utile. RFC 3398 décrit les correspondances entre ISUP et SIP. Quand une passerelle recevait un message de libération du réseau téléphonique, elle pouvait placer sa cause Q.850 dans le CANCEL SIP. L’autre côté apprenait davantage que le seul fait que la sonnerie devait cesser.

RFC 6432 a ensuite permis de transporter une cause Q.850 dans les réponses SIP autres que 100 Trying. RFC 8606 a ajouté le paramètre location lorsque l’emplacement de libération ISUP était disponible. Cet emplacement désigne une partie grossière du réseau—réseau local, de transit ou distant—et non la position physique ni l’identité des personnes.

Chaque traduction allonge cependant la chaîne. La valeur visible peut avoir été extraite d’un message ISUP, produite localement, copiée d’un voisin ou remappée selon une table particulière. Le dernier émetteur n’est pas forcément le premier observateur. La preuve complète demande le message source, la version de la table, l’identité de la passerelle et l’historique des copies.

History-Info de RFC 7044 et l’ancien mécanisme Diversion de RFC 5806 répondent à des questions voisines mais distinctes. Ils racontent le réacheminement ou la déviation. Reason explique pourquoi une requête ou une réponse permise a été émise. Une succession de cibles n’est pas une cause de libération ; une cause ne reconstitue pas toute la route.

Copier la cause pouvait copier l’erreur

Quand un proxy recevait un CANCEL portant Reason et créait un nouveau CANCEL vers l’étape suivante, il devait normalement copier le champ. Sans cette copie, l’action continuait tandis que son explication disparaissait. Avec elle, l’appareil final pouvait éviter un faux appel manqué.

Mais la copie éloignait aussi la valeur de son observation initiale. Un proxy pouvait répéter sans savoir. Un intermédiaire pouvait modifier le texte, perdre une extension, remplacer la cause ou supprimer le champ. Il faut donc distinguer « observé », « traduit » et « relayé » dans les journaux, même si les octets finaux semblent propres.

Le risque devenait opérationnel dans le problème HERFP : l’erreur finale d’une branche pouvait rester cachée pendant que d’autres branches continuaient. Falsifier ou supprimer Reason pouvait empêcher le client de corriger sa requête précédente et rendre l’établissement de session impossible. RFC 3326 recommandait donc une protection d’intégrité adaptée.

Une intégrité validée atteste seulement que les octets protégés n’ont pas changé entre des extrémités identifiées. Elle ne prouve ni l’événement réel, ni l’honnêteté de l’affirmation initiale, ni la justesse du mappage. L’absence de protection n’annule pas tout intérêt ; elle interdit simplement de tirer une conséquence forte sans autre corroboration.

RFC 3326 a ainsi préservé une chose que le changement d’état effaçait : la cause alléguée de l’action. Son héritage n’est pas de rendre le passé certain, mais de fournir une enveloppe structurée où action, cause, espace de codes et provenance peuvent rester distincts.

Sources