Résumé

  • History-Info conserve les Request-URI que les intermédiaires compatibles déclarent lorsqu’une requête initiale est reciblée ou dupliquée. Les hi-index dessinent un arbre ordonné ; rc, mp et np qualifient trois types de changement.
  • Cet arbre peut traverser des nœuds non compatibles, contenir des entrées anciennes ou suppléées, omettre une branche encore en attente et masquer légitimement une cible pour protéger la vie privée. TLS ne rend pas les intermédiaires de confiance infaillibles.
  • Une décision de routage défendable associe la trace au moteur de règle, à son propriétaire, aux données consultées, aux branches, au traitement de confidentialité et au résultat observé. La trace décrit un parcours ; elle ne lui confère pas sa légitimité.

Le rapport d’incident qui commence par la conclusion

Un centre d’assistance constate qu’un appel destiné à une équipe locale a abouti dans une messagerie gérée par un partenaire. Le rapport automatique affiche un arbre History-Info impeccable. Chaque index est valide, chaque URI semble s’enchaîner, la dernière branche a reçu une réponse finale. La première ligne du rapport affirme donc : « routage conforme ».

Cette conclusion ne figure pourtant nulle part dans le protocole.

La trace peut établir qu’à un point d’observation donné, une requête contenait une suite ordonnée de cibles. Elle ne dit pas quel administrateur a activé la règle, si le partenaire appartenait encore au périmètre contractuel, si l’annuaire consulté était à jour, si une branche concurrente a été cachée, si un service de confidentialité a anonymisé une URI, si un intermédiaire sur le chemin a modifié l’en-tête, ni si l’appelant a réellement obtenu le service attendu.

RFC 7044 définit History-Info pour combler une perte précise : lorsqu’un intermédiaire modifie la Request-URI, l’adresse précédente disparaît normalement de la requête transmise. Le nouvel en-tête conserve les cibles rencontrées par une requête initiale ou hors dialogue. Il ne normalise pas la politique locale qui a choisi ces cibles.

Le choix de la cible précède son récit

Dans le modèle de RFC 3261, un proxy effectue une détermination de cible. Il peut consulter un service de localisation, suivre une redirection, appliquer une configuration ou créer plusieurs branches. La Request-URI sortante indique la destination actuelle. Sans mécanisme complémentaire, elle n’explique pas la destination antérieure.

RFC 7044 nomme reciblage l’opération par laquelle une entité change la Request-URI conformément à ses règles puis relaie la requête. History-Info raconte le résultat observable de cette opération.

L’ordre des pouvoirs est essentiel. Le code exécuté par le proxy, le PBX ou le B2BUA choisit. L’en-tête rapporte. La norme définit une syntaxe commune. Le registre IANA des paramètres SIP attribue les noms History-Info, histinfo, history, rc, mp et np. Aucune de ces couches n’approuve à elle seule la règle d’entreprise, le contrat ou le consentement qui rendrait le détour légitime.

Le champ d’application reste celui des requêtes initiales ou hors dialogue. History-Info n’est pas le journal universel d’un appel. Les messages ultérieurs dans un dialogue, les flux média, l’enregistrement, la présence d’un agent, la facturation et la résolution du problème forment d’autres réalités.

Des coordonnées d’arbre, pas des horodatages

Chaque entrée possède une URI ciblée et un hi-index obligatoire. L’index est composé d’entiers non négatifs séparés par des points. Un enfant prolonge l’index de son parent ; un fork produit des enfants frères. Les entrées sont ordonnées en parcours préfixe afin de rendre la structure reconstruisible.

Cette représentation évite qu’une liste plate fasse passer deux branches parallèles pour deux redirections successives. Elle ne constitue cependant pas une horloge. L’index ne donne aucune durée, ne synchronise pas des nœuds indépendants et ne prouve pas qu’une branche située plus loin dans l’ordre a terminé plus tard.

