Résumé

  • SIP Outbound utilise des flux ouverts par le terminal pour lui acheminer de nouvelles requêtes. Il répond notamment aux situations où le serveur ne peut pas établir lui-même une connexion vers ce terminal.
  • Plusieurs enregistrements peuvent désigner des chemins différents vers une même instance. Le mandataire ne doit pas les traiter simultanément comme plusieurs destinataires indépendants.
  • Une erreur 430 concerne un flux défaillant. Une réponse finale provenant de l'instance impose, sauf les exceptions prévues, d'arrêter les tentatives du même envoi par ses autres chemins.

La seconde route devait parfois rester inutilisée

La règle paraît étrange dans un mécanisme destiné à améliorer la disponibilité. Le mandataire possède une autre route vers le téléphone, mais il ne doit pas toujours s'en servir.

Le RFC 5626, publié en octobre 2009, précise le cas : après une réponse finale autre que 408 ou 430, le mandataire ne doit pas transmettre la même requête à une autre cible représentant le même compte et la même instance. Celle-ci a déjà répondu. La réponse n'est pas rendue provisoire par l'existence d'une deuxième connexion.

Si une route est rompue, un nouvel essai peut réparer l'acheminement. Si le destinataire a répondu, un nouvel essai par une autre route peut seulement lui soumettre une seconde fois ce qu'il vient de traiter. Il fallait donc donner à la redondance assez de mémoire pour distinguer ces deux situations.

Cela supposait de savoir ce qui était réellement redondant : le destinataire, son adresse, son enregistrement ou le chemin qui permettait de l'atteindre.

Entretenir le chemin ne renouvelait pas toutes les promesses

La durée d'un enregistrement et la santé d'un flux ne sont pas identiques. Une erreur récupérable pendant le renouvellement de l'enregistrement ne justifie pas nécessairement de fermer une connexion qui continue de répondre aux messages de maintien en vie.

L'inverse est tout aussi instructif. Sur UDP, une réponse STUN peut parvenir au terminal tout en signalant une autre adresse publique ou un autre port. Le changement de XOR-MAPPED-ADDRESS doit être traité comme une défaillance du flux : quelque chose répond encore, mais ce n'est plus l'association enregistrée auparavant.

Le maintien en vie est local au prochain saut SIP. Il ne prouve pas que l'utilisateur final a reçu une demande, et encore moins que le média audio fonctionne. Sa fréquence arbitre entre temps de détection, batterie et charge. L'indication Flow-Timer du serveur n'est pas une garantie de livraison pendant toute la période annoncée.

Le RFC 6223, publié en avril 2011, a rendu explicite la négociation de ces échanges entre voisins au moyen du paramètre Via keep. Il précise que cette négociation ne définit pas la réutilisation des connexions. Maintenir un passage ouvert et décider quelles requêtes peuvent l'emprunter restent deux opérations.

D'autres extensions avaient d'autres objets

Le RFC 5923, de juin 2010, traite des alias de connexions TLS entre voisins capables d'initier une connexion dans les deux sens. L'authentification et la décision du serveur de réutiliser le canal y sont essentielles. Son domaine d'application renvoie précisément à Outbound lorsque le sens d'ouverture est contraint. Une connexion persistante n'est donc pas automatiquement un alias valable pour tout trafic inverse.

Le RFC 5627 répond à une autre question : comment donner à un tiers une URI qui désigne une instance particulière ? Lors d'un transfert, rappeler l'AOR peut atteindre un autre appareil ou la messagerie vocale, alors que l'on veut le terminal déjà engagé dans la conversation. Le GRUU fournit cette cible utilisable depuis l'extérieur, via son domaine. Il ne se confond pas avec le jeton du relais ni avec la preuve qu'un flux est vivant.

Le RFC 7118, de janvier 2014, rend la séparation particulièrement visible dans son scénario SIP sur WebSocket. Un client de navigateur peut employer un nom aléatoire sous .invalid dans Contact lorsqu'il a demandé et obtenu Outbound. Il ne connaît pas nécessairement son adresse de transport locale ; les requêtes reviennent par le mandataire et le flux existant. C'est une possibilité conditionnelle de ce scénario, pas une permission générale de publier des Contacts inutilisables.

Le registre SIP d'IANA fixe les noms et références de ces codes et paramètres. Il ne dit pas combien de produits les appliquent correctement. Le résultat historique est plus précis qu'une nouvelle promesse de disponibilité : plusieurs chemins peuvent rester plusieurs chemins, sans que le destinataire et sa réponse soient comptés plusieurs fois.

Une inscription ne fabriquait pas une entrée dans le pare-feu

Dans le SIP de 2002, décrit par le RFC 3261, l'enregistrement associe une adresse de référence, l'AOR, à un ou plusieurs Contacts. Le service de localisation fournit au mandataire les correspondances nécessaires pour acheminer une demande destinée à cet utilisateur. Le serveur d'enregistrement et le mandataire peuvent être deux fonctions d'un même équipement.

Ce modèle n'exige pas que l'adresse de l'utilisateur soit celle d'une machine permanente. Il doit cependant conduire à un terminal joignable. Or un téléphone situé derrière un NAT ou un pare-feu peut établir une connexion sortante sans accepter une nouvelle connexion venue du serveur. Un ordinateur peut également agir comme client TLS sans disposer d'un nom stable et du certificat qui permettraient d'en faire un serveur accessible de la même manière.

