Rapport de Projet de Fin D'études: Développement Et Intégration de Solutions CTI Dans Une Plateforme Cisco

Liste
des abréviations

Cycle de formation des ingénieurs en Télécommunications
Option :
Ingénierie des Réseaux

Rapport de Projet de fin d’études

Thème :

Développement et intégration de solutions
CTI dans une plateforme Cisco.

Réalisé par :
Seifeddine Tlili

Encadrants :
M. Riadh Tebourbi (SUP’COM)
M. Nizar Hedhili (OneTech Development)

Travail proposé et réalisé en collaboration avec

Année universitaire : 2006/2007
Dédicaces

A mes parents,
A mon frère,
A ma soeur,
A Weal et Youssef
A mon beau frère Hamadi
A toute ma famille,
Je dédie ce modeste travail
ii
Remerciements

Ce projet, réalisé au sein du Groupe OneTech dans l’entreprise OneTech développement
s’inscrit dans le cadre du Projet de Fin d’Etudes à l’Ecole Supérieure des Communications
de Tunis (SUP’COM) pour l’obtention du diplôme d’ingénieur en Télécommunications.
Au terme de ce projet, je tiens à exprimer ma profonde gratitude et mon immense respect à
M.. Riadh Tebourbi, maître assistant à Sup’Com, ainsi que M. Nizar Hedili Directeur
Technique à OneTech Développement pour m’avoir soutenu durant la période de mon projet.
J'aimerais témoigner du plaisir qu'était pour moi de travailler sous leurs directives.
Je tiens également à exprimer ma profonde reconnaissance à M. Samy Chapoutot, directeur
Commercial à OneTech développement pout sa disponibilité, ses qualités humaines et ses
conseils précieux.
De même, je souhaite transmettre l'expression de ma reconnaissance et ma plus profonde
gratitude aux ingénieurs de OneTech Développement qui m’ont offert un excellent cadre de
travail ainsi qu’un climat extrêmement agréable.
Avec beaucoup d'égard, je ne manquerai pas d'exprimer ma grande reconnaissance à tous les
enseignants et administrateurs de l'école supérieure 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 d’ingénieur en télécommunication à l’École Supérieure
des communications de Tunis, j’ai effectué un projet de fin d’études au sein de l’entreprise
OneTech développement filiale du groupe tunisien One TECH Group. Le sujet porte sur la
conception et l’implémentation de services liés à la téléphonie IP et le couplage téléphonie
informatique sur la plateforme Cisco CallManager.

Avec son concept « One Stop Shop », le groupe One TECH fournit une multitude de
solutions complémentaires pour la réalisation d’un large éventail de sousensembles complets
et de produits finis selon les exigences des clients et les normes internationales.
Les sociétés du groupe One Tech offre des solutions complémentaires, garantissant ainsi des
économies de temps, de transport et d’intégration [1].

Conscient des évolutions et des mutations dans le domaine des Technologies de l’information
et des communications, vecteurs de croissance et de développement à l’échelle mondiale, et
des enjeux vitaux à réduire la fracture numérique, OneTech affirma la détermination à
orienter sa stratégie vers les nouvelles Technologies de l’information et des communications
dans le cadre de partenariats internationaux axés sur la complémentarité [1].

iv
Table des matières

Table des matières :
I.1. Introduction générale........................................................................................................1
Chapitre 1 : Etude de problématique
I.1. Introduction.......................................................................................................................3
I.2. Architecture CTI de CallManager...................................................................................4
I.3. Déploiement de JTAPI dans une architecture Cisco......................................................5
I.4. Déploiement de services de téléphonie IP dans une architecture Cisco.......................6
I.4.1. Principe de fonctionnement des services de téléphonie IP.........................................7
I.5. Bilan de l’analyse et choix de la solution.........................................................................7
I.5.1. Ressources matérielles................................................................................................8
I.5.2. Etude des solutions possible........................................................................................8
I.5.2.1. Partie utilisateur.....................................................................................................8
I.5.2.1.1. Intégrer l’interface dans un Formulaire HTML..............................................8
I.5.2.1.2. Intégrer l’interface dans une interface utilisateur graphique.....................9
I.5.3. Partie serveur...............................................................................................................9
I.5.4. Choix de la solution.....................................................................................................9
I.6. Spécifications des besoins................................................................................................10
I.6.1. Spécifications des besoins fonctionnels....................................................................10
I.6.1.1. Développement de la partie Serveur d’application CTI......................................10
I.6.1.2. Développement de la partie Client......................................................................10
I.6.1.2.1. Développement de l’interface Client................................................................10
I.5.1.2.2. Développement de la partie CTI au niveau du client....................................11
I.7. Spécifications des besoins non fonctionnels...................................................................11
I.7.1. Contrainte temps de réponse.....................................................................................11
I.7.2. Contraintes liées au développement..........................................................................11
I.8. Conclusion........................................................................................................................11
Chapitre 2 Architecture et conception
II.1. Introduction....................................................................................................................12
II.2. Architecture matérielle et protocolaire........................................................................12
II.3. Choix de l’architecture..................................................................................................14
II.3.1. Diagramme de déploiement......................................................................................14
II.3.2. Justification conceptuelle..........................................................................................15
II.3.2.1. Choix de l’architecture client serveur.................................................................15
v
Table des matières

II.3.2.2. Choix du client CRM..........................................................................................15
II.4. Diagrammes de cas d’utilisation de la solution...........................................................15
II.4.1. Définition des différents acteurs agissant sur le système..........................................15
II.4.2. Les packages du diagramme de cas d’utilisation......................................................17
II.4.3. Diagrammes de cas d’utilisation...............................................................................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 d’application 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 séquence.................................................................................................28
II.6.1. Diagramme de séquence du serveur d’application CTI............................................29
II.6.2. Digramme de séquence du client CRM.....................................................................30
II.7. Conclusion.......................................................................................................................30
Chapitre 3 : Solution et implémentation
III.1. Introduction..................................................................................................................31
III.2. Environnement et langage de programmation..........................................................31
III.3. Choix de l’architecture logicielle.................................................................................32
III.3.1.Le package JTAPI.....................................................................................................32
vi
Table des matières

III.3.2.L’API Swing :...........................................................................................................36
III.3.3.L’API « JDBC »........................................................................................................36
III.3.4.Les serveurs...............................................................................................................37
III.3.5.Le système de gestion des bases de donnés :............................................................37
III.3.6.Les JSP......................................................................................................................37
III.3.7.XML..........................................................................................................................38
III.4. Les interfaces................................................................................................................38
III.4.1.Les interfaces utilisées pour les IP Phones................................................................39
III.4.2.Les interfaces graphiques..........................................................................................40
III.4.3.Lancement du Service...............................................................................................44
III.5. Conclusion.....................................................................................................................46
Conclusion générale ..............................................................................................................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 téléphonie IP Cisco.................................6
Figure 4 Enregistrement du téléphone IP et consultation des services......................................7
Figure 5 Architecture matérielle de la solution........................................................................13
Figure 6 Diagramme de déploiement du Service.....................................................................14
Figure 7 Les packages utilisés..................................................................................................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 séquence du serveur d'application CTI...........................................29
Figure 17 Diagramme de séquence du Client Crm..................................................................30
Figure 18 Modèle d’appel Jtapi................................................................................................33
Figure 19 Transition d’état du Provider...................................................................................34
Figure 20 Diagramme de transition d’un 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 téléphonie IP.....................................................................39
Figure 24 Page d’accueil..........................................................................................................40
Figure 27 Interfaces Swing......................................................................................................41
Figure 28 Ajout d’un agent d’une société................................................................................42
Figure 29 Rechercher un utilisateur.........................................................................................42
Figure 30 Ajout d’informations d’une société dans notre base de données.............................43
Figure 31 Recherche d’informations d’une société..................................................................43
Figure 32 Affichage des coordonnées de l’interlocuteur.........................................................44
Figure 33 Affichage des données à l'écran du poste IP............................................................45
Figure 34 Numéros non reconnus dans la base de données.....................................................45
Figure 35 Architecture globale du CTI....................................................................................51

Tlili.Seifeddine PFE Juin 2007 viii

Liste des abréviations
Liste des abréviations:
A
ACD Automatic Call Distributor
API Application Programming Interface

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

G
GUI Graphical User Interface

H
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol

I
IVR Interactive Voice Response

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

L
LDAP Lightweight Directory Access Protocol

Tlili Seifeddine PFE Juin 2007 ix
Liste des abréviations
T
TAPI Telephony API
TAPI SRV TAPI Server
TOIP Telephony Over IP
TSP Tapi Service Provider

U
UML Unified Modelling Language

X
XML Extensible Markup Language

Tlili Seifeddine PFE Juin 2007 x
Introduction générale

Dans un monde économique toujours plus actif, il n'est pas nécessaire de rappeler
l'importance de la relation clientèle. S'il est nécessaire de trouver de nouveaux prospects, il est
aussi important de conserver ses actuels clients.
Hors, il apparaît que la relation avec ces derniers passe en grande partie par le téléphone : le
média le plus utilisé et le plus accessible.
Traditionnellement séparés, la téléphonie et l’informatique font aujourd’hui l’objet d’une
convergence de plus en plus marquée se manifestant notamment par l’émergence des
solutions de téléphonie sur IP. Cette convergence a donné naissance à un nouveau concept, le
CTI ou le Couplage Téléphonie Informatique.

Le concept de Couplage Téléphonie Informatique permet de mettre en place des applications
nouvelles qui s’appuient sur l’exploitation simultanée de deux grandes dynamiques : la
puissance des services de commutations en temps réel des platesformes de communications,
et la capacité de traitement de l’information des réseaux informatiques.

