Résumé

  • RFC8599 impose de renouveler périodiquement la référence privée PURR, même lorsque les coordonnées de notification restent identiques, tout en gardant les anciennes valeurs utilisées par des dialogues en cours.
  • Cette référence appartient au contexte du proxy. Elle ne vaut ni identité mondiale du terminal, ni autorisation générale de le réveiller, ni garantie que tous les messages arriveront.
  • La bonne frontière associe discrétion extérieure et responsabilité locale : limiter les rapprochements possibles sans supprimer prématurément les dépendances d’une conversation.

Une réussite récente peut dissimuler un abandon ancien

Le cas délicat n’est pas le premier appel passé après une inscription réussie. C’est une requête envoyée au milieu d’un dialogue commencé plus tôt. Le terminal a pu obtenir depuis une nouvelle référence de notification ; son interlocuteur peut néanmoins utiliser celle reçue lors de l’établissement du dialogue. Si le proxy ne connaît plus cette ancienne valeur, la bonne santé de la dernière inscription ne résout rien.

Imaginons deux dialogues, sans prétendre décrire un incident réel. Le premier a été établi avec une référence que nous nommerons P1. Une inscription ultérieure fournit P2, qu’un autre dialogue pourra annoncer. Une requête concernant le premier arrive encore avec P1. Ces noms sont des repères pédagogiques, non des captures de paquets. La question est de savoir si le système sait servir une dépendance qui n’a pas pris fin.

Une démonstration centrée sur P2 peut être parfaitement convaincante et pourtant insuffisante. La nouvelle valeur existe, le terminal peut s’inscrire et les nouveaux échanges fonctionnent. Rien de cela ne prouve que le dialogue antérieur a cessé d’utiliser P1. Le renouvellement d’une référence ne constitue pas, en lui-même, une notification de fin de toutes les relations qui l’emploient.

C’est ce que rend explicite RFC8599, publié en mai2019. Dans ses dispositions sur les dialogues de longue durée, le texte exige de produire périodiquement une nouvelle PURR, même sans modification des paramètres de notification. Il exige aussi de conserver les anciennes valeurs aussi longtemps que les dialogues auxquels elles sont associées demeurent en cours. Les deux obligations se complètent ; aucune n’annule l’autre.

L’application endormie n’est pas une inscription effacée

SIP organise la signalisation, mais un système mobile peut suspendre l’application qui doit la recevoir. La présence d’une inscription n’assure donc pas que cette application reste disponible à tout instant sur une connexion. Le mécanisme de RFC8599 fait intervenir un service de notification, désigné PNS : le proxy lui demande de réveiller l’agent utilisateur, qui renouvelle ensuite son inscription.

La notification n’est pas le message SIP transporté sous un autre nom. Elle permet de remettre l’application dans une situation où la signalisation peut l’atteindre. Confondre ces fonctions conduirait à prendre l’acceptation d’une notification par le fournisseur pour la preuve que la requête de dialogue a été effectivement reçue et traitée.

L’agent utilisateur obtient auprès du fournisseur un identifiant PRID, avec un format propre au service. Le proxy reçoit les paramètres nécessaires dans l’inscription SIP : le fournisseur, cet identifiant et, si le service le réclame, un paramètre supplémentaire. La découverte du fournisseur, l’inscription auprès de celui-ci et l’entretien de cette relation ne sont pas uniformisés par RFC8599.

La durée de validité d’un abonnement au service, celle d’une association d’inscription SIP et celle d’un dialogue constituent ainsi des questions différentes. Une application peut se réveiller sans que tout message en attente reste encore utile. Un dialogue peut se poursuivre sans qu’une ancienne coordonnée de fournisseur reste autorisée. La continuité doit être examinée à la bonne échelle.

Les procédures s’appliquent d’ailleurs aux différentes associations d’inscription, et non à une inscription mondiale inventée pour simplifier le raisonnement. Plusieurs associations peuvent exister pour un agent utilisateur. Leur remise à jour après une notification ne transforme pas cette pluralité en une identité centrale unique.

Une référence destinée à ne pas tout révéler

Transmettre à l’interlocuteur les coordonnées privées nécessaires au service de notification serait une manière commode, mais risquée, de lier signalisation et réveil. RFC8599 choisit une indirection. En dehors des requêtes REGISTER, l’agent utilisateur ne doit pas insérer les paramètres de notification concernés, sauf pn-purr. Le correspondant reçoit une référence, pas les renseignements privés permettant au proxy de demander la notification.

PURR signifie Proxy Unique Registration Reference. Le caractère unique est défini dans le contexte du proxy qui la produit. Ce dernier retrouve les renseignements conservés à partir de la valeur reçue. Le mécanisme ne demande ni répertoire universel des téléphones ni organisme chargé d’attribuer une identité durable à chaque application.