Recevoir la réponse à REGISTER ne résout pas cette difficulté. Sur un transport fiable, SIP renvoyait déjà la réponse par la connexion utilisée pour la requête, tant qu'elle restait ouverte. Un INVITE arrivant plus tard n'est pas une réponse à cet enregistrement : c'est une nouvelle requête, pour laquelle il faut trouver un chemin retour utilisable.

Outbound s'appuie sur le flux créé par le terminal. Avec TCP, ce flux correspond à une connexion. Avec UDP, il désigne une association bidirectionnelle caractérisée par les adresses, les ports et le protocole de transport. Il ne faut donc pas ramener toute l'extension au maintien d'une connexion TCP. L'idée commune est de réutiliser une association dont on connaît le lien avec le terminal, au lieu de supposer que le serveur peut ouvrir une nouvelle voie vers le Contact.

Le chemin devait garder la mémoire de son premier relais

Le terminal n'est pas nécessairement relié directement au serveur d'enregistrement. Un mandataire de bordure peut recevoir REGISTER, puis le transmettre. Pour les requêtes futures, le serveur doit savoir qu'il faut repasser par ce relais.

Le RFC 3327, paru en décembre 2002, avait défini Path pour conserver cette information. Les intermédiaires inscrivent leur présence pendant l'enregistrement ; le vecteur obtenu est mémorisé avec la correspondance et placé dans Route lors d'une demande ultérieure passant par le domaine d'origine.

Ce n'est pas un itinéraire universel imposé à tout correspondant. Ce n'est pas non plus un dialog créé par REGISTER. Record-Route et Path ont des usages différents : l'un intervient dans le routage d'un dialog, l'autre permet de retrouver un terminal enregistré pour des demandes futures.

Outbound ajoute une précision décisive. Le premier relais doit pouvoir retrouver le flux particulier établi avec le terminal. Il introduit dans Path un jeton de flux, protégé contre les modifications, et l'indication ob prévue pour ce contexte. Le jeton n'est pas un nom mondial du téléphone. Il est une information exploitable par le relais pour reconnaître une association précise.

Cette distinction compte après un redémarrage ou la réutilisation d'une ressource locale. Une nouvelle connexion qui reçoit un ancien numéro de descripteur ne devient pas, pour cette raison, la connexion de l'ancien destinataire. Le système doit supprimer les correspondances liées à un flux dont il sait qu'il ne livrera plus rien.

Le même appareil pouvait revenir sous plusieurs enregistrements

Pour limiter l'interruption pendant la détection d'une panne, un terminal peut enregistrer plusieurs flux. Il faut alors distinguer l'identité persistante de l'instance et les inscriptions de chaque chemin.

Le instance-id reste stable lorsque l'appareil redémarre ou change de réseau. Les reg-id distinguent ses flux simultanés. Au redémarrage, le terminal réemploie la même série de reg-id afin que ses nouvelles inscriptions remplacent les anciennes. Il ne cherche pas à éviter toute collision de numéro ; il provoque les bonnes collisions pour éliminer les correspondances périmées.

La clé de la correspondance devient l'AOR avec l'instance-id et le reg-id. Le Contact reste conservé : le mandataire en a besoin pour construire ses cibles. Mais la comparaison des Contacts ne porte plus, à elle seule, toute la signification de l'enregistrement.

Le RFC interdit en conséquence de mettre simultanément plusieurs Contacts du même AOR et de la même instance dans l'ensemble des cibles. Un utilisateur peut bien avoir plusieurs terminaux. Ce qui ne doit pas être multiplié, c'est la tentative destinée à une seule instance simplement parce qu'elle dispose de plusieurs chemins.

Deux lignes dans la table ne prouvent donc ni deux téléphones, ni deux utilisateurs, ni même deux domaines de panne réellement indépendants.

Une panne pouvait être découverte du côté de l'appelant

L'exemple du RFC 5626 met en scène un terminal enregistré par deux relais. Le premier relais tombe, puis redémarre. Une demande arrive avant que le terminal ait constaté la disparition de son ancien flux.

Le relais ne retrouve plus ce flux et renvoie 430 Flow Failed. Le mandataire chargé de l'AOR peut sélectionner une autre correspondance du même AOR et de la même instance, avec un autre reg-id. Le second relais reçoit alors la demande et assure le routage du nouveau dialog. Le terminal répare plus tard son inscription par le premier relais.

Il s'agit d'un exemple de spécification, pas d'un incident observé chez un opérateur. Il n'établit pas non plus que tous les dialogs existants migreraient sans interruption. Il montre qu'une nouvelle requête peut être sauvée sans attendre que le terminal achève sa propre détection de panne.

430 ne condamne que le chemin concerné. La norme le destine aux échanges entre mandataires ; un terminal ne devrait pas le recevoir et le traite comme 400 si cela arrive. Un jeton altéré appelle un autre traitement, avec une réponse 403 recommandée. Ni l'identité de l'utilisateur ni son éventuelle décision ne doivent disparaître derrière un code générique de « problème réseau ».

La règle d'arrêt prend ici tout son sens. Le mandataire peut changer de route après une défaillance de flux ; il ne peut pas utiliser les routes suivantes pour ignorer une réponse finale déjà obtenue, hors les exceptions 408 et 430. Cela ne règle pas tous les nouveaux appels futurs. Cela borne une tentative précise vers une instance précise.