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

Cet article est le deuxième article d’une série consacrée au couplage téléphonie informatique avec Magento. Hier, a été présentée une introduction aux aspects fonctionnels d’une telle solution ; aujourd’hui, nous nous intéresserons au cœur du couplage : une introduction aux solutions d’interconnexion entre le réseau informatique et téléphonique.

Introduction aux solutions d’interconnexion

INTERFACES


Photo de carte de téléphonie X101P (1 FXO)

Lorsque l’on parle de couplage téléphonie informatique, il faut en premier lieu effectivement réussir à interconnecter les deux types de réseaux, et obtenir des informations sur l’appelant et éventuellement l’appelé. Pour ce faire, deux types de solutions existent :

  • Utiliser un opérateur qui propose des trunks SIP et une interconnexion au réseau téléphonique : cette solution peut paraître séduisante, car elle déporte une bonne partie de la problématique vers l’opérateur. Néanmoins, elle a également des inconvénients : tout d’abord, on ouvre le réseau informatique pour faire les accès pour la VOIP. Cette ouverture de réseau ne doit pas se faire n’importe comment : il faut sécuriser l’ouverture du flux, en utilisant au minimum uniquement des connexions sécurisées (SIPS, SRTP,...) si ce n’est en utilisant des firewall applicatifs (et dans ce cas, un chiffrement applicatif devient plus ardu) et des connexions VPN. D’autre part, il y a une problématique de QoS : en effet, on arrive facilement à contrôler la qualité de service des paquets sortants de son infrastructure, mais on peut plus difficilement jouer sur la QoS des paquets entrants. Si l’on passe sur des ressources partagées, il peut y avoir contention sur la ressource et le service peut en pâtir. Pour être théoriquement viable, la QoS devrait s’appliquer de bout en bout, jusqu’à l’opérateur VOIP, ce qui veut dire au minimum des contrats spécifiques. Une autre alternative est l’overprovisionning, c’est à dire avoir des surcapacités pour réussir la plupart du temps à absorber les pics de trafic. Enfin, il y a très souvent des problématiques de NAT, puisque le protocole SDP sous-jacent va utiliser les IP et ports pour indiquer les points de connexion des média. Cette problématique n’est pas uniquement du ressort de l’opérateur, car l’usager devra également avoir des clients SIP qui sont capables de mettre en oeuvre les solutions techniques que l’opérateur propose (notamment STUN, TURN et ICE).
  • Se connecter via des interfaces télécoms au réseau de l’opérateur. Cette solution permet de mieux dissocier le réseau téléphonique et le réseau informatique, et pourrait en théorie permettre des communications de qualité plus stable, dans la mesure où l’on cherche à passer non pas sur des réseaux à commutation de paquets, mais à commutation de circuits (établissement de circuits temporaires ou permanents entre deux points). Au niveau des types d’interfaces disponibles, on en trouve majoritairement deux/trois types :
    • les interfaces FXO/FXS (Foreign eXchange Office / Foreign eXchange Subscriber) : ce sont des interfaces analogiques. Les interfaces FXO se branchent à l’opérateur, tandis que les interfaces FXS se branchent à des téléphones (ou équivalent). Ce sont des interfaces où la signalisation et la voix sont associées sur le même support, qui véhiculent actuellement le numéro de téléphone via des séquences de croisement de fréquences identifiant des numéros, appelées DTMF. La signalisation à l’utilisateur est assurée via des séquences sonores, tandis que l’identifiant du numéro et/ou du nom se fait initialement via l’envoi de données au début de l’appel, typiquement lors des sonneries. Lorsqu’une telle interface est utilisée pour se connecter à un opérateur, un seul numéro de téléphone est attribué.
    • les interfaces BRI et PRI (Basic / Primary Rate Interface) : ces interfaces utilisent des codages comme Alternate Mark Inversion ou High Density Bipolar 3 qui véhiculent dans une certaine mesure un signal de synchronisation, puisque l’on fait par exemple varier le niveau du signal pour la valeur 1 (AMI) et que l’on casse une série de zéro en insérant une valeur 1 à intervalle régulier (viol de parité pour HDB3) pour ne pas perdre la synchronisation, ce qui leur permet d’atteindre des débits plus élevés que le codage V23 utilisé dans certains cas pour le callerId sur le FXO. Ce genre d’interfaces présente des trames de longueur fixe, avec des emplacements pour deux types de canaux : les canaux voix (canaux B) et le canal de signalisation (canal D). Le nombre de canaux B et D est différent en fonction de la technologie : par exemple, pour une interface BRI ISDN, on a par exemple 2 canaux B et un canal D, tandis que pour une interface PRI E1 on a 30 canaux B et un canal D. Au niveau signalisation, on utilise généralement Q921 pour la couche liaison de données et Q931 pour la couche réseau (couche d’appels). En s’intéressant à Q931, on constate qu’il y a une signalisation spécifique d’établissement d’appel, qui permet notamment de véhiculer le numéro demandé : de ce fait, il y a indépendance entre le canal utilisé et le numéro demandé, ce qui a également pour conséquence que l’on peut faire des économies d’échelles en véhiculant un nombre “approprié” de numéros au-dessus d’une même interface. La notion d’appropriation dépendant en particulier de la durée des appels, et du nombre d’appels que l’on tolère statistiquement de perdre. En ce qui concerne la présentation du nom, on constate dans la norme, qu’elle n’est prévue que dans un seul sens : du réseau vers l’usager, ce qui interdit le fait de “forger” cette information au niveau de l’utilisateur. Ceux qui s’intéressent à ce genre de technologies pourront s’y essayer grâce à l’IPBX Asterisk et les drivers DAHDI en utilisant des canaux de type TDMOE (Time Division Multiplexing Over Ethernet), qui permet d’émuler une liaison T1 (23B+1D) ; ce type de liaison a d’ailleurs une autre particularité, comme son nom l’indique : il est directement au-dessus d’Ethernet, et pas au niveau d’IP !


