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

Ceci est l’avant dernier article d’une série consacrée au couplage téléphonie informatique avec Magento. On a vu successivement :

Au menu aujourd’hui : quelques éléments au niveau des clients de téléphonie.

Possibilités traditionnelles de CTI au niveau des UA

Fonctionnalités intégrées à SIP

Nous allons commencer tout d’abord par des fonctionnalités d’information qui sont présentes directement dans le protocole SIP.

Pour commencer, il s’agit de voir comment établir un appel avec SIP. L’UA qui souhaite établir un appel va envoyer au proxy SIP, ou éventuellement même directement à l’autre UA, s’il la connaît, une requête INVITE, qui permet de commencer à négocier l’appel.

Cette requête fait parti d’un ensemble de requêtes et de réponses (réponses éventuellement provisoires en codes 1XX, puis une réponse définitive) que l’on appelle transaction, tandis que cette première transaction démarre également un dialogue SIP, identifié par un callID qui va être transféré de bout en bout, et qui va englober l’ensemble des transactions liées à l’appel.
La syntaxe de SIP ressemble assez fortement à ce qui se fait en HTTP ou SMTP. On retrouve une première ligne qui indique la requête en elle-même, à la manière de HTTP, puis on retrouve des headers, dont deux headers qui vont être essentiels pour du CTI : le header From, qui indique l’appelant, et le header To, qui indique l’appelé. Ces deux headers permettent de véhiculer à la fois un nom, ainsi qu’une adresse SIP, structurés de la même manière que les From et To des corps des messages SMTP.

Au niveau d’une passerelle de téléphonie, pour un appel téléphonique entrant on peut donc forger des messages From utilisant la présentation du nom, et éventuellement aussi la présentation du numéro de l’appelant dans une adresse SIP.

La réponse au message INVITE, qui contient une description de session SDP indiquant les paramètres de communication média souhaités pourra par exemple être une réponse OK, qui contiendra les paramètres de communication média de l’autre entité, ce qui constitue la négociation de média entre les deux entités. En suit alors un message ACK qui confirme la bonne réception de la réponse.

En fin d’appel, une des deux entités pourra envoyer une requête BYE, avec sa réponse OK.


INVITE sip:jm@192.168.3.9:5060 SIP/2.0
Via: SIP/2.0/UDP
192.168.3.150:5060;branch=z9hG4bK5345de41
Max-Forwards: 70
From: "Netapsys Grand Est" ;tag=as6632cd81
To:
Contact:
Call-ID:
2a78be2f5ec2f52835f6ab5045e6872e@192.168.3.150:5060
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.10.0
Date: Tue, 02 Aug 2016 19:14:13 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
P-Asserted-Identity: "'Netapsys Grand Est'"

Content-Type: application/sdp
Content-Length: 286

v=0
o=root 974966669 974966669 IN IP4 192.168.3.150
s=Asterisk PBX 13.10.0
c=IN IP4 192.168.3.150
t=0 0
m=audio 8568 RTP/AVP 0 8 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=sendrecv


Exemple de requête SIP INVITE, avec les champs From et To

De la sorte, on constate qu’un UA peut disposer dans les appels des informations relatives à l’identité de l’appelant et de l’appelé, ce qui constitue une des bases du CTI. Cependant, il faut également pouvoir observer un UA pour pouvoir réagir en déclenchant les fonctionnalités applicatives. Les fonctionnalités d’observation sont obtenues en conjuguant les fonctionnalités de plusieurs RFC simultanément :

  • La RFC 3265, qui est maintenant remplacée par la RFC 6665, définit un jeu de deux requêtes : la requête SUBSCRIBE, qui permet de souscrire à des événements issus d’un autre UA, et la requête NOTIFY, qui permet justement d’envoyer les notifications au souscripteur. Cependant, cette RFC décrit uniquement un mécanisme générique de souscription et de notification, les charges utiles étant laissées à la charge de spécification de packages d’événement.
  • Pour le CTI, il y a justement un package très utile, qui est le package “dialog” décrit dans la RFC 4235. Ce package inclut notamment les informations sur l’appelant et l’appelé, ce qui fait qu’on peut monitorer (si on dispose des autorisations nécessaires) l’activité d’un autre UA en matière d’appels émis et reçus, le package permettant de suivre grâce à un ensemble d’états le déroulement d’un dialogue SIP.
  • Il y a encore une autre RFC complémentaire qui peut être utile pour compléter le mécanisme SUBSCRIBE/NOTIFY : c’est la RFC 3903, qui définit la requête PUBLISH. Cette requête permet de publier un état vers un autre UA.


