L’abonné avait choisi le traitement de l’appel. Le réseau devait encore l’exécuter : RFC 3136

Résumé

• RFC 3136 organisait le passage d’un événement né dans le réseau téléphonique vers un abonné connecté à Internet, puis le retour éventuel de son choix de traitement.
• Le clic ne réalisait pas l’action. Le Gateway et le SPIRITS Client devaient porter la réponse, le Service Control Function devait la traduire en logique téléphonique et le commutateur devait reprendre le traitement de l’appel.

Un appel arrêté entre deux horloges

L’image historique est celle d’une ligne unique. Elle porte la session modem d’un foyer quand un appel vocal arrive. Le réseau téléphonique sait qu’un appel attend. L’ordinateur de l’abonné occupe la même ligne et se trouve, lui, sur Internet. Pour offrir Internet Call Waiting, il faut faire circuler un événement entre ces deux systèmes avant que l’attente téléphonique ne perde sa raison d’être.

Une fenêtre apparaît : accepter, transférer, envoyer vers la messagerie, faire écouter un message ou rejeter. L’utilisateur choisit. L’interface peut immédiatement surligner le bouton. Ce retour visuel est honnête s’il signifie « choix enregistré localement ». Il devient trompeur s’il signifie « appel traité ».

Le commutateur n’a pas vu le clic. Il détient l’appel et son propre état. Entre l’ordinateur et lui se trouvent un serveur d’interaction, une passerelle, un client côté téléphonique, une fonction de contrôle de service, puis la fonction de commutation. Chacun peut recevoir un message sans posséder l’autorité ni la capacité d’accomplir le résultat final.

Publié en juin 2001 avec le statut Informational, RFC 3136 n’était pas un protocole Internet complet. Le texte définissait une architecture : des composants, leurs responsabilités et les interfaces logiques qui les reliaient pour des services déclenchés dans le PSTN et prolongés sur Internet. Cette précision protège l’histoire contre une extrapolation facile. Une flèche d’architecture explique où une information doit aller ; elle ne prouve ni implantation, ni interopérabilité, ni résultat mesuré.

Le premier témoin était le commutateur

La chaîne commençait dans le réseau téléphonique. Le Service Switching Function, généralement présent dans un commutateur, reconnaissait un déclencheur du réseau intelligent et dialoguait avec le Service Control Function. Le SCF exécutait la logique de service et donnait aux commutateurs les instructions nécessaires pour achever l’appel.

Il faut déjà distinguer trois faits : un appel a atteint un point de détection ; le SSF a reconnu le déclencheur configuré ; le SCF a reçu une interaction exploitable. Un historique qui commence seulement au pop-up Internet ignore la partie du système qui avait autorité sur l’appel.

RFC 3136 plaçait ensuite un SPIRITS Client près de ce contrôle. Il recevait les requêtes du SCF et renvoyait les réponses. Il pouvait être co-localisé avec le SCF ou lui parler par l’interface D. Le dessin ne contraignait donc pas le déploiement à installer deux machines. Il découpait les rôles afin de rendre les responsabilités discutables.

Sur le chemin vers Internet, le SPIRITS Gateway servait d’intermédiaire. Il pouvait être co-localisé avec des éléments PINT. Le SPIRITS Server terminait les requêtes venant du PSTN et gérait l’interaction avec l’abonné : notification de l’appel, présentation des informations disponibles et relais du traitement choisi.

Le mot « Server » ne lui donnait pas la maîtrise du commutateur. Le mot « Client » ne réduisait pas le composant téléphonique à un simple écran. Dans cette architecture, les noms signalaient une relation de protocole, non une hiérarchie d’autorité universelle.

L’alphabet de RFC 3136 décrivait cinq preuves différentes

L’interface A reliait le PINT Client de l’hôte de l’abonné au PINT Server. Pour SPIRITS, son usage principal était l’enregistrement de session, donc l’activation temporaire du service ; elle pouvait aussi servir à l’abonnement. Une activation valide ne garantissait pas qu’un événement téléphonique futur serait reconnu ni que l’hôte resterait joignable.

L’interface B reliait le SPIRITS Server et le Gateway. Dans un sens passaient la notification d’appel et, si elles existaient, l’identité ou le numéro de l’appelant. Dans l’autre passait le choix de disposition fait à la volée. Recevoir la première moitié ne certifiait pas le retour de la seconde. Émettre la seconde ne certifiait pas sa livraison au contrôle téléphonique.

