Résumé

  • RFC 3149 permettait à un Call Agent MGCP d’associer un numéro de touche à une fonction, de régler labels et voyants et de piloter un écran XML, sans confondre l’événement de touche avec le résultat de l’appel.
  • L’état de l’écran pouvant être asynchrone par rapport à la signalisation, le document lui attribuait un endpoint disp/ distinct et donnait priorité à la couche XML pour les touches partagées.
  • Volume, bascule combiné/haut-parleur et microphone muet avec son voyant restaient locaux : l’intelligence externe s’arrêtait devant une surface physique immédiate.

Une touche n’envoyait qu’un numéro

MGCP supposait que la logique d’appel résidait dans un contrôleur extérieur au gateway. Les packages d’une ligne analogique suffisaient pour une connexion simple. Un téléphone professionnel ajoutait des fonctions : attente, transfert, conférence, messages, touches programmables, écran, touches contextuelles, haut-parleur et microphone.

RFC 3149 définit trois extensions. KY traitait les touches, leurs lampes et labels ; BP ajoutait la prise/dépose forcée et le bip ; XML transportait des demandes d’affichage et des sélections. La touche ne disait pourtant pas « attente ». Elle signalait son numéro. L’agent détenait la table qui transformait ce numéro en fonction.

Deux modèles pouvaient placer la même fonction à des positions différentes. Un événement valide prouvait donc qu’un endpoint avait rapporté une touche dans un ensemble demandé. Pour conclure que l’utilisateur avait demandé une mise en attente, il fallait la version de la table. Pour conclure que l’appel était réellement en attente, il fallait encore la décision, la signalisation et l’état des médias.

Cette distinction interdit au champ button de devenir une conclusion. Il faut préserver modèle, firmware, cartographie, numéro, transaction RQNT/NTFY, branche choisie par l’agent et résultat observable.

Le texte et la lampe n’exécutaient pas le service

L’agent pouvait allumer un voyant et placer un texte libre près d’une touche. Il transformait ainsi une surface générique en interface changeante. Mais le rendu avait sa propre temporalité. Un ancien label pouvait survivre à une nouvelle cartographie ; une lampe pouvait s’allumer alors que l’action échouait ; le bon événement pouvait venir d’une touche voisine de celle que l’utilisateur croyait lire.

Le RFC cherchait un minimum de signaux de bas niveau. Si l’agent ne s’intéressait qu’à l’appui, il n’avait pas besoin des messages appui et relâchement. Ce choix évitait un trafic redondant, mais le journal réseau ne racontait plus tout le geste humain. Position physique, rebond, relâchement et vue de l’utilisateur appartenaient à d’autres reçus.

Un label est donc une sortie de présentation, une lampe une sortie matérielle, une notification un événement et la fonction un résultat. Leur proximité sur le boîtier ne les fusionne pas.

L’écran reçut une identité séparée

Le document observa que l’état d’affichage pouvait être asynchrone par rapport à l’état de signalisation. Il proposa alors un endpoint différent, nommé en ajoutant disp/ devant le nom du téléphone.

Son exemple associe une sonnerie à un écran offrant le renvoi immédiat vers la messagerie. Le choix produit un post XML et peut annuler les temporisations de sonnerie. Afficher l’option, recevoir l’appui, poster la valeur, annuler le timer, modifier l’appel et produire le résultat distant sont six actes. Aucun n’est la preuve automatique des autres.

Le Call Agent envoyait une référence vers un deck et une card avec des substitutions. Une card pouvait contenir texte, liste, saisie, timer et navigation. Lorsqu’une touche appartenait à la fois au script et au téléphone, la couche XML la recevait d’abord, puis la consommait ou la transmettait.

Cette priorité est une règle de distribution, pas une garantie. Elle peut expliquer où l’événement s’est arrêté. Elle ne prouve ni le rendu, ni la livraison du post, ni le changement de signalisation. L’endpoint séparé rendait le désaccord visible et adressable.