[Aug 2 09:56:12] PRI Span: 2
[Aug 2 09:56:12] PRI Span: 2 < Protocol Discriminator: Q.931 (8) len=59
[Aug 2 09:56:12] PRI Span: 2 < TEI=0 Call Ref: len= 2 (reference 1/0x1) (Sent from originator)
[Aug 2 09:56:12] PRI Span: 2 < Message Type: SETUP (5)
[Aug 2 09:56:12] PRI Span: 2 < [04 03 80 90 a2]
[Aug 2 09:56:12] PRI Span: 2 < Bearer Capability (len= 5) [ Ext: 1 Coding-Std: 0 Info transfer capability: Speech (0)
[Aug 2 09:56:12] PRI Span: 2 < Ext: 1 Trans mode/rate: 64kbps, circuit-mode (16)
[Aug 2 09:56:12] PRI Span: 2 < User information layer 1: u-Law (34)
[Aug 2 09:56:12] PRI Span: 2 < [18 04 e9 81 83 81]
[Aug 2 09:56:12] PRI Span: 2 < Channel ID (len= 6) [ Ext: 1 IntID: Explicit Other(PRI) Spare: 0 Exclusive Dchan: 0
[Aug 2 09:56:12] PRI Span: 2 < ChanSel: As indicated in following octets
[Aug 2 09:56:12] PRI Span: 2 < Ext: 1 DS1 Identifier: 1
[Aug 2 09:56:12] PRI Span: 2 < Ext: 1 Coding: 0 Number Specified Channel Type: 3
[Aug 2 09:56:12] PRI Span: 2 < Ext: 1 Channel: 1 Type: CPE]
[Aug 2 09:56:12] PRI Span: 2 < [28 14 27 4e 65 74 61 70 73 79 73 20 47 72 61 6e 64 20 45 73 74 27]
[Aug 2 09:56:12] PRI Span: 2 < Display (len=20) [ 'Netapsys Grand Est' ]
[Aug 2 09:56:12] PRI Span: 2 < [6c 0e 21 81 27 30 33 36 38 30 30 31 37 35 38 27]
[Aug 2 09:56:12] PRI Span: 2 < Calling Party Number (len=16) [ Ext: 0 TON: National Number (2) NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
[Aug 2 09:56:12] PRI Span: 2 < Presentation: Presentation allowed, User-provided, verified and passed (1) ''0368001758'' ]
[Aug 2 09:56:12] PRI Span: 2 < [70 03 80 31 30]
[Aug 2 09:56:12] PRI Span: 2 < Called Party Number (len= 5) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) '10' ]
[Aug 2 09:56:12] PRI Span: 2 -- Making new call for cref 1
[Aug 2 09:56:12] PRI Span: 2 Received message for call 0xb6b06290 on link 0x9ef6aa4 TEI/SAPI 0/0
[Aug 2 09:56:12] PRI Span: 2 -- Processing Q.931 Call Setup
[Aug 2 09:56:12] PRI Span: 2 -- Processing IE 4 (cs0, Bearer Capability)
[Aug 2 09:56:12] PRI Span: 2 -- Processing IE 24 (cs0, Channel ID)
[Aug 2 09:56:12] PRI Span: 2 -- Processing IE 40 (cs0, Display)
[Aug 2 09:56:12] PRI Span: 2 -- Processing IE 108 (cs0, Calling Party Number)
[Aug 2 09:56:12] PRI Span: 2 -- Processing IE 112 (cs0, Called Party Number)
Exemple de capture d’une trame de SETUP Q931, avec les éléments numéro et nom de téléphone.

