Vous êtes sur la page 1sur 68

Liste des abrviations

Cycle de formation des ingnieurs en Tlcommunications


Option :

Ingnierie des Rseaux

Rapport de Projet de fin dtudes

Thme :

Dveloppement et intgration de solutions CTI dans une plateforme Cisco.


Ralis par :

Seifeddine Tlili
Encadrants :

M. Riadh Tebourbi (SUPCOM) M. Nizar Hedhili (OneTech Development)


Travail propos et ralis en collaboration avec

Anne universitaire : 2006/2007

Ddicaces
A mes parents, A mon frre, A ma soeur, A Weal et Youssef A mon beau frre Hamadi A toute ma famille, Je ddie ce modeste travail

ii

Remerciements
Ce projet, ralis au sein du Groupe OneTech dans lentreprise OneTech dveloppement sinscrit dans le cadre du Projet de Fin dEtudes lEcole Suprieure des Communications de Tunis (SUPCOM) pour lobtention du diplme dingnieur en Tlcommunications. Au terme de ce projet, je tiens exprimer ma profonde gratitude et mon immense respect M.. Riadh Tebourbi, matre assistant SupCom, ainsi que M. Nizar Hedili Directeur Technique OneTech Dveloppement pour mavoir soutenu durant la priode de mon projet. J'aimerais tmoigner du plaisir qu'tait pour moi de travailler sous leurs directives. Je tiens galement exprimer ma profonde reconnaissance M. Samy Chapoutot, directeur Commercial OneTech dveloppement pout sa disponibilit, ses qualits humaines et ses conseils prcieux. De mme, je souhaite transmettre l'expression de ma reconnaissance et ma plus profonde gratitude aux ingnieurs de OneTech Dveloppement qui mont offert un excellent cadre de travail ainsi quun climat extrmement agrable.

Avec beaucoup d'gard, je ne manquerai pas d'exprimer ma grande reconnaissance tous les enseignants et administrateurs de l'cole suprieure des communications de Tunis et tous les membres du jury pour avoir accept de juger ce modeste travail

iii

Avant propos
Dans le cadre da ma formation dingnieur en tlcommunication lcole Suprieure des communications de Tunis, jai effectu un projet de fin dtudes au sein de lentreprise OneTech dveloppement filiale du groupe tunisien One TECH Group. Le sujet porte sur la conception et limplmentation de services lis la tlphonie IP et le couplage tlphonie informatique sur la plateforme Cisco CallManager.

Avec son concept One Stop Shop , le groupe One TECH fournit une multitude de solutions complmentaires pour la ralisation dun large ventail de sous-ensembles complets et de produits finis selon les exigences des clients et les normes internationales. Les socits du groupe One Tech offre des solutions complmentaires, garantissant ainsi des conomies de temps, de transport et dintgration [1].

Conscient des volutions et des mutations dans le domaine des Technologies de linformation et des communications, vecteurs de croissance et de dveloppement lchelle mondiale, et des enjeux vitaux rduire la fracture numrique, OneTech affirma la dtermination orienter sa stratgie vers les nouvelles Technologies de linformation et des communications dans le cadre de partenariats internationaux axs sur la complmentarit [1].

iv

Table des matires

Table des matires :


I.1. Introduction gnrale ........................................................................................................ 1 Chapitre 1 : Etude de problmatique I.1. Introduction ....................................................................................................................... 3 I.2. Architecture CTI de CallManager................................................................................... 4 I.3. Dploiement de JTAPI dans une architecture Cisco...................................................... 5 I.4. Dploiement de services de tlphonie IP dans une architecture Cisco ....................... 6 I.4.1. Principe de fonctionnement des services de tlphonie IP ......................................... 7 I.5. Bilan de lanalyse et choix de la solution ......................................................................... 7 I.5.1. Ressources matrielles ................................................................................................ 8 I.5.2. Etude des solutions possible........................................................................................ 8 I.5.2.1. Partie utilisateur..................................................................................................... 8 I.5.2.1.1. Intgrer linterface dans un Formulaire HTML .............................................. 8 I.5.2.1.2. Intgrer linterface dans une interface utilisateur graphique..................... 9 I.5.3. Partie serveur............................................................................................................... 9 I.5.4. Choix de la solution..................................................................................................... 9 I.6. Spcifications des besoins................................................................................................ 10 I.6.1. Spcifications des besoins fonctionnels .................................................................... 10 I.6.1.1. Dveloppement de la partie Serveur dapplication CTI...................................... 10 I.6.1.2. Dveloppement de la partie Client ...................................................................... 10 I.6.1.2.1. Dveloppement de linterface Client................................................................ 10 I.5.1.2.2. Dveloppement de la partie CTI au niveau du client.................................... 11 I.7. Spcifications des besoins non fonctionnels................................................................... 11 I.7.1. Contrainte temps de rponse ..................................................................................... 11 I.7.2. Contraintes lies au dveloppement.......................................................................... 11 I.8. Conclusion ........................................................................................................................ 11 Chapitre 2 Architecture et conception II.1. Introduction.................................................................................................................... 12 II.2. Architecture matrielle et protocolaire........................................................................ 12 II.3. Choix de larchitecture .................................................................................................. 14 II.3.1. Diagramme de dploiement ...................................................................................... 14 II.3.2. Justification conceptuelle .......................................................................................... 15 II.3.2.1. Choix de larchitecture client serveur ................................................................. 15

Table des matires II.3.2.2. Choix du client CRM .......................................................................................... 15 II.4. Diagrammes de cas dutilisation de la solution ........................................................... 15 II.4.1. Dfinition des diffrents acteurs agissant sur le systme.......................................... 15 II.4.2. Les packages du diagramme de cas dutilisation ...................................................... 17 II.4.3. Diagrammes de cas dutilisation ............................................................................... 18 II.4.3.1. Package IpPhoneService ..................................................................................... 18 II.4.3.2. Package PushtoPhone.......................................................................................... 19 II.4.3.3. Package Database................................................................................................ 20 II.4.3.4. Package GUICrm ................................................................................................ 21 II.4.3.5. Package Telephony ............................................................................................. 22 II.5. Diagrammes de classes................................................................................................... 22 II.5.1. Diagramme de classe du Client Crm......................................................................... 23 II.5.1.1. La Classe CallerInfoServer ................................................................................. 24 II.5.1.2. La classe GuiCrm ................................................................................................ 24 II.5.1.3. La classe updateDb.............................................................................................. 24 II.5.1.4. La classe NumberFind......................................................................................... 25 II.5.1.5. La classe Affiche................................................................................................. 25 II.5.1.6. La classe AddToDb ............................................................................................. 25 II.5.1.7. La classe main ..................................................................................................... 25 II.5.2. Diagramme de classe du serveur dapplication CTI ................................................. 26 II.5.2.1. La classe PushXML ............................................................................................ 27 II.5.2.2. La classe Findnum............................................................................................... 27 II.5.2.3. La classe Index .................................................................................................... 27 II.5.2.4. La ClasseMenuDirectory..................................................................................... 28 II.5.2.5. La Classe Search ................................................................................................. 28 II.6. Digrammes de squence................................................................................................. 28 II.6.1. Diagramme de squence du serveur dapplication CTI ............................................ 29 II.6.2. Digramme de squence du client CRM..................................................................... 30 II.7. Conclusion....................................................................................................................... 30 Chapitre 3 : Solution et implmentation III.1. Introduction .................................................................................................................. 31 III.2. Environnement et langage de programmation .......................................................... 31 III.3. Choix de larchitecture logicielle................................................................................. 32 III.3.1.Le package JTAPI ..................................................................................................... 32 vi

Table des matires III.3.2.LAPI Swing : ........................................................................................................... 36 III.3.3.LAPI JDBC ........................................................................................................ 36 III.3.4.Les serveurs............................................................................................................... 37 III.3.5.Le systme de gestion des bases de donns : ............................................................ 37 III.3.6.Les JSP ...................................................................................................................... 37 III.3.7.XML .......................................................................................................................... 38 III.4. Les interfaces ................................................................................................................ 38 III.4.1.Les interfaces utilises pour les IP Phones................................................................ 39 III.4.2.Les interfaces graphiques .......................................................................................... 40 III.4.3.Lancement du Service ............................................................................................... 44 III.5. Conclusion ..................................................................................................................... 46 Conclusion gnrale .............................................................................................................. 46 Annexe..................................................................................................................................... 49 Bibliographie........................................................................................................................... 54

vii

Table de figures

Table de figures
Figure 1 Interfaces applicatives de CallManager ....................................................................... 4 Figure 2 Architecture Cisco CTI................................................................................................ 5 Figure 3 Composants essentiels pour les services de tlphonie IP Cisco................................. 6 Figure 4 Enregistrement du tlphone IP et consultation des services ...................................... 7 Figure 5 Architecture matrielle de la solution ........................................................................ 13 Figure 6 Diagramme de dploiement du Service ..................................................................... 14 Figure 7 Les packages utiliss.................................................................................................. 17 Figure 8 Diagramme des packages........................................................................................... 17 Figure 9 Diagramme du package IpPhoneService ............................................................. 19 Figure 10 Package PushToPhone............................................................................................. 20 Figure 11 Package PushToPhone............................................................................................. 21 Figure 12 Package GuiCrm ...................................................................................................... 21 Figure 13 Package Telephony .................................................................................................. 22 Figure 14 Diagramme de classe du Client Crm ....................................................................... 23 Figure 15 Diagramme de classe du serveur d'application CTI................................................. 26 Figure 16 Diagramme de squence du serveur d'application CTI ........................................... 29 Figure 17 Diagramme de squence du Client Crm .................................................................. 30 Figure 18 Modle dappel Jtapi................................................................................................ 33 Figure 19 Transition dtat du Provider ................................................................................... 34 Figure 20 Diagramme de transition dun call........................................................................... 35 Figure 21 Initialisation du moteur JTAPI et connexion au CallManager ................................ 36 Figure 22 Exemple d'utilisation de l'API XML de Cisco......................................................... 38 Figure 23 Interfaces du service de tlphonie IP ..................................................................... 39 Figure 24 Page daccueil .......................................................................................................... 40 Figure 27 Interfaces Swing ...................................................................................................... 41 Figure 28 Ajout dun agent dune socit ................................................................................ 42 Figure 29 Rechercher un utilisateur ......................................................................................... 42 Figure 30 Ajout dinformations dune socit dans notre base de donnes............................. 43 Figure 31 Recherche dinformations dune socit.................................................................. 43 Figure 32 Affichage des coordonnes de linterlocuteur ......................................................... 44 Figure 33 Affichage des donnes l'cran du poste IP............................................................ 45 Figure 34 Numros non reconnus dans la base de donnes ..................................................... 45 Figure 35 Architecture globale du CTI .................................................................................... 51

Tlili.Seifeddine PFE Juin 2007

viii

Liste des abrviations

Liste des abrviations:

A
ACD API Automatic Call Distributor Application Programming Interface

C
CCM CRM CTI CTIQBE Cisco CallManager Customer Relationship Management Computer Telephony Integration Computer Telephony Interface Quick Buffer Encoding

G
GUI Graphical User Interface

H
HTML HTTP HyperText Markup Language HyperText Transfer Protocol

I
IVR Interactive Voice Response

J
JDBC JSP JTAPI JVM Java DataBase Connectivity Java Server Page Java Telephony API Java Virtual Machine

L
LDAP Lightweight Directory Access Protocol

Tlili Seifeddine -PFE Juin 2007-

ix

Liste des abrviations

T
TAPI TAPI SRV TOIP TSP Telephony API TAPI Server Telephony Over IP Tapi Service Provider

U
UML Unified Modelling Language

X
XML Extensible Markup Language

Tlili Seifeddine -PFE Juin 2007-

Introduction gnrale

Introduction gnrale
Dans un monde conomique toujours plus actif, il n'est pas ncessaire de rappeler l'importance de la relation clientle. S'il est ncessaire de trouver de nouveaux prospects, il est aussi important de conserver ses actuels clients. Hors, il apparat que la relation avec ces derniers passe en grande partie par le tlphone : le mdia le plus utilis et le plus accessible. Traditionnellement spars, la tlphonie et linformatique font aujourdhui lobjet dune convergence de plus en plus marque se manifestant notamment par lmergence des solutions de tlphonie sur IP. Cette convergence a donn naissance un nouveau concept, le CTI ou le Couplage Tlphonie Informatique.

Le concept de Couplage Tlphonie Informatique permet de mettre en place des applications nouvelles qui sappuient sur lexploitation simultane de deux grandes dynamiques : la puissance des services de commutations en temps rel des plates-formes de communications, et la capacit de traitement de linformation des rseaux informatiques.

La plupart des projets d'intgration entre tlphonie et informatique concernent, essentiellement, la gestion de la relation client ou le help desk, au sein des centres d'appels. Fonction la plus courante : la monte de fiche ; le numro de l'appelant est reconnu et sa fiche apparat.

Cest dans ce cadre que ce projet sinscrit. Il sagit de concevoir, implmenter et intgrer le service Client CRM sur une plateforme base dquipements Cisco qui aura comme acteur principal le serveur IPPBX de Cisco, le CallManager. Le projet slargit encore plus, permettant dintgrer cette fonctionnalit au tlphone IP Cisco ainsi que le dveloppement et lintgration de services de tlphonie IP accessible partir de ce poste. La plupart des terminaux IP de Cisco faisant partie de la gamme 7900 savoir le IP phone 7940 peuvent accder diffrents services en utilisant le langage XML. Ce qui offre une facilit d'utilisation via une interface graphique et permet ainsi laccroissement de la productivit personnelle.

Tlili Seifeddine -PFE Juin 2007-

Introduction gnrale Dans ce rapport de fin dtude, nous commencerons, dans un premier chapitre par une recherche bibliographique. Nous prsenterons travers cette partie linfrastructure sur laquelle nous nous sommes bass pour implmenter ce service partir de cette tude, nous allons choisir la solution qui va tre implmente, et nous spcifierons les besoins de cette solution. Dans le deuxime chapitre, nous nous sommes bass sur le formalisme UML pour concevoir la solution choisie. Dans le troisime chapitre, nous prsentons les diffrents outils utiliss et les interfaces daccs aux services, soit partir dun poste PC ou dun tlphone IP.

Tlili Seifeddine -PFE Juin 2007-

Etude de problmatique

Chapitre 1 I.Etude de problmatique