L’interface C reliait le Gateway et le SPIRITS Client. Le Gateway pouvait contacter le Server ou agir comme serveur virtuel et terminer lui-même une requête. Par conséquent, une ligne de journal disant « request terminated » pouvait décrire une terminaison architecturale normale, et non un abandon ni la preuve d’un transfert vers un autre processus.

L’interface D portait les paramètres des déclencheurs du SCF vers le Client, puis la disposition de l’abonné vers le SCF. C’est là que le document formulait la limite essentielle : le SCF devait « transformer » le choix de l’utilisateur en actions appropriées, par exemple jouer une annonce, puis relancer le traitement suspendu dans le SSP.

L’interface E, enfin, portait les requêtes PINT au SCF pour exécution. PINT traitait le sens opposé—une demande née sur Internet vers un service téléphonique—mais ses composants aidaient à l’enregistrement et à l’architecture combinée. Le partage d’une passerelle ne fusionnait pas les événements.

« Transférer » n’était pas une instruction de commutateur

Prenons le choix le plus parlant. L’abonné demande que l’appel soit transféré vers un autre numéro. L’application peut conserver le bouton pressé, le numéro proposé et l’heure. Le Server peut accepter la saisie. Le Gateway peut authentifier le message. Le Client peut le remettre au SCF. À ce stade, le transfert n’existe encore que comme intention portée jusqu’au lieu de décision.

Le SCF doit lire l’état de l’appel, la souscription, les règles de l’opérateur et la destination. Il doit traduire l’intention en opérations compatibles avec le réseau téléphonique. Le SSP doit reprendre le traitement, construire le nouvel acheminement et recevoir les réponses ultérieures. La destination peut sonner sans être décrochée ; être occupée ; rejeter l’appel ; ou répondre via un système qui ne garantit aucune expérience humaine.

Le même raisonnement vaut pour « rejeter ». L’interface Internet peut envoyer un rejet, mais l’appelant n’entend une annonce ou une libération que si la logique et le commutateur les produisent à temps. « Accepter » peut exiger l’arrêt de la connexion modem avant que la ligne puisse porter la voix. La proposition VoIP apparaissait parmi les options de service, mais RFC 3136 précisait que l’architecture proposée ne la reflétait pas.

Le temps est donc une partie de la sémantique. Un choix authentique reçu après l’expiration du délai peut être parfaitement formé et opérationnellement caduc. Une réponse tardive ne devient pas fausse ; elle perd le pouvoir d’influencer cet appel.

Le journal connaissait son point de vue

RFC 3136 envisageait aussi des traitements définis à l’avance. L’abonné pouvait sélectionner une règle générale ou une règle adaptée à certains numéros appelants. Dans ce cas, aucune fenêtre n’était nécessaire. Le traitement pouvait s'appliquer automatiquement, puis un journal montrer la date, l'heure, le numéro, le nom et la disposition.

Ce journal était une trace utile de politique et d'observation. Il ne devenait pas, par sa seule présence, une caméra placée chez l'appelant et à la destination. Une ligne « forwarded » pouvait signifier règle sélectionnée, requête acceptée, instruction envoyée ou classement final choisi par l’implémentation. Pour devenir preuve, elle devait annoncer son témoin et son critère de clôture.

RFC 2995, qui précédait l’architecture, décrivait quatre implémentations pré-SPIRITS. Toutes prenaient en charge Internet Call Waiting ; la plupart s’appuyaient sur SIP et toutes utilisaient des solutions de réseau intelligent pour la partie PSTN. Mais le texte signalait aussi qu’elles n’interopéraient pas toutes et que les implémentations SIP ne parlaient pas nécessairement la même version.

Le terme « SPIRITS server » variait lui-même selon le contexte. Voilà pourquoi une description d’implémentation ne pouvait pas automatiquement valider chaque flèche de RFC 3136. Le running code prouvait que certains acteurs avaient construit certains chemins. Il ne prouvait pas une sémantique universelle du succès.

Informer un abonné n’impliquait pas lui remettre le contrôle

RFC 3298 a rendu cette séparation plus nette en 2002. Les exigences demandaient qu’un protocole SPIRITS minimal puisse assurer la notification de base sans dépendre de PINT ni d’interactions persistantes avec le PSTN. Un service pouvait donc publier un événement à l’hôte Internet sans lui accorder la capacité de modifier l’appel.