La plupart des projets d'intégration entre téléphonie 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 montée de fiche ; le numéro de l'appelant est reconnu et sa fiche
apparaît.

C’est dans ce cadre que ce projet s’inscrit. Il s’agit de concevoir, implémenter et intégrer le
service « Client CRM » sur une plateforme à base d’équipements Cisco qui aura comme
acteur principal le serveur IPPBX de Cisco, le CallManager. Le projet s’élargit encore plus,
permettant d’intégrer cette fonctionnalité au téléphone IP Cisco ainsi que le développement et
l’intégration de services de téléphonie 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 accéder à différents services en utilisant le langage XML. Ce qui offre une
facilité d'utilisation via une interface graphique et permet ainsi l’accroissement de la
productivité personnelle.
Tlili Seifeddine PFE Juin 2007 1

Dans ce rapport de fin d’étude, nous commencerons, dans un premier chapitre par une
recherche bibliographique. Nous présenterons à travers cette partie l’infrastructure sur
laquelle nous nous sommes basés pour implémenter ce service à partir de cette étude, nous
allons choisir la solution qui va être implémentée, et nous spécifierons les besoins de cette
solution.
Dans le deuxième chapitre, nous nous sommes basés sur le formalisme UML pour concevoir
la solution choisie.
Dans le troisième chapitre, nous présentons les différents outils utilisés et les interfaces
d’accès aux services, soit à partir d’un poste PC ou d’un téléphone IP.

Etude de problématique

Chapitre 1
I.Etude de problématique

I.1.Introduction

Le CRM (Customer Relationship Management) est l’un des aspects des applications du CTI,
il permet à l'entreprise d'obtenir des données importantes sur ses clients (liste de contacts,
pistes, opportunités, contrats, messages électroniques, comptes, historiques d'achats et
préférences) de manière à leur proposer des produits et des services qui répondent
précisément à leurs besoins lors d’un appel téléphonique et ainsi améliorer la qualité de
service offerte aux clients. Parmi les applications CRM qui sont étroitement liées au CTI on
cite la montée de fiche client lors d’un appel. L'analyse de ces données aide notamment les
entreprises à déterminer qui sont leurs meilleurs clients, à enrichir et à personnaliser les
relations avec ces clients, à gérer leurs campagnes de marketing, à réduire les délais de
réponse lors d’un processus de transaction téléphonique.
Dans ce chapitre nous allons analyser la solution que nous allons développer qui se résume à
la montée de fiche client lors d’un appel téléphonique que se soit sur l’ordinateur de
l’utilisateur ou encore sur un téléphone IP de la gamme Cisco 7900 ainsi que l’intégration de
services de téléphonie IP pour un poste IP afin de lui permettre d’interagir avec un serveur de
base de données utilisateurs. Dans cette partie nous allons présenter l’architecture Cisco pour
l’implémentation de solutions CTI ainsi que le déploiement de JTAPI dans une telle
infrastructure. Puis nous passons à l’architecture adoptée par Cisco pour le déploiement et
l’intégration de solutions de services de téléphonie IP.

I.2. Architecture CTI de CallManager

Cisco CallManager (voir Annexe) contient un ensemble d’interfaces qui permettent la
communication avec des applications extérieures. La figure 1 illustre les différents types
d’interfaces 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 d’application CTI. Parmi les applications CTI on retrouve la messagerie
unifiée, Call Center, EConferencing et les systèmes IVR.
L'Access aux services d'annuaire à partir de requêtes LDAP permettent l'authentification
d'appel dans un environnement d’application d'entreprise.
En utilisant XML à travers des message http,Cisco 7940 et 7960 IP Phones sont équipés d’un
client web leur permettent d’afficher des données sous forme XML[2].


I.3.Déploiement de JTAPI dans une architecture Cisco

L’architecture 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 l’interaction du CallManager avec deux
applications CTI utilisant différente API, une qui implémente le JTAPI et une autre qui
implémente le TAPI [2].

Figure 2 Architecture Cisco CTI

Le CallManager est capable de traduire différents protocoles CTI à savoir le CTIQBE (CTI
Quick Buffer Encoding) véhiculé à travers un lien TCP/IP.
Le lien entre l’application et le CallManager renferme un ensemble de protocoles CTI
compréhensible 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 qu’on 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 d’un autre côté dialogue avec
le CallManager via le protocole propriétaire de Cisco le CTIQBE. Ce TSP est relié au
CallManager grâce au lien CTI à travers le LAN de l’entreprise.

Les implémentations Cisco Tapi Service provider (TSP) et le JTAPI traduisent les APIs
utilisées par notre application en message CTIQBE compréhensible par le CallManager
Les applications CTI peuvent contrôler un certain nombre d’entité à travers le CallManager
parmi lesquelles on retrouve :
Appareil ou Device : Les appareils tel que IP Phones peuvent être contrôlés et surveillés à
partir d’une 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'intermédiaire d'un port de CTI.
Point d’itinéraire CTI (CTI route Point) : Un point d'itinéraire CTI est un dispositif virtuel
qui peut manipuler simultanément des appels multiples et tous sur la même ligne. Par
exemple, un point d'itinéraire CTI peut être un numéro 1800 qui recevra des appels et assurera
la fonction de routage de ces appels au port CTI approprié [2].
I.4.Déploiement de services de téléphonie IP dans une architecture Cisco

Parmi les atouts de l’architecture Cisco pour la TOIP ou Téléphonie IP est le fait de pouvoir
déployer une panoplie de services basé sur le langage XML et qui seront accessible via le
téléphone IP. Parmi les services qui peuvent être intégrés dans une telle architecture on cite
l’interaction du terminal IP avec un serveur de base de données, la consultation des nouveaux
produits offert par Cisco via Internet ainsi que les bulletins d’informations. La figure 3 illustre
les composants clé de déploiement des services de téléphonie IP [2].

Figure 3 Composants essentiels pour les services de téléphonie IP Cisco


I.4.1. Principe de fonctionnement des services de téléphonie IP

Dans un premier lors du démarrage du téléphone IP, ce dernier échangera des messages avec
le serveur CallManager en utilisant le protocole SCCP afin de s’enregistrer et obtenir ainsi
une adresse dans le réseau. Mais l’échange de messages SCCP entre le CCM et le IP Phone ne
s’arrête pas juste au fait de l’obtention d’une adresse mais aussi à la récupération des
privilèges accordé à savoir le droit de consulter les services de téléphonie IP disponible et une
fois que l’adresse du serveur a été récupéré, le poste IP envoi une requête de type http vers ce
serveur afin de consulter les services mis à sa disposition, la figure 4 illustre les étapes
décrites cidessus :

Figure 4 Enregistrement du téléphone IP et consultation des services

I.5. Bilan de l’analyse et choix de la solution

Ce projet consiste à concevoir et développer une application CTI qui se résume à établir une
connexion avec le IPPBX CCM afin de récupérer le numéro de la partie appelante et
permettre ainsi l’identification de l'interlocuteur.
Cette solution est basée sur l’API Cisco JTAPI dédiée pour le développement de solutions de
téléphonie et permet ainsi de bénéficier de nouveaux services.
La solution proposée a pour but de simplifier l’interaction de l’utilisateur avec les services de
téléphonie tout en masquant la partie CTI.

I.5.1. Ressources matérielles

Pour réaliser ce projet, la société OneTech développement m’a offert les ressources
nécessaires pour mener à bien mon projet à savoir :
Une plateforme Cisco CallManager installée 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 différentes solutions possibles en présentant les
avantages et les inconvénients de chaque solution.

I.5.2.1. Partie utilisateur

L’interface utilisateur doit être compréhensible et simple à manipuler par tous les utilisateurs,
il y a beaucoup de solutions possibles pour implémenter cette partie.

I.5.2.1.1. Intégrer l’interface dans un Formulaire HTML

L’idée est inspirée des formulaires HTML qu’on peut trouver sur certains sites web. Pour
accéder au service, l’utilisateur devra à chaque fois se connecter au serveur web afin
d’interagir avec ce formulaire qui intégrera les différents champs nécessaire pour le stockage
et la consultation des informations des clients de la société. Cette interface devra contenir les
différentes possibilités qu’un utilisateur aura besoin pour interagir avec la base de données à
savoir l’ajout d’un client ou agent d’une société, l’ajout d’une société, la recherche des
informations concernant un client ou une société ainsi que la possibilité d’effectuer une mise à
jour de la base de données.
Cette méthode présente beaucoup d’avantages :
Profiter des technologies du développement web pour implémenter cette interface.
L’interface est facile à manipuler par l’utilisateur.
Cette méthode présente aussi quelques inconvénients :

Le client doit impérativement passer par le serveur Web de la société et donc devra connaître
l’emplacement exacte du lien du service.
Le temps de traitement est assez long puisque le flux d’informations qui passera à travers le
réseau sera assez chargé donc risque de blocage et le service ne pourra pas être ainsi lancé.

I.5.2.1.2. Intégrer l’interface dans une interface utilisateur graphique

Dans une application, la partie graphique est aussi importante que la partie traitement car c’est
cette partie qui reste le plus visible pour l’utilisateur.
L’interface graphique utilisateur présente les mêmes fonctionnalités que celles d’un
formulaire HTML mais ne nécessite pas de serveur Web, elle fonctionne sur tout système
d’exploitation intégrant 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 l’échange de
flux d’information avec le CallManager pour récupérer l’état de la ligne téléphonique et
extraire ainsi le numéro de téléphone de l’interlocuteur lors d’un processus d’appel.
Cette approche présente des avantages par rapport à un formulaire HTML à savoir :
Pas besoin de connaître le lien, l’interface est sous forme d’un programme que l’utilisateur
final installera sur son ordinateur.
I.5.3. Partie serveur