I.1.Introduction
Le CRM (Customer Relationship Management) est lun des aspects des applications du CTI, il permet l'entreprise d'obtenir des donnes importantes sur ses clients (liste de contacts, pistes, opportunits, contrats, messages lectroniques, comptes, historiques d'achats et prfrences) de manire leur proposer des produits et des services qui rpondent prcisment leurs besoins lors dun appel tlphonique et ainsi amliorer la qualit de service offerte aux clients. Parmi les applications CRM qui sont troitement lies au CTI on cite la monte de fiche client lors dun appel. L'analyse de ces donnes aide notamment les entreprises dterminer qui sont leurs meilleurs clients, enrichir et personnaliser les relations avec ces clients, grer leurs campagnes de marketing, rduire les dlais de rponse lors dun processus de transaction tlphonique. Dans ce chapitre nous allons analyser la solution que nous allons dvelopper qui se rsume la monte de fiche client lors dun appel tlphonique que se soit sur lordinateur de lutilisateur ou encore sur un tlphone IP de la gamme Cisco 7900 ainsi que lintgration de services de tlphonie IP pour un poste IP afin de lui permettre dinteragir avec un serveur de base de donnes utilisateurs. Dans cette partie nous allons prsenter larchitecture Cisco pour limplmentation de solutions CTI ainsi que le dploiement de JTAPI dans une telle infrastructure. Puis nous passons larchitecture adopte par Cisco pour le dploiement et lintgration de solutions de services de tlphonie IP.

Tlili Seifeddine -PFE Juin 2007-

Etude de problmatique

I.2. Architecture CTI de CallManager


Cisco CallManager (voir Annexe) contient un ensemble dinterfaces qui permettent la communication avec des applications extrieures. La figure 1 illustre les diffrents types dinterfaces que peut fournir le CallManager ainsi que les applications qui peuvent interagir avec ces interfaces [2].

Figure 1Interfaces applicatives de CallManager

TAPI et JTAPI permettent de faire connecter au CallManager via les ports CTI les clients ou encore les serveurs dapplication CTI. Parmi les applications CTI on retrouve la messagerie unifie, Call Center, E-Conferencing et les systmes IVR. L'Access aux services d'annuaire partir de requtes LDAP permettent l'authentification d'appel dans un environnement dapplication d'entreprise. En utilisant XML travers des message http,Cisco 7940 et 7960 IP Phones sont quips dun client web leur permettent dafficher des donnes sous forme XML[2].

Tlili Seifeddine -PFE Juin 2007-

Etude de problmatique

I.3.Dploiement de JTAPI dans une architecture Cisco


Larchitecture CTI de Cisco renferme les composants suivants : Application Provider ou Fournisseur de plateforme applicative Serveur CCM Controllable CTI devices La figure 2 illustre les composants CTI et linteraction du CallManager avec deux applications CTI utilisant diffrente API, une qui implmente le JTAPI et une autre qui implmente le TAPI [2].

Figure 2 Architecture Cisco CTI

Le CallManager est capable de traduire diffrents protocoles CTI savoir le CTIQBE (CTI Quick Buffer Encoding) vhicul travers un lien TCP/IP. Le lien entre lapplication et le CallManager renferme un ensemble de protocoles CTI comprhensible par le CallManager puisque ce dernier ne distingue pas entre les applications TAPI et JTAPI. Pour permettre une application de dialoguer avec le Serveur de CallManager, Cisco fourni un logiciel quon appelle TSP ou Telephony Service Provider. Ce logiciel peut tre install sur le serveur CTI ou sur une machine part. Dans notre exemple le TSP offre des API comme le TAPI ou le JTAPI aux applications du serveur CTI et dun autre ct dialogue avec le CallManager via le protocole propritaire de Cisco le CTIQBE. Ce TSP est reli au CallManager grce au lien CTI travers le LAN de lentreprise. Tlili Seifeddine -PFE Juin 20075

Etude de problmatique Les implmentations Cisco Tapi Service provider (TSP) et le JTAPI traduisent les APIs utilises par notre application en message CTIQBE comprhensible par le CallManager Les applications CTI peuvent contrler un certain nombre dentit travers le CallManager parmi lesquelles on retrouve : Appareil ou Device : Les appareils tel que IP Phones peuvent tre contrls et surveills partir dune application CTI. Port CTI : Les Ports CTI sont des dispositifs virtuels qui servent manipuler les applications CTI. Par exemple, un IP Softphone de Cisco peut tre reli au CallManager par l'intermdiaire d'un port de CTI. Point ditinraire CTI (CTI route Point) : Un point d'itinraire CTI est un dispositif virtuel qui peut manipuler simultanment des appels multiples et tous sur la mme ligne. Par exemple, un point d'itinraire CTI peut tre un numro 1800 qui recevra des appels et assurera la fonction de routage de ces appels au port CTI appropri [2].

I.4.Dploiement de services de tlphonie IP dans une architecture Cisco


Parmi les atouts de larchitecture Cisco pour la TOIP ou Tlphonie IP est le fait de pouvoir dployer une panoplie de services bas sur le langage XML et qui seront accessible via le tlphone IP. Parmi les services qui peuvent tre intgrs dans une telle architecture on cite linteraction du terminal IP avec un serveur de base de donnes, la consultation des nouveaux produits offert par Cisco via Internet ainsi que les bulletins dinformations. La figure 3 illustre les composants cl de dploiement des services de tlphonie IP [2].

Figure 3 Composants essentiels pour les services de tlphonie IP Cisco

Tlili Seifeddine -PFE Juin 2007-

Etude de problmatique

I.4.1. Principe de fonctionnement des services de tlphonie IP


Dans un premier lors du dmarrage du tlphone IP, ce dernier changera des messages avec le serveur CallManager en utilisant le protocole SCCP afin de senregistrer et obtenir ainsi une adresse dans le rseau. Mais lchange de messages SCCP entre le CCM et le IP Phone ne sarrte pas juste au fait de lobtention dune adresse mais aussi la rcupration des privilges accord savoir le droit de consulter les services de tlphonie IP disponible et une fois que ladresse du serveur a t rcupr, le poste IP envoi une requte de type http vers ce serveur afin de consulter les services mis sa disposition, la figure 4 illustre les tapes dcrites ci-dessus :

Figure 4 Enregistrement du tlphone IP et consultation des services

I.5. Bilan de lanalyse et choix de la solution


Ce projet consiste concevoir et dvelopper une application CTI qui se rsume tablir une connexion avec le IP-PBX CCM afin de rcuprer le numro de la partie appelante et permettre ainsi lidentification de l'interlocuteur. Cette solution est base sur lAPI Cisco JTAPI ddie pour le dveloppement de solutions de tlphonie et permet ainsi de bnficier de nouveaux services. La solution propose a pour but de simplifier linteraction de lutilisateur avec les services de tlphonie tout en masquant la partie CTI.

Tlili Seifeddine -PFE Juin 2007-

Etude de problmatique

I.5.1. Ressources matrielles


Pour raliser ce projet, la socit OneTech dveloppement ma offert les ressources ncessaires pour mener bien mon projet savoir : Une plateforme Cisco CallManager installe sur un Serveur HP DL380 G4 Un commutateur Cisco Catalyst 2960 series Un routeur Cisco Catalyst 2080 series Cisco IP Phone 7940 ainsi que Cisco Ip Communicator (softphone).

I.5.2. Etude des solutions possible


Dans cette section nous avons tudi les diffrentes solutions possibles en prsentant les avantages et les inconvnients de chaque solution.

I.5.2.1. Partie utilisateur


Linterface utilisateur doit tre comprhensible et simple manipuler par tous les utilisateurs, il y a beaucoup de solutions possibles pour implmenter cette partie.

I.5.2.1.1. Intgrer linterface dans un Formulaire HTML


Lide est inspire des formulaires HTML quon peut trouver sur certains sites web. Pour accder au service, lutilisateur devra chaque fois se connecter au serveur web afin dinteragir avec ce formulaire qui intgrera les diffrents champs ncessaire pour le stockage et la consultation des informations des clients de la socit. Cette interface devra contenir les diffrentes possibilits quun utilisateur aura besoin pour interagir avec la base de donnes savoir lajout dun client ou agent dune socit, lajout dune socit, la recherche des informations concernant un client ou une socit ainsi que la possibilit deffectuer une mise jour de la base de donnes. Cette mthode prsente beaucoup davantages : - Profiter des technologies du dveloppement web pour implmenter cette interface. - Linterface est facile manipuler par lutilisateur. Cette mthode prsente aussi quelques inconvnients :

Tlili Seifeddine -PFE Juin 2007-

Etude de problmatique Le client doit imprativement passer par le serveur Web de la socit et donc devra connatre lemplacement exacte du lien du service. Le temps de traitement est assez long puisque le flux dinformations qui passera travers le rseau sera assez charg donc risque de blocage et le service ne pourra pas tre ainsi lanc.

I.5.2.1.2. Intgrer linterface dans une interface utilisateur graphique


Dans une application, la partie graphique est aussi importante que la partie traitement car cest cette partie qui reste le plus visible pour lutilisateur. Linterface graphique utilisateur prsente les mmes fonctionnalits que celles dun formulaire HTML mais ne ncessite pas de serveur Web, elle fonctionne sur tout systme dexploitation intgrant la machine virtuelle Java (JVM) et le traitement sera effectu sur le poste utilisateur. Cette partie devra prendre en charge la partie CTI c'est--dire lchange de flux dinformation avec le CallManager pour rcuprer ltat de la ligne tlphonique et extraire ainsi le numro de tlphone de linterlocuteur lors dun processus dappel. Cette approche prsente des avantages par rapport un formulaire HTML savoir : Pas besoin de connatre le lien, linterface est sous forme dun programme que lutilisateur final installera sur son ordinateur.

I.5.3. Partie serveur


Cette partie interprte les messages changs avec le CallManager sur ltat de la ligne tlphonique. Ainsi, lors darrives dun appel depuis lextrieur, le serveur doit tre capable dinterprter les messages changs avec le CallManager afin de rcuprer le numro de tlphone de linterlocuteur et ainsi renvoyer les informations de linterlocuteur vers le tlphone IP impliqu lors de la communication tlphonique. Cette partie intgrera aussi des services qui peuvent tre consults par un tlphone IP Cisco et prendra en charge ladaptation de laffichage sur le poste IP. Ce module doit tre en mesure de communiquer avec le CallManager, il faudra donc dvelopper une interface le reliant ce systme.

I.5.4. Choix de la solution


Selon ce qui a dj t avanc, on remarque que chaque solution a ses avantages et ses inconvnients, le but de ce projet est de trouver un compromis entre ces diffrentes solutions

Tlili Seifeddine -PFE Juin 2007-

Etude de problmatique pour que ce service soit accessible et facile utiliser par tout le monde, pour cela, la solution intgrant linterface utilisateur sous forme de formulaire HTML est carter. La solution qui sera retenu pour limplmentation de ce service est celle qui permettra un accs facile pour les utilisateurs. Pour cela on a opt pour la solution interface utilisateur graphique, il sagit de dvelopper une interface graphique pour les utilisateurs finaux du service, cette interface contiendra les mmes champs quun formulaire HTML. Non seulement, cette approche offre la possibilit de jouer sur la prsentation mais elle est trs maniable et extensible. Mais cependant lintgration de se service au poste de tlphone IP utilisera lapproche adopte pour la partie serveur puisque les tlphones IP de Cisco nintgre pas la machine virtuelle Java et peuvent supporter laffichage XML selon les spcifications de Cisco.

I.6.Spcifications des besoins


La spcification des besoins constitue la premire phase formelle et obligatoire du dveloppement informatique, en dautres termes cest un modle d'un logiciel. C'est aussi l'tape en gnie logicielle qui consiste dcrire ce que le logiciel doit faire.

I.6.1. Spcifications des besoins fonctionnels I.6.1.1. Dveloppement de la partie Serveur dapplication CTI
Cette partie constitue le noyau de notre projet vu que celle ci qui va sinterfacer avec le CallManager et observer ainsi ltat de la ligne tlphonique, si ltat de la connexion passe du mode IDLE en mode ALERTING (annexe) le serveur dapplication CTI alerte le client quun appel lui ait destin et affiche ainsi les donnes de linterlocuteur sur le tlphone IP. Ce serveur dapplication contient aussi une gamme de service accessible partie du tlphone IP afin dinteragir avec le serveur de base de donnes.

I.6.1.2. Dveloppement de la partie Client I.6.1.2.1. Dveloppement de linterface Client


Cette partie a pour objectif de simplifier linteraction du client avec le programme en question et de lui permettre didentifier linterlocuteur afin de modifier ou ajouter des informations le concernant, et de noter les transactions effectues avec lentreprise concerne lors de lappel. Tlili Seifeddine -PFE Juin 200710

Etude de problmatique

I.5.1.2.2. Dveloppement de la partie CTI au niveau du client


Cette partie aura comme tache de sinterconnecter au serveur CallManager et observer les vnements sur la ligne tlphonique, dans ce cas si un appel a t initi par le rseau PSTN cette partie renvoie ainsi le numro de tlphone au programme CRM qui effectuera laffichage lcran de lutilisateur (poste PC) des donnes de linterlocuteur. Sans cette partie notre application ne pourra pas sinterconnecter avec le CallManager et rcuprer ainsi le numro de tlphone ou le CallerID.

I.7.Spcifications des besoins non fonctionnels I.7.1. Contrainte temps de rponse


Un des impratifs les plus immdiats de ce projet est la contrainte temps de rponse .En effet le but de cet application est de pouvoir identifier notre interlocuteur avant mme de dcrocher lappareil tlphonique et collecter ainsi toutes les informations qui le concernent. En ce sens, il faut optimiser le temps de traitement de lapplication tant donn limportant volume des informations dont nous disposons concernant linterlocuteur.

I.7.2. Contraintes lies au dveloppement


Ladoption du langage de programmation Java pour cette application simpose. Une telle contrainte se justifie par le fait que les API fournis pour notre programme afin de se sinteragir avec le CallManager sont des APIs java. Une deuxime contrainte simpose au fait que les IP Phone Cisco ne prennent en charges que des formats XML bien spcifiques Cisco.

I.8.Conclusion
Dans ce chapitre nous avons prsent larchitecture rseau et lenvironnement propice pour le dploiement dapplications CTI dans une plateforme Cisco .Nous avons aussi explor le service quon va intgrer dans cette architecture en prsentant diffrentes solutions pour limplmentation, ainsi que la spcification des diffrents besoins fonctionnels et non fonctionnels requis pour limplmentation de la solution. Dans le chapitre suivant nous allons passer la partie conception de notre solution sous forme dapproche UML.

Tlili Seifeddine -PFE Juin 2007-

11

Architecture et conception

Chapitre 2 : II.Architecture et conception

II.1.Introduction
Pour mettre en oeuvre les propositions expliques dans le chapitre prcdent, il faut avant tout spcifier larchitecture matrielle et logiciel ncessaire. Cette tape est trs importante car elle permet par la suite de concevoir la solution dune faon plus prcise et de ne pas tre oblig de refaire la conception au cours de limplmentation effective de la solution. Dans ce chapitre, nous allons prsenter la conception du projet. Notre tude se base sur le
formalisme UML, nous identifierons les diffrents acteurs agissant sur notre solution ainsi que larchitecture de dploiement propos pour ce type de service CTI.

II.2.Architecture matrielle et protocolaire


Si nous revenons un peu au scnario dutilisation du service, nous pouvons dgager les diffrentes parties ncessaires pour raliser la solution propose. En fait, nous aurons besoin dune communication CTI pour tablir la connexion avec le CallManager, dune connexion au Cisco JTAPI pour changer les donnes JTAPI, dun serveur dapplication CTI qui aura pour rle dassurer laffichage des donnes clients sur le tlphone IP impliqu lors du processus dappel et dassurer de servir des services valeurs ajoutes pour la tlphonie IP. Nous aurons aussi besoin dune session avec un serveur de base de donnes pour la rcupration des donnes de linterlocuteur. Ces diffrentes parties sont prsentes dans la figure 5 qui explique larchitecture matrielle obtenue en dployant notre solution dans une architecture TOIP.

Tlili Seifeddine -PFE Juin 2007-

12

Architecture et conception

PSTN
CT IQB E/J AV

TC P/ IP

AJ

TA PI

SC

TP

Figure 5 Architecture matrielle de la solution

Les diffrents lments ncessaires pour cette architecture sont : Un serveur CallManager : Ce serveur est llment le plus important car il englobe plusieurs fonctions tel que la collecte des flux concernant les appels entrants, la communication avec les clients JTAPI et la supervision des IP phones. Un serveur de base de donnes : Dans ce serveur, nous allons stocker les contenus statiques telles que les informations de la partie appelante ainsi que les informations de la socit concerne par la transaction avec lagent. Un serveur dapplication CTI : Cette partie prendra en charge les diffrents services que peut y accder le tlphone IP ainsi que laffichage des informations de la partie appelante lors dun appel, ce serveur est en communication permanente avec Cisco CallManager. Le client JTAPI : Ce client renferme lapplication CRM dveloppe qui, de son cote aussi, est en communication permanente avec le CallManager.

Tlili Seifeddine -PFE Juin 2007-

HT

HT

TP

CP

C SC

13

Architecture et conception Notre mission consiste dvelopper le client JTAPI ainsi que le serveur dapplication CTI et de les intgrer avec les autres quipements prsents dans la figure 5 pour assurer le fonctionnement du service.

II.3.Choix de larchitecture II.3.1. Diagramme de dploiement


Le dploiement dune solution de couplage de tlphonie informatique prsente quelques difficults puisque de son ct, chaque constructeur prcise ces propres spcifications pour limplmentation de JTAPI. La figure 6 prsente le diagramme de dploiement est quivalente la figure prsente ci-dessus concernant larchitecture matrielle de la solution mais plus en dtails
Serveur dapplication CTI
JTAPI/ CTIQBE
Serveur J2EE Tomcat Module JTAPI

JSP Module Affichage vers le Ip Phone Ip Phone Cisco

LAN

Cisco CallManager

LAN
Module Ip Phone Service Module DataBase

LAN LAN
Serveur Base de donne relative aux clients

Serveur de donne
Module DataBase

JTAPI/ CTIQBE

Module JTAPI

Module JVM

Client CRM

Figure 6 Diagramme de dploiement du Service

Tlili Seifeddine -PFE Juin 2007-

14

Architecture et conception

II.3.2. Justification conceptuelle II.3.2.1. Choix de larchitecture client serveur


Pour les services de tlphonie IP, une telle architecture simpose du fait de la faible capacit de traitement des tlphones IP puisque les capacits de calcul des tlphones IP ne sont pas encore suffisantes pour pouvoir embarquer la totalit du service. De plus, les tlphones IP Cisco ne sont pas conus pour intgrer les fonctionnalits du JTAPI, qui pour bien fonctionner, doivent tre lancs dans une machine intgrant JVM. Ainsi le choix dune telle architecture porte tous les traitements relatifs au contrle dappel et lchange de messages CTIQBE au serveur dapplication CTI.

II.3.2.2. Choix du client CRM


Le choix dintgrer le composant CTI pour un client CRM dans un ordinateur personnel utilisant une machine virtuelle JVM sexplique du fait que lun des obstacles des solutions CTI est de pouvoir collecter les flux dinformations concernant linterlocuteur sans pour autant que le client final envoie une requte au serveur excutant la partie CTI. Cette approche a t traite par Cisco pour ces tlphones IP en utilisant une fonction bien particulire propre Cisco qui permet de forcer laffichage sur un tlphone IP Cisco. La plupart des projets CTI de ce genre utilisent la mme architecture que celle adopte pour le client CRM.

II.4.Diagrammes de cas dutilisation de la solution


Le modle du diagramme dutilisation permet de donner une vue densemble sur le fonctionnement globale de la solution ainsi que les interactions qui peuvent y avoir lieu entre les diffrents composants du systme.

II.4.1. Dfinition des diffrents acteurs agissant sur le systme


Le systme interagit avec 5 acteurs savoir : Client CRM : Le client est ici le programme qui va tre responsable dinterprter les commandes envoyes par le serveur de Base de donnes ainsi que le flux dinformations retourns par le CallManager pour lidentification et la rcupration du numro de tlphone de linterlocuteur. Ce client se prsente sous formes dinterface graphique interactive Tlili Seifeddine -PFE Juin 200715

Architecture et conception affichant les donnes concernant linterlocuteur ainsi que lentreprise concerne par la transaction lors de lappel tlphonique. Cette partie offre aussi la possibilit lutilisateur de sinteragir avec le serveur de base de donnes. CallManager : Cisco CallManager est un composant serveur de traitement et de contrle des appels de la solution de tlphonie IP de Cisco. Il a pour rle dinterprter le flux dinformations changes avec lapplication et de superviser de ltat de la connexion de ladresse rattache au poste tlphonique, le flux chang avec notre application est un flux JTAPI interprt par le CallManager sous forme de messages CTIQBE. Tlphone IP Cisco : Cest ce terminal qui affichera les informations de linterlocuteur lors dun appel, cet affichage est sous formes de balise XML interprtable par la gamme Cisco 7900, laccs au service de tlphonie IP sera initi partir de ce composant. Le serveur dapplication CTI : Il est responsable de la partie CTI conus pour rcuprer le numro de linterlocuteur, faire une recherche dans la base de donnes selon le numro de linterlocuteur et afficher le rsultat sur lcran du tlphone IP. Une autre fonctionnalit a t intgre ce serveur : Celle des services de tlphonie IP. Parmi les services intgrer on cite : Recherche dans la base de donnes partir du tlphone, consultation de lannuaire qui tablie une connexion notre base de donnes et consultation de lactualit en ligne de Cisco et de CNN La base de donnes : Elle contient des donnes relatives aux clients Parmi ces donnes on cite le numro de tlphone partir duquel le systme extrait les informations de linterlocuteur.

Tlili Seifeddine -PFE Juin 2007-

16

Architecture et conception

II.4.2. Les packages du diagramme de cas dutilisation


Dans cette partie nous allons dfinir les diffrents packages quon a dvelopp ainsi que linteraction entre eux travers le diagramme de packages. Pour notre projet les packages sont aux nombres de 5 comme lillustre la figure 7

Figure 7 Les packages utiliss

IP Phone Cisco Serveur d'application CTI

Include
PushToPhone IpPhoneServices

Include

Telephony

CallManager

Include Include

DataBase GUICrm

Include
Serveur Base de donne

Client Crm

Figure 8 Diagramme des packages

Tlili Seifeddine -PFE Juin 2007-

17

Architecture et conception

II.4.3. Diagrammes de cas dutilisation


Dans le diagramme des cas dutilisation, interviennent trois lments : les acteurs, le systme et les cas dutilisation. Lacteur reprsente une personne ou un autre systme qui interagit avec le systme en cours de modlisation. Pour indiquer la participation dun acteur un cas dutilisation, nous utilisons une flche (UML). Les cas dutilisation peuvent tre en relation (uses ou extension) [3].

II.4.3.1. Package IpPhoneService


Ce package permet dtendre les fonctionnalits du tlphone IP. En effet, il a pour rle doffrir une panoplie de services mis la disposition de lutilisateur du tlphone et de profiter des capacits et des services que peuvent intgrer les tlphones de la gamme Cisco 7900. Parmi les services offerts par ce package on cite : La possibilit deffectuer une recherche en se connectant au serveur de la base de donnes, consulter le rpertoire de la socit et dy extraire les numros de tlphone de ces clients. La possibilit de se connecter au site de Cisco et dafficher lactualit dans le monde des rseaux ainsi que les nouveaux produits lancs sur le march ou encore de consulter lactualit partir du site de CNN. Le fonctionnement du service de News utilise une connexion au serveur de Cisco et de CNN pour y extraire linformation demande sous format RSS (voir Annexe) et dadapter ce format au tlphone IP Cisco pour pouvoir lafficher sur lcran. La premire tape de fonctionnement de ce service est de consulter le serveur CallManager pour y extraire ladresse du serveur dapplications CTI et dextraire ainsi les services mis la disposition de lutilisateur, ce service est accessible par les IP Phones Cisco une fois que ladresse du serveur dapplication est configur comme lien des services de tlphonie (voir Annexe) au niveau CallManager. La figure 9 prsente le diagramme de cas dutilisation de ce package ainsi que les diffrents acteurs qui agissent directement sur le systme.

Tlili Seifeddine -PFE Juin 2007-

18

Architecture et conception

Figure 9 Diagramme du package IpPhoneService

II.4.3.2. Package PushtoPhone


Cette partie est une sorte de passerelle entre la partie CTI et le tlphone IP. En effet, elle a pour objectif dinformer le poste IP quun appel lui est destin et dafficher sur son cran les informations de son interlocuteur. Dans sa spcification pour JTAPI, Cisco a implment une fonction prdfinie qui permet de forcer un tlphone IP Cisco afficher des donnes sous format XLM interprtable par le poste IP. Une fois quon a rcupr le numro de linterlocuteur, notre application extrait les informations concernant le client depuis le serveur de la base de donnes et envoie le rsultat retourn par ce serveur au poste IP concern. Tlili Seifeddine -PFE Juin 200719

Architecture et conception Cette partie force le terminal IP afficher des donnes sur son cran sans pour autant avoir besoin de lintervention de lutilisateur.

IpPhone Cisco

Rcupration du numros de l'interlocuteur CallManager

Affichage des donnes

uses

Rcupration du numeros de poste appel

uses

Rcuperer les informations

uses

Rcuperations des informations de la partie appelante extends extends

Serveur d'applications CTI

Rcuperer les informations du client uses

Rcuperer les informations de la socit uses

Interrogation de la Base de donne

Serveur Base de donnes

Figure 10 Package PushToPhone

II.4.3.3. Package Database


Ce package traduit les ventuelles requtes susceptibles dtre lances par lutilisateur final afin dinteragir avec la base de donnes utilisateur. Parmi ces requtes on retrouve: La possibilit dajouter une nouvelle entre la base de donnes. Lancer une recherche par nom et prnom pour les clients ou simplement par nom de socit dans la base de donnes et afficher le rsultat sur lcran que ce soit celui dun PC ou dun poste IP.

Tlili Seifeddine -PFE Juin 2007-

20

Architecture et conception Effectuer une mise jour des informations relatives un client ou dune socit.

Figure 11 Package PushToPhone

II.4.3.4. Package GUICrm


Ce package se rsume en une interface graphique interactive mise la disposition de lutilisateur final afin de faciliter linteraction avec le serveur de la base de donnes et cest cette interface qui nous servira afficher les donnes relatives linterlocuteur lors darrive dun appel.

Figure 12 Package GuiCrm

Tlili Seifeddine -PFE Juin 2007-

21

Architecture et conception

II.4.3.5. Package Telephony


Le package Telephony est le cur mme de notre projet, en effet ce composant permet dassurer la connexion au serveur CallManager et de placer ainsi un observateur sur ltat de la ligne tlphonique ainsi que sur ltat de connexion des postes IP. Dans un premier temps, notre package sauthentifie auprs du CallManager afin de lancer un observateur sur les appels entrants. Ainsi lors dun appel entrant, ce package sera alert par le CallManager que ltat de la connexion du poste concern par la transaction tlphonique passe du mode Idle en mode Active. Une fois alerte, ce composant rcupre le numro de la partie appelante ainsi que le poste de la partie appele et le renvoi au package PushToPhone ainsi que le package GUICrm

Figure 13 Package Telephony

II.5.Diagrammes de classes
Les diagrammes de classes modlisent les interactions et les hirarchies entre les classes les plus importantes conues pour la ralisation de ce service. Pour modliser les diffrentes classes du systme final. Nous avons regroup les principales classes en des paquetages selon leurs rles. Dans ce qui suit nous reprsentons le Diagramme de classes constituants chaque paquetage. Nous nous sommes appuys sur le formalisme UML pour les reprsenter.

Tlili Seifeddine -PFE Juin 2007-

22

Architecture et conception

II.5.1. Diagramme de classe du Client Crm


Le diagramme suivant prsente les interactions entre les diffrentes classes utilises lors du dveloppement de la partie Client Crm.

CallerInfoServer -CTIServer -DestNumber -IdJTAPI -PassJTAPI +ProviderChangeEvent() +CallChangeEvent() +GetActiveCallPartyNumbers() +GetCallerInfoServer() NumberFind -NumberOrigin +FindfirmInformationByNumber() +FindCustumerInformationbyNumber() +LoadJDBCDriver() +Connection() +AddfirmInformation() +AddCustumerInformation() +LoadJDBCDriver() +Connection() AddToDb

Main -Numbers -GetCallerInfoServer -Cmd +CallerInfoServer() +GetCallerInforServer() +Runtime.getRuntime().exec()()

GuiCrm -OrigNumber -JPannel1 -JPannel2 -JPannel3 -JPannel4 +NumberFind() +AddToDb() +Affiche() +updateDb()

Affiche updateDb +UpdatefirmInformation() +UpdateCustumerInformation() +LoadJDBCDriver() +Connection() +DisplayfirmInformation() +DiplayCustumerInformation() +LoadJDBCDriver() +Connection()

Figure 14 Diagramme de classe du Client Crm

Tlili Seifeddine -PFE Juin 2007-

23

Architecture et conception

II.5.1.1. La Classe CallerInfoServer


La connexion au serveur CallManager est imprative afin de rcuprer le numro de la partie appelante, ainsi que pour linterroger sur ltat de la connexion. Afin de subvenir ce besoin, la mthode Provider permet dinitier ladresse du CallManager en passant comme paramtre le login de connexion ainsi que le mot de passe mais avant cela notre application doit lancer le moteur JTAPI partir de la fonction peer . Une fois ces deux tapes franchies, la mthode GetCallerInfoServer nous sert dobservateur sur ltat de la ligne et si un appel entrant est dtect elle nous informe du changement dtat de la connexion en rcuprant le numro des deux parties impliques lors du processus dappel. Ces paramtres sont ensuite enregistr dans les variables OrigNumber pour le numro dorigine et DestNumber pour le numro de destination.

II.5.1.2. La classe GuiCrm


Cette classe hrite des classes NumberFind, AddToDb, Affiche et updateDb. Elle est sous forme dinterface graphique. Elle renferme les fonctions que peut utiliser la personne final afin dinteragir avec le serveur de la base de donnes et elle permet laffichage des donnes de linterlocuteur lors de larrive dun appel. Cette classe renferme les interfaces JPannel1, JPannel2, Jpannel3, JPannel4 et JPannel5 qui sont sous formes dinterface graphiques, chacune delles offre la possibilit dinteragir avec le serveur de la base de donnes selon les besoins de lutilisateur qui parmi celle-ci on retrouve : Ajouter, modifier ou rechercher des informations concernant un client ou une socit, ces fonctions sont intgres dans les interfaces Jpannel1, JPannel2, JPannel3 et JPannel4. Quant linterface JPannel5, elle prend en charge laffichage des donnes de la partie appelante en rcuprant le numros de tlphone et en excutant la mthode Numberfind ().

II.5.1.3. La classe updateDb


Cette classe prend comme arguments dentre les donnes mettre jour dans la base de donnes et elle modifie les informations concernant le client ou la socit.

Tlili Seifeddine -PFE Juin 2007-

24

Architecture et conception

II.5.1.4. La classe NumberFind


Cette classe prend en entre un numro de tlphone et parcourt lensemble de la base de donnes afin de trouver une similitude avec les numros de tlphones dj enregistrs, que ce soit ceux dun client ou dune socit.

II.5.1.5. La classe Affiche


Cette classe prend comme paramtre dentre le nom et prnom dun client ou le nom dune socit et retourne les informations correspondantes depuis la base de donnes.

II.5.1.6. La classe AddToDb


Cette classe permet lutilisateur dajouter de nouvelles entres dans la base de donnes que ce soit des informations relatives une socit ou un client.

II.5.1.7. La classe main


Cette classe assure la fonction de lancer lensemble des classes cites ci-dessus, elle hrite des classes CallerInfoServer et GUICrm. Dans un premier temps elle fait appel la classe CallerInfoServer, en utilisant comme paramtre CTIServer qui est ladresse du serveur CallManager, IdJtapi qui reprsente le login et PassJtapi qui est le mot de passe ainsi que DestNumbr qui reprsente le poste observer par lapplication. Une fois ces paramtres chargs et la connexion au serveur CallManager est tabli, si un appel arrive et a comme destination le poste observ, le numro de tlphone est pass comme paramtre linterface GUICrm qui sencharge de lancer la classe NumberFind et ainsi de rcuprer les informations de lappelant.

Tlili Seifeddine -PFE Juin 2007-

25

Architecture et conception

II.5.2. Diagramme de classe du serveur dapplication CTI


CallerInfoServer -CTIServer -DestNumber -IdJTAPI -PassJTAPI +ProviderChangeEvent() +CallChangeEvent() +GetActiveCallPartyNumbers() +GetCallerInfoServer()

PushXml -firmName -FirmAddress -FirmActivities -Firmphone -Fcomments -Cname -Cfname -Cphone -Ccomments -CustumerContact -CustumerComment -NumbersOrigin -NumbersDest -XML +termTo.sendData()() +CalleInfoServer() +getCallerInfoServer()

findnum -NumberOrigine -XML +LoadJDBCDriver() +Connection()

FindFirm -FirmName +LoadJDBC() +Connection()

FindCustumer -Custumername -CustumerLastname +LoadJDBCDriver() +Connection()

Search

DirectoryFirm Index +LoadJDBC() +Connection() MenuDirectory

DirectoryCustumer +LoadJDBCDriver() +Connection()

Figure 15 Diagramme de classe du serveur d'application CTI

Tlili Seifeddine -PFE Juin 2007-

26

Architecture et conception Le serveur dapplication CTI fournit le mme service que celui du ClientCrm lexception prs que laffichage des informations de linterlocuteur seront affiches lcran du tlphone IP de lutilisateur du service. Il offre galement dautres services qui seront accessibles partir dun poste tlphonique IP Cisco.

II.5.2.1. La classe PushXML


Cette classe est quivalente la classe main du Client Crm, elle hrite de la classe CallerInfoSever et findnum. Elle rcupre le numro de tlphone partir de la classe CallerInfoServer, et fait appel la classe Findnum en lui passant comme argument NumberOrigin ensuite elle rcupre la variable XML qui va tre affich lcran du tlphone IP en utilisant la fonction dj prdfinie par Cisco SendData .

II.5.2.2. La classe Findnum


Cette classe soccupe de parcourir la base de donnes et dy extraire les informations dun client (agent de la socit) ou celle dune socit selon le numro de tlphone pass en argument. Une fois ces informations rcupres, elle les stocke dans la variable XML en utilisant les balises XML selon la spcification de Cisco.

II.5.2.3. La classe Index


Cette classe dfinit une liste de quatre choix : Directory, Find Custumer, CNNs News et Ciscos News. Elle hrite des classes Search et MenuDirectory. Le choix des lments CNNs News et Ciscos News cre une nouvelle instance de la classe en index. En ce sens, le choix du service News permet de ce connecter un serveur extrieur et dafficher les informations demandes lcran tout en utilisant cette classe c'est--dire index. Alors que le choix de Directory et Find Custumer nous renvoie aux classes MenuDirectory et Search.

Tlili Seifeddine -PFE Juin 2007-

27

Architecture et conception

II.5.2.4. La Classe MenuDirectory


Cette classe hrite des classes DirectoryFirm et DirectoryCustumer. Elle permet, selon le choix de lutilisateur dafficher le rpertoire par Socit ou par Client en faisant appel aux classes DirectoryFirm et DirectoryCustumer. Ces classes se chargent dextraire les informations de la base de donnes et de les afficher lcran du tlphone. Une fois laffichage effectu, ces deux classes offrent la possibilit lutilisateur de composer le numro souhait extrait de la base de donnes depuis la touche Dial affiche lcran.

II.5.2.5. La Classe Search


Cette classe hrite des classes FindCustumer et FindFirm. Elle est quivalente la classe MenuDirectory lexception quelle fait appel aux classes FindCustumer et FindFirm en utilisant comme argument dentre CustumerName et CustumerLastname pour le cas de FindCustumer et Firmname pour le cas de FindFirm. Les classes FindCustumer et FindFirm se chargent aprs de parcourir la base de donnes et dafficher le rsultat lcran du tlphone IP.

II.6.Digrammes de squences
Les diagrammes de squence permettent de dcrire les interactions entre les objets pour chaque cas d'utilisation. Dans notre cas, ces diagrammes sont lis aux diagrammes de cas dutilisation reprsents auparavant. Pour illustrer la diffrence entre nos deux clients : le client CRM et le cas du serveur dapplication CTI qui prend en charge laffichage du service sur les postes IP de lutilisateur. Nous allons assigner chaque type de client le diagramme de squence correspondant.

Tlili Seifeddine -PFE Juin 2007-

28

Architecture et conception

II.6.1. Diagramme de squences du serveur dapplication CTI


Ce scnario reprsente les fonctionnalits de base du serveur dapplication CTI savoir laffichage des donnes de linterlocuteur sur le IP Phone Cisco ainsi que laffichage du service de tlphonie IP intgrer dans notre solution.

Figure 16 Diagramme de squences du serveur d'application CTI

Tlili Seifeddine -PFE Juin 2007-

29

Architecture et conception

II.6.2. Digramme de squences du client CRM


Ce scnario fait intervenir une autre entit ; le client CRM. En effet dans ce composant laffichage est effectu sur un PC intgrant la machine virtuelle Java. Le diagramme de squences suivant reprsente la succession chronologique des diffrentes tapes intervenant dans la ralisation de la solution propose pour le Client CRM.

Figure 17 Diagramme de squences du Client Crm

II.7.Conclusion
Dans ce chapitre, nous avons prsent les diffrents diagrammes de cas dutilisation et de classes de notre application pour enfin aboutir ltablissement des diagrammes de squences. Dans le chapitre suivant nous allons expliquer les choix utiliss pour limplmentation de la solution adopte et dcrire la dmarche de la ralisation.

Tlili Seifeddine -PFE Juin 2007-

30

Solution et implmentation

Chapitre 3 : III.Solution et implmentation

III.1.Introduction
Aprs avoir dtermin les besoins de lapplication et conu les diffrentes parties de ce service, nous sommes passs la ralisation de la solution conue. Mais avant tout, nous prsentons les outils utiliss pour le dveloppement du service de tlphonie IP ainsi que de monte de fiche client.

III.2.Environnement et langage de programmation


Le choix du langage de programmation est un point crucial pour tout projet de dveloppement puisque il faut que ce dernier puisse subvenir nos besoins. Parmi les APIs de tlphonie disponible, on cite le JTAPI qui est une implmentation de Sun utilisant le langage Java et Tapi, tant dveloppe lorigine par Intel et Microsoft comme interface de dveloppement dapplication CTI pour les systmes dexploitation Windows. Ces deux APIs sont les plus couramment utilises et constituent la cl pour toute application CTI dveloppe dans une plateforme Cisco intgrant le CallManager, qui offre la possibilit de communiquer avec ces applications travers la couche TAPI. Cependant le choix reste restreint lutilisation de TAPI et JTAPI. Si on examine de prs ces deux technologies, on distingue des avantages quoffre JTAPI par rapport TAPI, parmi lesquelles la richesse de la bibliothque implmente par Cisco pour le JTAPI ainsi que la simplicit de limplmentation de cette API. Nous avons opt pour Java, en raison de la simplicit de lAPI JTAPI voques prcdemment mais aussi, parce que ce langage est le plus utilis dans le domaine du dveloppement des services. Surcrot, la plupart des API disponibles sur Internet sont des API Java. Java est un langage de programmation de quatrime gnration dvelopp par Sun. Il doit sa popularit croissante une caractristique majeure : sa portabilit. En effet, contrairement aux langages classiques dont le code doit tre compil en fonction de la plateforme pour laquelle

Tlili Seifeddine -PFE Juin 2007-

31

Solution et implmentation ils sont prvus, le code Java est compil vers un tat intermdiaire. Le programme rsultant doit tre excut via une machine virtuelle JVM (Java Virtual Machine). La machine virtuelle quant elle est lie la plateforme utilise, nanmoins lheure actuelle, de trs nombreux systmes sont supports tels que les PC tournant sous Windows, les Macintosh, etc. Il existe mme des JVM allges pour les PDA (Personnal Digital Assistant) ou certains tlphones portables. Grce cette technique, un programme ne doit tre compil quune seule fois, et peut ensuite tre utilis sur nimporte quelle version de la JVM. Traditionnellement, les langages interprts tels que Java sont moins rapides que leurs concurrents compils, mais le dveloppement de plus en plus pouss de la JVM, est en train de rapprocher les performances de Java de celles des langages tels que le C++.[4]

III.3.Choix de larchitecture logicielle III.3.1. Le package JTAPI


Le Jtapi renferme un ensemble de packages java. Chaque package fournit un service de tlphonie bien particulier pour les applications de couplage tlphonie informatique. Parmi ces packages on retrouve javax.telephony.callcontroll qui renferme laspect contrle et traitement dappel savoir initier un appel, rpondre un appel. Cette partie est essentielle pour notre application puisque elle sert sinterconnecter avec le CallManager pour changer les informations relatives un terminal tout en sintgrant avec la spcification de Cisco. Afin de rpondre aux besoins essentiels de notre application, il est ncessaire dintroduire le modle de Jtapi pour modliser le processus de communication entre la parie responsable du couplage tlphonie informatique avec le CallManager.

III.3.1.1. Modle dappel de la tlphonie Java


Le modle dappel englobe un ensemble dobjets java. Chaque modle dappel reprsente la fois une entit physique (appareil tlphonique) ou logique (une connexion) dans le monde de la tlphonie. Lobjectif du modle dappel est de dcrire les appels tlphonique et les points terminaux impliqus lors dun appel tlphonique [5]. Le diagramme ci-dessous illustre le modle dappel de Jtapi et les diffrentes entits qui le composent.

Tlili Seifeddine -PFE Juin 2007-

32

Solution et implmentation

Figure 18 Modle dappel Jtapi [5]

La partie qui va suivre dtaillera les principaux acteurs lors du processus dappel tlphonique entre deux terminaux utilisant lAPI Jtapi.

III.3.1.1.1. Provider
Un provider reprsente lentit logicielle dun central tlphonique avec ces interfaces et un systme de tlphonie sous-jacent dans notre cas le provider est le CallManager. Un provider peut se trouver dans l'un de ces trois tats : Provider.IN_SERVICE,

Provider.OUT_OF_SERVICE ou Provider.SHUTDOWN. L'tat du provider dtermine la validit de ces diverses actions possibles. Dtaillons quelque peu ces diffrents tats [5] : IN_SERVICE : Cet tat indique que le provider est actuellement en service et disponible pour les utilisateurs. OUT_OF_SERVICE : Cet tat indique qu'un provider n'est temporairement pas disponible pour une utilisation. Beaucoup de mthodes du provider sont incorrectes lorsquil se trouve dans cet tat. Les providers peuvent revenir en service tout moment, cependant, l'application ne peut prendre aucune mesure directe pour causer ce changement.

Tlili Seifeddine -PFE Juin 2007-

33

Solution et implmentation SUTDOWN : Cet tat indique qu'un provider n'est plus disponible une utilisation. La plupart des mthodes du provider sont incorrectes lorsquil se trouve dans cet tat Le diagramme suivant montre les transitions d'tat permises pour le provider dfini par le core package :

Figure 19 Transition dtat du Provider

III.3.1.1.2. Call
Un objet call reprsente un appel tlphonique.

III.3.1.1.2.1. Etats dun call


Un call peut se trouver dans trois tats : Call.IDLE, Call.ACTIVE ou Call.INVALID. Parmi les divers tats du cycle de vie dun call on cite [5] : IDLE : C'est l'tat initial de tout call. Dans cet tat, le call ne comporte aucune connexion. ACTIVE : Un call avec une certaine activit continue se trouve dans cet tat. Les call avec une ou plusieurs connexions associes se trouvent dans cet tat. INVALID : C'est l'tat final pour tout call. Dans cet tat, un call na plus aucune connexion. Mettons laccent sur le fait, quun call se trouvant dans cet tat, ne peut sans aucune faon tre utilis pour une action future.

Tlili Seifeddine -PFE Juin 2007-

34

Solution et implmentation

Figure 20 Diagramme de transition dun call

III.3.1.1.3. Connection
Une connexion reprsente un lien (une association) entre un call et une adresse. Le but d'une connexion est de dcrire le rapport entre un call et une adresse. Une connexion existe si une adresse particulire reprsente une partie dun appel tlphonique. Chaque connexion a un tat qui dcrit ltat actuel du rapport entre le call et l'adresse.

III.3.1.1.4. Objets address et terminal


Un objet d'adresse reprsente le point final logique d'un appel tlphonique. Et un terminal reprsente un point final physique (matriel) reli au rseau tlphonique. Les adresses et les terminaux sont dans un rapport multiple. Une adresse peut contenir des terminaux multiples, et les terminaux peuvent contenir galement des adresses multiples. Toutefois, le provider peut durant toute sa dure de vie connatre de nouveaux terminaux et de nouvelles adresses. Ces nouveaux objets reprsentent des adresses et des terminaux en dehors du domaine du provider et sont dsigns comme distants afin de les diffrencier des locaux. Par exemple, si le domaine du provider est un PBX, le provider connatra dabord toutes les adresses et tous les terminaux dans ce PBX. Toutes les adresses et tous les terminaux qu'il connat ultrieurement se trouvent en dehors de ce PBX [5]. Dans beaucoup de cas, un poste tlphonique (reprsent par un objet terminal) a seulement un numro de tlphone (reprsent par un objet d'adresse) associ ce dernier. Dans le cas de notre application, lobjectif est de placer un Listener sur une adresse bien particulire afin dtre avertis des diffrents vnements qui sont en liaison avec cette adresse savoir larrive dun appel qui sera gr par le provider CallManager.

