Implémentation d'un portail SMS à base du logiciel KANNEL

III.2.2- Edition du fichier de configuration relatif au SMSC virtuel

37

Sans pour autant se répéter, rappelons que c'est au fichier de configuration édité précédemment, à l`exception du groupe relatif au Fake SMSC, qu'il faut ajouter les groupes relatifs au SMSC virtuel. Le plus important est de reconnaître le type de SMSC auquel l`on se connecte, bref le protocole de communication afin de faire une configuration conséquente. « AT » est le type dans ce cas, puisque c`est le protocole de communication entre le serveur et le SMSC virtuel (modem).

La configuration de ce SMSC de type « at » permet au modem de se connecter au serveur Kannel et de fonctionner comme un SMSC virtuel. Voici un modèle de configuration:

group = smsc

smsc = at

modemtype = marque du modem

device = répertoire de type /dev

speed = nombre

pin = nombre

validityperiod = code

keepalive = nombre en seconde

my-number = numéro de téléphone

sms-center = numéro

sim-buffering = valeur booléenne

La configuration du groupe « modems » précise les paramètres sous lesquels doit fonctionner ce modem :

group = modems

id = marque du modem

name = marque du modem

detect-string = marque du modem

detect-strings = modèle de la marque

speed = valeur en bps

38

no-pin = valeur booléenne

enable-hwhs = AT+IFC=2,2

no-smsc = valeur booléenne

sendline-sleep = nombre

keepalive-cmd = AT

message-storage = SM ou ME

La figure III-8 est une illustration du déploiement du serveur connecté à un modem

GSM :

Figure III-8 : Schéma conceptuel du serveur connecté au modem GSM

39

III.3 - Déploiement de Kannel connecté à un SMSC HTTP

Les opérateurs de téléphonie mobile n'autorisent la connexion de l'application de l'éditeur de services à leurs SMSCs, qu'à travers des passerelles. En effet, outre leur fonction d'adaptation de protocoles émetteurs en protocoles récepteurs, les passerelles assurent des connexions (aux SMSCs) sécurisées. Les protocoles HTTP, et SMPP n'étant pas propriétaires, la plupart des passerelles SMS offrent une interface de communication soit en mode HTTP ou SMPP. Nous avons choisi de tester la connexion en mode HTTP puisqu'elle correspond effectivement au mode de connexion autorisé par les opérateurs de téléphonie mobile. L'effectivité de cette connexion passe aussi par une configuration adéquate.

III.3.1 - Fichiers de configuration

Le fichier de configuration relatif au SMSC de type HTTP peut présenter

cette allure :

group = smsc

smsc = http

system-type = kannel

send-url = http://localhost:22022

smsc-username = icom smsc-password = icom port = 13013

connect-allow-ip = 127.0.0.1;*.*.*.*

Les quatre premières variables sont fondamentales pour ce fichier. Les autres variables sont optionnelles. A titre d'explication du fichier de configuration, considérons la variable « port = 13013 », elle précise le port d'écoute du serveur, des messages provenant d'autres passerelles. Il faut tout de même rappeler que ces fichiers viennent en rajout aux configurations faites précédemment.

40

III.3.2 - Intérêt de la prise en compte du « SMSC de type HTTP »

Une fois le fichier correctement configuré et pris en compte par le reste du serveur, il est désormais possible de simuler la connexion à une passerelle SMS d'un SMSC réel, en mode HTTP. Pour ce faire, nous nous sommes procurés deux ordinateurs, sur lesquels nous avons préalablement installé le serveur Kannel, que nous avons mis en réseau par un câble croisé. Schématiquement, le premier ordinateur correspond à celui sur lequel nous avons déployé Kannel, connecté au « SMSC »virtuel tandis que sur le second est configuré le « SMSC de type HTTP ». De façon concrète, c'est au niveau du groupe « SEND-SMS USER », qu'est déclaré le nouvel utilisateur qu'est l'ordinateur où est implémenté le groupe « SMSC de type HTTP ». Tout se passe comme si c'était un éditeur de services qui se faisait créer un compte au niveau du SMSC de l'opérateur (qui correspond au serveur déployer avec le SMSC virtuel). Le second système (serveur Kannel où est configuré le « SMSC de type HTTP») peut être comparé à notre serveur SMS que nous seront amenés à connecter à la passerelle d'un SMSC réel à travers une liaison spécialisée TCP. En effet, pour les entités en bout de liaison, le protocole de communication demeure le même, qu'il s'agisse d'une liaison spécialisée, ou d'un câble croisé. La figure III-9 est la représentation schématique du scénario de test de la liaison HTTP de l'application au SMSC :

41

FigureIII-9 : Scénario de test de la liaison HTTP de l'application au SMSC

Rappelons que cette liaison à la passerelle SMS en mode HTTP, de notre application n'est envisageable que lorsque cette dernière tourne sous kannel, brunet, xidris ou wapme. A part le fait que la prise en compte de cet « SMSC » permette le test de la liaison en mode HTTP ,il permet également que notre plateforme serve de passerelle d'accès à un SMSC d'opérateur de téléphonie mobile pour ceux qui voudront initier des SMS surévalués.

La configuration des fichiers fut l'essentiel du travail réalisé, puisqu'il a fallu d'abord cerner les différentes variables, puis ensuite n'utiliser que celles qui correspondent à nos besoins. L'utilisation du « Fake SMSC » n'était pas aussi obligatoire, mais utile puisqu'il nous a permis non seulement de tester l'état de l'installation, mais aussi d'être rassuré que notre application peut dialoguer avec un SMSC « physique » quelconque. Le test par le SMSC virtuel nous a rassuré une fois de plus et de façon pragmatique que l'application mise en place, répond.

42

Quant-au test de la connexion à un SMSC en mode HTTP de notre serveur SMS, il nous a permis de rassurer à ICOM qu'elle peut enfin déployer la liaison louée sans crainte.

43