Cette partie interprète les messages échangés avec le CallManager sur l’état de la ligne
téléphonique. Ainsi, lors d’arrivées d’un appel depuis l’extérieur, le serveur doit être capable
d’interpréter les messages échangés avec le CallManager afin de récupérer le numéro de
téléphone de l’interlocuteur et ainsi renvoyer les informations de l’interlocuteur vers le
téléphone IP impliqué lors de la communication téléphonique.
Cette partie intégrera aussi des services qui peuvent être consultés par un téléphone IP Cisco
et prendra en charge l’adaptation de l’affichage sur le poste IP.
Ce module doit être en mesure de communiquer avec le CallManager, il faudra donc
développer une interface le reliant à ce système.
I.5.4. Choix de la solution

Selon ce qui a déjà été avancé, on remarque que chaque solution a ses avantages et ses
inconvénients, le but de ce projet est de trouver un compromis entre ces différentes solutions

pour que ce service soit accessible et facile à utiliser par tout le monde, pour cela, la solution
intégrant l’interface utilisateur sous forme de formulaire HTML est à écarter.
La solution qui sera retenu pour l’implémentation de ce service est celle qui permettra un
accès facile pour les utilisateurs. Pour cela on a opté pour la solution interface utilisateur
graphique, il s’agit de développer une interface graphique pour les utilisateurs finaux du
service, cette interface contiendra les mêmes champs qu’un formulaire HTML. Non
seulement, cette approche offre la possibilité de jouer sur la présentation mais elle est très
maniable et extensible. Mais cependant l’intégration de se service au poste de téléphone IP
utilisera l’approche adoptée pour la partie serveur puisque les téléphones IP de Cisco
n’intègre pas la machine virtuelle Java et peuvent supporter l’affichage XML selon les
spécifications de Cisco.
I.6.Spécifications des besoins

La spécification des besoins constitue la première phase formelle et obligatoire du
développement informatique, en d’autres termes c’est un modèle d'un logiciel. C'est aussi
l'étape en génie logicielle qui consiste à décrire ce que le logiciel doit faire.
I.6.1. Spécifications des besoins fonctionnels

I.6.1.1. Développement de la partie Serveur d’application CTI

Cette partie constitue le noyau de notre projet vu que celle ci qui va s’interfacer avec le
CallManager et observer ainsi l’état de la ligne téléphonique, si l’état de la connexion passe
du mode IDLE en mode ALERTING (annexe) le serveur d’application CTI alerte le client
qu’un appel lui ait destiné et affiche ainsi les données de l’interlocuteur sur le téléphone IP.
Ce serveur d’application contient aussi une gamme de service accessible à partie du téléphone
IP afin d’interagir avec le serveur de base de données.

I.6.1.2.
Développement de la partie Client
I.6.1.2.1. Développement de l’interface Client

Cette partie a pour objectif de simplifier l’interaction du client avec le programme en question
et de lui permettre d’identifier l’interlocuteur afin de modifier ou ajouter des informations le
concernant, et de noter les transactions effectuées avec l’entreprise concernée lors de l’appel.

I.5.1.2.2. Développement de la partie CTI au niveau du client
Cette partie aura comme tache de s’interconnecter au serveur CallManager et observer les
événements sur la ligne téléphonique, dans ce cas si un appel a été initié par le réseau PSTN
cette partie renvoie ainsi le numéro de téléphone au programme CRM qui effectuera
l’affichage à l’écran de l’utilisateur (poste PC) des données de l’interlocuteur. Sans cette
partie notre application ne pourra pas s’interconnecter avec le CallManager et récupérer ainsi
le numéro de téléphone ou le CallerID.
I.7.Spécifications des besoins non fonctionnels
I.7.1. Contrainte temps de réponse

Un des impératifs les plus immédiats de ce projet est la contrainte temps de réponse .En effet
le but de cet application est de pouvoir identifier notre interlocuteur avant même de décrocher
l’appareil téléphonique et collecter ainsi toutes les informations qui le concernent. En ce sens,
il faut optimiser le temps de traitement de l’application étant donné l’important volume des
informations dont nous disposons concernant l’interlocuteur.
I.7.2. Contraintes liées au développement

L’adoption du langage de programmation Java pour cette application s’impose. Une telle
contrainte se justifie par le fait que les API fournis pour notre programme afin de se
s’interagir avec le CallManager sont des APIs java.
Une deuxième contrainte s’impose au fait que les IP Phone Cisco ne prennent en charges que
des formats XML bien spécifiques à Cisco.
I.8.Conclusion

Dans ce chapitre nous avons présenté l’architecture réseau et l’environnement propice pour le
déploiement d’applications CTI dans une plateforme Cisco .Nous avons aussi exploré le
service qu’on va intégrer dans cette architecture en présentant différentes solutions pour
l’implémentation, ainsi que la spécification des différents besoins fonctionnels et non
fonctionnels requis pour l’implémentation de la solution.
Dans le chapitre suivant nous allons passer à la partie conception de notre solution sous forme
d’approche UML.
Architecture et conception

Chapitre 2 :
II.Architecture et conception

II.1.Introduction

Pour mettre en oeuvre les propositions expliquées dans le chapitre précédent, il faut avant tout
spécifier l’architecture matérielle et logiciel nécessaire. Cette étape est très importante car elle
permet par la suite de concevoir la solution d’une façon plus précise et de ne pas être obligé
de refaire la conception au cours de l’implémentation effective de la solution.
Dans ce chapitre, nous allons présenter la conception du projet. Notre étude se base sur le
formalisme UML, nous identifierons les différents acteurs agissant sur notre solution ainsi que
l’architecture de déploiement proposé pour ce type de service CTI.
II.2.Architecture matérielle et protocolaire

Si nous revenons un peu au scénario d’utilisation du service, nous pouvons dégager les
différentes parties nécessaires pour réaliser la solution proposée. En fait, nous aurons besoin
d’une communication CTI pour établir la connexion avec le CallManager, d’une connexion
au Cisco JTAPI pour échanger les données JTAPI, d’un serveur d’application CTI qui aura
pour rôle d’assurer l’affichage des données clients sur le téléphone IP impliqué lors du
processus d’appel et d’assurer de servir des services à valeurs ajoutées pour la téléphonie IP.
Nous aurons aussi besoin d’une session avec un serveur de base de données pour la
récupération des données de l’interlocuteur. Ces différentes parties sont présentées dans la
figure 5 qui explique l’architecture matérielle obtenue en déployant notre solution dans une
architecture TOIP.

PSTN
CT
IQB
E /J A V
IP AJ
TA
PI
P/
TC
CP
CP SC
P
SC
T
P
HT
T
HT

Figure 5 Architecture matérielle de la solution

Les différents éléments nécessaires pour cette architecture sont :
Un serveur CallManager : Ce serveur est l’élément 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 données : Dans ce serveur, nous allons stocker les contenus statiques
telles que les informations de la partie appelante ainsi que les informations de la société
concernée par la transaction avec l’agent.
Un serveur d’application CTI : Cette partie prendra en charge les différents services que peut
y accéder le téléphone IP ainsi que l’affichage des informations de la partie appelante lors
d’un appel, ce serveur est en communication permanente avec Cisco CallManager.
Le client JTAPI : Ce client renferme l’application CRM développée qui, de son cotée aussi,
est en communication permanente avec le CallManager.

Notre mission consiste à développer le client JTAPI ainsi que le serveur d’application CTI et
de les intégrer avec les autres équipements présentés dans la figure 5 pour assurer le
fonctionnement du service.
II.3.Choix de l’architecture
II.3.1. Diagramme de déploiement

Le déploiement d’une solution de couplage de téléphonie informatique présente quelques
difficultés puisque de son côté, chaque constructeur précise ces propres spécifications pour
l’implémentation de JTAPI. La figure 6 présente le diagramme de déploiement est
équivalente à la figure présentée cidessus concernant l’architecture matérielle de la solution
mais plus en détails
Serveur
d’application CTI
JTAPI/
CTIQBE
Serveur J2EE Tomcat Module JTAPI
Cisco
JSP CallManager
Module Affichage vers le Ip Phone
LAN
Ip Phone Cisco
LAN
Module Ip Phone Service

Module DataBase
LAN
LAN
Serveur Base de donnée relative aux clients
Serveur de donnée
JTAPI/
CTIQBE
Module DataBase
Module JTAPI
Module JVM
Client CRM

Figure 6 Diagramme de déploiement du Service

II.3.2. Justification conceptuelle

II.3.2.1. Choix de l’architecture client serveur

Pour les services de téléphonie IP, une telle architecture s’impose du fait de la faible capacité
de traitement des téléphones IP puisque les capacités de calcul des téléphones IP ne sont pas
encore suffisantes pour pouvoir embarquer la totalité du service. De plus, les téléphones IP
Cisco ne sont pas conçus pour intégrer les fonctionnalités du JTAPI, qui pour bien
fonctionner, doivent être lancés dans une machine intégrant JVM. Ainsi le choix d’une telle
architecture porte tous les traitements relatifs au contrôle d’appel et l’échange de messages
CTIQBE au serveur d’application CTI.

II.3.2.2. Choix du client CRM

Le choix d’intégrer le composant CTI pour un client CRM dans un ordinateur personnel
utilisant une machine virtuelle JVM s’explique du fait que l’un des obstacles des solutions
CTI est de pouvoir collecter les flux d’informations concernant l’interlocuteur sans pour
autant que le client final envoie une requête au serveur exécutant la partie CTI. Cette
approche a été traitée par Cisco pour ces téléphones IP en utilisant une fonction bien
particulière propre à Cisco qui permet de forcer l’affichage sur un téléphone IP Cisco.
La plupart des projets CTI de ce genre utilisent la même architecture que celle adoptée pour le
client CRM.
II.4.Diagrammes de cas d’utilisation de la solution