Tlili Seifeddine -PFE Juin 2007-

35

Solution et implmentation La premire chose faire est de se connecter l'interface JTAPI du Call Manager une fois la connexion tablie nombre d'vnements JTAPI pourront tre traits par notre application suivant qu'on dveloppera le code ncessaire la figure 21 illustre la premire tape de lancement du moteur Jtapi et de lobtention dun provider.

Figure 21 Initialisation du moteur JTAPI et connexion au CallManager

III.3.2. LAPI Swing :


Swing constitue une innovation apparue dans JDK1.1 en tant qu'extension de ce dernier et en tant que partie intgrante de Java 2 SDK. Swing est la seconde bibliothque de classes (la premire tant AWT) permettant de crer et de grer des interfaces graphiques. Les mthodes utilises pour construire une interface Swing sont sensiblement les mmes que celles de AWT soit [6] : Cration d'un cadre ou contenant Placer des composants dans ce contenant Effectuer la mise en page de ces composants dans le contenant grer les vnements et actions poses par l'utilisateur

III.3.3. LAPI JDBC


L'API JDBC permet aux applications java daccder par le biais d'une interface commune des sources de donns pour lesquelles il existe des pilotes JDBC. Normalement, il s'agit d'une

Tlili Seifeddine -PFE Juin 2007-

