SI HOPE Etude d'une passerelle/serveur SMS : Kannel Auteur: Nana Tchoutang Anicet IT Support Technique Fonction Destnataires: Sandeu Jean Jules Chef de projet SI Fonction Historique du document : Date Auteur Description 03/09/2009 NTA Premier Livrable Installaton et Confguraton de Kannel
I. Présentaton de Kannel Kannel est un projet Open Source, mis sous licence FreeBSD lancé par la compagnie fnlandaise Wapit Ltd en juin 1999. Elle est écrite en langage C, et fourni une passerelle mixte SMS et WAP. La licence FreeBSD est une licence libre utlisée pour la distributon de logiciels. Elle permet de réutliser une parte ou tout le logiciel sans restricton, qu'il soit intégré dans un logiciel libre ou propriétaire. En outre, elle permet également de gérer le push, le pull ou pull-push SMS c'est-à-dire respectvement, l'envoi des messages aux enttés extérieures, la récepton d'un SMS ou la récepton de requête, puis l'envoi de la réponse après traitement à partr de la plateforme. Au niveau de l'applicaton se fait le traitement de la requête, puis l'envoi de la réponse via le SMSC de ratachement à l'abonné demandeur. Dans la mesure où la passerelle est reliée à plusieurs SMSCs, une confguraton appropriée se chargera du routage du SMS-MT vers le SMSC concerné ; l'éditeur de service n'a donc pas l'obligaton de maîtriser avec ses contours le protocole d'interfaçage au SMSC, mais il est obligé de le déterminer. I.1 - Principe de fonctonnement de Kannel Le SMS est acheminé par le réseau de téléphonie mobile vers le serveur. Le serveur autorise à part la liaison au SMSC via une liaison spécialisée, une liaison à travers un simple modem GSM. L'acheminement des SMS requête-réponse difère selon les deux modes de liaison. En efet, selon le mode de liaison du serveur au SMSC de l'opérateur, par le truchement d'un modem GSM (SMSC virtuel), le SMS traverse quatre fois l'interface Air comme l'indique la fgure 1 : Figure 1 : Liaison du serveur SMS à travers un modem GSM Elle est indiquée lorsqu'il s'agit d'un trafc pas assez grand. Il est prouver empiriquement que le serveur connecté selon ce mode, ne peut traiter qu'au plus 6 à 10 SMS à la minute. Pour le mode de liaison, à travers une liaison spécialisée du serveur au SMSC de l'opérateur, le SMS ne traverse que deux fois l'interface Air comme l'indique la fgure 2 :
Figure 2 : Liaison du serveur SMS à travers une liaison spécialisée La liaison via un modem est celle que nous avons retenue pour les tests et présentaton de l'applicaton, surtout du fait de sa mise en œuvre facile, techniquement et fnancièrement. Les résultats obtenus seront valables pour une liaison spécialisée. Le traitement du SMS se faisant au sein du serveur, il convient de procéder à une étude de sa structure interne. I.2 - Architecture de Kannel L'architecture de Kannel révèle qu'il est composé de trois principaux blocs appelés encore «box» ; leur intercommunicaton correcte confère à Kannel, sa stabilité et son utlité. En efet, il s'agit de : > Le bearerbox; > Le SMS box; > Le WAP box. I.2.1 - Descripton des blocs a- Le bearerbox Le bearerbox est l'interface entre le réseau de téléphonie mobile et les autres compartments du serveur. Pour les autres blocs, Il joue le rôle de routeur. En efet, c'est lui qui reçoit les SMS provenant d'un réseau mobile et se charge de les transmetre au bloc approprié. Au fur et à mesure que les autres blocs se connectent et se déconnectent au bearerbox, ce dernier met à jour dynamiquement la liste des blocs en ligne. Mis à part la récepton de messages entrants, le bearerbox reçoit aussi tous les messages sortants et les adapte au format du réseau auquel il s'interconnecte. b- Le SMS box La concepton d'un SMS box est simple. Un SMS box reçoit un SMS à partr du bearerbox, l'analyse afn d'en extraire les mots-clés et les paramètres s'il y'a lieu. En foncton du mot clé, le serveur renvoie la réponse au client ; réponse qui peut être un texte statque, le résultat de l'exécuton d'une acton associée. Dans le cas où le service SMS confguré dans le fchier renvoie à un URL, le smsbox peut récupérer les données contenues et les envoyer au bearerbox qui à son tour les renvoie au client via le SMSC de l'opérateur de téléphonie mobile. Le smsbox peut également réceptonner les
SMS, provenant d`ordinateurs d'un réseau informatque tel que l'intranet ou l'internet. En efet, les messages reçus au format HTTP sont converts en messages de type SMS pour être accessibles aux terminaux GSM. c- Le WAP box Nous ne développerons pas assez cete parte.nous retendrons de ce bloc, qu'il met en place le protocole WAP (Wireless Applicaton Protocol) ; Protocole qui récupère les requêtes issues des mobiles supportant le WAP, puis les traduit en requêtes compréhensibles par les serveurs HTTP et vice versa. I.2.2- Mode de communicaton entre les blocs Les données sont échangées entre le bearerbox et les wapbox, smsbox à travers le protocole TCP /IP. TCP /IP est un protocole adapté très souvent pour une utlisaton en réseaux étendus (comme Internet), et son incorporaton dans la procédure de communicaton des diférents blocs de Kannel, signife que ces blocs peuvent être déployés sur des ordinateurs aussi distants que possible, si nécessaire. Les performances en termes de risque de crash sont plus optmisées lorsque ces blocs sont déployés sur des machines diférentes. Rappelons aussi, que de façon permanente, les diférents blocs, échangent à intervalles réguliers des messages de signalisatons. La fgure 3 représente l'architecture physique du serveur /passerelle Kannel : II- Interface avec les enttés externes Figure 3 : Architecture de Kannel Figure 4
Notre serveur SMS peut s'interfacer pour l`instant avec des enttés du type : > les terminaux GSM ou SMSC virtuel du genre WAVECOM ; > les SMSC tels que ceux de NOKIA ; > les serveurs HTTP ; > des passerelles SMS. La fgure 4 représente les diférentes enttés externes pouvant s'interfacer avec le serveur /passerelle Kannel : Quelque soit la nature de l'entité qui envoi la requête, le serveur l'intègre d'abord dans une fle d'attente, puis ensuite essaie de la renvoyer en mode TCP au SMS box à travers le bearerbox. II - Administraton de Kannel L'administraton peut se faire à travers la ligne de commande ou la requête HTTP. La syntaxe en mode HTTP est la suivante : «http ://localhost: 13000/command?password=icom». Les commandes sont multples, et peuvent être par exemple du type «resume» pour redémarrer le serveur s'il était isolé auparavant, «status» pour prendre connaissance du statut du serveur, ou «shutdown» pour arrêter le traitement des SMS à ceux qui se trouve déjà dans la fle d'atente. Somme toute, la maîtrise de la noton de passerelle en général, puis celle de passerelle dédiée SMS en partculier, n'a pas été sans intérêt. Elle nous a permis d'appréhender de façon globale le niveau de fonctonnement des diférents outls d'interconnexion et pour cause la passerelle inclut les fonctonnalités des outls de niveau qui lui est inférieur tels les routeurs, ponts, répéteurs. Le choix de la soluton libre «Kannel» comme passerelle SMS, ofre une multtude d'avantages. Pour se résumer, c'est une soluton stable, disponible en tout temps, non commercialisée, adaptable à nos besoins, pour ne citer que ceux-là. En renfort à tous ces arguments, Kannel se déploie de préférence dans un environnement libre tel que Linux. En efet, c'est donc après avoir installé «RedHAT enterprise 4», une distributon de Linux que nous avons déployé le noyau de traitement des SMS. MISE EN PLACE DU NOYAU DE TRAITEMENT DES SMS Ce chapitre sera sectonné en trois partes. La première parte sera consacré à l`installaton de Kannel et au test de son interacton avec un éventuel SMSC ; ce que nous appellerons le «Fake SMSC» ou le SMSC logiciel. Dans la deuxième parte, il s'agira de déployer Kannel lié à un SMSC virtuel, afn de tester les résultats des diférents services confgurés ; enfn, dans la dernière parte, nous aborderons la possibilité de connecter notre applicaton à une passerelle SMS d'un SMSC en mode HTTP.
Toujours dans cete parte, nous ne manquerons pas d`étudier la possibilité de faire aussi de notre applicaton, une passerelle d'accès SMS+ pour d'éventuels éditeurs de services. II.1- Mise en place de la passerelle/serveur Kannel II.1.1- Moyens utlisés et prérequis Les moyens utlisés pour l'implémentaton de Kannel sont à la fois matériels et logiciels. En efet, l'environnement Linux, la documentaton sur le serveur Kannel, les notons sur la pile de protocole TCP/IP (HTTP) nous ont été indispensables. «Redhat Enterprise 4» est la distributon de linux que nous avons retenu pour notre travail. C'est après l'avoir installé avec les paquetages nécessaires, sur un ordinateur Pentum IV, que nous allons déployer le serveur Kannel. II.1.2- Déploiement de Kannel à partr du code source II.1.2.1- compilaton La version de Kannel téléchargée dans notre cas est le 1.4.1 disponible sur htp://www.kannel.org/download/1.4.1/gateway-1.4.1.zip. Nous avons récupéré le fchier zippé sur une mémoire de masse (Clé USB) que nous avons transféré enfn sur notre poste de travail dans un répertoire à préciser comme on le fait pour la créaton de dossier dans Windows. Pour ce faire, nous avons procédé comme suit : > d`abord, créer le répertoire dans lequel va loger le fchier compressé à partr de la commande : mkdir > ensuite, copier ce fchier dans le répertoire en queston en tapant la commande : mcopy ou cp Une fois le fchier présent dans le répertoire, l'étape suivante va consister à la compilaton. Au fait, la compilaton traduit le code source en un langage compréhensible par la machine. Pour ce faire, il faut décompresser le fchier, avec la commande : unzip ou tar xzf. Après la décompression, lancer la commande :. /confgure -with-mysql -with-mysql-dir = [répertoire] Cete commande prépare la machine à la compilaton juste en vérifant si les paquetages indispensables y sont; elle est toujours associée par défaut à des optons. Et puisque, l'opton de connexion à une base de données n'est pas prise en compte par défaut, alors que nous en aurons besoin, nous l'avons rajouté comme l'indique la commande précédente. Le répertoire à préciser, est celui dans lequel est localisée la librairie MySQL. C'est la commande «make» qui déclenche la compilaton en vérifant d'abord la syntaxe correcte du code source. Pour faire simple, la compilaton est cete étape de l'installaton au cours de laquelle le code est transcrit en un langage compréhensible par la machine. II.1.2.2- Installaton Après la compilaton, il est nécessaire d`installer certains programmes complémentaires qui prennent en compte les diférents blocs du serveur, juste en tapant : make install = [répertoire]
Dans cete commande, le répertoire dans lequel seront installés les fchiers objets est à préciser. Dans notre cas, c'est le répertoire /etc/kannel qui a été choisi. A la fn de l`installaton de la passerelle/serveur, la possibilité est oferte d'en faire un portail SMS et/ou un portail WAP selon le besoin. La confguraton des fchiers sera faite en foncton du choix retenu. II.1.2.3- Confguraton des fchiers relatfs au serveur SMS En foncton de l`utlisaton que l'on veut en faire, le libellé des fchiers de confguraton, essentellement organisés en groupes, varie. Cependant, les fchiers relatfs au «bearerbox» sont obligatoires. En efet, les groupes «core» et «smsc» administrent le bearerbox tandis que les groupes «smsbox», «smsservice» s'occupent du «SMS box». Les diférents groupes sont défnis par une succession de variables. La syntaxe impose que ces groupes soient séparés les uns des autres par au moins une ligne vierge. D`une façon générale, il existe trois types de variables à savoir : > les variables obligatoires : elles sont indispensables au bon fonctonnement du groupe > les variables optonnelles : elles ne sont mentonnées que lorsque besoin il y'a > les variables facultatves : leur absence, n`entame en rien le bon fonctonnement de l`applicaton. La syntaxe générale des lignes de variable se présente comme suit : Variable = valeur. Toutefois, une variable peut être ajoutée et désactvée, juste en plaçant «#» au début de la ligne correspondante. L`éditon des fchiers de confguratons est strictement personnalisée, puisque dépendant des besoins exprimés.cete éditon peut se faire à partr de l'éditeur de texte, «Emacs» dans notre cas. Le fchier fnal est enregistré dans un répertoire à rappeler chaque fois que l`on voudra démarrer l'applicaton. a- Confguraton du groupe core La confguraton du groupe nommé «core» est indispensable au même ttre que le «bearerbox» qu'il paramètre. Le fchier fonctonnel n'est réduit qu`aux lignes qui ne seront pas précédées du signe dièse «#». Une confguraton simple du groupe nommé «core» peut se présenter comme suit : group = core admin-port = 13000 admin-password = icom status-password = icom admin-allow-ip = ``*.*.*.*`` admin-deny-ip =?127.0.0.1;*.*.*.*? smsbox-port = 14000 #wapbox-port = 2000 box-deny-ip =?*.*.*.*? box-allow-ip =?127.0.0.1;*.*.*.*?
log-fle =?tmp/kannel.log? log-level = 1 access-log =?tmp/smsinfo.access? store-fle =?tmp/sms.store? unifed-prefx =?+228, 00228,0 ; +,00? white-list =?http ://localhost/whitelist.txt? b- Confguraton du groupe «smsbox» Ce groupe précise à Kannel de ne fonctonner seulement que comme un serveur /passerelle SMS : group = smsbox bearerbox-host = 127.0.0.1; #sendsms-port = 1025 sendsms-chars =?1234567890? global-sender = 123456 log-fle =?/tmp/smsbox.log? log-level = 0 a 4. access-log =?tmp/smsbox.access? white-list = URL c- Confguraton des services Le groupe «sendsms-user» permet de défnir les utlisateurs accrédités pourcl'envoi de SMS, alors que le groupe «sms-service» permet de défnir lescservices SMS à tester. Chaque service est identfé par un mot clé dontcl'applicaton se chargera de renvoyer de façon automatque la réponse luiccorrespondant. Bref, ce sont ces services qui confèrent à Kannel sa foncton decserveur SMS ; la confguraton de ces services peut se présenter comme suit : group = sendsms-user username = icom password = icom user-deny-ip = «*.*.*.*» user-allow-ip = «*.*.*.*» faked-sender = 1 omit-empty = 1 forced-smsc = smsc-id group = sms-service keyword = heure header = icom footer = merci text = date
accepted-smsc = smsc faked-sender = 100 omit-empty = 1 d- confguraton du «Fake SMSC» ou «SMSC logiciel» L'étape suivante va consister à confgurer le groupe «smsc». En efet, c'est cete confguraton qui précise le SMSC de l'opérateur avec lequel peut dialoguer l'applicaton. Le plus important des paramètres est le protocole de communicaton avec le SMSC ; une fois le protocole défni, il ne restera qu`à efectuer une confguraton adéquate des paramètres restants, pour relier le serveur à ce dernier. En pratque, il n'en est pas ainsi puisque les opérateurs préfèrent ofrir très souvent des connexions relais (passerelle), utlisant plutôt le protocole HTTP (très répandu). Kannel en a aussi tenu compte et a proposé un type de groupe «smsc» spécial appelé «htp». En efet, Ce SMSC de type HTTP permet un accès à tout SMSC d'opérateur dont très souvent la passerelle ofre une interface HTTP; nous n'en sommes pas encore là, puisque cete opton fera l'objet d'un autre paragraphe. Pour l`instant, l'important est de s'assurer que l'installaton s'est opérée parfaitement. Cete vérifcaton passe par le test par le «Fake SMSC». En efet, le «Fake SMSC» joue le rôle d'un SMSC distant et permet de tester la fonctonnalité de l'applicaton ; ajoutons qu'il est purement logiciel et est implanté dans le serveur Kannel. La confguraton d'un «Fake SMSC» se présente comme suit : group = smsc smsc = fake port = 10000 connect-allow-ip = 127.0.0.1 La fgure5 matérialise la connexion entre le «Fake SMSC» et le serveur SMS : Figure 5 : Position logique du Fake SMSC Bien qu'ayant été installé avec le serveur, l'appréhension de sa foncton nous conduit à le placer à l'extérieur de ce dernier. Le test du «fakesmsc» se fait selon la syntaxe : test/fakesmsc [opton] «message à envoyer».
La fgure 6 regroupe les résultats du test que nous avons efectué : Figure 6 : Résultat du test de la connexion du serveur au Fake SMSC L'analyse de la fgure 6 en sa seconde ligne révèle que nous avons envoyé cinq (5) fois le message «heure». Il apparaît clairement qu'une réponse est envoyée à chaque requête, et vaut «mer+jui+30+2008 +16 :07 :03» En efet, cete réponse est conforme à notre confguraton, puisque cete dernière précise qu'à tout message correspondant à «heure», que la réponse renvoyée corresponde à la date et à l'heure du moment. Ces tests sont rassurants, mais pas absolument selon nous, pour baliser la voie à la mise en place d'une liaison spécialisée entre le SMSC et notre applicaton. Comme alternatve, nous avons proposé de passer par le test des services, à partr d'un modem GSM (SMSC virtuel) et pour cause, il arrive parfois que la pratque s'éloigne de la théorie. II.2- Déploiement de Kannel connecté à un SMSC virtuel II.2.1- Outls requis Tous les outls matériels et logiciels du paragraphe précédent, sont repris dans le cadre du déploiement du serveur Kannel connecté à un SMSC virtuel. L'opérateur de téléphonie mobile très souvent donne accès à son SMSC, que par le biais d`une passerelle SMS dont les paramètres sont communiqués à l'éditeur de services. A ttre d`informaton, ICOM s`est inscrite dans cete opton d`accès au SMSC, à conditon que nous lui assurons qu'à la toute première tentatve, la connexion
sera fonctonnelle. Pour des raisons de tests et pour une présentaton du produit, nous avons proposé un accès au SMSC via un modem GSM. En fait, cete étape du travail n'est qu'une parte d'un processus à deux niveaux que nous nous sommes fxés. II.2.1.1- Un ordinateur Un ordinateur aux caractéristques similaires à celles décrites, peut être utlisé également dans ce cas. La distributon de Linux adoptée reste la même c'est-à-dire «Redhat enterprise 4». Sur cet ordinateur, nous metrons en place le serveur /passerelle Kannel en suivant les étapes mises en exergue. Pour ce qui est de la confguraton des fchiers, seul le groupe du Fake SMSC, sera remplacé par celui du SMSC virtuel auquel le serveur Kannel est connecté. II.2.1.2- Modem GSM Les modems ne reçoivent des instructons qu'à partr des commandes dites de type AT. En efet, les commandes AT désignent un groupe de commandes, mis au point par Hayes afn de contrôler le fonctonnement des modems. Ces commandes permetent d'interroger le mobile pour obtenir des informatons ou bien d'exécuter une tâche afn de s`assurer que le modem peutonctonner de façon correcte (qualité du signal reçu...) WAVECOM est la marque de modem utlisé ; son modèle est de type Fastrack. C'est ce modem qui jouera le rôle de SMSC virtuel. Les images de la fgure 7 donnent des détails précis sur l'aspect physique du modem : Figure 7 : Présentation générale du modem GSM Wavecom
Le modem GSM fonctonne dans les bandes de fréquences 900MHz et /ou 1800MHz. Il intègre les fonctons de transmission de données/voix/sms et la foncton de FAX. Il est utlisé en GSM et DCS. Alimenté sous une tension contnue et il tolère des tensions comprise entre 9 à 12Volts. Il est fourni avec un convertsseur 1 10Volts AC-12Volts DC. Il a fallu donc intercaler un transformateur 220Volts- 1 10Volts entre le secteur et l'adaptateur. a- Préparaton du modem en vue de son utlisaton En appuyant sur le bouton d'éjecton de la trappe à l'aide de la mine d'un stylo par exemple, la trappe s'éjecte. Sur cete trappe éjectée, est posée convenablement la carte SIM ; l'ensemble est enfché dans le modem. L'antenne est connectée au port RF. L'ensemble modem-antenne est connecté à l'ordinateur à travers une liaison série RS232. Quant-au câble d'alimentaton, il sera enfché dans son port correspondant. b- Test des caractéristques du modem par les commandes AT Nous avons envoyé ces commandes à partr du programme Hyperterminal de Windows sur un port COM, obtenu en suivant le chemin ci-après : Démarrer/Programmes /Accessoires/ Communications/ Hyperterminal Ces tests permetent de s'assurer de l'état correct du modem. En premier, on lance toujours AT, puis on appuie sur la touche ENTREE, Si le modem est en état de fonctonner, alors il renvoi la réponse OK qui s'afche sur l'hyperterminal, comme l'indique la fgure 8: Figure 8 : Test de l'état du modem Cete première commande permet de s'assurer que le modem est en état de recevoir d'autres commandes. La syntaxe générale des commandes AT se présente de la manière suivante : AT + nom de la commande. La commande CGMI présente sur la fgure 9 permet simplement de préciser la marque de modem dont nous disposons : Figure 9 : Test de la marque du modem
La commande AT+CREG? permet de vérifer si le modem a été enregistré ou non par le réseau. En efet, lorsque la réponse à la commande afchera +CREG:O, 1 alors le modem est enregistré sur le réseau en tant qu'utlisateur local, alors que +CREG:0,5 indique qu'il s'agit d'un utlisateur internatonal, qui accède au réseau par roaming. Toute valeur autre que 0,1 ou 0,5 implique que l'accès au réseau mobile est refusé. Nos tests ont révélé ce que représente la fgure III-6 : Figure 10 : Test de l'enregistrement du modem sur le réseau Le niveau du signal est testé, à partr de la commande CSQ comme l'indique la fgure 11 : Figure 11 : Test du niveau du signal reçu par le modem En efet, c'est lorsque le niveau du signal reçu est situé entre 11 et 31 qu'il est optmal pour enclencher une communicaton. Alors, ce qui voudrait dire qu'au moment et en l'espace où nous avons efectué ces tests, toutes les conditons étaient réunies pour que notre modem soit opératonnel. II.2.2- Editon du fchier de confguraton relatf au SMSC virtuel Sans pour autant se répéter, rappelons que c'est au fchier de confguraton édité précédemment, à l`excepton du groupe relatf au Fake SMSC, qu'il faut ajouter les groupes relatfs au SMSC virtuel. Le plus important est de reconnaître le type de SMSC auquel l`on se connecte, bref le protocole de communicaton afn de faire une confguraton conséquente. «AT» est le type dans ce cas, puisque c`est le protocole de communicaton entre le serveur et le SMSC virtuel (modem). La confguraton de ce SMSC de type «at» permet au modem de se connecter au serveur Kannel et de fonctonner comme un SMSC virtuel. Voici un modèle de confguraton:
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 confguraton du groupe «modems» précise les paramètres sous lesquels doit fonctonner 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 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 fgure 12 est une illustraton du déploiement du serveur connecté à un modem GSM: Figure 12 : Schéma conceptuel du serveur connecté au modem GSM
II.3 - Déploiement de Kannel connecté à un SMSC htp Les opérateurs de téléphonie mobile n'autorisent la connexion de l'applicaton de l'éditeur de services à leurs SMSCs, qu'à travers des passerelles. En efet, outre leur foncton d'adaptaton de protocoles émeteurs 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 ofrent une interface de communicaton soit en mode HTTP ou SMPP. Nous avons choisi de tester la connexion en mode htp puisqu'elle correspond efectvement au mode de connexion autorisé par les opérateurs de téléphonie mobile. L'efectvité de cete connexion passe aussi par une confguraton adéquate. III.3.1 - Fichiers de confguraton Le fchier de confguraton relatf au SMSC de type HTTP peut présenter cete 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 fchier. Les autres variables sont optonnelles. A ttre d'explicaton du fchier de confguraton, 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 fchiers viennent en rajout aux confguratons faites précédemment. II.3.2 - Intérêt de la prise en compte du «SMSC de type HTTP» Une fois le fchier correctement confguré 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é 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ématquement, le premier ordinateur correspond à celui sur lequel nous avons déployé Kannel, connecté au «SMSC»virtuel tandis que sur le second est confguré 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 utlisateur 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 confguré 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 efet, pour les enttés en bout de liaison, le protocole de communicaton demeure le même, qu'il s'agisse d'une liaison spécialisée, ou d'un câble croisé. La fgure III-9 est la représentaton schématque du scénario de test de la liaison HTTP de l'applicaton au SMSC :
Figure13 : Scénario de test de la liaison HTTP de l'application au SMSC Rappelons que cete liaison à la passerelle SMS en mode HTTP, de notre applicaton n'est envisageable que lorsque cete dernière tourne sous kannel, brunet, xidris ou wapme. A part le fait que la prise en compte de cet «SMSC» permete 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 initer des SMS surévalués. La confguraton des fchiers fut l'essentel du travail réalisé, puisqu'il a fallu d'abord cerner les diférentes variables, puis ensuite n'utliser que celles qui correspondent à nos besoins. L'utlisaton du «Fake SMSC» n'était pas aussi obligatoire, mais utle puisqu'il nous a permis non seulement de tester l'état de l'installaton, mais aussi d'être rassuré que notre applicaton peut dialoguer avec un SMSC «physique» quelconque. Le test par le SMSC virtuel nous a rassuré une fois de plus et de façon pragmatque que l'applicaton mise en place, répond. 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 enfn déployer la liaison louée sans crainte.
CONCLUSION La réalisaton de ce projet a été bénéfque à plus d'un ttre. Ce fut pour nous l'occasion d'une véritable initaton aux réalités de la vie professionnelle. Le portail SMS que nous avons mis en place a exigé à la fois un minimum de connaissances du réseau GSM, partculièrement le monde du SMS et des outls de développement informatque puisqu'il est désormais impensable de dissocier les télécommunicatons de l'informatque. Ce portail SMS, joue un double rôle : > d'abord, il sert de passerelle SMS ; en ce sens, il est aussi d'un intérêt capital pour les opérateurs de téléphonie mobile, eux-mêmes. > ensuite, il sert de serveur SMS, du fait de sa capacité à traiter de façon automatque les requêtes SMS, qui lui parviennent. La dénominaton de «passerelle/serveur» atribuée n'apparaît plus donc sans sens ; nous pensons à notre humble avis, que l'appellaton «serveur» semble être plus global. Ainsi lorsque le nom «passerelle» seul, est utlisé seul, c'est que «Kannel» ne roule en ce moment seulement que comme une passerelle SMS. L'expérience que nous avons acquise suite à ce travail, nous a convaincu que l'avenir de la téléphonie mobile passe par de telles applicatons puisqu'à présent, le plus important est de permetre une pleine utlisaton du SMS, vu que presque tout le monde y est atré. Un des problèmes que nous avons rencontré, était le temps pour fnaliser le tout, puisque mis à part la taille des prérequis, leur aspect «nouveau» y avait contribué. Au fnal, ce projet nous a beaucoup apporté dans la compréhension de la technologie TCP/IP, des commandes linux que nous n'avions jamais essayé ; nous avons tant appris aussi sur les solutons «open source» et leur place dans l'implémentaton de produits téléinformatques. La langue anglaise quant-à elle, s'est une fois encore avérée, la langue du technicien, puisque nous n'avons pas pu nous en passer. Au niveau personnel, nous sommes sort grandit, puisque nous concevons désormais autrement le domaine des télécommunicatons. Nous pensons être devenu beaucoup plus imprégner. Cependant, la réalisaton de ce produit ne s'est pas faite techniquement de façon aisée, puisqu'il n'a pas suft de disposer simplement de la documentaton de «Kannel» pour metre en place, ce portail SMS. D'ailleurs, les foires aux questons sur Internet, communément appelées «forums» en témoignent. En somme, il fallait juste faire preuve d'ingéniosité. Toujours en raison de la difculté, résidant dans son déploiement, nous estmons à environ 75%, les potentalités du serveur Kannel, que nous avons pu actvés ; beaucoup encore reste à faire donc. Aussi, il ne faut pas non plus perdre de vue que jusqu'à ce stade, nous ne sommes qu'au début de l'apprentssage de la téléinformatque et que ce document est loin d'avoir la prétenton d'avoir tout dit. Notre souhait est qu'il serve de document français de base à la compréhension de la passerelle/serveur Kannel.