La valeur doit être impossible à forger, anonyme et non corrélable pour les entités autres que le proxy. Un grand espace de valeurs aléatoires produites de manière sûre constitue une possibilité ; ce n’est pas la désignation d’une recette obligatoire valable pour tous les exploitants. L’exigence porte sur les propriétés de la référence et sur l’usage qui en est fait.

L’exception concernant le proxy n’est pas une faiblesse accidentelle. Celui qui doit résoudre la demande a besoin de connaître l’association. La confidentialité recherchée consiste à empêcher les autres de reconstituer les mêmes rapprochements à partir de la valeur. Elle ne démontre pas que les en-têtes SIP, les métadonnées de dialogue ou les journaux d’exploitation sont tous anonymes.

Il faut également résister à une confusion avec GRUU. RFC5627 décrit une URI globalement routable destinée à joindre une instance précise d’agent utilisateur. PURR sert ici à retrouver localement des renseignements d’inscription pour une notification. Le fait que ces instruments participent tous deux à la joignabilité ne leur donne pas la même portée.

Le bénéfice du renouvellement apparaît alors plus nettement. Une valeur extérieure stable faciliterait des rapprochements au fil du temps. En produire de nouvelles réduit cette facilité, mais seulement si les anciennes ne deviennent pas un second annuaire partagé sans limites. La responsabilité interne et l’exposition externe n’ont pas à suivre une politique identique.

Le choix appartient à chaque dialogue

La prise en charge par le proxy ne suffit pas à enrôler toutes les conversations. L’agent utilisateur choisit, selon sa politique locale, si un dialogue doit permettre la réception de requêtes intermédiaires avec l’aide d’une notification. Le choix peut dépendre de caractéristiques de ce dialogue ou de ses médias. Il ne se résume pas à un consentement permanent pour tout ce que le terminal fera ensuite.

Quand il choisit le mécanisme, l’agent inclut pn-purr dans le Contact initial pertinent, avec la dernière valeur sip.pnspurr reçue. S’il n’a pas reçu l’indicateur de prise en charge, il ne doit pas fabriquer le paramètre. L’interlocuteur doit pouvoir se fier à une capacité effectivement annoncée, non à une promesse créée unilatéralement par l’application.

RFC6809 fournit le cadre Feature-Caps pour annoncer les capacités d’entités qui ne sont pas représentées par l’URI Contact. Le registre IANA décrit sip.pnspurr comme une capacité d’association entre une requête de dialogue et les renseignements d’inscription. Cette annonce ne donne pas au correspondant des droits généraux sur le fournisseur de notification.

Plusieurs décisions demeurent donc distinctes : l’application choisit le dialogue concerné ; le routage conduit la requête au bon proxy ; celui-ci retrouve l’association ; le service de notification applique ses propres conditions d’admission. Un succès au dernier niveau ne prouve pas que les conditions des précédents sont réunies.

Cette répartition permet de conserver une politique adaptée aux applications sans imposer une autorité extérieure qui approuverait chaque conversation. Elle impose aussi une certaine discipline de langage. « Référence reconnue » ne signifie pas « réveil toujours autorisé », et « notification acceptée » ne signifie pas « requête SIP terminée avec succès ».

Le renouvellement change l’avenir, pas automatiquement le passé

Les deux obligations de RFC8599 ne portent pas sur la même chose. La production de nouvelles valeurs concerne notamment ce qu’observeront les interlocuteurs futurs. La conservation des valeurs antérieures concerne les dépendances encore présentes. Le proxy doit pouvoir effectuer les deux opérations sans présenter la seconde comme un refus de protéger la vie privée.

Une nouvelle réponse d’inscription peut fournir une référence récente sans prouver que chaque dialogue établi a remplacé les informations de contact qu’il avait apprises. Tant qu’un dialogue en cours utilise l’ancienne association, sa résolution reste nécessaire. Le texte ne permet pas de déduire sa fin du simple passage d’un calendrier d’entretien.

Cela ne signifie pas conserver indéfiniment toutes les valeurs. L’obligation est attachée aux dialogues associés qui restent en cours. RFC8599 ne prescrit pas un intervalle mondial de renouvellement ni un nombre universel d’heures de conservation. Un exploitant doit rendre compte de la dépendance réelle ; il ne peut substituer un délai arbitraire à cette explication.

La conséquence pour la mémoire est une question d’ingénierie locale. Le nombre des inscriptions courantes ne décrit pas forcément toutes les associations encore utiles. La fréquence d’émission des références, la durée des dialogues et la clôture de leurs dépendances peuvent compter. Ce raisonnement n’est ni une mesure de capacité réalisée ici, ni un modèle de données imposé par le standard.

Une relève de proxy rend le problème visible. Copier la dernière inscription sur un nouveau nœud ne prouve pas que ce nœud saura servir P1. La réplication, le déplacement d’état ou l’organisation des partitions ne sont pas définis par un protocole universel dans RFC8599. L’adoption de la fonction n’est pas la preuve de sa continuité lors d’un changement d’exploitation.