36

Solution et implmentation base de donns relationnelle, et des pilotes JDBC sont disponibles pour tous les systmes connus de bases de donnes. [4]. Nous avons utilis cette API pour permettre aux classes Java de communiquer avec les bases de donns.

III.3.4. Les serveurs


Les JSP et les servlets ncessitent un serveur pour fonctionner nomm souvent moteur de servlets ou moteur de JSP. Le serveur le plus connu est le serveur Tomcat [10]. Cest un serveur Open Source qui agit comme un conteneur de servlets. Il fait partie du projet Jakarta, au sein de la fondation Apache. Tomcat implmente les spcifications des servlets et des JSP de Sun Microsystems. [7]

III.3.5. Le systme de gestion des bases de donns :


Le systme de gestion des bases de donns utilis dans ce projet est MySQL, il sagit dun SGBD libre et gratuit. Il est trs utilis et trs populaire. MySQL est un serveur de bases de donnes relationnelles SQL, trs rapide, multi-thread et multi-utilisateur.

III.3.6. Les JSP


Linterface utilisateur est compose de plusieurs pages web qui vont tre gnres dynamiquement selon les requtes de lutilisateur. Pour concevoir une telle interface, nous avons eu recours aux pages JSP ou Java Server Pages . Cest une technologie base sur Java qui permet aux dveloppeurs de gnrer dynamiquement du code HTML, XML ou tout autre type de page Web [4]. Comme nous utilisons une plateforme java pour dvelopper ce service, ce choix se rvlera trs bnfique puisque nous pouvons utiliser les diffrentes mthodes des classes dj dveloppes et compiles sans avoir, chaque fois, rcrire ces mthodes. Lavantage des JSP par rapport dautres scripts, qui sexcutent du ct serveur, est que le temps du traitement est moins important, cela est d au fait que ces scripts sont compils une seule fois, et on naura pas besoin de les recompiler chaque accs au service. Le principe de fonctionnement des JSP ressemble celui des servlets, mais il prsente quelques diffrences, comme la possibilit de les intgrer dans des pages HTML et de dfinir des liens entre eux. Un exemple dutilisation de cette technologie dans ce projet est la transmission du numro de tlphone de linterlocuteur dune page une autre.

