Résumé

  • RFC 3087 permettait à un client ou à un proxy SIP de choisir l’état initial d’une application par une Request-URI particulière : dépôt, message d’accueil, consultation ou demande de code secret.
  • Cette URI désignait un comportement configuré localement. Elle ne prouvait ni l’identité de l’appelant, ni son droit sur la boîte, ni la cause réelle du renvoi, ni l’enregistrement ou l’écoute du message.

Quand les anciens indices se dispersent

Dans une messagerie téléphonique classique, le numéro appelé, le numéro appelant et la cause du renvoi servaient à ouvrir directement le bon scénario. Une ligne occupée déclenchait un accueil ; une absence de réponse, un autre. Le numéro du poste pouvait dispenser l’abonné de saisir d’abord celui de sa boîte. Tout cela reposait sur la confiance accordée aux indices fournis par le réseau de téléphonie.

SIP rendait ce raisonnement moins sûr. Une requête pouvait traverser plusieurs mandataires et changer de destination opérationnelle. Le champ To gardait l’identité logique visée au départ, alors que le service utile à l’étape courante pouvait être tout autre. RFC 3087 donne un cas révélateur : A appelle B, B renvoie vers C, puis C vers sa propre messagerie. Si celle-ci déduit la boîte du seul champ To, elle trouve B alors qu'elle doit servir C.

Publié en avril 2001 dans la catégorie Informational, le texte n’ajoutait ni méthode ni en-tête à SIP. Il exploitait une faculté déjà prévue par RFC 2543 : un proxy pouvait réécrire la Request-URI, contrairement au champ To. La destination courante devenait ainsi une manière d’indiquer l’état initial voulu à l’application.

Le changement décisif n’était donc pas un nouveau paquet. Le contexte cessait d’être une conjecture reconstruite à l’arrivée ; il devenait le résultat explicite d’une décision d’acheminement.

Plusieurs portes pour une même messagerie

RFC 3087 imagine un ensemble d’identités SIP pour un même abonné. Une porte reçoit un dépôt avec l’annonce ordinaire. Une autre lance l’annonce d’occupation, une troisième un accueil spécial. Pour la consultation, une URI peut attendre une authentification SIP déjà vérifiée ; une autre ouvre un dialogue vocal demandant un code. Des entrées génériques commencent par demander quelle boîte utiliser.

Un proxy de type « find me » choisit la porte selon ce qu’il vient d’observer. Après avoir épuisé les contacts sans réponse, il peut viser le dépôt normal. Après une réponse d’occupation généralisée, il choisit l’annonce correspondante. Un état « ne pas déranger » conduit à une autre entrée. La messagerie reçoit alors une cible opérationnelle, sans devoir interpréter une combinaison fragile de To, From et de souvenirs du réseau commuté.

Mais les mots visibles dans l’URI n’étaient pas un vocabulaire normalisé. Le document recommande expressément de ne pas imposer de sémantique aux chaînes mnémotechniques. Un exploitant peut employer deposit, un numéro ou un paramètre arbitraire ; l’application doit accepter toute URI SIP valide prévue dans sa configuration. C’est le propriétaire du système qui tient la table entre l’identité et le comportement.

La conséquence pour l’enquête est nette. Une capture contenant le mot busy est suggestive, pas concluante. Elle établit la cible observée à ce saut. Pour connaître son sens et la raison de son choix, il faut aussi la configuration en vigueur et la décision du proxy.

La porte choisie n’accordait pas le passage

Les scénarios de consultation séparent précisément l’orientation et l’admission. Une source de confiance pouvait déléguer l’authentification à un proxy protégé. Une source authentifiée par SIP pouvait accéder au traitement prévu. En cas d’échec ou d’absence d’authentification, le service réorientait l’appel vers une URI qui demandait le code secret dans le canal vocal.

Une adresse spécifique à la consultation indiquait donc le parcours souhaité ; elle ne conférait pas le droit de lire la boîte. La relation sécurisée, les justificatifs SIP ou le code déterminaient l’accès. Même la reconnaissance d’un numéro venant du réseau téléphonique restait une hypothèse acceptée par l’opérateur, non la preuve cryptographique de la personne qui parlait.

Toutes les séquences détaillées du RFC supposent un proxy protecteur et une relation de confiance entre ce proxy et la messagerie. La section de sécurité n’invente aucune protection supplémentaire : elle renvoie aux garanties et limites de SIP.

On peut donc construire une chaîne de constatations modestes : le proxy a reçu une INVITE ; il a choisi telle Request-URI ; l’application a reconnu cette cible ; une branche d’authentification a été exécutée ; une session RTP a commencé. Aucun de ces faits ne démontre seul que l’humain possédait la boîte, que le motif historique du renvoi était exact, qu’un message a été durablement stocké ou qu’il a été entendu.

D’une convention locale à un langage commun

RFC 3261 a remplacé la première spécification SIP tout en conservant la séparation utile : la Request-URI désigne l’utilisateur ou le service actuellement adressé, et le proxy la remplace lorsqu’il sélectionne une cible. Plus tard, History-Info a fourni un moyen de transporter l’historique des redirections. Ces textes éclairent les couches sans attester l’usage d’une mise en œuvre particulière de RFC 3087.

RFC 4458, publié en 2006, révèle une autre limite. Il a défini les paramètres target et cause pour les applications de messagerie et de réponse vocale. Sa justification était pragmatique : chaque fournisseur pouvait rendre ses correspondances configurables, mais ces configurations locales ne suffisaient pas à l’interopérabilité entre contrôle d’appel, passerelle et messagerie unifiée.

Les deux documents répondent ainsi à deux problèmes différents. RFC 3087 montrait qu’une URI pouvait porter la décision de contexte sans confondre cible courante et identité logique. RFC 4458 donnait à des systèmes différents des noms communs pour la boîte visée et la cause annoncée. L’apparition du second ne prouve ni l’échec ni le succès commercial du premier.

La leçon durable tient à la suite des preuves : cible originale, Request-URI courante, règle de réécriture, table locale, résultat d’authentification, menu choisi, session média et reçu de stockage sont liés, mais distincts. Mettre le contexte dans l’acheminement réduit les suppositions. Cela ne transforme pas l’acheminement en identité.

Sources

  1. https://www.rfc-editor.org/info/rfc3087
  2. https://www.rfc-editor.org/rfc/rfc3087.html
  3. https://www.rfc-editor.org/rfc/rfc3087.txt
  4. https://datatracker.ietf.org/doc/rfc3087/
  5. https://www.rfc-editor.org/errata/rfc3087
  6. https://www.rfc-editor.org/rfc/rfc2543.html
  7. https://www.rfc-editor.org/rfc/rfc3261.html
  8. https://www.rfc-editor.org/rfc/rfc4244.html
  9. https://www.rfc-editor.org/rfc/rfc4458.html
  10. https://www.rfc-editor.org/rfc/rfc3326.html
  11. https://www.rfc-editor.org/rfc/rfc5411.html
  12. https://www.rfc-editor.org/rfc/rfc7044.html