Trois paramètres décrivent le mécanisme déclaré :

  • rc indique que la Request-URI a changé alors que l’entité considère l’utilisateur cible comme inchangé, par exemple d’une adresse publique vers un Contact enregistré ;
  • mp indique un mappage vers un autre utilisateur cible ou une autre adresse de référence ;
  • np indique que seul le prochain saut a changé, sans modification de la Request-URI.

Ils pointent vers d’autres entrées de l’arbre. Ils ne transportent aucune décision d’autorisation. Deux identités classées « même utilisateur » par un équipement peuvent relever de responsabilités juridiques différentes. Un mp correctement formé peut matérialiser une règle périmée. Un np ne garantit pas la probité du prochain intermédiaire.

Une absence n’a pas un sens unique

La prise en charge est facultative. histinfo s’annonce dans Supported ; il n’est pas imposé à chaque saut avec Require ou Proxy-Require. Un nœud non compatible peut créer une lacune sans malveillance.

Des entrées héritées de RFC 4244, désormais obsolète, peuvent aussi circuler. RFC 7044 exige leur transmission, mais interdit à un nœud d’inventer rétrospectivement rc, mp ou np pour une décision qu’il n’a pas observée. L’absence de paramètre ne prouve donc pas l’absence de reciblage.

Il existe même un traitement explicite des lacunes. Si la Request-URI reçue ne correspond pas à la dernière entrée, le destinataire ajoute une entrée pour le compte de l’entité précédente. Il peut attester qu’une modification a eu lieu, pas le mécanisme qui l’a provoquée. La nouvelle entrée reste sans rc, mp ou np.

Les forks créent une incomplétude temporelle. Dans un exemple de RFC 7044, une branche renvoie 200 tandis qu’une autre n’a pas encore répondu. La réponse gagnante ne peut pas contenir l’avenir de la branche en attente. Un collecteur placé du côté du gagnant reçoit un arbre valable, mais pas nécessairement l’ensemble de la tentative.

Les exemples de confidentialité de RFC 4244 montrent une autre tension : lorsqu’une branche privée est masquée, l’amont peut retenter une cible qu’il ignore avoir déjà été sollicitée. Ce n’est pas une faute automatique du mécanisme de confidentialité. C’est une raison d’établir des comportements prudents lorsque l’histoire est partielle.

La formulation rigoureuse est donc locale : « ce message contenait ces entrées à ce point d’observation ». La formulation « voici tout le parcours » demande des preuves supplémentaires.

Reason n’est pas la cause souveraine

Une entrée peut inclure des informations Reason dans la partie headers de l’URI. RFC 3326 définit notamment des causes SIP et Q.850 et permet plusieurs espaces de causes. RFC 7044 s’en sert pour contextualiser certains échecs ou délais d’attente.

Cela aide à comprendre qu’une branche a signalé « occupé » ou qu’un délai a été traité comme 408. Cela ne prouve ni la motivation humaine de la redirection, ni la validité de la politique, ni la vérité du système aval, ni la cause commerciale d’un incident. Reason peut être ignoré pour le traitement protocolaire et, sans intégrité, modifié ou supprimé.

Le registre des errata de RFC 7044 contient trois éléments Reported, dont une question technique sur les classes de réponse concernées, une question d’indexation et une correction de renvoi éditorial ; deux autres sont Rejected. Reported ne signifie pas Verified. Le statut doit rester visible dans une analyse d’implémentation.

La confidentialité réduit volontairement le champ visible

Les anciennes cibles peuvent révéler un appareil personnel, une identité secondaire, un service interne, une boîte vocale ou la topologie d’un réseau. RFC 3323 explique pourquoi la confidentialité SIP dépend souvent des intermédiaires : ils ajoutent eux-mêmes des informations de route.

RFC 7044 introduit la valeur history pour Privacy. La protection peut viser l’histoire concernée ou une entrée donnée. Un domaine peut protéger ses chemins internes même si la requête entrante ne réclame rien. Un UAS peut empêcher l’appelant de découvrir la cible finale. À la frontière, un service peut remplacer l’URI par une adresse sous anonymous.invalid.