Tlili Seifeddine -PFE Juin 2007-

37

Solution et implmentation

III.3.7. XML
Cisco met la disposition des dveloppeurs de service de tlphonie IP, une API bas sur le XML et qui permet dafficher des donnes sur les IP Phones Cisco de la gamme 7900. Ces services sont gnralement utiliss laide du protocole HTTP. Les tlphones se comportent donc comme une sorte de navigateur web, lexemple suivant illustre laffichage du menu en utilisant la spcification Cisco pour le XML.

Figure 22 Exemple d'utilisation de l'API XML de Cisco

III.4.Les interfaces
Comme cela a dj t voqu, le service dvelopp prsente deux approches dutilisation : Une approche pour les utilisateurs de Pc et une approche pour les IP Phones Cisco. Nous allons essayer dans cette partie de prsenter les principales interfaces auxquelles un utilisateur est confront selon les approches cites ci-dessus.

Tlili Seifeddine -PFE Juin 2007-

38

Solution et implmentation

III.4.1. Les interfaces utilises pour les IP Phones


Dans cette partie, nous allons exposer l'ensemble des interfaces qui sont mises la disposition des utilisateurs, lesquelles sont accessibles partir des postes IP en utilisant la touche Services

Figure 23 Interfaces du service de tlphonie IP

