Résumé

  • RFC 3608 autorise un registrar à renvoyer un vecteur Service-Route ordonné dans une réponse 2xx à REGISTER; le terminal peut le conserver pour l’adresse d’enregistrement concernée.
  • Ce reçu décrit une proposition à un instant donné. Il ne démontre ni l’emploi ultérieur du vecteur, ni la résolution des URI, ni le passage par chaque relais, ni l’application du service annoncé.

Publié sur la voie des normes en octobre 2003, RFC 3608 définit une extension SIP et son cycle de vie; il n’observe le réseau actuel d’aucun opérateur.

Un reçu peut être authentique tout en étant un mauvais alibi. Imaginons qu’un opérateur retrouve une réponse REGISTER contenant deux valeurs Service-Route. Le document prouve utilement qu’un registrar a proposé ces valeurs dans cet ordre. Il ne prouve pas qu’une requête ultérieure est née, encore moins qu’elle a suivi la chaîne et reçu le service attendu.

RFC 3608 est précis sur ce qu’il crée. Le terminal peut associer la valeur à son adresse d’enregistrement. Lors d’un renouvellement, la dernière réponse réussie remplace l’état précédent. Une réponse sans Service-Route doit effacer l’ancienne valeur; un refus ou l’expiration sans renouvellement doit conduire à l’abandonner. La route apprise possède donc une génération. Sans l’instance REGISTER, l’heure, l’expiration et la lignée des renouvellements, sa présence en base n’a pas de portée temporelle sûre.

La norme laisse aussi une décision au terminal: il peut exercer la route. S’il le fait, il place les valeurs dans Route en respectant leur ordre. Le verbe est important. La capacité de réutiliser une instruction n’est pas la preuve de son usage. Entre le stockage et la requête existent une décision locale, une application, un contexte de compte et parfois plusieurs identités sur le même appareil.

La route complète n’est d’ailleurs pas nécessairement celle du registrar. Un terminal itinérant peut devoir franchir un relais de sortie dans le réseau visité avant d’atteindre le domaine d’origine. RFC 3608 reconnaît que l’assemblage entre route locale, règle de proxy sortant et Service-Route dépend de l’implémentation. Le registrar connaît normalement son domaine administratif; il n’est pas réputé connaître la topologie visitée.

Cette limite sépare Service-Route de Path, défini par RFC 3327. Path est accumulé sur le trajet de REGISTER vers le registrar afin d’aider plus tard les requêtes du domaine d’origine à retrouver le contact. Service-Route repart du registrar vers le terminal et guide éventuellement les requêtes que ce terminal émet. Les confondre sous l’étiquette « chemin SIP » efface le sens, la direction et le détenteur de l’état.

Il faut ensuite distinguer Route de Via. Route contient des instructions encore à traiter. Via s’enrichit au fil du transfert de la transaction et sert notamment au retour de la réponse. Voir un relais dans Route ne signifie pas qu’il l’a reçu. Le voir dans une observation Via rapproche de la traversée réelle, mais ne démontre toujours pas qu’un module de service précis — journalisation, taxation, politique ou autre — a fonctionné à l’intérieur de ce relais.

Les URI ne sont pas des machines immuables. Les procédures de RFC 3263 peuvent sélectionner des transports et des destinations à partir du DNS. Les durées de vie expirent, les priorités changent, une cible tombe et une autre est essayée. Une politique locale peut modifier le choix. Deux requêtes portant la même URI Service-Route peuvent donc aboutir à des adresses, ports ou transports différents.

Les mécanismes plus récents ne suppriment pas cette incertitude. RFC 5626 ajoute des flux sortants et des jetons de flux; RFC 5923 traite de la réutilisation des connexions. Ils fournissent des preuves sur un état de transport. Ils ne font pas d’une réponse d’enregistrement passée le journal d’une requête future. Une connexion établie ne prouve pas que la transaction examinée l’a empruntée.

La sécurité du reçu reste indispensable. RFC 3608 avertit qu’un intermédiaire pourrait modifier ou insérer Service-Route et demande des protections d’intégrité et d’authentification. Une réponse protégée permet d’attribuer plus solidement la proposition au registrar. Elle ne protège pas par anticipation les choix DNS, pannes, changements de politique ou exécutions de service qui viendront plus tard.

Un système vérifiable doit conserver plusieurs pièces, sans les fusionner. Première pièce: la réponse REGISTER exacte, son Call-ID, son CSeq, l’adresse d’enregistrement, le contact, l’ordre des valeurs, l’identité du registrar, le résultat d’authentification, l’heure et l’expiration. Deuxième pièce: la requête ultérieure réellement construite, après combinaison avec la politique locale. Troisième pièce: les réponses DNS, leur âge, la destination et le transport sélectionnés, ainsi que les replis.

La traversée requiert des observations horodatées aux relais concernés, reliées par les identifiants de transaction. L’exécution du service requiert une trace du composant chargé de l’appliquer. Le résultat requiert sa propre mesure: réponse SIP, établissement du dialogue et, si la question porte dessus, résultat média ou applicatif. Session-ID, défini par RFC 7989, peut faciliter la corrélation, jamais fabriquer un événement absent.

Cette séparation accélère le diagnostic. Une mauvaise valeur renvoyée relève de la configuration du registrar. Une valeur périmée conservée relève du cycle de vie client. Une résolution devenue invalide relève de DNS ou du transport. Un relais peut être traversé tout en omettant le service. Une signalisation peut réussir alors que le média échoue. Le mot « enregistré » ne répond à aucune de ces questions.

Il ne s’agit pas d’imposer une conservation illimitée. Les durées peuvent être proportionnées, les identités pseudonymisées et l’échantillonnage adapté au risque. Mais la réduction doit être honnête: si seule la proposition de route est conservée, seul ce fait peut être affirmé.

RFC 3608 fournit une spécification initiale minimale: une syntaxe, un ordre et des règles de renouvellement. Il laisse les décisions ultérieures aux participants qui exécutent le code. C’est une limite saine. Le reçu d’enregistrement devient dangereux seulement lorsqu’une organisation lui prête une autorité sur une réalité qu’elle n’a pas observée.