Il existe donc une obligation sans institution nouvelle : celui qui détient l’association locale doit expliquer comment elle reste utilisable par les dialogues qui en dépendent. La difficulté de cette explication ne justifie pas, à elle seule, un registre central des références.

Il faut encore passer par le proxy

Même une association correctement conservée ne suffit pas si la requête intermédiaire ne parvient pas à l’entité capable de la retrouver. Le proxy participant doit s’inscrire dans Record-Route selon les procédures d’établissement applicables, afin de rester sur le chemin des requêtes du dialogue. Le jeu de routes du dialogue et la cible distante de RFC3261 constituent le cadre.

Il ne faut pas confondre ce chemin avec Path. RFC3327 traite des intermédiaires à traverser pour rejoindre un agent inscrit. Record-Route conserve un chemin pour le dialogue établi. Une inscription peut donc paraître bien renseignée sans démontrer que le message d’une conversation antérieure visitera le proxy qui détient PURR.

Les flux de RFC5626 apportent encore une autre réponse : connexions initiées par l’agent, entretien de la traversée de NAT et possibilités de connexions multiples. Ils ne dispensent pas de se demander si l’application peut recevoir la signalisation. Une connexion, une association d’inscription et un dialogue ne sont pas trois noms pour un seul état de disponibilité.

Lors du traitement concerné, pn-purr peut se trouver dans l’URI de la requête ou dans une URI Route, selon le jeu de routes. Si le proxy peut retrouver les renseignements nécessaires, il conserve la requête en attente et demande une notification. La réponse2xx de la transaction REGISTER associée permet ensuite de transmettre la requête intermédiaire correspondante.

Le proxy n’emploie pas pour cette association la comparaison d’URI du paragraphe5.3 destinée à d’autres traitements. La requête de dialogue ne transporte précisément pas les coordonnées pn-prid, pn-provider et pn-param. La référence sert à établir le lien que ces renseignements ne peuvent plus fournir dans le message reçu.

Cette séquence est celle des requêtes intermédiaires visées par le paragraphe6.2.3. Les requêtes initiales disposent d’autres règles et de conditions liées aux transports. Affirmer que toute signalisation SIP attend nécessairement une réponse REGISTER2xx ferait disparaître une distinction que le standard conserve.

Les limites survivent à la conservation

Une ancienne référence utile ne rend pas éternelle l’autorité de notification. Quand le proxy est informé qu’une association d’inscription a expiré ou a été supprimée, il ne doit plus demander de notification avec le PRID concerné. La conservation d’une dépendance de dialogue n’annule pas cette interdiction.

L’attente a également une fin. La transaction du demandeur peut expirer pendant que le proxy attend la notification, l’inscription et sa réponse. RFC8599 le rappelle et recommande une erreur qui affecte la transaction concernée plutôt que de dégrader inutilement tout le dialogue. Préserver une conversation ne promet pas que chaque tentative réussira.

Le fournisseur applique ses propres règles de sécurité, dont RFC8599 ne remplace pas la spécification. Ce dernier impose aussi de sécuriser convenablement la signalisation SIP. Les paramètres privés ne doivent pas s’échapper vers des utilisateurs ou des entités non fiables par d’autres chemins, par exemple des notifications d’événements d’inscription mal autorisées.

RFC8030 éclaire la sécurité d’HTTP Web Push, sans se substituer au choix du dialogue par l’application. Ces frontières doivent être vérifiées séparément. L’autorisation du fournisseur ne donne pas au proxy carte blanche pour ignorer une association expirée ; le maintien d’un dialogue ne promet pas que l’abonnement fournisseur soit toujours valide.

La documentation n’est pas une attestation d’exploitation

Le manuel du module registrar d’OpenSIPS3.6, retenu comme documentation d’une version précise, décrit pn_enable_purr, pn_process_purr et pn_refresh_timeout. L’intérêt de cette preuve est concret : l’annonce de capacité, la recherche de référence et la mise en attente ont des expressions différentes dans une implémentation.

Les deux articles de2020 consacrés à la prise en charge expliquent historiquement l’inscription et les requêtes de dialogue. Ils ne prouvent pas que chaque ancienne association sera conservée dans un groupe de nœuds actuellement déployé. Aucun opérateur SIP n’a été testé dans le cadre de cette recherche.

Les errata doivent être lus avec la même précision. Le8136, vérifié et éditorial, remplace sip.pnsreq par sip.pnsreg au paragraphe4.1.4. Le7136 est signalé comme technique et concerne des exemples d’URI REGISTER ; son statut n’en fait pas une modification normative acceptée. Il n’est pas nécessaire d’inventer ou de recopier un exemple exécutable pour exposer la frontière.

La conclusion ne réclame donc ni conservation sans fin, ni autorité centrale. Elle demande de ne pas faire payer aux dialogues anciens le renouvellement des références destinées aux échanges futurs. La discrétion peut progresser sans abandonner la responsabilité du proxy qui connaît encore l’association.

Sources