Tlili Seifeddine -PFE Juin 2007-

39

Solution et implmentation La premire interface mise la disposition de lutilisateur renferme diffrents menus qui permettent linteraction avec le serveur de base de donnes et la consultation des bulletins dinformations tlchargs partir du site Cisco et CNN. La figure 22 illustre le menu voqu ci-dessus :

Figure 24 Page daccueil

III.4.2. Les interfaces graphiques


Les interfaces Swing mises la disposition de lutilisateur constituent la fois un moyen daccs la base de donnes afin deffectuer lenregistrement des clients et aussi une interface qui servira laffichage des donnes de linterlocuteur lors de la rception dun appel. La figure 25 illustre le modle adopt pour ces interfaces swings

Tlili Seifeddine -PFE Juin 2007-

40

Solution et implmentation

Figure 25 Interfaces Swing

Les diffrents menus ; Add custumer et Add Firm permettent lutilisateur dajouter de nouvelles entres au serveur de base de donnes tandis que les champs Find Firm et Find Custumer offrent la possibilit de rechercher un client soit par nom de socit ou par nom et prnom de lagent ainsi que la possibilit deffectuer une mise jour concernant les informations des clients. Les figures 26 29 illustrent un cas dexemple dutilisation de ces interfaces.

Tlili Seifeddine -PFE Juin 2007-

41

Solution et implmentation

Figure 26 Ajout dun agent dune socit

Figure 27 Rechercher un utilisateur

Tlili Seifeddine -PFE Juin 2007-

42

Solution et implmentation

Figure 28 Ajout dinformations dune socit dans notre base de donnes

Figure 29 Recherche dinformations dune socit

Tlili Seifeddine -PFE Juin 2007-

43

Solution et implmentation

III.4.3. Lancement du Service


Cas du client CRM La figure 30 montre un aperu de lexcution du service en optant pour linterface Swing. Un client de la socit dont le numro est 1161 initie un appel au poste 1999 sur lequel un observateur a t plac afin de rcuprer le numro de linterlocuteur.

Figure 30 Affichage des coordonnes de linterlocuteur

Cas du IP Phone Cette partie renferme laspect CTI. En effet, pour pouvoir extraire le numro de tlphone de linterlocuteur et pousser laffichage des donnes ainsi rcupres partir de la base de donnes, notre application fait appel au serveur dapplication CTI qui est responsable deffectuer cette tache. La figure 31 illustre le cas de rception dun appel avec un numro de tlphone enregistr dans notre base de donnes tandis que la figure 32 voque le cas o le numro est inconnu dans notre base.

Tlili Seifeddine -PFE Juin 2007-

44

Solution et implmentation

Figure 31 Affichage des donnes l'cran du poste IP

Figure 32 Numro non reconnu dans la base de donnes

Tlili Seifeddine -PFE Juin 2007-

45

Solution et implmentation

III.5.Conclusion
A loccasion de ce chapitre nous avons trait la mthodologie adopte afin de raliser notre application. Une mthodologie qui a mis en oeuvre toute une panoplie assez complexe doutils. Lobjectif de ce projet est de simplifier le dploiement de solutions CTI dans un rseau de tlphonie IP. Le serveur dapplication CTI ainsi que le client CRM constituent le cur de notre application.

Tlili Seifeddine -PFE Juin 2007-

46

Conclusion Gnrale

Conclusion et perspective :
La gestion des donnes client permet de fournir une gestion simple et efficace des informations personnelles de la partie appelante. Ce processus de gestion dappel utilise les identifiants de la partie appelante ou appel pour rcuprer partir dune base de donnes les informations relatives au client et lassocier lappel pendant sa dure de vie. Cela permet l'appel d'tre trait de manire plus efficace et cest exactement dans ce but ou intervient notre application.

Au cours de projet, nous nous sommes intrss llaboration des diffrents points qui englobent le dploiement et lintgration de solutions de couplage tlphonie informatique dans un environnement logicielle Cisco, ainsi que le dveloppement de services de tlphonie IP. En premier lieu, nous avons pos la problmatique du projet savoir les objectifs atteindre ou encore les diffrentes approches qui peuvent tre utiliser pour notre application. Ensuite, nous avons conu et dvelopp un modle capable de rpondre nos besoins. Enfin, nous sommes passs ltape test et implmentation, en effet ce stade l nous pouvons affirmer que notre application a rpondu dune manire impressionnante aux attentes et aux objectifs fixs pralablement.

En effet, lapplication a t teste avec succs sur une plateforme de Tlphonie IP Cisco intgrant le CallManager. Loin de se contenter du dveloppement dune application rserve unique aux utilisateurs de PC, nous avons tendu notre tude en intgrant la partie CTI au IP Phone Cisco ainsi que le dveloppement de services de tlphonie IP.

Les fonctions que peut offrir le CTI sont particulirement extensibles et comme
perspectives ce projet, on pourra intgrer le concept de routage de fiche client dun utilisateur un autres ou encore intgrer dans cette dernire les diffrents concepts dun SoftPhone savoir composer un appel ou rpondre un appel.

Llaboration de ce projet ma permit dapprofondir et de concrtiser mes connaissances en informatique et surtout dans le domaine du dveloppement des applications de tlphonie. Nanmoins, ces connaissances, ne suffisent pas pour dvelopper des services de tlphonie valeurs ajouts. Il ma donc t donn dapprendre au cour de ce stage quil

Tlili Seifeddine -PFE Juin 2007-

47

Conclusion Gnrale faut joindre le monde informatique au monde des tlcommunications pour pouvoir crer de nouveaux services.

Tlili Seifeddine -PFE Juin 2007-

48

Annexe

Annexe A : Le couplage Tlphonie Informatique


1. Dfinition du CTI :
Le CTI, acronyme pour Computer Telephony Integration, soit Couplage Tlphonie Informatique est une faon d'intgrer voix et donnes dans une mme application ou encore dintgrer les fonctionnalits tlphoniques et informatiques dans un composant unique.

2. Historique du CTI :
Le CTI a t introduit en 1970 pour les ordinateurs grande puissance de calcul dans le but de commander les systmes de PBX. En 1990 la notion de personnel computer technology ou ordinateur personnel a t intgre dans le CTI et depuis, plusieurs standards ont vus le jour. Parmi les organismes qui ont contribu mettre au point le standard CTI on distingue [8] :

ITU Union international de Tlcommunication (Internationnal Telecommunication Union) a spcifi les applications de tlcoms pour les Commutateurs et les ordinateurs : Le TASC (Telecommunication Application for Switch and Computers) en 1994. Ces spcifications incluent un aperu gnral sur la norme TASC, larchitecture fonctionnelle et les services associs.

TTC comit de la technologie de tlcommunication (Telecommunication Technology Comittee) du japon a spcifi linterface entre les PBXs et les applications informatiques cette spcification concorde avec la norme SCAI (Switch-to-Computer Application Interface). [8]

ECMA lassociation europenne de constructeurs informatique (European Computer Manufacters Association) supervise le dveloppement du standard CSTA (Computer Supported Telecommunication Application) depuis 1988, ce standard spcifie

lenvironnement de commande entre commutateur et application informatique. [8]

Intel et Microsoft ont dvelopp en 1993 la spcification TAPI (Telephony Application Programming Interface) pour linterface de dveloppement dapplication CTI pour les systmes dexploitation Windows. [8]

Tlili Seifeddine -PFE Juin 2007-

49

Annexe Novel et Lucient ont lanc la norme TSAPI en 1993 pour la plateforme Netware contrairement TAPI qui est destin pour une plateforme Microsoft.

3. Les fonctions CTI:


Le CTI a t dvelopp pour grer les appels tlphoniques en intgrant laspect intelligent de linformatique. Par exemple, le CTI fournit une meilleure interface utilisateur que linterface traditionnelle des tlphones qui offre un accs limit partir du pav numrique. Plus encore le CTI offre des plateformes et des fonctionnalits qui permettent de piloter et invoquer des services tlphoniques valeurs ajoutes dune manire plus efficace et plus rapide. Les fonctions CTI peuvent tre classer en trois classes [8] : Contrle dappel ou (Call control functions). Traitement de donnes Media (Media processing).

3.1. Le contrle dappel


La control dappel reprsente la partie la plus importante dans le concept CTI, elle invoque de manire gnrale la supervision des appels tlphoniques et le contrle des systmes de tlphonie qui interagit avec les appels. Parmi les services de contrle dappel on retrouve le concept dinitiation dappel, affectation dune connexion un appel, routage automatique des appels ou encore la dtection de frappe du pav numrique du tlphone [8].

3.2. Traitement de donnes Mdia


Cet aspect englobe des fonctions lies au traitement de donnes parmi lesquelles on cite : Traitement de la voix et des donnes data savoir le Fax ou encore lenregistrement de messages vocaux, envoi et rception de Fax, gnration, et dtection de tonalit DMTF (Dualtone multi-frequency).

4. Composants CTI
Le CTI comporte trois composants : le Switch-to-host interface, lAPI et le CTI ressource architecture . Le Switch-to-host interface est linterface du type CSTA (Computer Supported Telephony Applications) ou SCAI (Switch-to-Computer Application Interface) qui fournit la connexion entre le PABX (ou IP-PBX) et le serveur CTI. LAPI permet un dveloppeur de crer une nouvelle fonction ou un service pour le CTI. Le CTI ressource

Tlili Seifeddine -PFE Juin 2007-

50

Annexe architecture est le gestionnaire de la tlphonie et des ressources dans le systme telle que la reconnaissance de la voix, la figure 33 illustre les diffrents composants voqus dans larchitecture CTI. [8]

Figure 33 Architecture globale du CTI

4.1. Switch-to-Host interface (Lien CTI)


Le premier composant de larchitecture CTI est le Switch-to-host interface, ce lien permet de fournir la connexion entre le commutateur et le serveur CTI et ainsi dassurer la communication entre ces deux composants. Plus traditionnellement les commutateurs reprsentaient des systmes ferms qui ne permettaient pas lintgration de services et ne fournissaient aucune interface de sortis pour un contrle externe du systme .Dans les applications de tlphonies, le commutateur est contrl par le serveur CTI excutant les applications de tlphonie. Cette interface est aussi appele lien CTI qui est totalement diffrente de linterface de la ligne tlphonique. [9] Connect au commutateur via le lien CTI, le serveur CTI fournit lenvironnement de tlphonie pour les dveloppeurs dapplications de tlphonie travers des standards API (Application Programming Interface) parmi lesquels on cite le JTAPI (Java Telephony Application Programming Interface) ou encore le TAPI (Telephony API) et le TSAPI (Telephone Services API) . [9] Deux technologies ont t proposes pour le lien CTI: Le CSTA (Computer Supported Telecommunications Application) et SCAI (Switch-toComputer Application Interface).

