Couplage Téléphonie Informatique et application à Magento : Cinquième partie

Cet article est le dernier d’une série consacrée au couplage téléphonie informatique avec Magento. Après avoir abordé successivement :

On va finalement terminer (en beauté) avec quelques spécificités de CTI dans un contexte web.

Spécificités du contexte web

Routage d’informations : middleware de messaging

Jusqu’à présent, on a parcouru des fonctionnalités qui étaient surtout fournies nativement par des hardphones. On a vu que l’on peut récupérer des informations des téléphones et lancer des appels. Néanmoins, il faut tenir compte d’une pratique très répandue qui est de mettre l’ensemble des téléphones physiques dans un réseau à part (VLAN au minimum, si ce n’est carrément un réseau physique séparé, en raison de la nécessité d’une alimentation POE des téléphones pour assurer la continuité de service même si l'on a une coupure de courant. Il ne faut pas oublier qu’il faut absolument réussir à passer des appels, puisque l’on pourrait aussi devoir émettre des appels d’urgences). De ce fait, il faudra quand même mettre en place une architecture qui permettra non seulement de récupérer les informations des UA, mais également de les acheminer jusqu’aux postes informatiques des utilisateurs. Il y a donc une problématique de routage des messages sous-jacente. Cette problématique peut être résolue par exemple en utilisant un framework de files de messages (message queuing), c’est à dire en utilisant des services comme RabbitMQ, dont l’utilisation est justement prévue dans la version EE de Magento2. Pour l’observation des appels émis et reçus, il s’agira donc de créer un système avec :

  • un producteur côté téléphonie, qui va récupérer les messages
  • un système de routage des informations
  • des consommateurs applicatifs, qui s’interfaceront par exemple avec Magento.

En pratique, il faudra plusieurs ouvertures de files sur le serveur de files de messages pour réussir à faire fonctionner le système. Par exemple :

  • une file de commande, qui permettra d’envoyer des commandes aux systèmes d’observation (démarrer une observation d’une ressource par exemple)
  • des files créées uniquement par les consommateurs, qui auront des topics qui seront les URI des ressources (ou au minimum les identifiants qui se trouvent avant le domaine). De la sorte, un exchange de type topic fera l’affaire pour dispatcher les événements sur tous les clients désireux d’obtenir des infos sur une ressource donnée. Cette file pour chaque client servira aussi pour les réponses directes aux commandes.

Dans le système, la clef de routage la plus naturelle, hors les clefs spéciales pour la liaison directe vers chaque observateur et la file de commande, sera la Request URI de la ressource, puisque cette dernière est déjà utilisée dans les requêtes SUBSCRiBE. C’est donc de ce fait un excellent candidat à cet effet.

Couche client web : les web-workers

L’avantage d’utiliser un système de files de messages comme RabbtMQ est qu’il existe un grand nombre de clients pour s’interfacer avec ce système, dont des clients Javascript pour le web. A cela s’ajoute la possibilité d’avoir des connexions plus “pérennes” que les connexions HTTP standard : les websockets, par exemple. Par contre, il faut alors que cette pérennité s’applique aussi au niveau de l’application web, ce qui n’est pas évident puisque la navigation résulte du fait d’aller de page en page. De ce fait, deux types d’approches sont envisageables :

  • abuser de l’AJAX : les appels AJAX permettent de récupérer le contenu d’autres pages tout en restant sur une même page. Mais ce mode de fonctionnement n’est guère possible si toute l’application n’a pas été prévue pour fonctionner de la sorte initialement.
  • utiliser des web workers : les webworkers sont une nouveauté de HTML5. Ils permettent dans une certaine mesure de faire des travaux en parallèle, et peuvent communiquer avec les pages à l’aide de messages. Deux types de workers existent : les workers dédiés et les workers partagés. Ce sont ces derniers qui nous intéresseront le plus, car si on intègre les mécanismes de communication dans un worker partagé, ce worker subsistera jusqu’à ce que plus aucune page du site ne soit chargée. A noter que dans le cadre de la navigation avec un seul onglet, les tests que j’ai réalisés montrent que le fait d’aller sur une autre page du même site ne remet pas le compteur de référence à 0. En revanche, si on force le rechargement de la page dans ces conditions, là le compteur de référence sera réinitialisé, et un nouveau web worker sera créé.

On comprend donc que la deuxième solution, utilisant les web workers partagés, semble plus plausible, puisque Magento, a intégré dans son fonctionnement standard de la navigation à travers plusieurs pages (par exemple, une page d’édition, associée à une page de post qui va renvoyer sur la page d’édition par exemple, agrémentée d’un message de session), mais nécessitera une division de l’application web en au moins deux couches :

  • La couche du worker
  • La couche autour du worker (IHM d’interaction avec le worker).

De plus, le développement de l’application risque d’être plus difficile, car il est a priori moins aisé de débugger avec des workers. En pratique, des navigateurs comme Google Chrome fournissent des outils permettant d’inspecter les workers partagés.

En revanche, il subsiste des limitations à l’intérieur des workers. En effet, il n’est pour l’instant, par exemple, pas encore possible d’utiliser WebRTC dans un worker partagé, notamment car il faut associer un élément de DOM à un flux de média, par exemple, pour restituer les flux distants à l’utilisateur local.

TEL URI et ENUM


tel:+33368001758


Exemple de Tel URI

A l’inverse, on peut aussi créer des petites applications pour réorienter et transformer les URL vers le navigateur web, en ayant pour intention de déployer le minimum d’intelligence sur les postes, de sorte à faciliter la maintenabilité du système en réduisant les mises à jour requises.

Dans cette optique, on peut mettre à profit plusieurs notions pour utiliser un algorithme “stable” se basant sur des données centralisées :

  • tout d’abord, il faut se rappeler que les numéros de téléphones publics sont standardisés dans la norme E.164.
  • ensuite, on peut remarquer que la RFC 3966 définit le schéma de protocole “tel”, dans lequel on peut en particulier retranscrire les numéros publics E.164. Autrement dit, il est possible d’inclure dans une forme standardisée des numéros de téléphone dans des documents, via des liens
  • fort de cet encapsulation du numéro de téléphone E.164 dans une tel URI, on comprend qu’on peut chercher à supporter le schéma de protocole tel au niveau des machines
  • on peut également à nouveau décapsuler le numéro de téléphone E.164 des tel URI publics, pour retrouver le numéro E.164 d’origine, et ensuite utiliser les services ENUM, qui s’appuient sur un algorithme strictement défini et des enregistrements DNS pour dériver une URI depuis un numéro E.164. Cette URI peut par exemple être une URI SIP, mais pourrait très bien aussi être une URI HTTP, ce qui correspond assez bien aux deux exploitations que l’on pourrait souhaiter en faire.
  • le problème avec ENUM, c’est qu’en théorie, on devrait disposer d’un registre public en France nommé 3.3.e164.arpa. Or, il y a eu des essais en 2001-2002, mais je n’ai pas vu d’informations sur la commercialisation de services ENUM en France. Du fait de sa non-popularité, il est nécessaire d’utiliser un registre ENUM privé pour résoudre les adresses et fournir ainsi un service à ses utilisateurs. Néanmoins ce problème est plus un problème commercial que technique. D’autre part, il faut bien voir que le schéma d’URI tel permet également d’encapsuler des numéros privés, dont on peut éventuellement aussi souhaiter assurer une translation privée. Dans ce cas, un usage privé de ENUM pourrait être intéressant (avec des enregistrements DNS non publics). Si l’on souhaite personnaliser les numéros avec des URI qui n’ont qu’une signification intra-entreprise, ce n’est que cette approche qui est de toute façon utilisable.

Il est intéressant donc de reconsidérer d’éventuelles applications pratiques de Tel URI et de ENUM :

  • à travers son numéro de téléphone, fournir aux utilisateurs extérieurs un ou plusieurs autres services pour joindre son interlocuteur dans une entreprise, en incorporant des liens avec le protocole tel dans des documents avec des hyperliens et en fournissant des enregistrements publics
  • A travers un service ENUM privé, on arrive à faire du CTI qui peut fournir une manière souple pour récupérer des informations sur un numéro, ou bien même de l’appeler (par exemple si on utilise une URI SIP pour un softphone, ou une URI HTTP pour un webphone hébergé dans une page web)

On constate qu’au niveau de Magento, on pourra vraisemblablement non seulement inclure les tel URI dans les pages web, et les mails qui sont produits par le système, mais également dans des PDF, puisque le Zend Framework utilisé dans Magento contient la possibilité d’inclure des liens dans les PDF (au minimum dans la version livrée avec Magento 1.9.2.4).

Les webphones



Exemple d’intégration de webphone : la stack SIP en JS en elle-même est dans l’onglet à droite de l’onglet actif, tandis que les contrôles sont déportés dans la page de l’onglet actif. Un appel est en cours (l’utilisation du micro est matérialisée par le point rouge).

Les webphones sont des softphones intégrés dans les pages web. Concrètement, ils rassemblent plusieurs technologies : dont une technologie de transport de la signalisation, qui est bien souvent les websockets. Cette couche est le plus souvent pilotée par une stack de signalisation, écrite en JS, comme par exemple une stack SIP. Si cette stack ne traite que de la signalisation, pour être utile, elle interagit cependant avec le WebRTC (Web Real Time Communication), qui est un ensemble technique permettant de gérer notamment :

  • La capture et la restitution des flux audio ou vidéo
  • La gestion des endpoints media et la problématique NAT associée
  • La préparation de description et de réponse d’offres en JSEP (Javascript Session Establishment Protocol, protocole encore en version draft, qui encapsule en gros du SDP)

L’usage d’un webphone ainsi constitué nécessite quelques prérequis techniques :

  • Disposer d’un IPBX capable de s’interfacer avec du transport en web socket (et en plus, web socket au dessus de SSL) - ou au minimum d’un proxy SIP qui pourra se mettre dans la route pour assurer la communication
  • Disposer des mécanismes nécessaires pour assurer la résolution des problématiques NAT dans le cadre de l’utilisation de ICE (Interactive Connectivity Establishment): serveur STUN (Simple Traversal of UDP through NAT - souvent utilisé avec deux serveurs), serveur TURN (Traversal Using Relay NAT)

A l’usage, on constate que c’est le plus souvent l’API de signalisation qui va demander la configuration à utiliser, et que l'API va s’interfacer d'elle-même avec le WebRTC, de sorte que le développeur a majoritairement à manipuler l’API de signalisation.

Avec la spécificité de Magento qui est que l’on navigue sur différentes pages, il faut faire en sorte de pouvoir conserver la continuité des appels en cours. De là, on en déduit qu’il pourrait être plus intéressant d’intégrer la véritable partie moteur webphone dans une page “maître” spécifique qui restera tout le temps active, tandis que la partie d’interfaçage graphique devrait se situer dans des blocs et du code JS intégré aux pages Magento. La liaison entre les deux étant assurée par un shared web worker pour assurer la transmission des informations entre la page maître et les autres pages. Ceci signifie également qu’il est à ce moment nécessaire de créer un protocole de communication entre le web worker et les autres pages. C’est donc un travail non négligeable qui peut se présenter.

L’utilisation du webphone a surtout l’avantage de faciliter à long terme la maintenabilité (puisque le code est centralisé et nécessite un seul déploiement central, et pas sur tous les postes) et l’utilisation “tout terrain” de la solution, les parties liées au matériel et les problématiques NAT étant laissées au navigateur.

De plus, en étant déjà dans l’interface web de l’utilisateur, on est aussi au bon endroit pour présenter des fonctionnalités CTI sur les appels. A l’inverse, on est à “l’endroit le plus éloigné” pour interroger les services : c’est à dire qu’il faudra éventuellement mettre en place un nécessaire pour récupérer au minimum un stock d’information de base sur l’appel, qui permettront à l’utilisateur de cerner rapidement le contexte métier de l’appel (par exemple accès à la balance des paiements du client, aux anciennes commandes passées,...), quitte à fournir des liens vers d’autres ressources dans l’interface pour obtenir des informations détaillées. La fourniture de ces informations pourra a priori se faire par exemple via des appels XHR ou un système de files de messages.

Conclusion

En conclusion, on a constaté que le couplage téléphonie informatique peut revêtir bien des formes, mais est à la base possible car les protocoles de téléphonie pure incluent les informations nécessaires au couplage tel que le numéro de téléphone et la présentation du nom. Ensuite, le protocole SIP, qui est utilisé pour la signalisation des appels VOIP, continue à véhiculer ces informations, qui sont exploitables soit depuis un UA, soit depuis un B2BUA comme Asterisk, ou éventuellement même depuis un proxy SIP (par exemple Kamailio, qui est également capable d’ajouter des headers dans des requêtes SIP, et ce, en fonction de données récupérées dans une BD). Enfin, les données peuvent être acheminées jusqu’à l’ordinateur de la personne, si elles ne s’y trouvent pas déjà (cas du softphone et du webphone).

A l’inverse, on a vu qu’il était également possible de donner des ordres aux téléphones, et notamment des créations d’appels, de diverses manières. On a également constaté que ce couplage ne se limitait pas à la téléphonie en elle-même, mais peut également prendre place dans des documents, par exemple via les Tel URI.

Magento, peut interagir à divers niveaux, que ce soit au niveau serveur, en travaillant en collaboration plus ou moins étroite avec l’IPBX, ou que ce soit au niveau client, les nouvelles capacités comme le WebRTC ou les web workers permettant d’espérer une intégration des webphones métiers dans les pages web adaptées aux spécificités de l’application.

Il reste un domaine que je n’ai pas évoqué : l’utilisation des techniques de VOIP pour fournir un accès VOIP direct aux clients, éventuellement même depuis leur ordinateur. Bien qu’une telle chose serait techniquement possible, je ne pense pas que cela soit une bonne chose, car cela suppose au niveau du client une certaine préparation (utilisation d’un micro casque ou d’un téléphone USB branché à l’ordinateur par exemple, avec l’ajustement des niveaux de son), préparation qui pourrait être délicate pour certains utilisateurs, et pas forcément suffisante si une contention de bande passante se présente. En revanche, cette intégration peut être éventuellement réalisée dans le cadre des interfaces mobiles. Et Magento fournit déjà un système d’applications mobiles, en particulier pour Android, où on peut par exemple remplacer des SMS par des notifications d’applications : on constate donc que la téléphonie pourra in fine éventuellement devenir un service rendu par l’informatique, comme le mail par exemple.



Ce dernier article clôt cette série consacrée au couplage téléphonie informatique avec Magento.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.