<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="partial" entity="sip:jm7@10.0.0.2">
<dialog id="idcdeb6026" call-id="ce532d45-1c339164-77585c77@10.0.0.6" local-tag="624FF151-C7F6C400" remote-tag="as6cff82d1" direction="initiator">
<state>confirmed</state>
<local>
<identity display="jm7">sip:jm7@10.0.0.2</identity>
<target uri="sip:jm7@10.0.0.6:5060">
<param pname="+sip.rendering" pval="yes" />
</target>
</local>
<remote>
<identity>sip:3@10.0.0.2</identity>
<target uri="sip:3@10.0.0.2">
</target>
</remote>
</dialog>
</dialog-info>


Exemple d’évènement dialog

On constate donc qu’on a tout le nécessaire pour obtenir des informations sur un appel en cours. Cependant, on pourrait également souhaiter déclencher un appel sur un autre poste. Ceci est possible grâce à la méthode REFER, définie dans la RFC 3515 : dans un contexte hors dialogue, on envoie la requête au futur appelant, et le champ Refer-To contient la cible à appeler.

UA-CSTA

On a donc remarqué que le protocole SIP avait déjà un gros nécessaire pour à la fois observer les appels d’un UA et pour émettre des appels. Cependant, ce n’est pas la seule solution protocolaire qui est possible. Par exemple, l’ECMA a défini une utilisation de SIP qui va permettre d’établir des sessions SIP à des fins de monitoring ou de commande : défini dans le Technical Report 87, il s’agit de UA-CSTA, User Agent Computer Supported Telecommunication Applications. En pratique, on crée des sessions SIP qui n’auront pas un contenu SDP, mais application/csta+xml. Le contenu va pouvoir lancer par exemple une commande initiale, puis on utilisera des requêtes SIP INFO pour les prochaines requêtes. L’appel sera terminé comme d’habitude par une requête BYE. De manière symétrique, on pourra déclencher également du monitoring depuis l’INVITE initial, et ce sera alors l’UA monitoré qui va déclencher des messages INFO à destination de l’application de management, jusqu’à ce qu’un BYE vienne arrêter la conversation.

Les messages CSTA en format XML sont définis dans le standard ECMA 323, tandis que la charge utile proprement dite est définie dans le standard ECMA 269. Il faut ensuite voir au niveau des UA quelles sont les commandes et les événements supportés. On peut par exemple regarder la commande MakeCall pour émettre des appels, ou MonitoringStart et MonitoringStop pour le monitoring.

D’autres API ont bien évidemment été développées, comme par exemple TAPI, JTAPI, ou TSAPI.

Les API du téléphone : Notifications URI, Push URI, et Browser

La plupart des hardphones disposent d’une stack HTTP qui permet de configurer manuellement le poste. Cette stack HTTP comporte fréquemment une URI qui permet de déclencher une numérotation d’appel. De manière réciproque, la plupart des hardphones permettent également d’envoyer des notifications sur une ou plusieurs URL lorsque des événements surviennent (appel entrant, appel sortant, combiné décroché, combiné raccroché…). Cependant ces fonctionnalités sont des fonctionnalités propriétaires et donc non standardisées. Si l’on souhaite les utiliser, il est donc nécessaire de se plonger attentivement dans la documentation fournie par les constructeurs. Il convient toutefois de faire attention avec ce genre de fonctionnalités. En effet, la réponse d’un appel HTTP peut parfois prendre du temps à venir, et il faut considérer comment se comporte le téléphone : va-t-il attendre la réponse avant de continuer dans son exécution ? Il faudra donc vérifier ce genre de comportement, définir si nécessaire des stratégies asynchrones pour fournir une réponse appropriée au téléphone, et définir des temporisations pour éviter de bloquer l’utilisation du téléphone.