Le modèle du diagramme d’utilisation permet de donner une vue d’ensemble sur le
fonctionnement globale de la solution ainsi que les interactions qui peuvent y avoir lieu entre
les différents composants du système.
II.4.1. Définition des différents acteurs agissant sur le système

Le système interagit avec 5 acteurs à savoir :
Client CRM : Le client est ici le programme qui va être responsable d’interpréter les
commandes envoyées par le serveur de Base de données ainsi que le flux d’informations
retournés par le CallManager pour l’identification et la récupération du numéro de téléphone
de l’interlocuteur. Ce client se présente sous formes d’interface graphique interactive

affichant les données concernant l’interlocuteur ainsi que l’entreprise concernée par la
transaction lors de l’appel téléphonique.
Cette partie offre aussi la possibilité à l’utilisateur de s’interagir avec le serveur de base de
données.
CallManager : Cisco CallManager est un composant serveur de traitement et de contrôle des
appels de la solution de téléphonie IP de Cisco. Il a pour rôle d’interpréter le flux
d’informations échangées avec l’application et de superviser de l’état de la connexion de
l’adresse rattachée au poste téléphonique, le flux échangé avec notre application est un flux
JTAPI interprété par le CallManager sous forme de messages CTIQBE.
Téléphone IP Cisco : C’est ce terminal qui affichera les informations de l’interlocuteur lors
d’un appel, cet affichage est sous formes de balise XML interprétable par la gamme Cisco
7900, l’accès au service de téléphonie IP sera initié à partir de ce composant.
Le serveur d’application CTI : Il est responsable de la partie CTI conçus pour récupérer le
numéro de l’interlocuteur, faire une recherche dans la base de données selon le numéro de
l’interlocuteur et afficher le résultat sur l’écran du téléphone IP.
Une autre fonctionnalité a été intégrée à ce serveur : Celle des services de téléphonie IP.
Parmi les services à intégrer on cite : Recherche dans la base de données à partir du téléphone,
consultation de l’annuaire qui établie une connexion à notre base de données et consultation
de l’actualité en ligne de Cisco et de CNN
La base de données : Elle contient des données relatives aux clients Parmi ces données on
cite le numéro de téléphone à partir duquel le système extrait les informations de
l’interlocuteur.


II.4.2. Les packages du diagramme de cas d’utilisation

Dans cette partie nous allons définir les différents packages qu’on a développé ainsi que
l’interaction entre eux à travers le diagramme de packages.
Pour notre projet les packages sont aux nombres de 5 comme l’illustre la figure 7

Figure 7 Les packages utilisés

IP Phone Cisco
Serveur d'application CTI
Include
PushToPhone IpPhoneServices
Include
Telephony
CallManager Include
Include
DataBase
GUICrm Include
Serveur Base de donnée
Client Crm

Figure 8 Diagramme des packages


II.4.3. Diagrammes de cas d’utilisation

Dans le diagramme des cas d’utilisation, interviennent trois éléments : les acteurs, le système
et les cas d’utilisation. L’acteur représente une personne ou un autre système qui interagit
avec le système en cours de modélisation. Pour indiquer la participation d’un acteur à un cas
d’utilisation, nous utilisons une flèche (UML). Les cas d’utilisation peuvent être en relation
(uses ou extension) [3].

II.4.3.1. Package IpPhoneService

Ce package permet d’étendre les fonctionnalités du téléphone IP. En effet, il a pour rôle
d’offrir une panoplie de services mis à la disposition de l’utilisateur du téléphone et de
profiter des capacités et des services que peuvent intégrer les téléphones de la gamme Cisco
7900.
Parmi les services offerts par ce package on cite :
La possibilité d’effectuer une recherche en se connectant au serveur de la base de
données, consulter le répertoire de la société et d’y extraire les numéros de téléphone de ces
clients.
La possibilité de se connecter au site de Cisco et d’afficher l’actualité dans le monde des
réseaux ainsi que les nouveaux produits lancés sur le marché ou encore de consulter
l’actualité à partir du site de CNN.
Le fonctionnement du service de News utilise une connexion au serveur de Cisco et de CNN
pour y extraire l’information demandée sous format RSS (voir Annexe) et d’adapter ce format
au téléphone IP Cisco pour pouvoir l’afficher sur l’écran.
La première étape de fonctionnement de ce service est de consulter le serveur CallManager
pour y extraire l’adresse du serveur d’applications CTI et d’extraire ainsi les services mis à la
disposition de l’utilisateur, ce service est accessible par les IP Phones Cisco une fois que
l’adresse du serveur d’application est configuré comme lien des services de téléphonie (voir
Annexe) au niveau CallManager.
La figure 9 présente le diagramme de cas d’utilisation de ce package ainsi que les différents
acteurs qui agissent directement sur le système.

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 téléphone IP. En effet, elle a
pour objectif d’informer le poste IP qu’un appel lui est destiné et d’afficher sur son écran les
informations de son interlocuteur.
Dans sa spécification pour JTAPI, Cisco a implémenté une fonction prédéfinie qui permet de
forcer un téléphone IP Cisco à afficher des données sous format XLM interprétable par le
poste IP.
Une fois qu’on a récupéré le numéro de l’interlocuteur, notre application extrait les
informations concernant le client depuis le serveur de la base de données et envoie le résultat
retourné par ce serveur au poste IP concerné.

Cette partie force le terminal IP à afficher des données sur son écran sans pour autant avoir
besoin de l’intervention de l’utilisateur.
Récupération du
numéros de l'interlocuteur
IpPhone Cisco
CallManager
Affichage des «uses» Récupération du

données
numeros de poste appelé
«uses»
Récuperer les
informations «uses»
Récuperations des
informations de la partie
appelante
Serveur d'applications CTI
«extends» «extends»
Récuperer les Récuperer les

informations du client informations de la société
«uses» «uses»
Interrogation de la
Base de donnée
Serveur Base de données

Figure 10 Package PushToPhone

II.4.3.3. Package Database
Ce package traduit les éventuelles requêtes susceptibles d’être lancées par l’utilisateur final
afin d’interagir avec la base de données utilisateur.
Parmi ces requêtes on retrouve:
La possibilité d’ajouter une nouvelle entrée à la base de données.
Lancer une recherche par nom et prénom pour les clients ou simplement par nom de société
dans la base de données et afficher le résultat sur l’écran que ce soit celui d’un PC ou d’un
poste IP.

Effectuer une mise à jour des informations relatives à un client ou d’une société.

Figure 11 Package PushToPhone

II.4.3.4. Package GUICrm
Ce package se résume en une interface graphique interactive mise à la disposition de
l’utilisateur final afin de faciliter l’interaction avec le serveur de la base de données et c’est
cette interface qui nous servira à afficher les données relatives à l’interlocuteur lors d’arrivée
d’un appel.

Figure 12 Package GuiCrm


II.4.3.5. Package Telephony
Le package Telephony est le cœur même de notre projet, en effet ce composant permet
d’assurer la connexion au serveur CallManager et de placer ainsi un observateur sur l’état de
la ligne téléphonique ainsi que sur l’état de connexion des postes IP.
Dans un premier temps, notre package s’authentifie auprès du CallManager afin de lancer un
observateur sur les appels entrants. Ainsi lors d’un appel entrant, ce package sera alerté par le
CallManager que l’état de la connexion du poste concerné par la transaction téléphonique
passe du mode Idle en mode Active.
Une fois alertée, ce composant récupère le numéro de la partie appelante ainsi que le poste de
la partie appelée et le renvoi au package PushToPhone ainsi que le package GUICrm
Figure 13 Package Telephony

II.5.Diagrammes de classes
Les diagrammes de classes modélisent les interactions et les hiérarchies entre les classes les plus
importantes conçues pour la réalisation de ce service. Pour modéliser les différentes classes du
système final. Nous avons regroupé les principales classes en des paquetages selon leurs rôles.
Dans ce qui suit nous représentons le Diagramme de classes constituants chaque paquetage. Nous
nous sommes appuyés sur le formalisme UML pour les représenter.

II.5.1. Diagramme de classe du Client Crm
Le diagramme suivant présente les interactions entre les différentes classes utilisées lors du
développement de la partie Client Crm.

CallerInfoServer
-CTIServer
-DestNumber NumberFind
AddToDb
-IdJTAPI -NumberOrigin
-PassJTAPI +FindfirmInformationByNumber()
+AddfirmInformation()
+ProviderChangeEvent() +FindCustumerInformationbyNumber()
+AddCustumerInformation()
+CallChangeEvent() +LoadJDBCDriver()
+LoadJDBCDriver()
+GetActiveCallPartyNumbers() +Connection()
+Connection()
+GetCallerInfoServer()
Main
-Numbers
-GetCallerInfoServer
-Cmd
+CallerInfoServer()
+GetCallerInforServer() GuiCrm
+Runtime.getRuntime().exec()() -OrigNumber
-JPannel1
-JPannel2
-JPannel3
-JPannel4
+NumberFind()
+AddToDb()
+Affiche()
+updateDb()
Affiche
updateDb +DisplayfirmInformation()
+DiplayCustumerInformation()
+LoadJDBCDriver()
+UpdatefirmInformation()
+Connection()
+UpdateCustumerInformation()
+LoadJDBCDriver()
+Connection()

Figure 14 Diagramme de classe du Client Crm