Lorsque le traitement devait revenir, RFC 3298 représentait la suite : enregistrement, notification, disposition, Service Control, SSP. Il décrivait la réaction à la notification comme l’élément restant nécessaire à la livraison du service. Accepter, rejeter et rediriger formaient le vocabulaire de base ; la prise d’appel en VoIP restait hors du périmètre.

Cette distinction devrait gouverner l’interface. « Appel entrant » est un état de notification. « Choix envoyé » est un état de commande. « Politique acceptée » est un état de contrôle. « Appel transféré » exige une preuve plus éloignée. Un unique symbole vert ferait perdre la géographie du système.

En 2004, RFC 3910 a spécifié le protocole SPIRITS sur SIP SUBSCRIBE/NOTIFY et XML. Pour clarifier les rôles, le Server Internet devint le subscriber d’événements et le Client téléphonique le notifier. Ce changement lexical rappelait que le sens de chaque message dépendait de l’acteur qui le produisait.

RFC 3910 distinguait aussi les points de détection de type Request, qui suspendaient le traitement jusqu’à une réponse, des points Notification, qui laissaient le traitement continuer après l’avis. Le même événement pouvait donc demander une décision ou seulement informer. Un NOTIFY reçu ne démontrait pas que le commutateur attendait le clic.

La souscription elle-même possédait plusieurs états. Après une réponse 202, un premier NOTIFY indiquait que la demande était acceptée et en cours de traitement ; un second suivait lorsque les points de détection étaient initialisés. Après cela seulement, un événement futur pouvait déclencher une nouvelle notification. Accepté, initialisé et déclenché n’étaient pas trois orthographes du même succès.

L’interface qui transformait le choix restait locale

RFC 3910 s’attachait aux interfaces B et C. Il indiquait explicitement que D relevait de la politique locale de l’opérateur PSTN : interface fonctionnelle ou échange de messages, selon l’implémentation. Le protocole commun s’arrêtait donc juste avant de prétendre normaliser universellement la relation avec le SCF.

Ce partage est une discipline, pas un défaut. Les messages Internet pouvaient partager un schéma, des événements obligatoires et des règles de transaction. L’opérateur conservait la décision sur la manière d’intégrer ces demandes à son contrôle de service, sur l’identité reconnue, les droits courants et les traitements disponibles.

Une syntaxe portable diminue l’ambiguïté entre organisations. Elle ne rend pas le Gateway souverain sur le commutateur. Elle ne fait pas non plus de l’abonné la source exclusive de politique : une préférence légitime peut encore rencontrer une souscription expirée, une ligne différente, une règle anti-fraude ou un état d’appel incompatible.

La sécurité suivait la capacité de nuire

RFC 3136 considérait l’interface B, généralement placée sur l’Internet public, comme la plus exposée au vol et au déni de service. L’interface C pouvait rester dans l’intranet du fournisseur, mais le Gateway connecté à Internet ouvrait une frontière ; un pare-feu seul pouvait ne pas suffire.

Le danger n’était pas abstrait. Une inscription frauduleuse pouvait détourner les notifications. Une disposition modifiée pouvait faire rejeter ou transférer un appel. Une réponse rejouée pouvait viser un autre événement. Le numéro et le nom de l’appelant soulevaient une question de confidentialité avant même toute commande.

Il faut donc séparer identité authentifiée, intégrité du message, association avec la ligne, durée de session, autorité sur le traitement, politique SCF, exécution par le switch et résultat observé. La preuve que l’utilisateur a choisi quelque chose répond à une seule de ces questions.

L’enseignement ne dépend pas du modem

L’époque a changé, mais l’architecture du malentendu demeure. Un tableau de bord propose de basculer du trafic, révoquer une clé, rediriger une conversation ou arrêter un processus. Le bouton est proche de l’utilisateur ; l’effet se trouve dans un autre domaine de contrôle. Entre eux, des intermédiaires authentifient, traduisent, mettent en file, appliquent une politique et commandent des machines.

RFC 3136 avait l’honnêteté de ne pas appeler tout cela « le clic ». Il donnait un nom au choix, un autre au contrôle de service et un autre à la commutation. L’abonné pouvait décider du traitement souhaité. Le réseau devait encore le rendre réel.