On notera que la possibilité de pousser du contenu vers les téléphones ne se limite parfois pas à du texte, mais permet également de manipuler un minimum le téléphone en lui faisant exécuter une charge utile spécifique.

On en arrive à ce moment à l’intégration non pas du téléphone dans l’application, mais de l’application dans le téléphone. En effet, certains téléphones fournissant des écrans “graphiques” (même couleur pour certains modèles), avec des résolutions non négligeables, prévoient carrément des langages permettant d’utiliser ces capacités de présentation. On peut par exemple trouver des charges XML ou des charges HTML qui seront interprétées par les téléphones, charges qui intègrent les spécificités des téléphones. On trouve dans ces API des possibilités pour augmenter l’ergonomie de ces applications : la possibilité de définir des actions particulières pour les softkeys, c’est à dire, les touches contextuelles qui s’affichent directement sur l’écran.

Dans le cadre de Magento, on peut mettre à profit les possibilités de theming qui existent dans Magento pour créer un thème spécifique pour les téléphones, ainsi que des contrôleurs qui chargeront ce thème, de sorte à créer un microsite spécialisé pour ces périphériques.

Développement de plugins pour les softphones


Exemple d’interfaçage entre Magento et Jitsi (réalisé via des web services)

D’autres types de téléphones existent également, comme par exemple les softphones. Certains softphones se prêtent particulièrement bien au développement de plugins, comme par exemple Jitsi, qui utilise en interne une infrastructure OSGI qui est divisée en bundles. En fonction des solutions utilisées, on peut carrément développer des plugins pour les téléphones, de sorte à lancer des URL forgées pour interagir avec l’application. A l’inverse, pour les appels sortant, on peut éventuellement chercher à intégrer au niveau système la gestion de certains protocoles tel que le protocole SIP en utilisant des URI forgées au niveau applicatif. Cependant, la question de l’authentification se pose dans ce cas, car comme on est dans le cadre d’appels, il faut pouvoir s’identifier rapidement pour accéder aux informations. Dans ce contexte, une ouverture de navigateur prend déjà du temps, et une authentification par mot de passe prendrait trop de temps. Au niveau de Magento, comme il s’agira d’accéder au BO, il serait bon de mettre une méthode d’authentification rapide en place comme une authentification par clef (si on dispose d’une méthode rapide pour déverrouiller le stockage des clefs, ou si l’on peut utiliser les certificats personnels stockés dans l’ordinateur) ou l’authentification intégrée Windows, si on utilise cette plateforme et que l’on proxifi avec un IIS le système.

Toutefois, au lieu de chercher à instancier le navigateur pour afficher les informations, une autre solution serait de passer par les web services fournis par Magento. Un tel accès suppose de bien identifier les personnes qui vont en avoir besoin, et de pouvoir si nécessaire gérer de manière suffisamment fine les autorisations. Néanmoins, un tel fonctionnement permettrait de rester dans le softphone, ce qui veut dire qu’il n’y aurait pas d’autre application à lancer, et que l’on peut déverrouiller par exemple au démarrage un keystore en cas d’authentification par clef.

En ce qui concerne l’utilisation d’une application, on peut également chercher à centraliser l’utilisation de cette application par les autres logiciels pour essayer de profiter au mieux du couplage téléphonique réalisé dans le softphone :

  • on peut tout d’abord, au niveau du navigateur, utiliser l’application pour gérer plus de protocoles (comme par exemple les telURI)
  • on peut également faire de même au niveau du système, si le système le permet. C’est par exemple le cas dans Windows, où l’on peut définir dans des packages d’installation des clefs dans le registre de manière correspondante.

Mardi prochain (18 octobre), vous pourrez lire le dernier article de la série où l’on abordera en particulier les spécificités du CTI dans un contexte Web.

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.