II.5.1.1. La Classe CallerInfoServer
La connexion au serveur CallManager est impérative afin de récupérer le numéro de la partie
appelante, ainsi que pour l’interroger sur l’état de la connexion. Afin de subvenir à ce besoin,
la méthode Provider permet d’initier l’adresse du CallManager en passant comme paramètre
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 méthode
GetCallerInfoServer nous sert d’observateur sur l’état de la ligne et si un appel entrant est
détecté elle nous informe du changement d’état de la connexion en récupérant le numéro des
deux parties impliquées lors du processus d’appel. Ces paramètres sont ensuite enregistré
dans les variables OrigNumber pour le numéro d’origine et DestNumber pour le numéro de
destination.

II.5.1.2. La classe GuiCrm
Cette classe hérite des classes NumberFind, AddToDb, Affiche et updateDb. Elle est sous
forme d’interface graphique. Elle renferme les fonctions que peut utiliser la personne final
afin d’interagir avec le serveur de la base de données et elle permet l’affichage des données de
l’interlocuteur lors de l’arrivée d’un appel.
Cette classe renferme les interfaces JPannel1, JPannel2, Jpannel3, JPannel4 et JPannel5
qui sont sous formes d’interface graphiques, chacune d’elles offre la possibilité d’interagir
avec le serveur de la base de données selon les besoins de l’utilisateur qui parmi celleci on
retrouve : Ajouter, modifier ou rechercher des informations concernant un client ou une
société, ces fonctions sont intégrées dans les interfaces Jpannel1, JPannel2, JPannel3 et
JPannel4.
Quant à l’interface JPannel5, elle prend en charge l’affichage des données de la partie
appelante en récupérant le numéros de téléphone et en exécutant la méthode Numberfind ().

II.5.1.3. La classe updateDb

Cette classe prend comme arguments d’entrée les données à mettre à jour dans la base de
données et elle modifie les informations concernant le client ou la société.


II.5.1.4. La classe NumberFind

Cette classe prend en entrée un numéro de téléphone et parcourt l’ensemble de la base de
données afin de trouver une similitude avec les numéros de téléphones déjà enregistrés, que
ce soit ceux d’un client ou d’une société.

II.5.1.5. La classe Affiche

Cette classe prend comme paramètre d’entrée le nom et prénom d’un client ou le nom d’une
société et retourne les informations correspondantes depuis la base de données.

II.5.1.6. La classe AddToDb

Cette classe permet à l’utilisateur d’ajouter de nouvelles entrées dans la base de données que
ce soit des informations relatives à une société ou à un client.

II.5.1.7. La classe main

Cette classe assure la fonction de lancer l’ensemble des classes citées cidessus, elle hérite des
classes CallerInfoServer et GUICrm.
Dans un premier temps elle fait appel à la classe CallerInfoServer, en utilisant comme
paramètre CTIServer qui est l’adresse du serveur CallManager, IdJtapi qui représente le
login et PassJtapi qui est le mot de passe ainsi que DestNumbr qui représente le poste à
observer par l’application. Une fois ces paramètres chargés et la connexion au serveur
CallManager est établi, si un appel arrive et a comme destination le poste observé, le numéro
de téléphone est passé comme paramètre à l’interface GUICrm qui s’encharge de lancer la
classe NumberFind et ainsi de récupérer les informations de l’appelant.

II.5.2. Diagramme de classe du serveur d’application CTI
CallerInfoServer
-CTIServer
-DestNumber
-IdJTAPI
-PassJTAPI
+ProviderChangeEvent() findnum
PushXml
+CallChangeEvent()
+GetActiveCallPartyNumbers() -firmName -NumberOrigine
+GetCallerInfoServer() -FirmAddress -XML
-FirmActivities +LoadJDBCDriver()
-Firmphone +Connection()
-Fcomments
-Cname
-Cfname
-Cphone
-Ccomments
-CustumerContact
-CustumerComment
-NumbersOrigin
-NumbersDest
-XML
+termTo.sendData()()
+CalleInfoServer()
+getCallerInfoServer()
FindFirm FindCustumer
-FirmName -Custumername
-CustumerLastname
+LoadJDBC()
+LoadJDBCDriver()
+Connection()
+Connection()
Search
DirectoryFirm
Index
+LoadJDBC()
+Connection()
MenuDirectory
DirectoryCustumer
+LoadJDBCDriver()
+Connection()

Figure 15 Diagramme de classe du serveur d'application CTI

Le serveur d’application CTI fournit le même service que celui du ClientCrm à l’exception
prés que l’affichage des informations de l’interlocuteur seront affichées à l’écran du téléphone
IP de l’utilisateur du service. Il offre également d’autres services qui seront accessibles à
partir d’un poste téléphonique IP Cisco.

II.5.2.1. La classe PushXML

Cette classe est équivalente à la classe main du Client Crm, elle hérite de la classe
CallerInfoSever et findnum.
Elle récupère le numéro de téléphone à partir de la classe CallerInfoServer, et fait appel à la
classe Findnum en lui passant comme argument NumberOrigin ensuite elle récupère la
variable XML qui va être affiché à l’écran du téléphone IP en utilisant la fonction déjà
prédéfinie par Cisco « SendData ».

II.5.2.2. La classe Findnum

Cette classe s’occupe de parcourir la base de données et d’y extraire les informations d’un
client (agent de la société) ou celle d’une société selon le numéro de téléphone passé en
argument. Une fois ces informations récupérées, elle les stocke dans la variable XML en
utilisant les balises XML selon la spécification de Cisco.

II.5.2.3. La classe Index

Cette classe définit une liste de quatre choix : Directory, Find Custumer, CNN’s News et
Cisco’s News. Elle hérite des classes Search et MenuDirectory.
Le choix des éléments CNN’s News et Cisco’s News crée une nouvelle instance de la classe
en index. En ce sens, le choix du service News permet de ce connecter à un serveur extérieur
et d’afficher les informations demandées à l’écran 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.


II.5.2.4. La Classe MenuDirectory

Cette classe hérite des classes DirectoryFirm et DirectoryCustumer. Elle permet, selon le
choix de l’utilisateur d’afficher le répertoire par Société ou par Client en faisant appel aux
classes DirectoryFirm et DirectoryCustumer.
Ces classes se chargent d’extraire les informations de la base de données et de les afficher à
l’écran du téléphone. Une fois l’affichage effectué, ces deux classes offrent la possibilité à
l’utilisateur de composer le numéro souhaité extrait de la base de données depuis la touche Dial
affichée à l’écran.

II.5.2.5. La Classe Search

Cette classe hérite des classes FindCustumer et FindFirm. Elle est équivalente à la classe
MenuDirectory à l’exception qu’elle fait appel aux classes FindCustumer et FindFirm en
utilisant comme argument d’entrée CustumerName et CustumerLastname pour le cas de
FindCustumer et Firmname pour le cas de FindFirm. Les classes FindCustumer et
FindFirm se chargent après de parcourir la base de données et d’afficher le résultat à l’écran
du téléphone IP.
II.6.Digrammes de séquences
Les diagrammes de séquence permettent de décrire les interactions entre les objets pour
chaque cas d'utilisation. Dans notre cas, ces diagrammes sont liés aux diagrammes de cas
d’utilisation représentés auparavant.
Pour illustrer la différence entre nos deux clients : le client CRM et le cas du serveur
d’application CTI qui prend en charge l’affichage du service sur les postes IP de l’utilisateur.
Nous allons assigner à chaque type de client le diagramme de séquence correspondant.

II.6.1. Diagramme de séquences du serveur d’application CTI

Ce scénario représente les fonctionnalités de base du serveur d’application CTI à savoir
l’affichage des données de l’interlocuteur sur le IP Phone Cisco ainsi que l’affichage du
service de téléphonie IP intégrer dans notre solution.

Figure 16 Diagramme de séquences du serveur d'application CTI


II.6.2. Digramme de séquences du client CRM

Ce scénario fait intervenir une autre entité ; le client CRM. En effet dans ce composant l’affichage
est effectué sur un PC intégrant la machine virtuelle Java. Le diagramme de séquences suivant
représente la succession chronologique des différentes étapes intervenant dans la réalisation de la
solution proposée pour le Client CRM.

Figure 17 Diagramme de séquences du Client Crm
II.7.Conclusion

Dans ce chapitre, nous avons présenté les différents diagrammes de cas d’utilisation et de
classes de notre application pour enfin aboutir à l’établissement des diagrammes de
séquences.
Dans le chapitre suivant nous allons expliquer les choix utilisés pour l’implémentation de la
solution adoptée et décrire la démarche de la réalisation.

Solution et implémentation

Chapitre 3 :
III.Solution et implémentation