On a donc compris via ces explications comment sont récupérées les informations de l’appelant au niveau de l’appelé, informations de numéro et éventuellement de nom qui permettront d’en savoir plus sur l’appelant et de faire du couplage téléphonie informatique sur les appels entrants.

PROTOCOLE SIP

Les protocoles de VOIP vont être importants dans le couplage téléphonie informatique. Un certain nombre de protocoles existent, mais un protocole est devenu le standard le plus utilisé : il s’agit du protocole Session Initiation Protocol : SIP.

Ce protocole est défini dans un grand nombre de RFC, dont en particulier la RFC 3261. Le protocole SIP met en oeuvre plusieurs types d’entités, dont notamment :

  • Des User Agent Clients, c’est à dire des clients SIP : on retrouve des clients de types assez différents, comme par exemple des téléphones SIP matériel, des softphones, des Analog Telephone Adapter (ATA), ou même des webphones (c’est à dire des systèmes applicatifs utilisant par exemple le WebRTC intégré au navigateur et une stack SIP JS). Du fait de leur statut, ils vont être impliqués à la fois dans la signalisation et dans le flux média d’un appel.
  • Des User Agent Servers : des proxy SIP : les proxy SIP font office de “routeurs avancés” pour la signalisation des appels. Non seulement ils ont pour charge de transmettre au “next-hop” les paquets SIP, mais peuvent également assurer d’autres tâches, comme la transmission d’un paquet à des cibles multiples (fork de l’appel dans le cadre de l’initiation d’une session par exemple), ou encore assurer des fonctions d’authentification. Généralement, un des proxys SIP de l’infrastructure en embarque un.
  • Registrar : le registrar sert à stocker l’enregistrement de clients SIP qui ont des IP/ports dynamiques, et qui doivent donc se faire connaître pour pouvoir recevoir des appels.
  • Des Back To Back User Agent (B2BUA) : ces éléments ne sont pour ainsi dire que des éléments optionnels d’une infrastructure SIP. Néanmoins, ces entités intègrent souvent des fonctionnalités avancées en leur sein, fonctionnalités qui nécessitent d’être centralisées (des salles de conférences, par exemple), ou qui pourraient ne pas être implémentées chez tous les clients. Par exemple, l’envoi de touches DTMF peut se faire de plusieurs moyens, dont notamment directement dans le média audio, en fonction des codecs utilisés, ou dans le trafic RTP, sous forme d’événement, ou sous forme de message SIP INFO. Autre exemple au niveau même du protocole SIP : on peut utiliser des messages SIP reINVITE ou utiliser des messages SIP REFER dans le cadre des transferts.


Exemple classique de cheminement d’infos SIP : l’UAC de gauche souhaite appeler l’UAC de droite. En bleu le chemin des médias, en rouge, le chemin d’une requête de l’UAC de gauche vers l’UAC de droite.

Avec ces quelques informations, on comprend déjà que de nombreuses typologies SIP peuvent être constituées :

  • Des solutions où l’on cherchera par exemple à mettre une bonne partie de l’“intelligence” dans des entités centralisées, de sorte à réduire les prérequis techniques des UA. Il est donc fort probable que l’on utilisera des B2BUA, et que ces B2BUA pourront être mis à contribution pour le couplage téléphonie informatique, d’autant plus qu’un environnement Web est un environnement client/serveur, où le serveur est donc également centralisé. Une communication serveur à serveur peut donc être mise en oeuvre.
  • Des solutions où l’on cherchera plutôt à mettre en avant l’utilisation du protocole SIP entre les différents UA, et où l'on aura une “intelligence requise” au niveau des UA plus forte. Dans ces cas , il faudra donc chercher plutôt à récupérer des informations auprès des UA. Dans le monde data, ceci correspond aux interfaces qui sont intégrées aux navigateurs via une logique intégrée en JS par exemple.
  • Et entre les deux, on peut avoir toute une gamme de solutions intermédiaires. On comprendra qu’il est toujours possible, pour des fonctionnalités spécifiques, de mixer les deux types de solutions : router des appels pour des fonctionnalités spécifiques vers un B2BUA qui va les acheminer ensuite vers d’autres UA du réseau (par exemple : un serveur assurant la répartition des appels entrants sur un call center).

On va s’intéresser aux deux approches, à savoir aux possibilités d’information qui sont généralement intégrées aux UA (et n’utilisant pas forcément uniquement le protocole SIP), ainsi qu’à un B2BUA Open Source : Asterisk.


A mardi 11 octobre, pour le prochain volet consacré à une introduction au couplage Asterisk Magento !

Un commentaire

  1. Salut tout le monde, super sujet technique. Il est possible sur la première option de passer par proxy SSL, SOCKS4 ou SOCKS5, des niveaux élevés de confidentialité et d’anonymat sécurisant l’interconnexion réseau.
    Pour plus d’informations je vous invite à voir https://meilleurvpn.net/proxy/

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.