Tlili Seifeddine -PFE Juin 2007-

51

Annexe Le dveloppement du CSTA a t initi par lassociation ECMA tant dis que le SCAI est la version dveloppe par lANSI (American National Standards Institute) qui repose sur les mmes concepts que celui du CSTA mais il est plus complexe quant son intgration et dploiement dans une architecture de dveloppement dapplication CTI [9].

4.2. Le Standard CSTA


Ce protocole dcrit les types de donnes changes au niveau de la couche Application. Le CSTA spcifie les interfaces dapplications ainsi que les protocoles utiliser pour superviser et contrler les appels et les terminaux dun rseau de communication. En dautres termes le CSTA consiste en une interface CTI qui permet de fournir laccs aux services de communications ainsi que le dveloppement dapplications bas sur diffrents API tlphonique [9]. La plupart des constructeurs de PBX ont adopt le CSTA comme leur standard, il reprsente la base de la plupart des APIs savoir TSAPI ou TAPI.

4.2.1. Le protocole CSTA


Le protocole CSTA spcifie lensemble des commandes et la structure des donnes pour la communication entre le commutateur et lhte. A travers ce protocole, lhte accde aux services de tlphonie CSTA intgrs dans le commutateur [2].

4.3. La plateforme Applicative (API)


Le principe de la technologie CTI est de permettre une application d'agir sur le PABX comme si elle tait un simple tlphone. Cela est possible grce des interfaces de programmation dapplications (Application Programming Interface API) standardises. Les API sont des interfaces qui offrent un dveloppeur logiciel de crer de nouvelles applications de tlcommunications, se sont des passerelles logicielle qui permettent de discuter avec du matriel tlphonie, cette partie a pour but de dcrire les trois principaux API qui sont les plus utilises pour le dveloppement dapplications de tlphonie.[9] TAPI : Acronyme pour Telephony Application Programming Interface, elle a t dveloppe par Microsoft pour les machines fonctionnant avec un systme dexploitation Windows. TSAPI : (Telephony Services API) Dveloppe par Novell et Lucent Technologies Tlili Seifeddine -PFE Juin 200752

Annexe JTAPI : (Java Telephony) Dveloppe par SunMicrosysteme, cette API fournit une portabilit et une approche orient objet pour les applications tlphonique dveloppes en Java.

4.4. Architecture des ressources CTI


Dans un systme CTI, un ou plusieurs composants Hardware sont necessaire pour implmenter les fonctions du CTI. Ces ressources matrielles incluent analog/digital trunk interface, traitement de la voix, traitement des donnes fax, reconnaissance de voix Le CTI ressource architecture est typiquement quivalent un systme ouvert qui supporte toute intgration de nouvelles ressources CTI fabriques par diffrents constructeurs. Les standards pour CTI ressource architecture incluent : Multi-Vendor Integration Protocol (MVIP) Le protocole MVIP fait partie de la famille des standards open source qui supportent lintgration de traitement de la voix, traitement de donnes Fax/Data et plusieurs technologies informatique qui requirent la connexion au rseau tlphonique soit un Rseau PSTN ou IP pour la VOIP. Le MVIP offre une approche dintgration entre le PC et le PBX ainsi que d'autres systmes de commutation de tlphone. Signaling Computing System Architecture (SCSA) SCSA est une architecture complte et ouverte pour lintgration des fonctions de la tlphonie informatique (CT computer Telephony). Ce protocole contient non seulement le modle hardware qui spcifie le Bus CTI pour la c ommutation en temps rel des donnes mais il intgre aussi le modle logiciel qui identifie les services pour le traitement de mdia et le contrle dappel. [9]

5. Les applications CTI 5.1. Le service vocal interactif


Les serveurs vocaux donnent la possibilit un utilisateur du tlphone de dialoguer avec le systme d'information de l'entreprise par : Accs aux donnes sous forme parle Introduction de messages dans le systme de l'entreprise via le serveur vocal sous forme numrique (clavier) ou parle Les applications classiques du serveur vocal sont les services de transaction (rservations, tlpaiement) et les services de consultation (horaires, comptes bancaires, ...) ou encore de standard automatique.[9]

Tlili Seifeddine -PFE Juin 2007-

53

Annexe

5.2. LIdentification de l'appelant/Monte de fiche client


A chaque nouvel appel tlphonique, la 'fiche client monte' l'cran de l'agent. Celui-ci gagne du temps, il connat tout de suite le nom de l'appelant et pourra accueillir son interlocuteur de la faon la plus personnalise possible, il peut s'informer sur l'historique des contacts avec ce client et viter ainsi de redemander le besoin client. Inutile de demander le nom de l'appelant, il est affich sur votre cran avant mme de dcrocher.

5.3. La messagerie unifi ou Unified Messaging


En outre, la messagerie unifie volue, depuis peu, vers le concept de communication unifie. Il ne s'agit plus alors seulement de regrouper des messages crits et vocaux mais de raliser une synthse complte entre ces mdias et avec les fonctions d'annuaire et d'agenda. Avec Unity Unified Messaging (Cisco) ou Cisco Web Attendant, un message vocal ou crit peut tre lu par un PC, un GSM ou un PDA. De plus, l'utilisateur peut crer des rgles de routage tenant compte, par exemple, de son agenda ou de l'identit de chaque appelant. [8]

Tlili Seifeddine -PFE Juin 2007-

54

Annexe

Annexe B :
CallManager
La plate-forme Cisco CallManager tend les fonctionnalits tlphoniques dans lentreprise aux quipements connects sur le rseau de donnes tels que les tlphones IP, les quipements de traitement de la voix, les passerelles VoIP et les applications multimdia. Les services additionnels de data, voix et vido tels que la messagerie unifie, la confrence multimdia, le centre de contact collaboratif et les systmes de rponse multimdia interactifs interagissent avec la solution dIP Tlphonie par lintermdiaire des interfaces de programmation ouverts (APIs) natifs de Cisco CallManager. Cisco CallManager sinstalle sur les serveurs de convergence de mdia de Cisco (MCSs) ainsi que sur un choix de serveurs dautres constructeurs (HP, IBM). Cisco CallManager est livr avec une srie dapplications et dutilitaires qui comprend Cisco CallManager Attendant Console, qui est un logiciel de poste oprateur pour PC, une application de confrence en mode impromptu (ad-hoc), Bulk Administration Tool (BAT), CDR Analysis and Reporting tool (CAR), Real-Time Monitoring Tool (RTMT), Cisco CallManager Auto-Attendant, qui est un standard automatique simple et de petite capacit, Tool for Auto-registered Phones Support (TAPS) et IP Manager Assistant (IPMA). [10]

Tlili Seifeddine -PFE Juin 2007-

55

Annexe

Annexe C :
1. Le format RSS
Format de syndication de contenu Web, bas sur le XML, qui permet dindexer de faon automatise le contenu dun site Web et de le mettre instantanment disposition dautres sites. Le format RSS est en fait une manire de dcrire le contenu dun site Web (articles, informations, vnements) et plus gnralement toute page qui prsente un contenu mis jour chronologiquement. Il permet des sites Web dafficher automatiquement les derniers titres parus sur un autre site. Cr lorigine par Netscape, le format RSS est dsormais utilis couramment pour partager du contenu entre sites Web [11]. RSS est lacronyme de Really Simple Syndication (RSS 2.0), RDF Site Summary (RSS 0.9, 1.0 et 1.1) ou Rich Site Summary (RSS 0.91), suivant les diffrentes versions [11].

2. Le langage XML
Extensible Markup Language (langage de balisage extensible), gnralement abrg XML, est un standard du World Wide Web Consortium qui sert de base pour crer des langages de balisage : c'est un mtalangage . En ce sens, XML permet de dfinir un vocabulaire et une grammaire associe sur base de rgles formalises. Il est suffisamment gnral pour que les langages bass sur XML, appels aussi dialectes XML, puissent tre utiliss pour dcrire toutes sortes de donns et de textes. Il s'agit donc partiellement d'un format de donns. L'extensibilit de XML est principalement assure par la notion d'espace de nommage. L'objectif initial de XML tait de faciliter le partage de textes et d'informations structures, par exemple au travers d'Internet, en sparant le contenu du contenant. Il constitue une simplification de SGML tout en continuant assurer la portabilit des documents, notamment grce l'intgration d'Unicode.

Tlili Seifeddine -PFE Juin 2007-

56

Bibliographie

Bibliographie
[1] www.onetech-group.com [2] CTI Applications Architecture and Design for CallManager 3.1 October, 2001 IP Telephony Design Guide. [3] http://uml.free.fr/index-cours.html, Laurent Piechocki
[4] Cay S. Horstmann And Gary Cornell, Au Coeur de Java 2, CampusPress, dition 2000

[5] JTAPI specifications, 22 Mars 2000. [6] http://www.a525g.com/programmation/java-swing.htm [7] www.rr0.org/java/Tomcat.html [8] Cisco Lessons documentations, Computer Telephony Integration and ICM. [9] Michael Bayer ,Computer Telephony Demystified - Putting CTI, Media Services, and IP Telephony to Work, New York McGraw-Hill Professional, Janvier 2000. [10] John Alexander, Chris Pearce, Anne Smith, Delon Whetten, Cisco CallManager Fundamentals Second Edition, Cisco Press, 22 Septembre 2005.

Tlili Seifeddine -PFE Juin 2007-

57

[11] http://fr.wikipedia.org/wiki/Really_Simple_Syndication

Titre :

Dveloppement et intgration de solutions CTI dans une plateforme Cisco.

Rsum
Le Couplage tlphonie informatique permet de coupler la tlphonie, principal canal de communication client distance, et le systme informatique de lentreprise, source de connaissance du client. Il constitue le point cl pour la relation client pour toutes entreprises. C'est dans cette perspective que s'inscrit notre projet qui a pour objectif de concevoir et de raliser une application CTI adapt la fois au IP Phone Cisco et au PC, base sur la plateforme Cisco dont le CallManager constitue le noyau, mais le projet slargit encore plus, afin de faire profiter lutilisateur des avantages que fournit cette plateforme savoir la possibilit dintgrer de nouveaux services de tlphonie IP accessible partir du IP Phone. Pour cela, nous mettons en oeuvre un serveur dapplications CTI constituant une couche architecturale part entire pour les IP Phones, dans le but dafficher les informations de linterlocuteur ainsi que les diffrents services de tlphonie IP dvelopps pour les IP Phone. Le Client CRM assura cette tache pour les utilisateurs de PC.

Mots cls
JTAPI, CTI, Cisco CallManager, Java, CRM, IP Phone, services de tlphonie IP.