III.1.Introduction
Après avoir déterminé les besoins de l’application et conçu les différentes parties de ce
service, nous sommes passés à la réalisation de la solution conçue. Mais avant tout, nous
présentons les outils utilisés pour le développement du service de téléphonie IP ainsi que de
montée de fiche client.
III.2.Environnement et langage de programmation
Le choix du langage de programmation est un point crucial pour tout projet de développement
puisque il faut que ce dernier puisse subvenir à nos besoins.
Parmi les APIs de téléphonie disponible, on cite le JTAPI qui est une implémentation de Sun
utilisant le langage Java et Tapi, étant développée à l’origine par Intel et Microsoft comme
interface de développement d’application CTI pour les systèmes d’exploitation Windows.
Ces deux APIs sont les plus couramment utilisées et constituent la clé pour toute application
CTI développée dans une plateforme Cisco intégrant le CallManager, qui offre la possibilité
de communiquer avec ces applications à travers la couche TAPI. Cependant le choix reste
restreint à l’utilisation de TAPI et JTAPI. Si on examine de près ces deux technologies, on
distingue des avantages qu’offre JTAPI par rapport à TAPI, parmi lesquelles la richesse de la
bibliothèque implémentée par Cisco pour le JTAPI ainsi que la simplicité de l’implémentation
de cette API.
Nous avons opté pour Java, en raison de la simplicité de l’API JTAPI évoquées
précédemment mais aussi, parce que ce langage est le plus utilisé dans le domaine du
développement des services. Surcroît, la plupart des API disponibles sur Internet sont des API
Java.
Java est un langage de programmation de quatrième génération développé par Sun. Il doit sa
popularité croissante à une caractéristique majeure : sa portabilité. En effet, contrairement aux
langages classiques dont le code doit être compilé en fonction de la plateforme pour laquelle
ils sont prévus, le code Java est compilé vers un état intermédiaire. Le programme résultant
doit être exécuté via une machine virtuelle JVM (Java Virtual Machine). La machine virtuelle
quant à elle est liée à la plateforme utilisée, néanmoins à l’heure actuelle, de très nombreux
systèmes sont supportés tels que les PC tournant sous Windows, les Macintosh, etc. Il existe
même des JVM allégées pour les PDA (Personnal Digital Assistant) ou certains téléphones
portables. Grâce à cette technique, un programme ne doit être compilé qu’une seule fois, et
peut ensuite être utilisé sur n’importe quelle version de la JVM.
Traditionnellement, les langages interprétés tels que Java sont moins rapides que leurs
concurrents compilés, mais le développement 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 l’architecture logicielle
III.3.1. Le package JTAPI
Le Jtapi renferme un ensemble de packages java. Chaque package fournit un service de
téléphonie bien particulier pour les applications de couplage téléphonie informatique. Parmi
ces packages on retrouve javax.telephony.callcontroll qui renferme l’aspect contrôle et
traitement d’appel à savoir initier un appel, répondre à un appel.
Cette partie est essentielle pour notre application puisque elle sert à s’interconnecter avec le
CallManager pour échanger les informations relatives à un terminal tout en s’intégrant avec la
spécification de Cisco. Afin de répondre aux besoins essentiels de notre application, il est
nécessaire d’introduire le modèle de Jtapi pour modéliser le processus de communication
entre la parie responsable du couplage téléphonie informatique avec le CallManager.

III.3.1.1. Modèle d’appel de la téléphonie Java
Le modèle d’appel englobe un ensemble d’objets java. Chaque modèle d’appel représente à la
fois une entité physique (appareil téléphonique) ou logique (une connexion) dans le monde de
la téléphonie. L’objectif du modèle d’appel est de décrire les appels téléphonique et les points
terminaux impliqués lors d’un appel téléphonique [5].
Le diagramme cidessous illustre le modèle d’appel de Jtapi et les différentes entités qui le
composent.

Figure 18 Modèle d’appel Jtapi [5]

La partie qui va suivre détaillera les principaux acteurs lors du processus d’appel téléphonique
entre deux terminaux utilisant l’API Jtapi.

III.3.1.1.1. Provider
Un provider représente l’entité logicielle d’un central téléphonique avec ces interfaces et un
système de téléphonie sousjacent 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 détermine la
validité de ces diverses actions possibles. Détaillons quelque peu ces différents é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 méthodes du provider sont incorrectes lorsqu’il
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.
SUTDOWN : Cet état indique qu'un provider n'est plus disponible à une utilisation. La
plupart des méthodes du provider sont incorrectes lorsqu’il se trouve dans cet état
Le diagramme suivant montre les transitions d'état permises pour le provider défini par le
core package :
Figure 19 Transition d’état du Provider

III.3.1.1.2. Call
Un objet call représente un appel téléphonique.
III.3.1.1.2.1. Etats d’un call

Un call peut se trouver dans trois états : Call.IDLE, Call.ACTIVE ou Call.INVALID.
Parmi les divers états du cycle de vie d’un 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 associées se trouvent dans cet état.
INVALID : C'est l'état final pour tout call. Dans cet état, un call n’a plus aucune
connexion. Mettons l’accent sur le fait, qu’un call se trouvant dans cet état, ne peut sans
aucune façon être utilisé pour une action future.

Figure 20 Diagramme de transition d’un call