Une telle anonymisation peut être exactement le comportement attendu. Elle ne doit pas être automatiquement qualifiée de falsification. Elle réduit néanmoins la proposition démontrable par l’auditeur aval. Le journal devrait nommer la frontière, la règle de confidentialité et l’existence d’une correspondance protégée accessible aux personnes habilitées.

L’autorité qui choisit une cible et celle qui peut la cacher ne sont pas nécessairement les mêmes. Une architecture saine enregistre les deux décisions séparément.

TLS protège le transport, pas la vertu

RFC 7044 recommande fortement TLS ou un environnement sécurisé. SIPS protège contre un acteur arbitraire hors chemin dans son modèle de confiance. Les intermédiaires du chemin doivent toutefois lire et enrichir History-Info.

Un intermédiaire malveillant ou compromis peut supprimer, déplacer ou réécrire des entrées. RFC 7044 indique explicitement que le mécanisme ne prévient ni ne détecte cette modification par un intermédiaire malveillant.

Il faut donc conserver, à chaque observation, le pair TLS, le résultat de certificat, le domaine de confiance et l’empreinte du message. « Transporté par SIPS » est une propriété de canal. « Attesté de bout en bout » serait une propriété bien plus forte, que l’en-tête ne fournit pas.

L’application doit déclarer sa propre lecture

RFC 7044 demande aux applications de prévoir les informations manquantes ou incomplètes. Différents services peuvent légitimement sélectionner différentes positions rc.

Un PBX d’entreprise et une messagerie grand public ne recherchent pas nécessairement la même identité appelée. Si l’appel a été transféré avant d’entrer dans l’entreprise, choisir aveuglément le premier rc peut attribuer l’appel à une personne extérieure. RFC 4458 illustre une limite comparable pour les services vocaux : les paramètres target et cause peuvent apparaître dans la Request-URI courante ou dans History-Info selon les capacités des proxies et le chemin suivi.

L’application doit préciser son objet, ses domaines de confiance, son traitement des lacunes et de la confidentialité, ainsi que son choix lorsque plusieurs entrées se contredisent. La norme commune reste ainsi minimale. Les décisions futures ordinaires restent locales, auprès de ceux qui possèdent le contexte et supportent la perte — l’un des principes de Heng Lu. Ce choix local doit toutefois être exportable et contestable.

Construire le dossier au-delà de l’en-tête

Le premier niveau conserve le message : méthode, Request-URI reçue et envoyée, Call-ID, CSeq, branche Via, horodatage, point d’observation et empreinte contrôlée.

Le deuxième conserve séparément l’arbre reçu et l’arbre émis : ordre exact, index, URI, référence rc/mp/np, Reason, confidentialité, format ancien, résultat d’analyse et lacune ajoutée. Il ne complète jamais un mécanisme manquant par intuition.

Le troisième décrit la décision réelle : identifiant et version de la règle, source de consultation, résultat, réponse de redirection, ensemble des candidats, cible choisie, ordre de repli, création des branches, identité de service, locataire, propriétaire et approbation.

Le quatrième sépare confiance et confidentialité : domaines d’entrée et de sortie, pair TLS, transformation, règle, table de correspondance protégée, droits et durée de conservation.

Le dernier relie les transactions de chaque branche, réponses, délais, CANCEL, branche gagnante, jambes amont et aval d’un B2BUA, dialogue, média, application atteinte, enregistrement, facturation et plainte.

Les contradictions sont précieuses. Un gagnant peut omettre un frère connu. Un rc peut contredire une frontière de locataire. Reason peut diverger du journal applicatif. Un B2BUA peut produire un arbre correct sans savoir relier ses deux jambes. Une réponse 200 peut coexister avec un échec média. Les effacer derrière « conforme » revient à créer du pouvoir par compression.

Sources