Le modèle remplaçait une découverte exhaustive

Pour choisir la bonne cartographie, l’agent devait connaître les capacités. Plutôt qu’un protocole découvrant chaque touche, RFC 3149 introduisit le paramètre expérimental X-UA : le téléphone répondait par une chaîne identifiant sa marque et son modèle, puis l’agent consultait un profil.

La chaîne n’était pas une attestation matérielle. Elle pouvait être ignorée par un gateway incompatible, ne plus correspondre au firmware, ou viser un profil incomplet. Elle ne prouvait ni la présence du clavier attendu, ni le câblage du voyant, ni le fonctionnement du haut-parleur.

Le préfixe expérimental imposait même le doute : un paramètre X- non pris en charge devait être ignoré plutôt que faire échouer l’échange. L’absence de réponse n’autorisait pas l’invention d’un modèle par défaut. Elle appelait un repli borné.

Le geste immédiat resta dans le téléphone

La section la plus importante énumère ce qui ne devait pas monter vers l’agent. Le volume de sonnerie, du combiné et du haut-parleur restait local. Une fois le haut-parleur actif, l’utilisateur pouvait prendre le combiné puis revenir au haut-parleur sans interaction avec le Call Agent. La touche muet et son voyant étaient également locaux.

Il ne s’agissait pas d’une anomalie dans l’architecture. Le centre détenait la sémantique variable des services ; le terminal gardait la manipulation immédiate de son matériel audio. L’intelligence était divisée selon les conséquences.

Il serait abusif d’attribuer au texte une mesure de latence ou une théorie complète de panne. Le document ne les fournit pas. Il établit seulement la localité de ces fonctions et l’absence d’interaction distante lors de la bascule audio.

Même localement, plusieurs réalités subsistaient. L’appui muet, l’état logiciel, le voyant et l’absence effective d’audio ne s’équivalaient pas. Une vérification des médias restait nécessaire.

Une commande distante pouvait être annulée par la main

Le package BP autorisait une prise de ligne forcée, une dépose forcée et un bip. Une application sur ordinateur pouvait sélectionner un numéro et faire activer le haut-parleur. Mais l’utilisateur pouvait annuler la prise forcée en raccrochant.

La commande n’était donc pas le dernier mot. L’agent demandait, le gateway interprétait, le matériel changeait et l’utilisateur pouvait agir en sens contraire. Un système d’observation devait conserver ces quatre temps.

Le paragraphe de sécurité restait lui aussi limité : l’extension n’ajoutait rien aux considérations de base de MGCP. Cela ne signifiait pas que XML, cartes de touches ou hook distant étaient automatiquement authentifiés ou autorisés. Le mode password masquait les caractères à l’écran, sans prouver le chiffrement du transport.

Enfin, la note IESG disait que le document décrivait un protocole non-IETF alors déployé dans des produits, pendant que Megaco/H.248 traitait le même espace sur la Standards Track. Cette hiérarchie documentaire n’efface pas le fonctionnement observé et ne prouve aucune migration universelle.

Le code en fonctionnement jugeait la cartographie

Une architecture centralisée peut échouer par couches. Les fonctions distantes disparaissent tandis que le bouton muet continue. Une mise à jour de l’agent change le sens d’une touche sans modifier le plastique. Un deck XML affiche un renvoi alors que la sonnerie persiste.

Dans chaque cas, l’étiquette centrale est une proposition. Si la touche annoncée « attente » ne modifie pas les médias, la fonction n’a pas produit son effet. Si le voyant muet brille et que le microphone émet encore, la présentation locale contredit la réalité. Si disp/ et l’endpoint téléphonique divergent, l’asynchronisme prévu devient une observation à traiter.

RFC 3149 laisse ainsi une petite limite constitutionnelle dans un appareil. Le centre peut nommer, programmer et coordonner. Le fait qu’un terminal lui rende compte ne lui transfère pas la garde de tout geste physique.

Sources