III.3.1.1.3. Connection
Une connexion représente un lien (une association) entre un call et une adresse. Le but d'une
connexion est de décrire le rapport entre un call et une adresse. Une connexion existe si une
adresse particulière représente une partie d’un appel téléphonique. Chaque connexion a un
état qui décrit l’état actuel du rapport entre le call et l'adresse.
III.3.1.1.4. Objets address et terminal
Un objet d'adresse représente le point final logique d'un appel téléphonique. Et un terminal
représente un point final physique (matériel) relié au réseau téléphonique. 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 durée de vie connaître de nouveaux terminaux et de
nouvelles adresses. Ces nouveaux objets représentent des adresses et des terminaux en dehors
du domaine du provider et sont désignés comme distants afin de les différencier des locaux.
Par exemple, si le domaine du provider est un PBX, le provider connaîtra d’abord toutes les
adresses et tous les terminaux dans ce PBX. Toutes les adresses et tous les terminaux qu'il
connaît ultérieurement se trouvent en dehors de ce PBX [5].
Dans beaucoup de cas, un poste téléphonique (représenté par un objet terminal) a seulement
un numéro de téléphone (représenté par un objet d'adresse) associé à ce dernier. Dans le cas
de notre application, l’objectif est de placer un « Listener » sur une adresse bien particulière
afin d’être avertis des différents événements qui sont en liaison avec cette adresse à savoir
l’arrivée d’un appel qui sera géré par le provider CallManager.
La première chose à faire est de se connecter à l'interface JTAPI du Call Manager une fois la
connexion établie nombre d'événements JTAPI pourront être traités par notre application
suivant qu'on développera le code nécessaire la figure 21 illustre la première étape de
lancement du moteur Jtapi et de l’obtention d’un provider.

Figure 21 Initialisation du moteur JTAPI et connexion au CallManager

III.3.2. L’API Swing :
Swing constitue une innovation apparue dans JDK1.1 en tant qu'extension de ce dernier et en
tant que partie intégrante de Java 2 SDK. Swing est la seconde bibliothèque de classes (la
première étant AWT) permettant de créer et de gérer des interfaces graphiques. Les méthodes
utilisées pour construire une interface Swing sont sensiblement les mêmes que celles de AWT
soit [6] :
Création d'un cadre ou contenant
Placer des composants dans ce contenant
Effectuer la mise en page de ces composants dans le contenant
gérer les événements et actions posées par l'utilisateur
III.3.3. L’API « JDBC »

L'API JDBC permet aux applications java d’accéder par le biais d'une interface commune à
des sources de donnés pour lesquelles il existe des pilotes JDBC. Normalement, il s'agit d'une
base de donnés relationnelle, et des pilotes JDBC sont disponibles pour tous les systèmes
connus de bases de données. [4].
Nous avons utilisé cette API pour permettre aux classes Java de communiquer avec les bases
de donnés.
III.3.4. Les serveurs

Les JSP et les servlets nécessitent un serveur pour fonctionner nommé souvent moteur de
servlets ou moteur de JSP. Le serveur le plus connu est le serveur Tomcat [10]. C’est un
serveur Open Source qui agit comme un conteneur de servlets. Il fait partie du projet Jakarta,
au sein de la fondation Apache. Tomcat implémente les spécifications des servlets et des JSP
de Sun Microsystems. [7]
III.3.5. Le système de gestion des bases de donnés :
Le système de gestion des bases de donnés utilisé dans ce projet est MySQL, il s’agit d’un
SGBD libre et gratuit. Il est très utilisé et très populaire. MySQL est un serveur de bases de
données relationnelles SQL, très rapide, multithread et multiutilisateur.
III.3.6. Les JSP

L’interface utilisateur est composée de plusieurs pages web qui vont être générées
dynamiquement selon les requêtes de l’utilisateur. Pour concevoir une telle interface, nous
avons eu recours aux pages JSP ou « Java Server Pages ». C’est une technologie basée sur
Java qui permet aux développeurs de générer dynamiquement du code HTML, XML ou tout
autre type de page Web [4].
Comme nous utilisons une plateforme java pour développer ce service, ce choix se révèlera
très bénéfique puisque nous pouvons utiliser les différentes méthodes des classes déjà
développées et compilées sans avoir, à chaque fois, à réécrire ces méthodes.
L’avantage des JSP par rapport à d’autres scripts, qui s’exécutent du côté serveur, est que le
temps du traitement est moins important, cela est dû au fait que ces scripts sont compilés une
seule fois, et on n’aura pas besoin de les recompiler à chaque accès au service.
Le principe de fonctionnement des JSP ressemble à celui des servlets, mais il présente
quelques différences, comme la possibilité de les intégrer dans des pages HTML et de définir
des liens entre eux. Un exemple d’utilisation de cette technologie dans ce projet est la
transmission du numéro de téléphone de l’interlocuteur d’une page à une autre.
III.3.7. XML

Cisco met à la disposition des développeurs de service de téléphonie IP, une API basé sur le
XML et qui permet d’afficher des données sur les IP Phones Cisco de la gamme 7900. Ces
services sont généralement utilisés à l’aide du protocole HTTP. Les téléphones se comportent
donc comme une sorte de navigateur web, l’exemple suivant illustre l’affichage du menu en
utilisant la spécification Cisco pour le XML.

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

III.4.Les interfaces
Comme cela a déjà été évoqué, le service développé présente deux approches d’utilisation :
Une approche pour les utilisateurs de Pc et une approche pour les IP Phones Cisco.
Nous allons essayer dans cette partie de présenter les principales interfaces auxquelles un
utilisateur est confronté selon les approches citées cidessus.

III.4.1. Les interfaces utilisées 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 téléphonie IP
La première interface mise à la disposition de l’utilisateur renferme différents menus qui
permettent l’interaction avec le serveur de base de données et la consultation des bulletins
d’informations téléchargés à partir du site Cisco et CNN.
La figure 22 illustre le menu évoqué cidessus :

Figure 24 Page d’accueil

III.4.2. Les interfaces graphiques
Les interfaces Swing mises à la disposition de l’utilisateur constituent à la fois un moyen
d’accès à la base de données afin d’effectuer l’enregistrement des clients et aussi une interface
qui servira à l’affichage des données de l’interlocuteur lors de la réception d’un appel.
La figure 25 illustre le modèle adopté pour ces interfaces swings


Figure 25 Interfaces Swing

Les différents menus ; Add custumer et Add Firm permettent à l’utilisateur d’ajouter de
nouvelles entrées au serveur de base de données tandis que les champs Find Firm et Find
Custumer offrent la possibilité de rechercher un client soit par nom de société ou par nom et
prénom de l’agent ainsi que la possibilité d’effectuer une mise à jour concernant les
informations des clients. Les figures 26 à 29 illustrent un cas d’exemple d’utilisation de ces
interfaces.


Figure 26 Ajout d’un agent d’une société

Figure 27 Rechercher un utilisateur

Figure 28 Ajout d’informations d’une société dans notre base de données

Figure 29 Recherche d’informations d’une société
III.4.3. Lancement du Service
Cas du client CRM
La figure 30 montre un aperçu de l’exécution du service en optant pour l’interface Swing. Un
client de la société dont le numéro est « 1161 » initie un appel au poste « 1999 » sur lequel un
observateur a été placé afin de récupérer le numéro de l’interlocuteur.

Figure 30 Affichage des coordonnées de l’interlocuteur

Cas du IP Phone
Cette partie renferme l’aspect CTI. En effet, pour pouvoir extraire le numéro de téléphone de
l’interlocuteur et « pousser » l’affichage des données ainsi récupérées à partir de la base de
données, notre application fait appel au serveur d’application CTI qui est responsable
d’effectuer cette tache.
La figure 31 illustre le cas de réception d’un appel avec un numéro de téléphone enregistré
dans notre base de données tandis que la figure 32 évoque le cas où le numéro est inconnu
dans notre base.

Figure 31 Affichage des données à l'écran du poste IP

Figure 32 Numéro non reconnu dans la base de données

III.5.Conclusion
A l’occasion de ce chapitre nous avons traité la méthodologie adoptée afin de réaliser notre
application.
Une méthodologie qui a mis en oeuvre toute une panoplie assez complexe d’outils. L’objectif
de ce projet est de simplifier le déploiement de solutions CTI dans un réseau de téléphonie IP.
Le serveur d’application CTI ainsi que le client CRM constituent le cœur de notre application.

Conclusion Générale
Conclusion et perspective :

La gestion des données client permet de fournir une gestion simple et efficace des
informations personnelles de la partie appelante. Ce processus de gestion d’appel utilise les
identifiants de la partie appelante ou appelé pour récupérer à partir d’une base de données les
informations relatives au client et l’associer à l’appel pendant sa durée de vie. Cela permet à
l'appel d'être traité de manière plus efficace et c’est exactement dans ce but ou intervient notre
application.

Au cours de projet, nous nous sommes intéréssé à l’élaboration des différents points
qui englobent le déploiement et l’intégration de solutions de couplage téléphonie informatique
dans un environnement logicielle Cisco, ainsi que le développement de services de téléphonie
IP. En premier lieu, nous avons posé la problématique du projet à savoir les objectifs à
atteindre ou encore les différentes approches qui peuvent être utiliser pour notre application.
Ensuite, nous avons conçu et développé un modèle capable de répondre à nos besoins. Enfin,
nous sommes passés à l’étape test et implémentation, en effet à ce stade là nous pouvons
affirmer que notre application a répondu d’une manière impressionnante aux attentes et aux
objectifs fixés préalablement.

En effet, l’application a été testée avec succès sur une plateforme de Téléphonie IP
Cisco intégrant le CallManager.
Loin de se contenter du développement d’une application réservée unique aux utilisateurs de
PC, nous avons étendu notre étude en intégrant la partie CTI au IP Phone Cisco ainsi que le
développement de services de téléphonie IP.

Les fonctions que peut offrir le CTI sont particulièrement extensibles et comme
perspectives à ce projet, on pourra intégrer le concept de routage de fiche client d’un utilisateur à
un autres ou encore intégrer dans cette dernière les différents concepts d’un SoftPhone à savoir
composer un appel ou répondre à un appel.

L’élaboration de ce projet m’a permit d’approfondir et de concrétiser mes
connaissances en informatique et surtout dans le domaine du développement des applications
de téléphonie. Néanmoins, ces connaissances, ne suffisent pas pour développer des services
de téléphonie à valeurs ajoutés. Il m’a donc été donné d’apprendre au cour de ce stage qu’il
Conclusion Générale
faut joindre le monde informatique au monde des télécommunications pour pouvoir créer de
nouveaux services.

Annexe
Annexe A : Le couplage Téléphonie Informatique

1. Définition du CTI :
Le CTI, acronyme pour Computer Telephony Integration, soit Couplage Téléphonie
Informatique est une façon d'intégrer voix et données dans une même application ou encore
d’intégrer les fonctionnalités téléphoniques 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 systèmes de PBX.
En 1990 la notion de « personnel computer technology » ou ordinateur personnel a été
intégrée 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 Télécommunication (Internationnal Telecommunication Union) a
spécifié les applications de télécoms pour les Commutateurs et les ordinateurs :
Le TASC (Telecommunication Application for Switch and Computers) en 1994.
Ces spécifications incluent un aperçu général sur la norme TASC, l’architecture fonctionnelle
et les services associés.

TTC comité de la technologie de télécommunication (Telecommunication Technology
Comittee) du japon a spécifié l’interface entre les PBXs et les applications informatiques cette
spécification concorde avec la norme SCAI (SwitchtoComputer Application Interface). [8]

ECMA l’association européenne de constructeurs informatique (European Computer
Manufacters Association) supervise le développement du standard CSTA (Computer
Supported Telecommunication Application) depuis 1988, ce standard spécifie
l’environnement de commande entre commutateur et application informatique. [8]

Intel et Microsoft ont développé en 1993 la spécification TAPI (Telephony Application
Programming Interface) pour l’interface de développement d’application CTI pour les
systèmes d’exploitation Windows. [8]

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é développé pour gérer les appels téléphoniques en intégrant l’aspect intelligent de
l’informatique. Par exemple, le CTI fournit une meilleure interface utilisateur que l’interface
traditionnelle des téléphones qui offre un accès limité à partir du pavé numérique. Plus encore
le CTI offre des plateformes et des fonctionnalités qui permettent de piloter et invoquer des
services téléphoniques à valeurs ajoutées d’une manière plus efficace et plus rapide.
Les fonctions CTI peuvent être classer en trois classes [8] :
Contrôle d’appel ou (Call control functions).
Traitement de données Media (Media processing).
3.1. Le contrôle d’appel

La control d’appel représente la partie la plus importante dans le concept CTI, elle invoque de
manière générale la supervision des appels téléphoniques et le contrôle des systèmes de
téléphonie qui interagit avec les appels. Parmi les services de contrôle d’appel on retrouve le
concept d’initiation d’appel, affectation d’une connexion à un appel, routage automatique des
appels ou encore la détection de frappe du pavé numérique du téléphone [8].
3.2. Traitement de données Média

Cet aspect englobe des fonctions liées au traitement de données parmi lesquelles on cite :
Traitement de la voix et des données data à savoir le Fax ou encore l’enregistrement de
messages vocaux, envoi et réception de Fax, génération, et détection de tonalité DMTF (Dual
tone multifrequency).
4. Composants CTI

Le CTI comporte trois composants : le «Switchtohost interface», l’API et le « CTI ressource
architecture ». Le «Switchtohost interface» est l’interface du type CSTA (Computer
Supported Telephony Applications) ou SCAI (SwitchtoComputer Application Interface) qui
fournit la connexion entre le PABX (ou IPPBX) et le serveur CTI. L’API permet à un
développeur de créer une nouvelle fonction ou un service pour le CTI. Le « CTI ressource
Annexe
architecture » est le gestionnaire de la téléphonie et des ressources dans le système telle que la
reconnaissance de la voix, la figure 33 illustre les différents composants évoqués dans
l’architecture CTI. [8]

Figure 33 Architecture globale du CTI

4.1. SwitchtoHost interface (Lien CTI)
Le premier composant de l’architecture CTI est le Switchtohost interface, ce lien permet de
fournir la connexion entre le commutateur et le serveur CTI et ainsi d’assurer la
communication entre ces deux composants. Plus traditionnellement les commutateurs
représentaient des systèmes fermés qui ne permettaient pas l’intégration de services et ne
fournissaient aucune interface de sortis pour un contrôle externe du système .Dans les
applications de téléphonies, le commutateur est contrôlé par le serveur CTI exécutant les
applications de téléphonie. Cette interface est aussi appelée lien CTI qui est totalement
différente de l’interface de la ligne téléphonique. [9]
Connecté au commutateur via le lien CTI, le serveur CTI fournit l’environnement de
téléphonie pour les développeurs d’applications de téléphonie à 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é proposées pour le lien CTI:
Le CSTA (Computer Supported Telecommunications Application) et SCAI (Switchto
Computer Application Interface).
Annexe
Le développement du CSTA a été initié par l’association ECMA tant dis que le SCAI est la
version développée par l’ANSI (American National Standards Institute) qui repose sur les
mêmes concepts que celui du CSTA mais il est plus complexe quant à son intégration et
déploiement dans une architecture de développement d’application CTI [9].

4.2. Le Standard CSTA
Ce protocole décrit les types de données échangées au niveau de la couche Application.
Le CSTA spécifie les interfaces d’applications ainsi que les protocoles à utiliser pour
superviser et contrôler les appels et les terminaux d’un réseau de communication. En d’autres
termes le CSTA consiste en une interface CTI qui permet de fournir l’accès aux services de
communications ainsi que le développement d’applications basé sur différents API
téléphonique [9].
La plupart des constructeurs de PBX ont adopté le CSTA comme leur standard, il représente
la base de la plupart des APIs à savoir TSAPI ou TAPI.
4.2.1. Le protocole CSTA
Le protocole CSTA spécifie l’ensemble des commandes et la structure des données pour la
communication entre le commutateur et l’hôte. A travers ce protocole, l’hôte accède aux
services de téléphonie CSTA intégrés 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 téléphone. Cela est possible grâce à des interfaces de
programmation d’applications (Application Programming Interface API) standardisées.
Les API sont des interfaces qui offrent à un développeur logiciel de créer de nouvelles
applications de télécommunications, se sont des passerelles logicielle qui permettent de
discuter avec du matériel téléphonie, cette partie a pour but de décrire les trois principaux API
qui sont les plus utilisées pour le développement d’applications de téléphonie.[9]
TAPI : Acronyme pour Telephony Application Programming Interface, elle a été développée
par Microsoft pour les machines fonctionnant avec un système d’exploitation Windows.
TSAPI : (Telephony Services API) Développée par Novell et Lucent Technologies
Annexe
JTAPI : (Java Telephony) Développée par SunMicrosysteme, cette API fournit une portabilité
et une approche orienté objet pour les applications téléphonique développées en Java.
4.4. Architecture des ressources CTI

Dans un système CTI, un ou plusieurs composants Hardware sont necessaire pour
implémenter les fonctions du CTI. Ces ressources matérielles incluent analog/digital trunk
interface, traitement de la voix, traitement des données fax, reconnaissance de voix …
Le « CTI ressource architecture » est typiquement équivalent à un système ouvert qui
supporte toute intégration de nouvelles ressources CTI fabriquées par différents constructeurs.
Les standards pour « CTI ressource architecture » incluent :
MultiVendor Integration Protocol (MVIP) –Le protocole MVIP fait partie de la famille des
standards open source qui supportent l’intégration de traitement de la voix, traitement de
données Fax/Data et plusieurs technologies informatique qui requièrent la connexion au
réseau téléphonique soit un Réseau PSTN ou IP pour la VOIP. Le MVIP offre une approche
d’intégration entre le PC et le PBX ainsi que d'autres systèmes de commutation de téléphone.
Signaling Computing System Architecture (SCSA) –SCSA est une architecture complète et
ouverte pour l’intégration des fonctions de la téléphonie informatique (CT computer
Telephony). Ce protocole contient non seulement le modèle hardware qui spécifie le Bus CTI
pour la c ommutation en temps réel des données mais il intègre aussi le modèle logiciel qui
identifie les services pour le traitement de média et le contrôle d’appel. [9]
5. Les applications CTI
5.1. Le service vocal interactif
Les serveurs vocaux donnent la possibilité à un utilisateur du téléphone de dialoguer avec le
système d'information de l'entreprise par :
• Accès aux données sous forme parlée
• Introduction de messages dans le système de l'entreprise via le serveur vocal sous forme
numérique (clavier) ou parlée Les applications classiques du serveur vocal sont les services de
transaction (réservations, télépaiement) et les services de consultation (horaires, comptes
bancaires, ...) ou encore de standard automatique.[9]

Annexe
5.2. L’Identification de l'appelant/Montée de fiche client

A chaque nouvel appel téléphonique, la 'fiche client monte' à l'écran de l'agent. Celuici gagne
du temps, il connaît tout de suite le nom de l'appelant et pourra accueillir son interlocuteur de
la façon la plus personnalisée 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 même de décrocher.
5.3. La messagerie unifié ou Unified Messaging
En outre, la messagerie unifiée évolue, depuis peu, vers le concept de communication unifiée.
Il ne s'agit plus alors seulement de regrouper des messages écrits et vocaux mais de réaliser
une synthèse complète entre ces médias 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 créer des règles de
routage tenant compte, par exemple, de son agenda ou de l'identité de chaque appelant. [8]
Annexe
Annexe B :

CallManager

La plateforme Cisco CallManager étend les fonctionnalités téléphoniques dans l’entreprise
aux équipements connectés sur le réseau de données tels que les téléphones IP, les
équipements de traitement de la voix, les passerelles VoIP et les applications multimédia. Les
services additionnels de data, voix et vidéo tels que la messagerie unifiée, la conférence
multimédia, le centre de contact collaboratif et les systèmes de réponse multimédia interactifs
interagissent avec la solution d’IP Téléphonie par l’intermédiaire des interfaces de
programmation ouverts (APIs) natifs de Cisco CallManager.
Cisco CallManager s’installe sur les serveurs de convergence de média de Cisco (MCSs) ainsi
que sur un choix de serveurs d’autres constructeurs (HP, IBM). Cisco CallManager est livré
avec une série d’applications et d’utilitaires qui comprend Cisco CallManager Attendant
Console, qui est un logiciel de poste opérateur pour PC, une application de conférence en
mode impromptu (adhoc), Bulk Administration Tool (BAT), CDR Analysis and Reporting
tool (CAR), RealTime Monitoring Tool (RTMT), Cisco CallManager AutoAttendant, qui
est un standard automatique simple et de petite capacité, Tool for Autoregistered Phones
Support (TAPS) et IP Manager Assistant (IPMA). [10]

Annexe
Annexe C :

1. Le format RSS
Format de syndication de contenu Web, basé sur le XML, qui permet d’indexer de façon
automatisée le contenu d’un site Web et de le mettre instantanément à disposition d’autres
sites. Le format RSS est en fait une manière de décrire le contenu d’un site Web (articles,
informations, événements) et plus généralement toute page qui présente un contenu mis à jour
chronologiquement. Il permet à des sites Web d’afficher automatiquement les derniers titres
parus sur un autre site. Créé à l’origine par Netscape, le format RSS est désormais utilisé
couramment pour partager du contenu entre sites Web [11].
RSS est l’acronyme 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 différentes versions [11].

2. Le langage XML

Extensible Markup Language (langage de balisage extensible), généralement abrégé XML, est
un standard du World Wide Web Consortium qui sert de base pour créer des langages de
balisage : c'est un « métalangage ». En ce sens, XML permet de définir un vocabulaire et une
grammaire associée sur base de règles formalisées. Il est suffisamment général pour que les
langages basés sur XML, appelés aussi dialectes XML, puissent être utilisés pour décrire
toutes sortes de donnés et de textes. Il s'agit donc partiellement d'un format de donnés.
L'extensibilité de XML est principalement assurée par la notion d'espace de nommage.
L'objectif initial de XML était de faciliter le partage de textes et d'informations structurées,
par exemple au travers d'Internet, en séparant le contenu du contenant. Il constitue une
simplification de SGML tout en continuant à assurer la portabilité des documents, notamment
grâce à l'intégration d'Unicode.

Bibliographie
Bibliographie

[1] www.onetechgroup.com

[2] CTI Applications Architecture and Design for CallManager 3.1 October, 2001 IP
Telephony Design Guide.

[3] http://uml.free.fr/indexcours.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/javaswing.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 McGrawHill Professional, Janvier 2000.

[10] John Alexander, Chris Pearce, Anne Smith, Delon Whetten, Cisco CallManager
Fundamentals Second Edition, Cisco Press, 22 Septembre 2005.


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

Développement et intégration de solutions CTI dans une plateforme Cisco.

Résumé
Le Couplage téléphonie informatique permet de coupler la téléphonie, principal canal de
communication client à distance, et le système informatique de l’entreprise, 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 réaliser une application CTI adapté à la fois au IP Phone Cisco et au PC, basée sur la
plateforme Cisco dont le CallManager constitue le noyau, mais le projet s’élargit encore
plus, afin de faire profiter l’utilisateur des avantages que fournit cette plateforme à savoir
la possibilité d’intégrer de nouveaux services de téléphonie IP accessible à partir du IP
Phone.
Pour cela, nous mettons en oeuvre un serveur d’applications CTI constituant une couche
architecturale à part entière pour les IP Phones, dans le but d’afficher les informations de
l’interlocuteur ainsi que les différents services de téléphonie IP développés pour les IP
Phone. Le Client CRM assura cette tache pour les utilisateurs de PC.
Mots clés
JTAPI, CTI, Cisco CallManager, Java, CRM, IP Phone, services de téléphonie IP.

Rapport de Projet de Fin D'études: Développement Et Intégration de Solutions CTI Dans Une Plateforme Cisco

Transféré par

Droits d'auteur :

Formats disponibles

Rapport de Projet de Fin D'études: Développement Et Intégration de Solutions CTI Dans Une Plateforme Cisco

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport de Projet de Fin D'études: Développement Et Intégration de Solutions CTI Dans Une Plateforme Cisco

Transféré par

Droits d'auteur :

Formats disponibles

Liste

Rapport de Projet de fin d’études

Module Ip Phone Service

Affichage des «uses» Récupération du

Récuperer les Récuperer les

Serveur Base de données

Vous aimerez peut-être aussi