You are on page 1of 118

Universit Cheikh Anta Diop de Dakar / Ecole Suprieure Polytechnique / Dpartement Gnie Informatique

BP 5085 Dakar Fann


Tl. (221) 824 13 88 - Fax (221) 825 55 94

Mise en place dun systme distribu de supervision, de taxation


et de gestion des quotas sur un rseau de tlphonie sur IP

Mmoire de fin de cycle ingnieur pour lobtention du D.I.T


(Diplme dIngnieur Technologue) en informatique

Prsent par
Mouhamad KAMARA

Sous la direction de
Bara THIAM (CFAO TECHNOLOGIES)
Samuel OUYA (Ecole Suprieure Polytechnique)

Anne acadmique 2002 - 2004


A

Mes parents Delphine Aminata TRAORE et Moussa KAMARA


Pour les efforts et sacrifices consentis tout au long de mes tudes.
Que Dieu les garde en vie et me donne la sagesse de mriter leur confiance

Mes frres et surs


Pour leur dvouement sans borne

Anne acadmique 2002 - 2004


Merci

o Bara THIAM (Responsable du Centre de dveloppement) et Mr Samuel OUYA


(Responsable du dpartement informatique de lESP) pour leur constante
disponibilit dans lencadrement de ce stage, pour tous leurs avis clairs.
o toute lquipe du Centre de Dveloppement, Joseph Ndiaga SENE, Thomas
RECHTER, Pape DETHIE, Mame Khary DIAGNE, Cyril NIANG, Bouna BADIANE, pour
leur accueil et leurs remarques constructives.
o Jol ROUX, Directeur Gnral de CFAO Technologies Sngal.
o Au personnel de CFAO Technologies Sngal.
o la communaut Internet qui maintient au quotidien toute une masse
dinformations si prcieuse dont nous nous sommes inspirs pour raliser ce
mmoire.
o Aux personnes qui ont contribu de prs ou de loin la construction de ce
mmoire, au bon droulement de mon stage et dont il est impossible de faire la
liste sans en oublier.

Anne acadmique 2002 - 2004


4

SOMAIRE

SOMMAIRE

INTRODUCTION-------------------------------------------------------------------------------------6
1. Prsentation du lieu de stage-------------------------------------------------------7
2. Prsentation du sujet-------------------------------------------------------------------11
2.1. Problmatique--------------------------------------------------------------------------------- 12
2.2. Le sujet de stage----------------------------------------------------------------------------- 12
2.3. Choix dune dmarche et justification-------------------------------------------13
3. La tlphonie sur IP---------------------------------------------------------------------14
3.1. La Tlphonie sur IP et les protocoles-------------------------------------------16
3.2. Normalisation de la Tlphonie sur IP-------------------------------------------18
3.3. Qualit de service et capacit--------------------------------------------------------19
3.4. La tlconfrence multimdia--------------------------------------------------------19
3.5. Les modes de communication--------------------------------------------------------19
3.6. Les Protocoles--------------------------------------------------------------------------------- 20
3.7. Les produits et matriels dun rseau de tlphonie sur IP--------27
4. Spcifications JTAPI----------------------------------------------------------------------51
4.1. Les configurations supportes-------------------------------------------------------53
4.2. Larchitecture du package JTAPI-----------------------------------------------------54
4.3. Les objets de JTAPI-------------------------------------------------------------------------- 55
4.4. Structure Objet-------------------------------------------------------------------------------- 55
4.5. Structure dynamique---------------------------------------------------------------------- 56
4.6. Les diffrents tats------------------------------------------------------------------------- 58
4.7. Les vnements------------------------------------------------------------------------------ 59
4.8. Droulement dun programme-------------------------------------------------------60
4.9. Implmentation CISCO et exemple------------------------------------------------60
5. La plate-forme J2EE----------------------------------------------------------------------62
5.1. Quest ce que J2EE-------------------------------------------------------------------------- 63
5.2. Larchitecture Deux Tiers (Two Tiers architecture)-----------------------64
5.3. Larchitecture n Tiers---------------------------------------------------------------------- 65

Mise en place dun systme distribu de supervision, de taxation et de gestion des quotas sur un rseau de tlphonie sur
IP
5

SOMAIRE

5.4. Architecture du JDK J2EE---------------------------------------------------------------- 66


5.5. Les diffrents outils de bas niveau ------------------------------------------68
5.6. Implmentation de J2EE (les serveurs dapplication)-----------------71
5.7. J2EE en pratique------------------------------------------------------------------------------ 75
5.8. Serveur dapplication : utilisations et limites-------------------------------78
5.9. IDE (Integrated Development Environment)---------------------------------80
5.10. Le futur de J2EE---------------------------------------------------------------------------- 81
6. Spcifications et exigences du systme------------------------------------83
6.1. Description gnrale----------------------------------------------------------------------- 84
6.2. Modles des cas dutilisation---------------------------------------------------------86
6.3. Modles conceptuels----------------------------------------------------------------------- 89
6.4. Contraintes dordres gnrales-----------------------------------------------------91
6.5. Hypothses et dpendances----------------------------------------------------------92
6.6. Description dtaille----------------------------------------------------------------------- 92
6.7. Classes dimplmentation-------------------------------------------------------------101
Conclusion-----------------------------------------------------------------------------------------104
1) Bilan----------------------------------------------------------------------------------------------------- 104
2) Perspectives-------------------------------------------------------------------------------------------- 104
Bibliographie-------------------------------------------------------------------------------------105
1) Les sites web------------------------------------------------------------------------------------- 105
2) Ouvrages gnraux--------------------------------------------------------------------------- 106
ANNEXE----------------------------------------------------------------------------------------------107
1) Exemple de droulement dun programme JTAPI---------------------------107
2) Implmentation CISCO et exemple--------------------------------------------------108
3) Classes dimplmentation---------------------------------------------------------------- 109

Mise en place dun systme distribu de supervision, de taxation et de gestion des quotas sur un rseau de tlphonie sur
IP
INTRODUCTION

Les nouvelles technologies de la communication rapprochent


ostensiblement le transfert des flux voix et donnes sur une infrastructure
unique. Les ramifications et lacceptation grandissante des protocoles de
linternet suggrent lemploi du protocole IP comme une solution de
transport de la voix sur les infrastructures IP existantes. Aprs de
nombreuses initiatives de recherche, les produits de tlphonie sur IP
arrivent sur le march. Aujourdhui, rien nest encore simple, les standards
ne sont pas toujours au rendez-vous et surtout, les technologies doivent
apporter une solution labsence dune qualit de service encore
insuffisante sur lInternet.
1. Prsentation du lieu de stage
Socit Anonyme conseil dadministration fonde en 2002 avec un
capital de neuf cent soixante dix milliions de Fcfa (970 000 000 Fcfa),
CFAO TECHNOLOGIES Sngal sengage par ses choix et ses partenaires
assurer la mise en uvre des projets qui lui sont confis et garantir la
qualit de ses prestations.
Son mtier est d'accompagner ses clients dans la conduite du
changement de leur entreprise et d'acclrer la transformation de leurs
objectifs stratgiques en ralisations oprationnelles. Elles peuvent tre
technologiques (restructuration de centres informatiques, mise en oeuvre
d'architectures distribues, dploiement de rseaux,....) ou applicatives
(mise en oeuvre de progiciels en sous-traitance de l'diteur).
Elle a dvelopp une gamme complte de services qui apportent
des solutions concrtes dans les domaines suivants:
l'installation et le dploiement de systmes centraux ou
distribus, serveur et rseaux, amnagement de sites
informatiques (pr cblage, cblage) installation, migration et
test (matriels, logiciels et rseaux)
la maintenance prventive et corrective des quipements et des
logiciels systme et middleware
l'assistance l'exploitation et l'optimisation des performances,
l'administration de systmes et de rseaux, l'analyse des
performances et de capacits, Audit help desk : il s'agit de fournir
une structure de support tlphonique permettant de recevoir,
travers un point de contact unique, une assistance et des conseils
l'installation, au fonctionnement et l'utilisation du systme
la protection des systmes d'informations, plan de scurit,
sauvegarde et archivage, secours informatique, haute
disponibilit
la formation : son activit de formation s'appuie sur ses propres
comptences ddies et sur un modle de tiers formateurs
permettant d'accder aux offres de ses principaux partenaires
(CISCO, IBM, LOTUS, MICROSOFT), qu'il s'agisse de filires
standards, ou bien de cours sur-mesure conus spcifiquement
pour rpondre aux objectifs des clients.
Elle est structure en trois (03) ples :
Ple Solutions qui contient les corps de mtiers suivants :
o Informatique
o Solutions data
o Tlcommunications
o Radio communication.
Ple Equipements contient :
o Ascensorie
o Climatisation
Ple Produits contient :
o Bureautique
o Vente Produits.
Notre stage cest droul au sein du Centre de dveloppement qui
fait partie du ple Solutions. Ce ple est un regroupement de
comptences dans le domaine de linformatique, comptences confirmes
par de multiples certifications. Son savoir faire repose sur :
Une qualification rigoureuse des besoins (tude pralable, cahier
des charges, audit, ) et une mthode de conduite de projet
prouve
Le respect des standards dans la mise en uvre des
infrastructures
Un portefeuille de comptences disponibles au travers de son
propre rseau
Un cadre contractuel dfinissant clairement les responsables de
chacun, les engagements et les cots
11

Prsentation du sujet

2. Prsentation du sujet

2.1. Problmatique
12

Prsentation du sujet

Avec laugmentation continue de la vitesse des microprocesseurs et le


dveloppement des techniques de traitement du signal, il est devenu
raliste de faire transiter de la voix, au mme titre que des donnes
informatiques, sur le rseau Internet. Hormis lintrt technologique, la
tlphonie sur le rseau semble avoir un intrt conomique vident en
autorisant des communications vocales des tarifs pour le moment
imbattables. Or toutes les organisations, entreprises, administrations,
associations qui utilisent le tlphone sont lafft de sources
dconomies. Elles sont donc naturellement intresses par toutes les
innovations dans ce secteur, dautant que la mise en concurrence en
matire de tlcommunication devient la rgle. Cependant, la tlphonie
sur Internet est encore loin de satisfaire aux exigences de qualit de
service attendues pour ce type de service, mme si de fortes
amliorations sont prvisibles
Le tlphone tant l'outil indispensable quune socit confie tous ses
collaborateurs, son utilisation est la respiration de l'entreprise, de son bon
usage dpend limage, la performance... mais aussi les cots de la socit.
Il suffit d'un court instant pour constater que les tarifs des oprateurs
baissent, alors que le montant des factures tendance fortement
augmenter.
Do la ncessit de disposer doutils permettant de faire la lumire
sur :
Les charges rduire (appels vers portables, choix de
loprateur, )
Les postes optimiser
Laffectation des cots
2.2. Le sujet de stage
Au vu de la problmatique pose plus haut, un thme se dgage qui
sera le sujet prsent dans ce mmoire savoir : La mise en place dun
systme distribu de supervision, de taxation et de gestion des quotas sur
13

Prsentation du sujet

un rseau IP Telephony, bas sur la technologie J2EE et les spcifications


JTAPI.
La vue densemble du projet consiste mettre en place un systme
distribu pour la supervision des appels entrants et sortants (savoir qui a
appel, pendant combien de temps, vers quelle destination, aide la
rduction des charges), de taxation (laffectation des cots) et de gestion
des quotas (refuser quun poste ayant dpass sa limite puisse appeler)
sur un rseau IP telephony. Nous aurons donc trois modules dvelopper :
un module pour la supervision des appels (entrants, sortants)
un module pour la taxation des appels
un module de gestion des quotas dappels.
Le contexte dapplication du projet est avant tout dapporter une
fonctionnalit en plus celles prsentes dans les outils de gestion et
danalyse tlphonique du march, savoir la gestion de quotas
tlphoniques. Cette dernire se fera sous forme de notification de
rappel par email en cas de dpassement de quota, mais aussi se
traduira par une impossibilit pour le poste en question dmettre un
appel (sauf dans le cas du rtablissement de son quota). De cette faon
le systme offrira une analyse et un contrle plus prcis de ltat des
appels tlphoniques.
2.3. Choix dune dmarche et justification
Compte tenu du fait de la technologie qui sera utilise dans le
dveloppement du systme (J2EE), nous nous proposons dadopter UML
comme langage de modlisation de notre systme.
14

Prsentation du sujet

3. La tlphonie sur IP
15

Prsentation du sujet

Le dveloppement rapide de lInternet et lutilisation croissante des


rseaux fonds sur le protocole Internet (IP) pour les services de
communications, y compris pour les applications telles que la tlphonie,
sont devenus des domaines importants pour lindustrie des
tlcommunications. La possibilit dacheminer du trafic vocal et de la
vido sur des rseaux IP et les avantages offerts, notamment au niveau de
lintgration voix donnes constituent un point de convergence entre deux
technologies : la commutation de circuits et la commutation de paquets.
Lapparition rcente de la transmission de la voix et de la vido sur
IP reprsente une avance technologique importante dans le domaine du
multimdia et offre un service conu pour permettre aux compagnies
dutiliser leurs rseaux Internet pour y faire passer leur trafic de la voix
sans ncessiter de changement des quipements ou rseaux existants. En
dautre terme, lajout de quelques quipements tels que les passerelles
permettent de garder les mmes supports, utiliss auparavant pour
acheminer les communications tlphoniques, pour vhiculer la voix, la
vido et les donnes. Cette technologie exige des protocoles spcialiss
ddis ce genre dapplications, comme le protocole de transport en
temps rel RTP (Real-Time Transport Protocol) utilis en parallle avec
dautres protocoles qui concernent surtout la signalisation, la demande de
rservation de ressources, la ngociation de capacit comme le standard
H323 et le protocole dInitiation de sessions SIP (Session Initiation
Protocol).
Aujourdhui, la technologie de la tlphonie sur IP a produit plusieurs
services bass sur les diffrents scnarios de communication (tlphonie
PC PC, tlphonie entre un PC et un poste tlphonique et tlphonie
entre postes tlphoniques ou fax). En consquence, cette technologie est
devenue un outil de communication multimdia bas sur le rseau
Internet, intgrant des outils dinterfaces avec les rseaux tlphoniques
traditionnels.
16

Prsentation du sujet

Les analystes spcialistes des questions techniques annoncent


depuis plusieurs annes que toutes les formes de communications
fusionneront tt ou tard en une plateforme unique et, depuis quelques
annes, il semble vident quavec la technologie IP adopte, quelle soit
bien la plate-forme unificatrice de tous les rseaux de communications sur
internet. De mme, le march de la voix et de la vido sur IP a ouvert
plusieurs perspectives en ce qui a trait la tlphonie sur IP,
tlconfrence, transferts de donnes etc. et a contribu la rduction
des prix des communications internationales grce la concurrence.
Limportance de cette technologie et lavenir qui lui est rserv nous a
encourags simpliquer dans ce domaine avec enthousiasme.
3.1. La Tlphonie sur IP et les protocoles
3.1.1. Principe de la Tlphonie sur IP
La tlphonie sur IP est la transmission de la voix sur les rseaux
Internet. Le principe de base de cette transmission consiste en :
La voix transmettre est chantillonne et numrise par un
convertisseur analogique numrique.
Le signal numrique obtenu est comprim et encod grce des
algorithmes de compression spcifiques.
Le signal est dcoup en paquets.
Les paquets sont transmis travers le rseau Internet la
rception, les paquets sont rassembls, le signal de donnes ainsi
obtenu est dcomprim puis convertis en signal analogique
sonore.
Selon le type de terminal utilis, on distingue trois scnarios
possibles de tlphonie sur IP.
3.1.1.1.Tlphonie de PC PC
Dans ce scnario, les deux correspondants utilisent un PC rattach
au rseau Internet par lintermdiaire dun fournisseur daccs Internet.
17

Prsentation du sujet

Cette technique ncessite des participants la communication davoir un


PC muni dun modem, dune carte rseau, dun microphone, dun haut-
parleur et dun logiciel de tlphonie IP compatible de chaque ct. La
voix est comprime et dcomprime par un logiciel de compression. Ce
mode de fonctionnement ncessitait auparavant que les correspondants
se fixent un rendez-vous pralable sur Internet ou soient connects en
permanence. De nos jours, comme nous allons lexpliquer dans les
prochains chapitres, des protocoles de signalisations ont t labors pour
pallier ce genre de problme.

Figure 1 : Tlphonie de PC PC
3.1.1.2.Tlphonie entre PC et poste tlphonique et vis
versa
Dans ce scnario, lun des correspondants utilise un PC rattach au
rseau Internet par un fournisseur daccs Internet, lautre correspondant
utilise un tlphone rattach au rseau tlphonique commut. Une
passerelle est ncessaire ente les deux rseaux pour rendre possible cette
technique et faire la conversion entre rseaux (dans ce cas elle fait la
conversion Internet-RTC et vis versa). Elle se charge galement de lappel
du correspondant et de lensemble de la signalisation relative la
communication tlphonique du ct du correspondant demand. Du ct
PC, une signalisation dappels est ncessaire pour tablir une
communication et ngocier les paramtres de communication multimdia.
18

Prsentation du sujet

Figure 2 : Tlphonie entre PC et poste tlphonique


3.1.1.3.Tlphonie entre postes tlphoniques
Dans ce cas les deux correspondants utilisent un tlphone
conventionnel via le rseau tlphonique commut. Une passerelle est
utilise de chaque ct entre ce rseau et le rseau Internet pour
convertir la voix IP en voix et vis versa. Le rseau Internet est utilis pour
la connexion longue distance.

Figure 3 : Tlphonie entre postes tlphoniques


3.2. Normalisation de la Tlphonie sur IP
La plupart des tlphones sont encore, et seront encore pendant
plusieurs annes, connects aux rseaux tlphoniques traditionnels
commutation de circuits. Les services de tlphonie IP doivent donc
pouvoir accepter tout trafic manant de ces rseaux et assurer la
terminaison dune communication. La normalisation technique de la
tlphonie IP est en cours dans le cadre de nombreuses entits
industrielles et dorganismes de normalisation tels que le secteur de la
normalisation des tlcommunications de lIUT (IUT-T), le secteur des
radiocommunications de lIUT (IUT-R), et le groupe dtude sur lingnierie
Internet (IETF). Un exemple de normalisation dans le cadre de lIUT est la
srie de recommandations H323 pour les champs suivants :
audioconfrence, visioconfrence multimdia, tablissement et
19

Prsentation du sujet

commande dappel, gestion de la bande passante, interfaces entre


diffrentes architecture rseaux, et le protocole dinitiation de session SIP
dfini par lIETF pour la confrence, la tlphonie, la notification
dvnements et la messagerie instantane. Ces protocoles seront
dtaills dans les paragraphes qui suivent.

3.3. Qualit de service et capacit


La qualit de service est un facteur dterminant dans la tlphonie et,
ce titre, occupe le centre du dbat sur la tlphonie IP. La qualit peut se
dfinir sur plusieurs plans : fiabilit, dbit, scurit. Nanmoins, cest
parce que la qualit de transmission de la tlphonie caractrisant
actuellement lInternet public est perue comme mdiocre que la
tlphonie sur Internet est rarement considre comme un service de
qualit. En rgle gnrale, pour amliorer la qualit, on peut soit mettre
en application des critres de qualit de service, soit accrotre la capacit
disponible.
3.4. La tlconfrence multimdia
La tlconfrence multimdia dsigne lensemble des moyens et des
services accessibles par des terminaux spcifiques permettant la tenue et
lanimation de runions entre deux ou plusieurs groupes de personnes
loigns. Toutes les applications de tlconfrence utilisent un ou
plusieurs mdias : la voix, limage fixe ou anime et/ou des donnes en
temps rel.
3.5. Les modes de communication
Le mode point point Le mode point point correspond une
communication entre deux participants. Cest le mode de fonctionnement
le plus simple mettre en uvre.

Figure 4 : Le mode point point


20

Prsentation du sujet

Le mode multipoint pleinement interconnects Ce mode correspond au


cas o une tlconfrence met en relation plus de deux participants
simultanment. Ces participants sont interconnects en multicast.

Figure 5 : Le mode multipoint pleinement interconnect


Le mode multipoint via un MCU : Dans ce mode plusieurs participants
sont connects via une unit de contrle MCU (Multipoint Control Unit).
Celle-ci gre les procdures dappels entrants et sortants (entre le MCU et
les terminaux).

Figure 6 : Le mode multipoint via un MCU


3.6. Les Protocoles
Le transfert de donnes sur Internet seffectue par paquets de
donnes. Cette structure repose sur lutilisation de protocoles TCP/IP
(Transport Control Protocol/ Internet Protocol).
21

Prsentation du sujet

Chaque document, quil sagisse de texte, image ou voix, est numris


puis rparti en paquets. Chacun de ces paquets est alors envoy sur
Internet indpendamment des autres et essaie de prendre le chemin le
plus rapide pour parvenir sa destination. Ceci est ralis en fonction de
lencombrement dune partie ou de lautre du rseau au moment o le
paquet est expdi. La segmentation de linformation permet une plus
grande flexibilit dans lutilisation des ressources puisque la
communication ne monopolise pas une ligne donne. Dans le reste de
cette section, nous ferons un bref descriptif des protocoles de transport
utiliss.
3.6.1. Le Protocole IP
Le protocole IP est au centre du fonctionnement de lInternet. Il fait
partie de la couche Internet de la suite de protocoles TCP/IP. Il assure sans
connexion un service non fiable de dlivrance de paquets IP. Le service est
non fiable car il nexiste aucune garantie pour que les paquets IP arrivent
destination. Certains paquets peuvent tre perdus, dupliqus ou remis
en dsordre. On parle de remise au mieux. Le protocole IP permet aux
paquets de se dplacer sur le rseau Internet, indpendamment les uns
des autres, sans liaison ddie. Chacun dentre eux, envoy sur le rseau,
se voit attribuer une adresse IP. Cette dernire est un en-tte accol
chaque paquet et contenant certaines informations, notamment, ladresse
destinataire, sa dure de vie, le type de service dsir, etc.
3.6.2. Le Protocole TCP
Le protocole TCP est un protocole de contrle de transmission, il fait
partie de la couche transport du modle OSI. Il est orient connexion, cest
dire, il assure un circuit virtuel entre les applications utilisateurs. Le
protocole TCP tablit un mcanisme dacquittement et de re-mission de
paquets manquants. Ainsi, lorsquun paquet se perd et ne parvient pas au
destinataire, TCP permet de prvenir lexpditeur et lui rclame de
renvoyer les informations non parvenues. Il assure dautre part un contrle
22

Prsentation du sujet

de flux en grant une fentre de congestion qui module le dbit


dmission des paquets. Il permet donc de garantir une certaine fiabilit
des transmissions. TCP assure un service fiable et est orient connexion,
cependant il ne convient pas des applications temps rel cause des
longs dlais engendrs par le mcanisme dacquittement et de
retransmission.
3.6.3. Le Protocole UDP
Le protocole UDP est le protocole de transport sans confirmation.
UDP est un protocole simple qui permet aux applications dchanger des
datagrammes sans accus de rception ni remise garantie. Le traitement
des erreurs et la retransmission doivent tre effectus par dautres
protocoles. UDP nutilise ni fentrage, ni accuss de rception, il ne re-
squence pas les messages, et ne met en place aucun contrle de flux.
Par consquent, la fiabilit doit tre assure par les protocoles de couche
application. Les messages UDP peuvent tre perdus, dupliqus, remis hors
squence ou arriver trop tt pour tre traiter lors de leurs rception. UDP
est un protocole particulirement simple conu pour des applications qui
nont pas assembler des squences de segments. Son avantage est un
temps dexcution court qui permet de tenir compte des contraintes de
temps rel ou de limitation despace mmoire sur un processeur,
contraintes qui ne permettent pas limplmentation de protocoles
beaucoup plus lourds comme TCP. Dans des applications temps rel, UDP
est le plus appropri, cependant il prsente des faiblesses dues au
manque de fiabilit. Des protocoles de transport et de contrle temps rel
sont utiliss au dessus du protocole UDP pour remdier ses faiblesses et
assurer sa fiabilit. Ces protocoles sont RTP et RTCP et sont dtaills dans
le paragraphe suivant.
3.6.4. Les protocoles de transport temps rel
3.6.4.1.Le protocole RTP
23

Prsentation du sujet

Le groupe de lIETF a dvelopp en 1993 le protocole de transport


en temps rel (RTP, RFC 1889) dont le but est de transmettre sur Internet
des donnes qui ont des proprits temps rel (audio, vido ). Cest un
protocole de la couche application du modle OSI et utilise les protocoles
de transport TCP ou UDP, mais, gnralement, il utilise UDP qui est mieux
appropri ce genre de transmission. La figure 7 reprsente larchitecture
du protocole RTP.

Figure 7 : Architecture RTP


Le rle principal de RTP consiste mettre en uvre des numros de
squences de paquets IP et des mcanismes dhorodatages (Timestamp)
pour permettre de reconstituer les informations de voix ou vido. Plus
gnralement, RTP permet :
Didentifier le type de linformation transporte
Dajouter des indicateurs de temps (horodater) et des numros
de squence linformation transporte
De contrler larrive destination des paquets.
Len-tte RTP (Tableau I ci-dessous) indique le type, la source, et les
caractristiques de contrle du temps des donnes encodes. Ce standard
inclut en effet un horodateur (Timestamp) des paquets permettant au
24

Prsentation du sujet

destinataire dutiliser la numrotation des squences pour reconstituer


lordre original des paquets et de dtecter les paquets perdus.

V P X CC M PT Numro de
Squence
Horodatage (Timestamp)
Identificateur de source de synchronisation (SSRC)
Identification des sources contributrices (CSRC)
En-ttes supplmentaires
Donnes
Tableau 1 : En-tte du paquet RTP
Le champ V (2 bits) : Version RTP, actuellement V=2.
Le champ P (1 bit) : Si P=1 le paquet contient des octets
additionnels de bourrage (padding) pour finir le dernier paquet.
Le champ Extension X (1 bit) : Si X=1, len-tte est suivie dun
paquet dextension.
Le champ CSRC count CC (4 bits) : Il contient le nombre de CSRC
qui suivent len-tte.
Le champ M (1 bit) : Son interprtation est dfinie par un profil
dapplication (Profile).
Le champ Donnes type PT (7 bits) : Ce champ identifie le type
de donnes (audio, vido, image, texte).
Le champ numro de squence (16 bits) : Sa valeur initiale est
alatoire et il sincrmente de 1 chaque paquet envoy, il peut
servir dtecter des paquets perdus.
Le champ horodatage (32 bits) :Ce champ reflte linstant o le
premier octet du paquet RTP a t chantillonn.
25

Prsentation du sujet

Le champ SSRC (32 bits) :Ce champ identifie de manire unique


la source de synchronisation. Sa valeur est choisie de manire
alatoire par lapplication.
Le champ CSRC (32 bits) : Ce champ identifie les sources
participantes.
RTP supporte diffrents types de codage et de compression
des donnes. Beaucoup de formats standardiss sont accepts
(GSM, G.723.1, G.729 pour laudio et MPEG, H261 pour la vido).
3.6.4.2.Le protocole RTCP
RTCP (Real Time Control Protocol, RFC 1889) est un protocole de
contrle utilis conjointement avec RTP pour contrler les flux de donnes
et la gestion de la bande passante. RTCP permet de contrler le flux RTP,
et de vhiculer priodiquement des informations de bout en bout pour
renseigner sur la qualit de service de la session de chaque participant
la session. Des quantits telles que le dlai, la gigue, les paquets reus et
perdus sont trs importants pour valuer la qualit de service de toute
transmission et rception temps relles. Cest le protocole sous-jacent
(UDP par exemple) qui permet grce des numros de ports diffrents et
conscutifs (port pair pour RTP et port impair immdiatement suprieure
pour RTCP) le multiplexage des paquets de donnes RTP et des paquets de
contrle RTCP. Le protocole RTCP remplit trois fonctions :
Linformation sur la qualit de service : RTCP fournit, en
rtroaction des informations sur la qualit de rception des
donnes transmises dans les paquets RTP. Cette information est
utilise par la source mettrice pour adapter le type de codage
au niveau des ressources disponibles.
Lidentification permanente : RTCP transporte un identificateur
original de la source RTP cest dire la provenance du flux,
appel CNAME (Canonical name). Cet identificateur permet une
26

Prsentation du sujet

identification permanente de chacun des flux multimdia


entrants.
Le calibrage de la frquence dmission : La rception des feed-
back et la connaissance du nom permanent servent ajuster la
frquence denvoi des paquets la bande passante mise la
disponibilit de lutilisateur situ lautre extrmit.
Chaque paquet RTCP contient un rapport metteur ou rcepteur
suivi dune description de la source (source description). Il existe cinq
types de paquets de contrle (Tableau II). Chaque paquet commence par
un en-tte fixe suivi dlments structurs qui peuvent tre de longueur
variable selon le type de paquet

RR Rapport metteur
SR Rapport Rcepteur
SDES Description de Source
BYE Fin de session
APP Nouveau champ
Tableau 2 : Les paquets de contrle
RR : contient le rapport de la qualit de la livraison des donnes
des participants passifs (rcepteur) incluant le nombre de
paquets reus, le nombre de paquets perdus, la gique et
lhorodatage qui permet le calcul du dlai total de transmission
entre les deux parties.
SR : contient le rapport de la qualit de livraison des donnes des
participants actifs (metteurs). Il contient les champs du RR, et
des informations sur lmetteur, la synchronisation (pour
synchroniser deux sources de donnes), un compteur cumulatif
de paquets et le nombre doctets envoys.
SDES : contient linformation concernant les metteurs comme le
nom canonique (CNAME), et le nom dusager (NAME), le numro
27

Prsentation du sujet

de tlphone (PHONE) et dautres informations concernant les


participants.
BYE : indique la fin de la participation dune des parties.
APP : Dans le cas des applications spcifiques, les donnes
peuvent tre transmises dans des paquets spcifiques de type
APP.
Le tableau III dtaille len-tte ce message commun tous les
paquets RTCP :
V P RC PC Longueur
Rapport (s)
Tableau 3 : En-tte des paquets RTCP
Le champ V (2 bits) : Indique la version de RTP, actuellement
V=2.
Le champ P (1 bit) : Si P=1 le paquet contient des octets
additionnels de bourrage (padding) pour finir le dernier paquet.
Le champ RC (5 bits) : Il contient le nombre de rapports contenus
dans le paquet (un paquet pour chaque source).
Le champ PT (8 bits) : Il donne le type de rapport du paquet
(PT=SR=200, PT=RR=201, PT=SDES=202, PT=BYE=203,
PT=APP=204).
Le champ Longueur (16 bits) : Il indique la longueur du paquet.
3.7. Les produits et matriels dun rseau de tlphonie sur
IP
3.7.1. le PABX-IP
Cest lui qui assure la commutation des appels et leurs autorisations,
il peut servir aussi de routeur ou de switch dans certains modles, ainsi
que de serveur DHCP. Il peut possder des interfaces de type analogique
(fax), numriques (RNIS, OSIG) ou oprateur (RTC-PSTN). Il peut se gre
par IP en intranet ou par un logiciel serveur spcialis que ce soit en
28

Prsentation du sujet

interne ou depuis lextrieur. Il peut sinterconnecter avec dautres PABX


quelque soit la marque (rseau htrogne).
3.7.2. Le serveur de communication
Il gre les autorisations dappels entre les terminaux IP ou softphone
e les diffrentes signalisations du rseau. Il peut possder des interfaces
rseaux oprateurs (RTC-PSTN), sinon les appels extrieurs passeront par
la passerelle ddie cela (Gateway).

3.7.3. La passerelle (Gateway)


C'est un lment de routage quip de cartes d'interfaces
analogiques et/ou numriques pour s'interconnecter avec soit
d'autres PABX soit des oprateurs de tlcommunications locaux,
nationaux ou internationaux. Plusieurs passerelles peuvent faire
partie d'un seul et mme rseau, ou l'on peut galement avoir une
passerelle par rseau local (LAN). La passerelle peut galement
assurer l'interface de postes analogiques classiques qui pourront
utiliser toutes les ressources du rseau tlphonique IP (appels
internes et externes, entrants et sortants).
3.7.4. Le routeur
Il assure la commutation des paquets d'un rseau vers un
autre rseau.
3.7.5. Le switch
Il assure la distribution et commutation de dizaines de port
Ethernet 10/100 voire 1000 Mbits/s. Suivant les modles, il peut
intgrer la tl alimentation des ports Ethernet la norme 802.3af
pour l'alimentation des IP-phones ou des bornes WIFI en 48V.
3.7.6. Le gatekeeper
Il effectue les translations d'adresses (identifiant H323 et @
IP du rfrencement du terminal) et gre la bande passante et les
29

Prsentation du sujet

droits d'accs. C'est le point de passage oblig pour tous les


quipements de sa zone d'action.
3.7.7. Le MCU
Cest est un lment optionnel et gre les confrences audio
vido.
3.7.8. L'IP-PHONE
C'est un terminal tlphonique fonctionnant sur le rseau
LAN IP 10/100 avec une norme soit propritaire, soit SIP, soit
H.323. Il peut y avoir plusieurs codecs pour l'audio, et il peut
disposer d'un cran monochrome ou couleur, et d'une ou plusieurs
touches soit programmables, soit prprogrammes. IL est en
gnral dot d'un hub passif un seul port pour pouvoir alimenter
le PC de l'utilisateur (l'IP PHONE se raccorde sur la seul prise
Ethernet mural et le PC se raccorde derrire l'IP PHONE).
3.7.9. Le SOFTPHONE
C'est un logiciel qui assure toutes les fonctions
tlphoniques et qui utilise la carte son et le micro du PC de
l'utilisateur, et aussi la carte Ethernet du PC. Il est gr soit par le
Call Manager, soit par le PABX-IP.
La voix et la vido sur IP procurent des avantages certains aux
entreprises et aux utilisateurs. Un seul rseau est utilis pour la voix, la
vido et les donnes, ce qui a pour consquence de rduire les frais
dexploitations. Dautre part, les utilisateurs peuvent viter les frais dus
aux appels interurbains et payer uniquement les frais de connexions
locales. Dautres applications de la voix et la vido sur IP permettent la
tenue de runions et de confrences multimdia. Nous avons prsent le
principe de la tlphonie sur IP et des modes de communications. Nous
avons galement tudi les diffrents protocoles qui sont utiliss dans la
tlphonie sur IP. Parmi ces protocoles, nous avons prsent les protocoles
30

Prsentation du sujet

de transports et de contrles en temps rel RTP et RTCP qui utilisent le


protocole UDP pour le transport de la voix et de la vido.
Dans le prochain paragraphe, nous allons tudier le standard H.323
qui permet entre autre la signalisation des appels.
3.8. Historique du standard H323
La premire version a t approuve en octobre 1996. Elle dfinit les
standards pour les transmissions multimdias au dessus des rseaux IP.
Cependant, cette version prsentait des faiblesses telles que labsence de
la qualit de service. La deuxime version de H323, approuve en janvier
1998, permet une interoprabilit entre diffrents rseaux. De plus, Il
sadapte facilement avec dautres technologies de rseaux de paquets. La
troisime version de H323, approuve le 30 septembre 1999, introduit
quelques nouvelles fonctionnalits (identification de lappelant,
communication entre gardes-barrire ). La quatrime version, a t
approuve en novembre 2000.
3.8.1. Les lments du H323
Les lments de base du standard H323 sont les terminaux, les
gardes-barrire, les passerelles et les units de contrle multipoint MCUs.
Les MCUs sont cits sparment, mais en pratique ils font souvent partie
des gardes-barrire ou des ordinateurs rapides qui servent plusieurs
utilisateurs.
3.8.1.1.Les Terminaux
Un terminal est un priphrique qui supporte les communications
multimdia bidirectionnelles en temps rel. Tous les terminaux H323
doivent supporter H.245, RAS (Registration Admission Status) et RTP (Real
Time Transport Protocol). Un terminal H323 fournit les services suivants :
Services H245 : lchange de capacits et la gestion des canaux
logiques.
Services H225 : gestion de la signalisation des appels.
Services RAS : lenregistrement auprs du garde-barrire.
31

Prsentation du sujet

Services RTP / RTCP : Squencement des paquets audio et vido.


3.8.1.2.Les Gardes-barrire
Le garde-barrire est un lment vital dans un systme H323. Il joue
le rle de contrleur pour tous les appels lintrieur de la zone H323
(une zone H323 est une agrgation de garde-barrire et de tous les autres
lments terminaux et MCU qui sont enregistr auprs de lui). Il fournit les
services aux lments qui sont enregistrs auprs de lui tel que la
conversion des adresses, le contrle dadmission, la gestion de la bande
passante et la capacit de routage.
3.8.1.3.Les Passerelles
Une passerelle H323 est un lment du rseau qui assure la
conversion voulue entre les formats de transmission (par exemple, du
format H.225.0 au format H.221 ou vice versa) ainsi quentre les
protocoles de communication (par exemple du protocole H.245 au
protocole H.242 ou vice versa). La passerelle assure aussi Ltablissement
et la libration des communications tant du ct rseau commutations
de paquets que du ct rseau commutation de circuits.
3.8.1.4.Les units de contrle multipoint (MCUs)
Le MCU est un lment du rseau qui fournit les capacits
plusieurs terminaux et passerelles pour participer une confrence
multipoint. En dautres termes, un MCU gre les ressources de la
confrence et les changes de capacits. Le MCU se compose de deux
parties : un contrleur multipoint obligatoire qui assure la gestion dau
moins trois terminaux participants une confrence multipoint. Le
contrleur multipoint permet de ngocier avec tous les terminaux les
moyens mettre en uvre pour parvenir tablir des communications
multimdia. Il peut galement exercer un contrle au niveau des
ressources de la confrence pour dterminer par exemple lentit qui
transmet en muticast. La deuxime partie est le processeur multipoint
32

Prsentation du sujet

facultatif qui assure le traitement centralis des flux de donnes dans une
confrence multipoint.
3.8.1.5.Protocoles et procdures
La recommandation H323 enveloppe dautres recommandations
pour permettre les communications en temps rel. Le tableau IV rsume
quelques unes dentre elles :
Recommandation Aperu
Codecs Audio G.711 Encode le signal selon les lois A ou en
G.723.1 G.729 64 Kbit/s Encode et compresse le signal
vocal en 5.3 et 6.4 Kbit/s Encode et
compresse le signal vocal en 8 et 13
Kbits/s
Codecs Vido H.261 H.263 Encode et compresse la vido en 64 kb/s
Encode et compresse faible taux de
compression
Communication de Protocole de donnes pour les
donnes T.120 confrences multimdia
Contrle H.245 H.225.0
Transport temps rel RTP /
Protocole de contrle pour les
RTCP
communications de donnes Protocole
de signalisation des appels Protocoles de
transport et de contrle en temps rel
Scurit H.235 Scurit, cryptage pour les terminaux
des sries H32x
Services Protocole pour les services
supplmentaires H.450.1 supplmentaires Transfert dappels et
H.450.2 et 450.3 autres services supplmentaires
Tableau 4 : Recommandations du H323
3.8.1.6.La pile H323
La figure 8 montre la pile des protocoles spcifis par le standard
H323
33

Prsentation du sujet

Figure 8 : Le pile protocole du terminal H323


Cette pile est indpendante des rseaux et des protocoles de
transport utiliss. Si le protocole IP est utilis (ce qui est le plus souvent le
cas) alors les paquets audio, vido et H.225.0 RAS utilisent UDP comme
protocole de transport alors que les paquets de contrle (H.245 et H.225.0
call signaling) utilisent TCP. La pile H323 est constitue des lments
dcrits ci-dessous :
Les codecs Audio : H323 spcifie une srie de codecs audio
classs par dbits allant de 5.3 64 kb/s. G.711 est le codec le
plus populaire conu pour les rseaux de tlphonie. Aujourdhui,
les terminaux H323 supportent le codec G.723.1 qui est plus
efficace et produit une meilleure qualit audio 5.3 kb/s et 6.3
kb/s. Les codecs G.729 utilisent la quantification prdiction
linaire pour produire une qualit suprieure des taux de 16
kb/s et 8 kb/s.
Les codecs Vido : La communication vido ncessite une bande
passante importante, do lintrt davoirdes techniques de
compression et de dcompression performante.
H323 spcifie deux codecs vidos : H.261 et H.263.
34

Prsentation du sujet

Les codecs H.261 produisent la transmission vido pour des


canaux avec une bande passante de p x 64 kb/s (p est une
constante qui varie de 1 30).
Les codecs H.263 sont conus pour des transmissions faible dbit
sans perte de qualit.
3.8.1.7.Confrence de donnes
Les capacits des confrences de donnes en temps rel sont
requises pour des activits telles que le partage dapplications, le transfert
de fichiers, la transmission de fax, la messagerie instantane. La
recommandation T.120 fournit ces capacits optionnelles au H323.
3.8.1.8.Mcanismes de contrle et de signalisation
Le flux dinformations dans les rseaux H323 est un mixage de
paquets audio, vido, donnes et de contrle. Linformation de contrle
est essentielle pour ltablissement et la rupture des appels, lchange et
la ngociation des capacits. H323 utilise trois protocoles de contrles :
Contrle multimdia H.245, signalisation dappel H.225 / et H.225.0 RAS.
3.8.1.9. La signalisation
La signalisation est indispensable pour tablir une communication
tlphonique. Elle permet dans un premier temps denvoyer des
messages avant la communication, davertir lutilisateur et de connatre la
progression de lappel et enfin de mettre un terme la communication. Il
existe actuellement deux protocoles de signalisation pour les rseaux IP,
la signalisation H.225 qui fait partie du standard H323 et le rcent
protocole SIP.
3.8.1.10. Signalisation des appels H.225
La signalisation des appels est importante pour tablir et rompre
une connexion entre deux entits. Q.931 a t dvelopp initialement
pour la signalisation dans les Rseaux Numriques Intgration de
Service (ISDN). H.225.0 a adopt la signalisation Q.931 en lincluant dans
le format de ses messages Deux entits dsirant tablir une connexion
35

Prsentation du sujet

doivent ouvrir un canal de signalisation. La signalisation dappels H.225.0


est envoye directement entre les entits priphriques quand aucun
garde-barrire nest utilis. Si un garde-barrire est utilis alors la
signalisation dappels H.225.0 doit tre rout travers ce garde-barrire.
3.8.1.11. H.225.0 RAS
Les messages H.225.0 RAS (registration, admission, status)
dfinissent une communication entre les terminaux et un garde-barrire.
H.225.0 RAS soccupe de la communication entre le garde-barrire et les
diffrents terminaux. Elle gre les oprations suivantes : linscription, le
contrle dadmission, la gestion de la bande passante. Un canal de
signalisation est utilis afin de transporter les diffrents messages RAS.

3.8.1.12. Le protocole de contrle de signalisation


H.245
La flexibilit de H.323 ncessite que les diffrends terminaux
ngocient les capacits avant que les liens de la communication audio,
vido et/ou donne ne soient tablit. H.245 utilise les messages de
contrle et de commandes qui sont changs durant lappel. Ces
messages sont classs en quatre catgories :
Messages dchanges de capacits
Messages pour la gestion des canaux logiques
Messages pour la gestion des flux de contrle
Commandes gnrales et indications
Le standard H.323 est omniprsent dans les communications
multimdia en temps rel et il est utilis par plusieurs compagnies telles
que Intel, Microsoft, Cisco, IBM, etc. Son indpendance des plates formes
permet le concevoir des applications multimdia sans changer
linfrastructure des rseaux. Dans le chapitre suivant nous allons tudier
36

Prsentation du sujet

un autre protocole de signalisation concurrent du H.323 appel protocole


dinitiation de session. Nous prsenterons aussi une comparaison entre
ces deux protocoles.
Le Protocole dInitiation de Session (SIP)
3.8.1.13. Introduction
Dvelopp par lIETF et prsent dans le RFC 2543, le protocole
dinitiation de session (SIP) est un protocole de signalisation appartenant
la couche application du modle OSI. Son rle est douvrir, modifier et
librer les sessions entre un ou plusieurs utilisateurs. Louverture de ces
sessions permet de raliser de laudio ou vidoconfrence, de
lenseignement distance, de la voix (tlphonie) et de la diffusion
multimdia sur IP. Notons quavec SIP, les utilisateurs qui ouvrent une
session peuvent communiquer en mode multicast, en mode point point
ou dans un mode combinant ceux-ci. Pour ouvrir une session, lutilisateur
met une invitation transportant un descripteur de session permettant
aux utilisateurs souhaitant communiquer de saccorder sur la compatibilit
de leur mdia. Ainsi SIP peut relier des stations mobiles en transmettant
ou redirigeant les requtes vers la position courante de la station appele.
Notons que SIP possde lavantage de ne pas tre attach un mdium
particulier et est sens tre indpendant du protocole de transport. De
plus il peut tre tendu et sadapter aux volutions futures.
3.8.1.14. Architecture de SIP
Larchitecture de SIP est prsente la figure 9 :
37

Prsentation du sujet

Figure 9 : architecture de SIP


A chacune des couches de larchitecture SIP sont associs des
protocoles tels que :
RSVP (Resource Reservation Protocol) : protocole utilis pour
rserver les ressources rseaux sur IP.
RTP (Real Time Transport protocol) : protocole de transport des
donnes en temps rel.
RTCP (Real Time Control Protocol) : protocole qui assure le
contrle de flux des donnes multimdia.
SAP (Session Annoucement Protocol) : protocole pour annoncer si
les sessions multimdia ouvertes sont en multicast.
SDP (Session Description Protocol) : protocole de description des
sessions multimdia.

3.8.1.15. Modle client-serveur


Pour tablir une communication, lappelant, que lon dsignera par
client, adressera sa requte un serveur SIP, qui lui donnera les moyens
de communiquer. Il existe cinq types de serveurs :
38

Prsentation du sujet

lUAS (User Agent Server) : cest lapplication du terminal


dabonn qui reoit les requtes. LUAC (User Agent Client) est
lapplication cliente qui met les requtes;
le relais mandataire ou PS (Proxy Server) : auquel est reli un
terminal fixe ou mobile agit la fois comme client et serveur. Un
tel serveur peut interprter et modifier les messages quil reoit
avant de les transmettre;
le RS (Redirect Server) : ralise simplement une association
dadresses vers une ou plusieurs adresse (lorsquun client appelle
un terminal mobile - redirection vers le PS le plus proche - ou en
multicast, le message mis est redirig vers toutes les sorties
auxquelles sont relis les destinataires);
le LS (Location Server) fournit la position courante des utilisateurs
dont la communication traverse les RS et PS auxquels ils sont
rattachs : Cette fonction est assure par le service de
localisation;
le RG (Registrar) est un serveur qui accepte les requtes
REGISTER et offre galement un service de localisation comme le
LS. Chaque PS ou LS est gnralement reli un Registrar.
Pour tablir la communication entre lUAC (Agent utilisateur
client) du terminal appelant et lUAS (Agent utilisateur serveur)
du terminal appel, ceux-ci doivent tre identifis. Ainsi, chaque
utilisateur et sa machine est identifi par une adresse appele
URL SIP qui se prsente comme une URL Mailto ou Telnet :
utilisateur@machine
La partie utilisateur est compose dun nom ou un numro de
tlphone alors que la partie machine est un nom de domaine ou une
adresse IP. Si le client souhaite communiquer avec son destinataire, il
envoie une requte URI directement vers le port dentre de lUAS du
39

Prsentation du sujet

destinataire de la requte. Le protocole utilis (TCP ou UDP), ladresse IP


et le port dentre du serveur du destinataire doivent tre prciss, lors de
lmission dune requte URI. Une fois le client connect un serveur SIP
distant, il peut lui adresser une ou plusieurs requtes SIP et recevoir une
ou plusieurs rponses de ce serveur. Les rponses contiennent certains
champs identiquement remplis ceux des requtes : ce sont les champs
Call-ID dont le rle est de dfinir de faon unique une invitation
particulire, le champ Cseq qui est utilis pour identifier un message
faisant partie dune ngociation dinvitation, le champ Via qui indique le
chemin pris par la requte pour arriver jusqu destination et les url To et
From qui contiennent les adresses sources et destination des clients. Les
changes client-serveur se font laide de requtes (INVITE, ACK, BYE,
REGISTER, OPTION, CANCEL). Celles-ci sont dfinies dans les paragraphes
ultrieurs.
3.8.1.16. URL SIP
Il existe cinq types de format de nommage universel SIP (URL SIP)
qui sont : (FROM, COURANTE, TO, CONTACT et EXTERNAL).
URL TO : contient ladresse du destinataire de la requte SIP.
URL FROM : contient ladresse source du client qui met la
requte SIP.
URL COURANTE : ou requte URI: prcise la destination de la
requte REGISTER cest dire son domaine denregistrement. La
requte REGISTER est transmise de serveur en serveur jusqu ce
quelle ait atteint le serveur dont le domaine correspond celui
list dans la requte URI.
URL CONTACT : les requtes autres que REGISTER destination
de lURL TO sont redirigs aux adresses donnes dans lURL
CONTACT.
40

Prsentation du sujet

URL EXTERNAL : rserv des applications futures. La structure


de lURL est la suivante :
sip : informations_utilisateur@domaine paramtres en-ttes
avec informations_utilisateur = (nom de lutilisateur :mot de
passe) ou (numro de tlphone si user = phone)
domaine = nom de domaine ou adresse IP : port
paramtres = ;transport = udp ou tcp; user = phone ou IP
; method = INVITE, ACK, OPTIONS, BYE, CANCEL, REGISTER ; ttl =
0 255 ; maddr = adresse IP de multicast ; tag = compteur en
hxadcimal
en-tte = ?hname= hvalue & hname = hvalue .
Seules les URL CONTACT et EXTERNAL contiennent les
paramtres transport, method, ttl, maddr et des en-ttes. Nous
illustrons par un exemple une requte SIP par lexemple dune
personne nomme Jacques dont lurl est Jacques@uqam.ca qui
invite une personne Bill ayant pour url Bill@ele.ets.ca . La requte
INVITE sera la suivante :
INVITE sip :ele.ets.ca Via: SIP/2.0/UDP ets.ca From:
sip:Jacques@uqam.ca
To: sip:Bill@ele.ets.ca CallID: 1468@ets.ca Cseq: 1 INVITE
3.8.1.17. Les mthodes
Les changes client-serveur se font laide de requtes INVITE, ACK,
BYE, REGISTER, OPTIONS et CANCEL. tudions en dtail ces six mthodes
qui permettent les changes entre client et serveur :
INVITE : indique que lapplication ou utilisateur est invit
participer une session.
ACK :confirme que le client a reu une rponse positive une
requte INVITE.
41

Prsentation du sujet

OPTIONS : un PS en mesure de contacter lUAS appel, doit


rpondre une requte OPTIONS prcisant ses capacits
contacter lUAS.
BYE : est utilise par lUAS de lappel pour signaler au PS local
quil ne souhaite plus participer la session.
CANCEL : la requte CANCEL est envoye par un UAC ou un PS
pour annuler une requte non valid par une rponse finale
dtat.
REGISTER : cette mthode est utilise par le client pour
enregistrer ladresse dans lURL TO par le serveur auquel il est
reli. Ladresse denregistrement est du type
Utilsateur@Domaine.
3.8.1.18. les codes dtats
Une rponse une requte est caractrise par un code appel code
dtat. Le tableau ci-dessous rcapitule ces codes :
Code Signification
1xx Information
2xx Succs
3xx R acheminement
4xx Erreur requtes
5xx Erreur serveur
6xx Erreur globale
Tableau 5 : Rcapitulatif des codes
3.8.1.19. Description des messages SIP
Un message SIP peut tre une requte dun client vers un serveur ou
bien une rponse dun serveur vers un client. Ces deux types de
messages SIP utilisent le format suivant :
42

Prsentation du sujet

Figure 10 : Messages SIP


Avec : Dbut de ligne = ligne de requte ou ligne dtat En-tte = en-tte
gnrale ou en-tte de requte ou en-tte de rponse ou en-tte dentit.
Le champ en-tte gnral sapplique la fois aux messages de requtes
et de rponses. Le champ en-tte dentit dfinit le type dinformations
contenues dans le corps du message. Le champ en-tte de requte
autorise le client ajouter des informations concernant sa requte et le
champ en-tte de rponse autorise le serveur ajouter des informations
concernant sa rponse. La description des 36 noms den-ttes est donne
en dtail dans le document normalis RFC 2543. CRLF = indique la fin de
ligne et le dbut du corps du message (optionnel) Corps du message =
selon la mthode il indique des informations sur la progression de la
requte, description de la session, description de destinations ou services
intermdiaires, causes derreurs.
3.8.1.20. Diagramme des squences
Dans la section prcdente on a prsent le format des messages
SIP changs entre diffrentes entits SIP lors de la signalisation des
appels. Dans cette section, on procde la modlisation oriente objet de
ce procd. On prsente le comportement dynamique du protocole SIP
durant ltablissement et la fermeture dappel.
tablissement dappel : Dans ce cas deux clients tablissent lappel
par lintermdiaire dun serveur proxy en mode point point. Le
diagramme de squences suivant illustre ce cas de figure :
43

Prsentation du sujet

Figure 11 : tablissement dappel


Terminaison dappel : La figure 11 prsente la fermeture de lappel.
Lentit, qui dsire mettre fin cet appel, envoie un message BYE et
lautre rpond par un OK.

Figure 12 : terminaison dappel


44

Prsentation du sujet

3.8.1.21. Discussion
Nous avons choisi dutiliser le protocole SIP pour ses caractristiques
suivantes :
Fiabilit : SIP peut fonctionner aussi bien avec TCP quavec UDP.
Vu que UDP est un protocole non fiable, SIP doit fournir sa propre
fiabilit faite de retransmission. Le protocole TCP par contre est
fiable; une fois que la connexion est tablie les donnes
arriveront destination.
Services : SIP permet des services similaires aux services de la
tlphonie classique. Il fournit les lments de construction de
ces services laide des enttes et des mthodes. Parmi ses
services :
o Le transfert dappel : permet un utilisateur de transfrer
un appel tabli une tierce partie. SIP le ralise par
lintermdiaire de len-tte Contact. -Le transfert de
communication : permet lutilisateur appel de faire
suivre un appel une autre adresse en utilisant les en-ttes
Contact, Call-ID
o Invitation dun groupe : Contrairement aux autres
protocoles de signalisations, SIP permet des appels qui
atteignent une personne ou bien un groupe de personnes.
Ceci est rendu possible grce lutilisation dUDP qui
permet le multicast.
o Mobilit de personnes : La mobilit dune personne
correspond la capacit de crer et de recevoir un appel
nimporte quel terminal et dans nimporte quel site. SIP
permet de joindre la personne appele, mme en cas de
changement de terminal. Ceci est possible grce au serveur
de redirection dont le rle est de rediriger les appels vers
une autre destination que la personne appele a choisi.
45

Prsentation du sujet

Flexibilit Topologique : SIP permet des confrences en mode


multicast, multipoint pleinement interconnects ou bien en mode
multipoints via un MCU. De mme, SIP et H323 sont conus pour
rpondre aux besoins de contrle de session et de fonctions de
signalisation dans une architecture de contrle dappel distribue.
Dans ce qui suit nous allons comparer ces deux protocoles par
rapport certains critres :
o Simplicit H.323 utilise une reprsentation pour ses
messages, base sur le standard ASN.1 ce qui complique
les procdures danalyse des messages. En revanche, SIP
code ses messages sous forme textuelle (comme HTTP). Ce
format textuel tend faciliter la mise au point et lanalyse.
o Dlai dinitiation dappel Dpendamment si le garde
barrire est utilis ou non, tablir un appel H.323 ncessite
lchange de plusieurs paquets et un intervalle de temps de
6 7 RTT (Round-trip times). En revanche, pour tablir un
appel SIP via UDP cela prend 1.5 RTT et un change de 4
paquets seulement (INVITE, 200 OK, ACK, BYE).
o Neutralit du protocole de transport SIP peut utiliser aussi
bien TCP que UDP, incluant ATM, AAL5, IPX, X.25 sans
changement au protocole. H.323 ncessite un protocole de
transport fiable.
o Du fait de lutilisation de UDP, SIP peut facilement envoyer
les requtes via le multicast. H.323 a une spcification
diffrente (appele H.332) pour supporter le multicast.
o Complexit Les spcifications SIP sont nettement plus
courtes que les spcifications Q.931 et H.245 combines.
o Description de contenu H.323 utilise toujours H.245 pour
ngocier le type de mdia dans une confrence; SIP peut
utiliser nimporte quel format de description. SIP ne
46

Prsentation du sujet

possde pas toute la flexibilit de ngociation du H.245,


cependant le H245 est restreint seulement aux codecs ITU-
T.
3.8.2. Le Protocole MGCP (Media Gateway to Media
Controller Protocols)
Le protocole MGCP (Media Gateway to Media Controller Protocols)
rsulte de la fusion des deux protocole SGCP 1.1 ( Simple Gate Control
Protocol ) et du protocole IDPC 1.0 ( Internet Protocol Device Control ). Le
protocole SGCP est utilis pour contrler lactivit dune Telephony
Gateway travers un lment de contrle dappel externe nomm Call
Agent. Le protocole IPDC est utilis pour raliser le control de connexions
du Media Gateway et le transport de la signalisation.
Le protocole MGCP suppose une architecture de contrle dappelle
dont laquelle llment intelligent de contrle se trouve en dehors de
Gateway, et cest lui qui assure le contrle de lactivit de la passerelle
multimdia laide dun protocole de contrle. Cet lment de contrle
sappelle Media Gateway Contoller ou Call Agent. Dans larchitecture
MGCP il existe plusieurs Call Agent. Le protocole MGCP suppose que ces
diffrents Calls Agents doivent se synchroniser lun avec les autres pour
envoyer des messages cohrents aux passerelles au-dessous de leurs
contrles. Finalement MGCP est un protocole matre /esclave ou on
sattend ce que les Gateways excutent des commandes envoyes par
les Call Agents.
3.8.2.1.Gnralits
Dans le rseau tlphonique la couche de signalisation est spare
de la couche de transport de parole. Le rle important de la signalisation
est dchanger les messages entre les diffrentes entits pour tablir un
circuit de parole entre des utilisateurs qui dsirent dialoguer. Le rle des
protocoles de VOIP est dassurer la connexion entre les deux rseaux
RTC/RNIS et le rseau Internet. Cest dans cette notion dinterconnexion
47

Prsentation du sujet

entre les deux mondes que se situe le protocole MGCP. Cette intgration
permet au rseau RTC de voir les lments de rseau tlphonique
comme tant autre switcher du rseau RTC. Larchitecture relative
linterconnexion du rseau tlphonique avec un rseau IP est prsente
sur le schma ci-dessous.

Figure 13 : interconnexion dun rseau tlphonique un rseau IP


Le ple d'interconnexion est compos de trois entits fonctionnelles
et d'un protocole permettant le dialogue au niveau de ces entits :
Passerelle multimdia (Media Gateway). Elle assure la
transformation d'un flux vocal entre le mode circuit et le mode
paquet.
Contrleur de la passerelle multimdia (Media Gateway
Controller). Il assure le contrle de l'activit de la passerelle
multimdia l'aide du protocole de contrle (Control Protocol).
Module de signalisation. Il assure la transcription de la
signalisation ISUP.
Ces trois entits fonctionnelles peuvent tre physiquement spares
ou alors couples au sein d'un mme quipement. Le protocole MGCP est
le protocole de contrle qui permet le dialogue entre Media Gateway
Controller (Call Agent) et Media Gateway. Dans ce protocole
48

Prsentation du sujet

linterconnexion entre le rseau tlphonique et le rseau IP est assur


par deux niveaux logiques :
Niveau de signalisation assur par lutilisation du SG (Signaling
Gateway).
Niveau de voix assur par lutilisation de passerelle multimdia.
En ce qui concerne le Call Agent il y a trois catgories de messages :
Des messages du rseau RTC transfrs par le SG ( Signaling
Gateway).
Des messages originaires Network Management changs entre
le Call Agent et les Gateways.
Des messages de la MGC pour maintenir la Bases de donnes.
Larchitecture gnrale du protocole MGCP est reprsente dans
la figure suivant :

Figure 14 : Architecture MGCP


Dans cette architecture la gestion des diffrents Gateways ainsi que
les interconnexions avec le rseau PSTN est assure par les Call Agents.
Lidentification dune extrmit ce fait par le nom du domaine de la
Gateway a laquelle lextrmit est relie et par un nom local dans ce
Gateway.
49

Prsentation du sujet

3.8.2.2.Mode de fonctionnement
Le protocole MGCP est un protocole de contrle de fonctionnement
de Media Gateway. Dans ce protocole llment intelligent est le Call
Agent il contrle les passerelles par lutilisation des huit commandes
changer entre lui et les passerelles. Ces commandes sont reprsentes
dans le tableau suivant :

Commandes Directions Code


NotificationReques Call Agent Gateway RQNT
t
Notification Gateway Call Agent NTFY
CreateConnection Call Agent Gateway CRCX
ModifyConnection Call Agent Gateway MDCX
DeleteConnection Call Agent Gateway DLCX
AuditEndPoint Call Agent Gateway AUEP
AuditConnection Call Agent Gateway AUCX
RestartInProgress Gateway Call Agent RSIP
Tableau 6 : Commandes MGCP
3.8.2.3.Les commandes MGCP
Notification Request :
Le Call Agent peut envoyer cette commande au Gateway, pour lui
demander de dtecter lapparition des vnements spcifiques pour un
terminal. Ces spcifications peuvent tre des signalisations tlphoniques
comme laccrochage ou le dcrochage du tlphone ou bien des tonalits
pour des extrmits spcifique. Une des plus importantes options de
Notification Request est lassociation dune action avec chaque
vnement. Lutilisation de cette option permet la rduction de nombre de
messages changs entre le Call Agent et le Media Gateway.
Notification Command :
Le Gateway utilise cette commande comme rponse la commande
Notification Request envoyer par le Call Agent, cette commande indique
50

Prsentation du sujet

au Call Agent que lvnement est dclench. Le Gateway peut envoyer


un ou plusieurs rponses des vnement dans une seule commande,
ces vnements sont envoys par le Media Gateway dans lordre de
dtection des ces vnements et cest le rle de Call Agent de mettre ces
vnements dans lordre correcte.
Create Connection :
Cette commande est envoye par le Call Agent au Media Gateway
pour crer une connexion entre deux extrmits. Autres que les
paramtres ncessaires qui permettent au Media Gateway de crer des
connexions, il y a des options LocalConnectionOptions qui dfinissent les
qualits de services de la connexion. Par lenvoie du message Notification
Request le Call Agent a la capacit denvoyer des actions qui
correspondent chaque vnement. Lutilisation de cette option dans la
cration dune connexion permet de diminuer le nombre de messages
changs entre le Call Agent et le Media Gateway.
Modify Connection :
Cette commande permet au Call Agent de modifier les paramtres
associs une connexion dj tablie.
Delete Connection :
Cette commande est envoye par le Call Agent au Gateway, elle lui
permet de terminer une conversation tlphonique. Sil existe plus dun
seul Media Gateway pour une conversation le Call Agent doit envoyer
cette commande chaque Gateway. Une fonctionnalit important du
protocole MGCP associ cette commande est quil faut au Media
Gateway lors de la terminaison dun appel denvoyer au Call Agent une
reponse qui contient les informations suivantes :
Nombres de paquets (RTP) envoys.
Nombres doctets envoys.
Nombres de paquets (RTP) reus.
51

Prsentation du sujet

Nombres doctets reus.


Nombres de paquets perdus.
Information sur la gigue.
Information sur les dlais de transmission.
Le protocole MGCP permet au Gateway de couper une connexion
quand il veut. Dans ce cas le Gateway envoie au Call Agent une
commande Delete Connection qui contient tous les paramtres
statistiques si dessus. Il faut noter aussi que la Call Agent la possibilit
de supprimer une connexion de multiples extrmits dans le mme temps
et ceci par lenvoie dun message Delete Connection a un Gateway avec le
caractre *. Cette commande ne ramne pas des informations statistiques
sur la connexion.
Audit Endpoint :
Le Call Agent peut utiliser cette commande pour dtecter si une
extrmit est dcroche ou en tat de sonnerie. Dans ce cas le Gateway
ramne une rponse qui contient des informations sur des extrmits
spcifiques.
Audit Connection :
Cette commande permet au Call Agent de dtecter tous les
paramtres lis une connexion spcifique.
Restart In Progress :
Cette commande est envoye par le Gateway au Call Agent. Il
permet dinformer le Call Agent de mettre hors services une extrmit ou
un groupe dextrmits quils ont des problmes. Dans ce cas la Call Agent
peut dcider de tester ces extrmits avant de les mettre hors service.
52

Prsentation du sujet

4. Spcifications JTAPI
53

Prsentation du sujet

JTAPI a t cre par Sun Microsystems en 1996 et a pour but de faciliter


le dveloppement dapplications contrlant les appels tlphoniques sans
se soucier de larchitecture matrielle. Il est la charge de chaque
constructeur de faire sa propre implmentation de lAPI en suivant les
spcifications venant de Sun Microsystems. JTAPI repose donc sur le
langage Java, et est donc une API oriente objets.
JTAPI est une API portable, oriente objet pour les applications de
tlphonie bases sur java. JTAPI couvre un large auditoire du dveloppeur
dapplications de type centre dappel au dveloppeur dapplications web.
LAPI est construite pour faciliter la programmation dapplications simples
tout en fournissant toutes les fonctionnalits ncessaires aux applications
de tlphonie avances.
JTAPI est en ralit un ensemble dAPIs. Le noyau de lAPI fourni le call
model (modle dappel) standard et des fonctionnalits rudimentaires de
tlphonie comme effectuer un appel tlphonique, rpondre un appel
et dconnecter un tlphone. Le noyau est entour dAPIs standard
fournissant des fonctionnalits dans des domaines spcifiques de la
tlphonie comme les centres dappel et laccs au mdia. Larchitecture
du noyau JTAPI et de ses extensions est dcrite plus tard dans le
document. Les applications crites avec JTAPI sont portables travers
diverses plates-formes et systmes de tlphonie.
Le dveloppement bas sur la tlphonie peut facilement devenir un
cauchemar car la plus part des systmes de tlphonie classique sont
bass sur des architectures matrielles propritaires. Pour faciliter la tche
je ne vais parler ici que de JTAPI (Java Telephony Programming Interface).
Il est impossible de couvrir dans ce mmoire toutes les possibilits
offertes par JTAPI, dautant quelles peuvent varier en fonction de
larchitecture utilise. La prsente partie va donc prsenter larchitecture
minimale de JTAPI pour permettre sa comprhension. Nous terminerons
54

Prsentation du sujet

cette partie par un exemple dun programme frquemment dvelopp


reposant sur larchitecture tlphonie IP de la socit CISCO Systems.
4.1. Les configurations supportes
JTAPI tourne sur une varit de configurations systme, cela inclus les
serveurs centraliss avec un accs direct aux ressources du systme de
tlphonie mais aussi les ordinateurs loigns avec un accs aux
ressources travers un rseau. Dans la premire configuration un
ordinateur du rseau hberge lapplication JTAPI et accde aux ressources
du systme de tlphonie travers le rseau. Dans la deuxime
configuration lapplication tourne sur un ordinateur avec ses propres
ressources de tlphonie.
4.1.1. La configuration rseau
Dans la configuration rseau, lapplication JTAPI ou lapplet java
tourne sur une machine loigne. Cette machine accde aux ressources
du rseau utilisant ainsi un serveur centralis qui gre les ressources de
tlphonie. JTAPI communique avec ce serveur au travers dun mcanisme
de communication distance comme RMI (Remote Method Invocation) de
java, JOE, ou un protocole de tlphonie. La figure suivante illustre
larchitecture de cette configuration.
55

Prsentation du sujet

Figure 15 : configuration rseau


4.1.2. La configuration desktop
Dans la configuration desktop, lapplication JTAPI ou lapplet java
tourne sur la mme machine qui gre les ressources de tlphonie. La
figure suivante illustre larchitecture de cette configuration.

Figure 16 : configuration desktop


4.2. Larchitecture du package JTAPI
JTAPI est compos dun ensemble de package java. Chaque package
fourni des fonctionnalits spcifiques un aspect particulier des
applications de tlphonie. Les implmentations des serveurs de
tlphonie choisissent les packages quils supportent dpendant des
capacits de leur plate-forme matrielle. La figure suivante illustre
larchitecture des packages de lAPI.
56

Prsentation du sujet

Figure 17 : architecture du package


4.3. Les objets de JTAPI
Le Modle objet de JTAPI est calqu sur larchitecture standard
tlphonique. En effet il existe un objet par lment de larchitecture
tlphonique. Nous pouvons classifier ces objets en deux types diffrents :
Objet Physique
Objet Logique
Les objets physiques correspondent aux lments ayant une ralit
physique :
Elments Nom de lobjet
Tlphone Terminal
PABX1 Provider
Numro de tlphone Address

Les objets logiques correspondent tout ce qui est connexion :


Elments Nom de lobjet
Appel Call
Connexion Connection
1
PABX (Private Automatic Branch Exchange) ou changeur de branche priv automatique est le cur de la
tlphonie, il permet de grer les appels et den faire le routage
57

Prsentation du sujet

Connexion au tlphone TerminalConnection

La sparation en deux catgories na pour but que de faciliter la


comprhension par la suite, car les objets sont construits de la mme
manire par catgories. Nous pouvons aussi noter que les objets
physiques sont toujours prsents. En revanche les objets logiques ne sont
crs que lors dun appel.
4.4. Structure Objet
Nous parlerons dans cette partie du Modle objet de JTAPI. Nous
pouvons noter lapparition de deux objets ( vrai dire des interfaces)
JTapiPeerFactory et JTapiPeer. Ces interfaces nont pour but que daider le
moteur JTAPI trouver la connexion et instancier lObjet Provider.

Figure 18 : structure objet


Comme dans une architecture tlphonique le Provider est au centre
du modle. Il est le gardien du rseau tlphonique et permet de
trouver la localisation et dinstancier des objets Address (numro de
tlphone) et Terminal (Le tlphone en lui-mme).Bien videment un
provider contient une collection dobjets Address et Terminal.
Remarquons aussi quun tlphone peut avoir plusieurs numros
associs, lobjet Terminal possde donc aussi une collection Address. Dans
le cas de centres dappel un numro de tlphone peut tre associ
plusieurs tlphones, donc lobjet Terminal contient une collection dobjet
Address.
58

Prsentation du sujet

4.5. Structure dynamique


Lors de lmission ou de la rception dun appel JTAPI va crer
dynamiquement tous les objets permettant de grer lappel et les diverses
connexions. Nous allons voir dans un premier temps le modle objet, puis
nous verrons lordre de cration de ces objets en faisant le parallle avec
les tlphones.

4.5.1. Modle objet

Figure 19 : modle objet


Lobjet Provider est une fois encore au centre de tout. Lobjet Call est la
reprsentation logique de lappel, il est compos dau moins deux
connections : une vers chaque numro composant lappel. Un appel peut
tre compos de plus de deux connections, par exemple dans le cas d'une
confrence tlphonique. Le lien entre la Connection et le Terminal est
59

Prsentation du sujet

assur par lobjet TerminalConnection. Il peut y avoir plusieurs


TerminalConnection dans le cas cit plus haut dun centre dappel.

4.5.2. La notion dtat

Figure 20 : diffrents tats dun appel

Ce schma permet dintroduire une notion trs importante en


programmation tlphonique : ltat. En fait chaque objets peut traverser
plusieurs tats durant sont cycle de vie. Dans lexemple ci-dessus A
numrote, les deux objets Call et Connection sont immdiatement crs.
60

Prsentation du sujet

Leurs tats respectifs sont IDLE (attente) et une fois la connexion vers le
tlphone de B tablie le tlphone sonne. Les trois objets sont encore en
position dattente, jusqu' que B dcroche. Si B ne dcroche pas nous
allons directement la dernire tape. Sinon lappel devient effectif
jusqu' quune des deux parties raccroche (dans lexemple B raccroche).

4.6. Les diffrents tats


Comme nous lavons vu dans la partie prcdente les objets logiques
changent dtat au cours du temps. Les objets physiques ont le mme
comportement. Une des diffrences importantes entre ces deux catgories
est leur cycle de vie. En effet les objets logiques ont un cycle de vie qui
correspond lappel, de la numrotation jusqu' ce quun des
interlocuteurs raccroche son tlphone. Les objets physiques quand eux
ont une dure de vie presque gale celle du programme. Les trois objets
physiques ont deux tats IN_SERVICE et OUT_OF_SERVICE. Ltat
OUT_OF_SERVICE correspond gnralement la phase dinitialisation.
Lorsquun objet est OUT_OF_SERVICE il nest pas utilisable. Il est important
de noter quil faut attendre que lobjet soit IN_SERVICE avant de pouvoir
lutiliser.
4.7. Les vnements
Nous avons vu que, dans les deux derniers chapitres, les divers objets
de JTAPI transitent par diffrents tats. Il est trs important, pour le bon
droulement du programme dutiliser les objets dans le bon tat. Pour
nous aider dans notre tche Java met notre disposition un outil pour
grer les vnements, bas sur le modle dobservation.
4.7.1. Gestion des vnements
Le modle dobservation, ncessite trois objets :
Un objet observateur
Un objet observ
Un objet reprsentant lvnement
61

Prsentation du sujet

Lobservateur doit avant tout senregistrer auprs de lobserv. Ceci


laide dune mthode gnralement appele AddObserver. Le nom de la
mthode peut diffrer lgrement et contient le nom de lvnement
attendu, par exemple, pour les vnements lis un appel tlphonique
la mthode sappellera : addCallObserver. Lvnement apparaissant, une
mthode spcifique de lobservateur sera appele, avec en paramtre
lobjet dcrivant lvnement. Par exemple, dans le cas dun vnement
li un appel la mthode sappellera callChangedEvent.

4.7.2. Evnements et JTAPI


Voici un tableau rcapitulatif des diffrentes mthodes pour
enregistrer un observateur par objet et les mthodes grant les
vnements. Nous verrons dans la prochaine partie comment assembler
tout ceci de faon faire lossature type dun programme JTAPI
Observation de ltat
Nom de lobjet Mthode Mthode de Gestion
denregistrement
Provider addObserver providerChangedEvent
Terminal addObserver terminalChangedEvent
Address addObserver addressChangedEvent
Observation dun appel
Address addCallObserver callChangedEvent
Terminal addCallObserver callChangedEvent

Lobservation dun appel se fait en enregistrant un vnement sur


un objet Address ou Terminal et non sur lobjet Call. Ce qui est logique car
ce sont eux qui permettent la cration de lappel.

4.8. Droulement dun programme


infra en ANNEXE
4.9.Implmentation CISCO et exemple
infra en ANNEXE
62

Prsentation du sujet

Ci-dessous les diffrentes interfaces implmentes dans notre


application :

INTERFACE METHODE IMPLEMENTEE


CallControlCallObserver callChangedEvent
CiscoProviderObserver providerChangedEvent

Ainsi, suivant l'implmentation de la mthode callChangedEvent, il


est possible de dfinir les comportements que l'application devra observer
losqu'un tlphone IP sonne, lorsqu'il est en communication, lors d'un
transfert de communication... C'est en exploitant ces vnements que
nous avons contruit une application de supervision des appels, qui
prsentait dans une fentre l'tat des postes IP (ALERTING,
CALL_IN_PROGRESS, DIALING_NUMBER, IN_CALL, ON_HOOK...). Le schma
ci-dessous rsume le mcanisme dcrit plus haut.

Figure 21 : mcanisme de supervision des appels


63

Prsentation du sujet

5. La plate-forme J2EE
64

Prsentation du sujet

5.1. Quest ce que J2EE


A lorigine le langage JAVA tait utilis pour crire des programmes
embarqus dans des priphriques lectroniques. Aujourdhui il est utilis
pour construire de larges systmes dentreprise. Cependant le langage
seul ne suffit pas rpondre au besoin dun systme dentreprise. Une
plate-forme est ncessaire pour fournir des services tels que :
La possibilit de stocker des informations dans une base de
donnes.
La possibilit de distribuer votre application sur plus dune
machine.
Le support des transactions, pour prvenir la corruption des
informations.
Le multithreading pour les accs concurrents aux services.
Le Connection Pooling pour la grer la dgradation des
performances au niveau de la base de donne.
La scalabilit pour lutilisation sur des plates-formes de tailles
trs infrieures ou trs suprieures.
Une application dentreprise ne peut pas tre localise sur une seule
machine, cest pourquoi il nous faut utiliser un type darchitecture une
infrastructure qui donnerait des directives sur les conduites adopter pour
placer chaque composant de notre systme.
J2EE dfini les standards pour le dveloppement dapplications multi
tiers. Il est bas sur des composants modulaires standard et fourni un
ensemble complet de service permettant de grer le comportement de
65

Prsentation du sujet

lapplication automatiquement sans programmation complexe. J2EE utilise


plusieurs technologies qui sont :
JDBC (Java Database Connectivity) pour la connectivit avec les
bases de donnes.
CORBA (Common Object Request Broker Architrecture) pour
linteraction aux ressources existantes de lentreprise.
Un modle de scurit qui protge les donnes des applications
Internet.
Un support complet pour les composants EJBs (Entreprise Java
Bean), JMS (Java Message Service), Java Servlets API, JSPs (Java
Server Page), XML (Extensible Markup Language), JCA (Java
Connectors Architecture), ect
Le standard J2EE inclus les spcifications compltes et les tests
complmentaires permettant dassurer la portabilit des applications
travers une large varit de systmes dentreprises capable de supporter
J2EE
5.2. Larchitecture Deux Tiers (Two Tiers architecture)
Dans larchitecture deux tiers, la logique de prsentation se situe du
ct client de lapplication de mme que la logique mtier. Les donnes
sont stockes sur un serveur et le client doit excuter des requtes SQL
pour communiquer avec le serveur. Il peut arriver parfois quune partie de
la logique mtier soit prsente sur le serveur sous forme de procdures
stockes ou de daemon.
66

Prsentation du sujet

Figure 22 : Architecture Deux Tiers


Cette architecture comporte cependant de srieux dsavantages. Le
principal est que la logique de prsentation et la logique mtier sont mises
ensemble, ce qui rend le systme plus difficile maintenir et
comprendre. Prenons lexemple dune application crite en Visual Basic
dont on voudrait transformer linterface graphique en interface web. tant
donn que la logique mtier est lie la logique de prsentation, il est
impossible modifier la prsentation sans altrer la logique mtier et il est
fort probable que la logique mtier devra tre r implmente
5.3. Larchitecture n Tiers
La plate-forme J2EE utilise un modle distribu multi tiers pour les
applications dentreprise. La logique applicative est divise en composants
en accord avec des standards, et les diffrents composants qui constituent
lapplication J2EE sont installs sur diffrentes machines reprsentant un
tiers dans lenvironnement J2EE. La figure 1 suivante donne un aperu du
modle multi tiers de la plate-forme
67

Prsentation du sujet

Figure 23 : Modle multi tiers


On remarque sur la figure 22 que la plate-forme est compose de 4
tiers qui sont :
Le Client-tier components qui tourne gnralement sur une machine
cliente.
Le Web-tier components qui tourne sur un serveur J2EE.
Le Business-tier components qui tourne aussi sur un serveur J2EE.
Le (EIS)-tier (Entreprise information system) gnralement des
logiciels qui tournent sur un serveur EIS.
Cependant une application J2EE peut tre constitue de trois ou quatre
tiers comme montrer dans la figure 1. les applications J2EE multi tiers sont
souvent considres comme tant trois tiers parce quelles sont rparties
en trois endroits : la machine du client, la machine serveur J2EE et la base
de donnes ou le systme legacy en back-end. Les applications trois tiers
qui tourne installes de la sorte tendent le standard deux tiers le modle
client et serveur en plaant un serveur multi tiers entre le client et le back
end storage
68

Prsentation du sujet

5.4. Architecture du JDK J2EE


J2EE dcrit larchitecture dun standard pour les serveurs dapplication.
Le schma qui suit dcrit plus prcisment les composants, les
dpendances et les protocoles utiliss.

Figure 24 : Schma de relations entre composants et tiers dans


larchitecture J2EE
Les diffrents rectangles dfinissent les conteneurs (de
lenvironnement dexcution J2EE) qui fournissent les services pour les
diffrents composants (reprsenter par les rectangles dans les rectangles).
Lensemble des composants sera expliqu dans le chapitre suivant. Les
flches reprsentent les types daccs que le type dapplication peut avoir
avec les autres applications distantes. Par exemple, lapplication client
peut se connecter au Web Container par lintermdiaire des JSP /
Servlet, elle peut galement se connecter EJB Container .
Voici prsent le schma de linteroprabilit entre la plateforme J2EE
et les autres programmes (les diffrents protocoles utiliss).
69

Prsentation du sujet

Figure 25 : Schma de linteroprabilit entre la plateforme J2EE et les


autres programmes
Ce schma est trs important dans le domaine de linteroprabilit
entre diffrentes applications. Il fournit les informations concernant les
protocoles utiliss pour chacune des connexions distantes possibles. Par
exemple, Web Container fournit des accs via HTTP / SSL ou SOAP ;
EJB Container fournit des accs HTTP / IIOP (RMI : Internet Inter-Orb
Protocol) / SSL
Nous pouvons alors penser quun client en C#, par exemple, peut se
70

Prsentation du sujet

connecter sur un EJB en mode HTTP (dans lidal) ou via le protocole IIOP
(plus rpandu).
5.5. Les diffrents outils de bas niveau
Nous avons vu (trs succinctement) plus haut larchitecture globale de
la plateforme J2EE. Nous allons maintenant prsenter les diffrents outils.
Il existe 3 grands types doutils :
Composants
Services dinfrastructures
Services de communications
5.5.1. Composants
On distingue en gnral deux catgories de composants :
Web
Mtiers
5.5.1.1.web
Il sagit de la partie prsentation (interface de lutilisateur et les
traitements). Le client reoit seulement du texte HTML, mais il sagit
seulement de la partie visible de lapplication. Derrire la scne,
diffrentes technologies permettent votre code dtre plus performant,
plus robuste, et plus facile mettre maintenir
5.5.1.1.1. les JSP
Les JSP (Java Server Page) sont les pages servant gnrer lensemble
du code HTML de linterface utilisateur. On y intgre aussi bien du code
HTML que des scriplet Java (code java) ou encore des balises
personnalises (tag-lib). Cette technologie est donc ddie la gnration
de HTML et non au traitement de la requte de lutilisateur. On lappelle
gnralement : Vue.
5.5.1.1.2. Les Servlet
Une Servlet est une classe Java qui permet de traiter une requte
venant dun client. Cette technologie doit soccuper de traiter les donnes
71

Prsentation du sujet

envoyes par lutilisateur et choisir la Vue retourner celui-ci.


On appelle cette partie : Contrleur. En gnral, la classe Java ne doit
quasiment pas gnrer de code HTML (sauf dans certains cas prcis).
5.5.1.2.Mtier EJB (Entreprise JavaBean)
Il s'agit de composants spcifiques chargs des traitements des
donnes propres un secteur d'activit (on parle de logique mtier ou de
logique applicative) et de l'interfaage avec les bases de donnes.
On parle de la partie : Modle.
5.5.2. Services dinfrastructures
5.5.2.1.JDBC (Java Database Connectivity)
Cest une API daccs aux bases de donnes. Les serveurs dapplication
fournissent en plus des pools de connexion avec les bases de donnes.
Cela rduit le nombre de lignes crire et optimise son utilisation.
5.5.2.2.JNDI (Java Native Directory Interface)
Cune API d'accs aux services de nommage et aux annuaires
d'entreprises tels que DNS, NIS, LDAP, etc
5.5.2.3.JTA/JTS
Cest une API dfinissant des interfaces standard avec un gestionnaire
de transaction.
5.5.2.4.JCA (J2EE Connector Architecture)
Cest une API de connexion au systme d'information de l'entreprise,
notamment aux systmes dits Legacy tels que les ERP.
5.5.2.5.JMX (Java Management eXtension)
Cette API fournit des extensions permettant de dvelopper des
applications web de supervision d'applications.
5.5.3. Services de communications
5.5.3.1.JAAS
Cest une API de gestion de l'authentification et des droits d'accs.
5.5.3.2.RMI (Remote Method Invocation)
Cest une API permettant la communication synchrone entre objets.
72

Prsentation du sujet

5.5.3.3.Web Services
Les Web services permettent de partager un ensemble de
mthodes qui pourront tre appeles distance. Cette technologie utilise
XML, ce qui permet dtre utilise par nimporte quel langage et nimporte
quelle plateforme.
5.5.3.4.JMS (Java Message Service)
Cette API fournit des fonctionnalits de communication asynchrone
(appeles MOM pour Middleware Object Message) entre applications.
5.5.3.5.JavaMail
Cest une API permettant l'envoi de courrier lectronique.
5.6. Implmentation de J2EE (les serveurs dapplication)
Il est avant tout indispensable de dfinir clairement ce qu'est un
serveur d'application. En effet, une confusion rgne dans les esprits quant
la notion de serveur d'application. Cette confusion a t introduite en
grande partie par les diteurs de serveurs d'application J2EE (Java2
Entreprise Edition) afin de s'approprier ce march. La notion de serveur
d'application a en effet t mlange avec celle de serveur d'objet qui n'a
absolument rien voir.
5.6.1. Quest ce quun serveur dapplication ?
Le serveur d'application est l'environnement d'excution des
applications ct serveur. Il prend en charge l'ensemble des
fonctionnalits qui permettent N clients d'utiliser une mme application :
Gestion de la session utilisateur : N clients utilisant une mme
instance d'application sur le serveur, il est ncessaire que le serveur
d'application puisse conserver des contextes propres chaque
utilisateur (par exemple, un panier de commandes). La plupart des
serveurs d'application gnrent un identifiant unique pour chaque
nouveau client et transmettent cet identifiant lors de chaque
change HTTP par URL longs, variables caches ou cookies.
73

Prsentation du sujet

Gestion des montes en charge et reprise sur incident : Afin de


grer toujours plus d'utilisateurs, le serveur d'application doit
pouvoir se dployer sur plusieurs machines et ventuellement offrir
des possibilits de reprise sur incident (mme si dans la grande
majorit des cas, on se contente d'une gestion des montes en
charge au niveau rseau - botier de rpartition, DNS round-robin,
reverse proxy ...).
Ouverture sur de multiples sources de donnes : C'est le serveur
d'application qui rend accessible les donnes des applications du
systme d'information. Il doit donc pouvoir accder de
nombreuses sources de donnes. On s'attend galement ce qu'il
fournisse des mcanismes performants comme le pooling de
connexion base de donnes.
Et bien dautre encore
Le serveur d'application est donc indispensable si l'on souhaite viter
de re-dvelopper l'ensemble de ces fonctionnalits (cas des GGI). Les
moteurs JSP/Servlets, Microsoft ASP, Cold Fusion, PHP, ect... sont ce titre
des serveurs d'application (mme si il sont intgrs au Serveur Web
PHP/ASP).
5.6.2. Quest ce quun serveur dobjet ?
Pour aborder la notion de serveur d'objets, il faut comprendre qu'il
existe deux mthodes pour accder aux donnes et aux traitements.
La premire consiste accder directement aux sources de
donnes. Cette mthode de programmation n'empche en aucun
cas de structurer ses dveloppements.
La deuxime mthode consiste s'appuyer sur des objets mtier
(client, fournisseur ...) afin de masquer la complexit d'accs aux
donnes. Un objet AssurSocial possdera par exemple une
mthode dbit () et une mthode crdit () qui chaque appel iront
modifier les donnes dans une ERP (Entreprise Resource Planning),
74

Prsentation du sujet

un systme de CRM (Customer RelationShip Managment) ou une


base de donnes.

Figure 26 : Traitement dune requte cliente


1. Requte du client
2. Le serveur web passe la requte au serveur dapplication
3. Le serveur dapplication traite la requte par des appels au
serveur dobjets
4. Le serveur dobjet traite les donnes avec les bases de
donnes (en tout genre)
5. Le serveur dobjet retourne les objets au serveur
dapplication
6. Le serveur dapplication renvoie le rsultat au serveur web
7. Le serveur web fait suivre le rsultat au client
Pour grer ces objets, un environnement d'exploitation est ncessaire :
le serveur d'objets. Ce serveur d'objets va devoir fournir des services tout
fait diffrents de ceux des serveurs d'application :
Gestion de la persistance des objets,
Gestion des transactions objets mtier
Gestion des montes en charge : ici les mcanismes n'ont rien voir
avec ceux mis en oeuvre pour un serveur d'application. Il faut
pouvoir assurer la transparence de localisation, l'instanciation, ...
des objets mtier ...
75

Prsentation du sujet

Bref, on le voit, on a faire des techniques trs diffrentes. Les


principaux serveurs d'objets ce jour sont les serveurs EJB (Enterprise
Java Beans), Corba. Ils ne sont ncessaires ces dveloppements que si
l'on souhaite utiliser pleinement la logique d'objets mtier.
Il est donc important de ne pas mlanger ces notions afin d'viter de se
faire prendre comme 80% des acheteurs de serveurs J2EE (incluant
serveur d'application et serveur d'objets) qui n'utilisent que le moteur de
JSP/Servlets dont les cots sont beaucoup plus limits que l'ensemble J2EE
(incluant le serveur d'objets EJB).
Sur le terrain, on rencontre beaucoup plus de dveloppements sur des
serveurs d'application seuls que d'applications utilisant des serveurs
d'objets. En fait, le march des serveurs d'application s'est fortement
structur depuis une ou deux annes. De plusieurs dizaines de
technologies il y a peu, seules trois technologies mergent aujourd'hui :
l'offre Java, l'offre Microsoft et l'offre PHP. Hormis cas particulier, nous
recommandons de ne pas sortir de ces trois choix.
Les points cls d'une architecture sont les capacits transactionnelles
du serveur d'application dlivrer des pages et intgrer une monte en
charge L'ergonomie au sens large est un autre point cl. Les choix de
design doivent prendre en compte les contraintes du Web (taille des
images, ...).
Le march offre trois familles de solutions de dveloppement pour les
serveurs d'application.
Les solutions de scripting peuvent tre simples et productives mais
plutt orientes vers les sites jetables, de type vnementiel. Un
site en ASP, PHP 3 ou ColdFusion peut tre dvelopp trs
rapidement ; par contre, sa maintenance est complique voire
quasi-impossible.
Les solutions orientes objets techniques permettent de factoriser le
code sans rentrer dans la complexit des objets mtier. Il est
76

Prsentation du sujet

important d'imposer des rgles de dveloppement prcises ses


quipes et prestataires. Les dveloppements JSP/Servlets/JavaBeans,
PHP4/5, ASP/DCOM (et ASP.Net/DCOM) permettent de tels
dveloppements.
Les solutions orientes mtier sont plus complexes et plus
coteuses mettre en oeuvre. Elles ncessitent la mise en place de
serveur d'objets. On retrouve principalement sur ce march les
serveurs d'EJB libres et propritaires.
Pour ces trois familles de solutions, des produits Open Source existent
et sont de plus en plus adopts dans les administrations et entreprises
(TomCat, JBoss, JonAS).
5.7. J2EE en pratique
5.7.1. J2EE contre ses concurrents
Chaque plateforme de dveloppement a ses avantages et ses
inconvnients. Le premier avantage de cette plateforme est quelle a t
adopte par les plus grands groupes dans le monde entier. Nous parlons,
bien entendu dIBM, Oracle, BEA .
Celle-ci est galement stable et fiable, en effet, elle existe depuis 1998
et volue constamment. Mme si cest Sun Microsystems qui organise les
spcifications de cette plateforme, elle a depuis le dbut su couter les
retours de dveloppeurs. Sun a mis en place un systme de spcifications
pour lesquelles les dveloppeurs peuvent indiquer leurs besoins, solutions
ou mcontentement.
De plus, la plateforme sappuyant sur Java, permet davoir des
applications totalement indpendantes de la plateforme systme utilise
(aussi bien Windows que Linux ou Mac OS).
Son concurrent principal est la plateforme .Net (dvelopp par
Microsoft). Cette plateforme, bien que plus facile prendre en main,
manque de maturit et mme si elle sduit certaines entreprises, elle est
77

Prsentation du sujet

plutt utilise pour les projets beaucoup moins importants, complexes que
ceux utilisant J2EE.
.Net na bien sr rien envier J2EE et rciproquement. De plus,
linteroprabilit tant de plus en plus exploite, J2EE et .Net peuvent
communiquer ensemble de faon transparente.
5.7.2. Composants standard contre framework
Nous vous avons prsent le standard J2EE avec lensemble de ses
composants. Cependant il est parfois lourd dutiliser un composant conu
pour de grande architecture alors que notre application est restreinte.
Lensemble de la communaut OpenSource (principalement) sest occup
(et soccupe) de lancer sur le march des frameworks servant simplifier
lutilisation de telle ou telle technologie.
Souvent plus limit que le standard, les framework sont plus simple
dutilisation et plus performant dans certains cas.
5.7.2.1.EJB vs Hibernate vs Spring
Les EJB peuvent parfois tre la bte noire des dveloppeurs J2EE. En
effet, ils ne sont pas vident mettre en place et sont souvent lourds
lutilisation. Ils sintgrent le plus souvent dans les projets de grandes
envergures.
Pour les projes plus courants et plus petits, les framework Hibernate et
Spring peuvent trs largement remplacer ces EJB.
5.7.2.1.1. Prsentation
Les EJB grent laccs et le traitement des donnes (persistantes ou
non). Pour faire de mme avec lutilisation de framework externe, il faut
en utiliser deux en gnral.
Hibernate : cest un framework qui permet de mapper une base
de donnes relationnelle en objets (POJO : Plain Old Java Object). Il
permet donc dabstraire totalement laccs la base de donnes et
propose donc un accs totalement orient objet aux donnes.
78

Prsentation du sujet

Spring : cest un framework qui permet de remplacer la lourdeur


des serveurs dapplication lourds. En effet, on parle de conteneur
lger . Il prend en charge la cration et la mise en relation dobjets
par lintermdiaire dun fichier de configuration dcrivant lensemble
de ces relations. Lun des avantages principal est quil nimpose pas
dhriter ou dimplmenter une quelconque interface ou classe
contrairement aux EJB.
5.7.2.1.2. Utilisation
Lutilisation de ces deux frameworks dans une mme application est
recommande, en effet Hibernate vous permet daccder aux donnes
alors que Spring vous servira de fabrique automatise !
De plus ces deux framework sintgrent trs facilement et ne ncessite
quun moteur de servlet. Contrairement aux EJB qui ncessitent un
serveur dapplication les grants (beaucoup plus lourd !).
5.7.2.2.Servlet et JSP vs Struts
Avec larrive des JSP aprs celle des Servlets, les dveloppeurs ont pu
commencer sparer de faon remarquable la couche prsentation de la
couche application / traitement. Cependant la maintenance du code et la
lourdeur dutilisation des servlets ont montr leurs limites
Le modle MVC que chaque dveloppeur pensait de son ct tait
chaque fois trop limit et peu volutif.
Larrive de Struts a permis davoir une base solide rpondant un
modle MVC bien cadr.
5.7.2.2.1. Prsentation
Struts est un framework qui permet de construire des applications web.
Il se base sur la technologie Servlet / JSP en ajoutant la prise en charge du
Modle MVC2 (Modle Vue Contrleur). Il fournit la charpente dune
application web et vite aux dveloppeurs davoir grer de faon
fastidieuse la sparation Modle Vue Contrleur.
5.7.2.2.2. Utilisation
79

Prsentation du sujet

Lutilisation de ce framework est quasiment omniprsente dans le


dveloppement dapplication web. Cependant Struts nest pas la seule
technologie aidant au dveloppement de la couche application /
prsentation web. En effet, on peut galement retrouver JSF (Java Server
Faces) ou Cocoon
5.8. Serveur dapplication : utilisations et limites
Les serveurs dapplication se sont dvelopps depuis la cration de
J2EE. On peut distinguer principalement 2 grandes catgories de
serveurs :
Open Source : volue grce la communaut
Propritaire : volue selon lditeur
Chaque catgorie a ses avantages et ses inconvnients. Nous allons
dcrire les serveurs les plus connus afin davoir une vision globale des
solutions disponibles.
5.8.1. Open Source
5.8.1.1. Tomcat Apache
Tomcat est un conteneur de servlet qui implmente la rfrence
officielle pour les Servlet Java et les JSP. Ce serveur est trs rpondu pour
les applications web.
Source : http://jakarta.apache.org/tomcat/index.html
Technologies implmentes :
JSP
Servlet
JDBC
JNDI

5.8.1.2.Jonas ObjectWeb
Jonas est un serveur dapplication implmentant la rfrence officielle
pour les EJB. Il intgre un lien avec Tomcat afin dintgrer les
fonctionnalits pour les applications web.
80

Prsentation du sujet

Source : http://jonas.objectweb.org/
Technologies implmentes :
JSP
Servlet
EJB
JCA
JDBC
JTA
JMS
JMX
JNDI
JAAS
JavaMail

5.8.1.3.JBoss

JBoss accumule les mmes fonctionnalits que Jonas. Cependant son


architecture est assez diffrente et repose principalement sur un BUS .
Des projets gravitent autour de ce serveur tels que des plug-in pour
Eclipse, des modules pour lAOP (Aspect Oriented Programming),
Hibernate
JBoss est lun des serveurs dapplication les plus populaires dans lOpen
Source (avec Jonas). Il est galement de plus en plus utilis en milieu
professionnel.
Source: http://www.jboss.org/products/jbossas

5.8.2. Propritaire

Les serveurs dapplication propritaires se dmarquent grce des


outils facilitant le dveloppement et/ou la configuration des applications
au sein du serveur dapplication.
81

Prsentation du sujet

En contrepartie, ils font payer les licences dutilisation de leur serveur.


Voici un ensemble de serveurs les plus utiliss :
WebSphere : IBM
WebLogic : BEA
WebObject : Apple
Oracle Application Server : Oracle

5.9. IDE (Integrated Development Environment)

Pour dvelopper des applications complexes, il faut imprativement un


IDE (Integrated Environnement Development).
De mme quavec les serveurs dapplication, il existe les IDE Open Source
et ceux qui sont propritaires.
Voici une prsentation de quelques IDE les plus connus.
5.9.1. Open Source
5.9.1.1.Eclipse : IBM
Un outil trs bien cr car il est simple utilis, et il permet
dapprendre java. Cependant, beaucoup de plugins sont prsents, et ils
vous aideront aller de plus en plus loin au fur et mesure de votre
apprentissage.
Lien : http://www.eclipse.org
5.9.1.2.NetBeans : Sun
Un autre outil trs bien ralis pour apprendre. Comme cest un outil
ralis par Sun, il intgre merveille des outils comme Sun Application
Server, de plus, il intgre des plugins de trs bonne qualit, comme le
profiler, qui permet de monitorer vos applications. On regrte quil nest
pas autant de plugins que eclipse mme si il est globalement daussi
bonne voir de meilleur qualit.
Lien: http://www.netbeans.org
5.9.2. Propritaire
82

Prsentation du sujet

5.9.2.1.Rational Software Architect (RSA)


Un outil taill pour les professionnels car il permet des fonctionnalits
trs puissantes. La gnration de code et lutilisation doutil de
modlisation sont trs pousses. Cependant il est permable aux
dbutants, pour qui Eclipse est mieux adapt, et il reste trs cher. Il est
dailleurs bas sur Eclipse.
Lien : http://www-306.ibm.com/software/fr/awdtools/
5.9.2.2.XCode et WebObject : Apple
Apple propose une solution trs puissante, trs base sur laspect
WYSIWYG, tout en ayant une programmation trs propre et efficace.
Cependant, cette solution ne fonctionne que sous Mac.
5.9.2.3.JDeveloper Oracle
Oracle JDeveloper est un EDI complet et gratuit permettant de
modliser et dvelopper des applications Java pour les plateformes J2SE,
J2EE ou J2ME. Il est trs bien intgr aux bases de donnes Oracle, avec
notamment un dbuggueur PL/SQL.
5.10. Le futur de J2EE
J2EE est une plateforme en constante volution. La version 1.4 est celle
utilise dans la plus part des serveurs actuels et la version 1.5 viens de
sortir.
Cette version corrigera des spcifications parfois trop complexes. Elle
ajoutera galement de nouveaux composants la plateforme afin de
faciliter toujours plus le dveloppement dapplication dentreprise.
Voici la nouvelle architecture de la nouvelle version de J2EE.
83

Prsentation du sujet

Figure 27 : architecture J2EE5


Le JDK 1.5 intgre de nouvelles fonctionnalits, cest donc pour cela
que la version J2EE 5 les utilisera afin davoir une plateforme bien plus
abordable que la prcdente et beaucoup plus optimise.
84

Prsentation du sujet

6. Spcifications et exigences du
systme

6.1. Description gnrale


85

Prsentation du sujet

6.1.1. Objectifs
Lobjectif premier de cette partie est de :
Dfinir les spcifications et exigences de notre systme
Dgager les diffrentes fonctionnalits du systme
Dfinir larchitecture gnrale du systme
Reprsenter la solution sous forme dartfacts
La vue densemble du projet consiste mettre en place une
application distribue de supervision, de taxation et de gestion des quotas
tlphoniques partir des informations gnrs par le Call Manager de
CISCO (CDR).
Le contexte dapplication du projet est de pouvoir utiliser les
informations des communications tlphoniques gnres par le Call
Manager afin de pouvoir effectuer une taxation, une gestion de quotas de
communications, et avoir des statistiques sur lvolution des
consommations.
6.1.2. Vue densemble des fonctionnalits du systme
6.1.2.1.Gestion de la scurit
Ce module intgrera la gestion des utilisateurs et de leurs profils, la
gestion des fonctionnalits et des permissions. Il permettra entre autre
un utilisateur donn de pouvoir se connecter lapplication et de pouvoir
consulter ltat de ses communications tlphoniques.
6.1.2.2.Gestion du paramtrage
Ce module permettra la gestion des paramtres de lapplication,
notamment les informations de la socit, lenvoi ventuel de mail dans le
cas du dpassement de quotas tlphoniques, la mise jour des
informations sur loprateur et ses tarifs de communications.

6.1.2.3.Gestion de la facturation
86

Prsentation du sujet

Ce module intgrera la taxation des consommations tlphoniques


dun poste, dun service, ou dun site suivant des priodes (Semaines,
mois, annes) et en fonctions des tarifs oprateurs qui seront fixs au
niveau du module de gestion du paramtrage.
6.1.2.4.Gestion des Statistiques
Ce module permettra dtablir des statistiques sur les
consommations tlphoniques effectues avec possibilit de les imprimer.
6.1.2.5.Gestion des appels
Ce module intgrera la gestion des quotas tlphoniques, la mise
jour des postes, il permettra aussi de pouvoir consulter les appels mis
par poste, par priode suivant le profil utilisateur.
6.1.3. Perspective du systme
Plusieurs produits offrent des alternatives intressantes, seulement
notre systme aura la particularit doffrir une fonctionnalit en plus de
celle prsente dans les autres produits, savoir de pouvoir grer les
quotas tlphoniques qui plus est dans un environnement IP et en temps
rel.

Figure 28 : une vision du systme


6.2. Modles des cas dutilisation
87

Prsentation du sujet

Les figures ci-aprs dcrivent sous forme schmatique les cas


dutilisation du systme qui correspondent aux fonctionnalits numres
plus haut.

Figure 29 : cas dutilisation pour la gestion de la scurit


88

Prsentation du sujet

Figure 30 : cas dutilisation pour la gestion des appels


89

Prsentation du sujet

Figure 31 : cas dutilisation pour la gestion de la facturation

Figure 32 : cas dutilisation pour la gestion des statistiques


90

Prsentation du sujet

Figure 33 : cas dutilisation pour la gestion du paramtrage


6.3. Modles conceptuels
Chaque objet de domaine reprsente une table du systme. Une ligne
entre deux objets signifie quil existe une relation entre les objets et
chaque relation est de type un plusieurs comme dcrit dans la figure
ci-dessous :

Figure 34 : Cardinalits entre objets de domaine


91

Prsentation du sujet

6.3.1. Gestion de la scurit

Figure 35 : Modle de domaine de la gestion de la scurit


6.3.2. Gestion des appels

Figure 36 : Modle de domaine de la gestion des appels


92

Prsentation du sujet

6.3.3. Gestion du paramtrage

Figure 37 : Modle de domaine de la gestion du paramtrage


6.4. Contraintes dordres gnrales
6.4.1. Limitation du matriel
tant donn quil sagit dun systme distribu le systme pourra
tre dploy sur plusieurs machines (un pour le serveur dapplication, un
autre pour le serveur web) ou sur un seul ordinateur (un seul serveur
dapplication + serveur web).
6.4.2. Interface dautres systmes
Notre systme aura un lien avec le PBX, ce dernier avertira le
systme lorsquune communication tlphonique sera initie afin que lon
puisse agir sur elle (gestion de quota ou supervision des appels). Ce lien
sera effectu au travers dune API java
6.4.3. Contrainte au niveau langage de programmation
Nous utiliserons java comme langage de programmation pour sa
robustesse, sa potabilit mais aussi pour son architecture qui a tous points
de vue offre une scurit dans lexcution des programmes.
6.4.4. Exigences de fiabilit
93

Prsentation du sujet

Il est vident que la base de donnes devra tre sauvegarde pour


conserver lintgrit des donnes et pour prvenir tous actes de dsastre.
Pour le moment, le comment et lendroit de la sauvegarde nont pas t
dfinis.
6.4.5. Sret et scurit
Les utilisateurs du systme pourront y accder grce un login et un
mot de passe.
6.5. Hypothses et dpendances
Java est un langage indpendant de la plateforme, ce qui nous
permettra de dvelopper notre systme sans se proccuper du systme
dexploitation sur lequel il sera dploy.
6.6. Description dtaille
6.6.1. Description textuelle des cas dutilisation
Ci-dessous une description textuelle de quelque cas dutilisation du
systme.
Cas dutilisation Sauthentifier
Acteur(s) principal (aux) Un utilisateur (administrateur ou autre)
Brve description Le systme authentifie lutilisateur qui se connecte
Pr condition(s) La page dauthentification est affiche au niveau du
navigateur
Post condition(s) Lutilisateur est authentifi
Scnario principal Lutilisateur entre au niveau de la page dauthentification
son login et son mot de passe et valide. Le systme vrifie
que les informations entres par lutilisateur sont valides et
le redirige vers la page principal.
Scnario(s) alternatif(s)
Scnario(s) dexception Les informations entres par lutilisateur ne sont pas
correctes, le systme aprs vrification affiche une erreur

Cas dutilisation Vrifier quotas


Acteur(s) principal (aux) System
Brve description Le systme vrifie que le ou les quotas ne sont pas atteints
ou dpasss
Pr condition(s) Un appel est mis, le PBX informe le systme
Post condition(s) Le ou les quotas sont vrifis
Scnario principal Une connexion vient dtre tablit entre un poste et le PBX
(initialisation dune communication), le systme vrifie si le
94

Prsentation du sujet

quota est dpass ou pas.


Scnario(s) alternatif(s)
Scnario(s) dexception

Cas dutilisation Bloquer poste


Acteur(s) principal (aux) System
Brve description Le systme envoi une notification au PBX pour quil bloque
un poste
Pr condition(s) Le serveur est en marche et fonctionnel
Le quota est vrifi
Post condition(s) le poste est bloqu
Scnario principal Le systme vrifie le quota du poste, si le quota est dpass
le systme notifie le PBX dinterrompre la communication
en cours.
Scnario(s) alternatif(s)
Scnario(s) dexception

6.6.2. Spcifications fonctionnelles


6.6.2.1.Diagrammes de classe
Chaque objet de domaine reprsente une table du systme. Une ligne
entre deux objets signifie quil existe une relation entre les objets et
chaque relation est de type un plusieurs comme dcrit dans la figure
ci-dessous :

Figure 38 : Cardinalit en objet de domaine


6.6.2.1.1. Gestion de la scurit
95

Prsentation du sujet

Figure 39 : Diagramme de classe de la gestion de la scurit

6.6.2.1.2. Gestion des appels


96

Prsentation du sujet

Figure 40 : Diagramme de classe de la gestion des appels

6.6.2.1.3. Gestion du paramtrage


97

Prsentation du sujet

Figure 41 : Diagramme de classe de la gestion du paramtrage


6.6.2.2.Diagrammes de squence
6.6.2.2.1. Interaction des diffrents composants
Globalement toutes les requtes du client connect au travers dun
browser passeront par une servlet GatewaySerlet centrale. Cette
servlet va soccuper de rechercher le cas dutilisation (UseCase Controller)
excuter suivant le type de requte du client. Les UseCase Controller
peuvent interagir avec plusieurs objets de domaine. Les objets de
domaine dialoguent avec la base de donnes au travers de deux classes :
une abstraite et une classe implmentant un langage SQL spcifique la
source de donnes ce qui permet dutiliser au sein de lapplication
plusieurs source de donnes.
98

Prsentation du sujet

Figure 42 : Diagramme dinteraction des composants de lapplication


6.6.2.2.2. Diagramme de squence ADD1 (GET)
Ce diagramme de squence reprsente les squences daction
excuter lors de lajout dun enregistrement de manire gnral. Chaque
appel une page devant faire une insertion denregistrements dans une
table passera par cette squence daction. Cette squence nest valable
que pour linsertion dans une seule table pour les insertions dans plusieurs
tables, il existe dautres squences daction qui seront excutes.
99

Prsentation du sujet
100

Prsentation du sujet

6.6.2.2.3. Diagramme de squence ADD1 (POST)


Une fois que lutilisateur valide son formulaire lensemble daction ci-
dessous est excut. Il part du mme principe que le premier diagramme
savoir que pour toute validation de formulaire, cest cet ensemble
daction qui sera excut avant toute insertion en base.
101

Prsentation du sujet
102

Prsentation du sujet

6.6.3. Exigences logiques de bases de donnes


La base de donnes utilise pour le systme sera conue selon le
concept de bases de donnes relationnelles. Toutes les donnes seront
accessibles selon les droits attribus aux utilisateurs du systme.
Les donnes persistantes reprsenteront essentiellement celles
permettant une bonne gestion de la taxation des appels et de la gestion
des quotas tlphoniques.
6.6.4. Exigences non fonctionnelles
Notre systme reposera sur une architecture n-tiers solide offrant un
accs au travers dun simple navigateur. Seuls les utilisateurs internes la
socit pourront y avoir accs selon des droits dutilisation relativement
fiables. Vu le langage utilis le problme de portabilit ne se pose pas.
6.6.5. Exigences au niveau du PBX
Le PBX (CALL Manager) avec qui initialement notre application sera
interface devra tre configur de manire ce que lutilisateur que nous
allons employer pour nous enregistrer au pr du PBX ait sa charge la
supervision de tous les postes IP CISCO mais aussi il faudrait que lon lui
active lutilisation dapplication CTI (Computer Telephone Integration).
Cette configuration pralable se fera au travers de linterface
dadministration du CALL Manager.
6.7. Classes dimplmentation
Ci-dessous quelques classes dimplmentation de lapplication :
La classe GatewayServlet
Lobjectif de cette classe est de faire un mappage entre les
noms des cas dutilisation et les composants UseCaseController .
Cest travers cette servlet que toutes les requtes http passent. Le
mappage est dcrit dans une fichier de configuration :
UsesCases.xml. Le nom du cas dutilisation est pass comme
paramtre dinitialisation la servlet et est utilis comme cl dans la
Map de UseCaseController . Cette Map est ensuite place dans la
103

Prsentation du sujet

session de lutilisateur afin de faciliter la localisation de


UseCaseController . La servlet effectue un lookup du
UseCaseController correspondant au nom du cas dutilisation
pass en paramtre avant dappeler la mthode run du
UseCaseControler .
infra en ANNEXE
Linterface UseCaseControler
Tous les UseCaseControler implmentent cette interface et
redfinissent ainsi selon leur besoin la mthode run . Le
paramtre ServletConfig fourni un accs au contexte de la servlet
qui peut tre utilis pour lire des fichiers se trouvant dans la
structure de rpertoire de lapplication web. Le paramtre
HttpServletRequest fourni laccs certains paramtres mais aussi
aux objets de la session utilisateur. Le paramtre
HttpServletResponse fourni un accs la sortie standard (navigateur
du client) requis pour envoyer une rponse de type HTML ou autre
au client.
infra en ANNEXE
Le descripteur de deployment (web.xml)
Cest dans ce fichier que lon spcifie les noms des servlets et
leurs paramtres dinitialisation. Dans notre cas chaque cas
dutilisation aura une entre dans le fichier de ce type :
infra en ANNEXE
Le fichier UsesCases.xml
Utilis pour mapper un cas dutilisation avec son
UseCaseControler correspondant :
infra en ANNEXE

La classe Jtrace
104

Prsentation du sujet

Cette classe permet de tracer toutes les communications qui


transitent par le PBX IP. Cest dans cette classe aussi que lon a
vrifier, suivant lvnement, quun utilisateur na pas dpass sa
limite de quota.
infra en ANNEXE
Conclusion
1) Bilan
Notre travail consistait concevoir et raliser une application de
supervision, de taxation et de gestion des quotas sur un rseau de tlphonie sur
IP.

Seule une partie de la conception pu tre ralise ce jour compte tenu


de certaines contraintes matrielles et de temps.

Le module de gestion de la scurit, le module de gestion des quotas et le


module de supervision des appels qui reprsentent en quelque sorte, le noyau de
lapplication, ont t dvelopps. Le but tait de pouvoir disposer de cet ensemble
de fonctions avant lintgration du module de taxation.

2) Perspectives
A lissu de ce projet, lobjectif est de mettre en place ce systme au prs
dentreprise disposant de PBX IP que ce soit du CISCO, ASTERISK, ou un autre et
ne voulant pas trop dpenser pour acqurir un tel systme. Il faut dire que de tels
outils existent mais seulement ils sont propritaires et cotent cher.

Outre la mise en place en interne de la solution, une intgration dautres


PBX-IP tel que ASTERISK sera faite afin que la solution puisse tre dploye aux
prs dentreprises de la place. Dj deux entreprises ce sont montres
intresses.
Bibliographie

1) Les sites web


Site Description
http://www.ibm.com
http://www.improve-technologies.com improve technologies
http://solutions.journaldunet.com/printer/0304 Panorama des services et composants
01_j2ee.shtml J2EE
http://javarome.free.fr/net/JAAS.html Site de JAAS Java Authentication and
Authorization Service.
http://www.portalscommunity.com/library/fund Un article trs intressant sur les
amentals.cfm fondamentaux concernant les portails
dentreprise
http://www.portalscommunity.com Site sur les portails dentreprise
http://www.infini-fr.com/ Vulgarisation informatique et ressources
gratuites
http://www.application-server.com Site sur les serveurs dapplication
http://www.01net.com
http://uml.free.fr
http://www.uml.org/
http://www.rational.com/uml/
http://www.commentcamarche.net Vulgarisation informatique et ressources
gratuites
http://www.polymorphe.org Ressources (cours, logiciels, etc.) gratuites
http://www.developpez.com Site de ressources pour dveloppeurs
http://java.sun.com/product/jtapi/jtapi-
1.2/Overview.html
http://www-
rocq.inra.fr/who/Philippe.Sultan/iptelJavaCisco.
html
http://www.application-servers.com
http://supinfo-projects.com/
http://www.asteriskjava.org
http://www.voip-inf.org

2) Ouvrages gnraux

o C.BROILLET, F. DUTOIT : Mmoire de fin de cycle, Mise en place dun


mulateur JTAPI
o Mircea Calota : Mmoire de fin de cycle, Dveloppement doutils de
gestion et monitoring des iPBX sous JTAPI
o Mourad El ALLIA : Mmoire de fin de cycle, DVELOPPEMENT DUN
ENVIRONNEMENT DE COMMUNICATION MULTIMDIA (VOIX ET VIDO)
SUR INTERNET
o Sebastien PIERRE : Mmoire de fin de cycle, Conception et ralisation
d'une plateforme applicative pour le protocole SIP

3) Ouvrages spcialiss
o SUN Microsystems : Telecom Network Management with Enterprise
JavaBeans Technology, Mai 2001
o CISCO Systems :

Cisco CallManager 3.3(2) Call Detail Record Definition, 2002


Cisco IP Telephony Network Design Guide, 2000 - 2001

o Lucent Technologies : Java Telephony API (JTAPI) Client Programmers


Guide, Octebre 1997
ANNEXE

1) Exemple de droulement dun programme JTAPI

Nous allons ici voir les tapes communes tout programme JTAPI.
Initialisation du moteur
JtapiPeer peer = JtapiPeerFactory.getJtapiPeer ( null );
System.out.println("Get Provider");
provider = peer.getProvider ( providerString );

Ajout dun observateur sur lobjet Provider


provider.addObserver(this);
Il faut effectivement attendre que le provider soit en tat de grer les
demandes que nous lui ferons par la suite. Pour ceci il faut attendre quil passe
dans ltat IN_SERVICE
Gestion de ltat du provider

public void providerChangedEvent(ProvEv[]eventList) {

if ( eventList != null ) {

for ( int i = 0; i < eventList.length; i++ ) {

if ( eventList[i] instanceof ProvInServiceEv ) {

//Provider prs nous pouvons passer la suite

Un fois le provider en tat de recevoir nos demandes, il nous suffit en


fonction des besoins du programme dinstancier des objets Address ou/et
Terminal. Dans lexemple nous allons nous occuper seulement dun objet Address,
la mthodologie pour le Terminal est exactement la mme.

Demande au provider de lAddress


Address addr = provider.getAddress(Numero_de_telephone);

addr.AddObserver(this);

Gestion de ltat de lobjet Address

public void addressChangedEvent ( AddrEv [] events ) {

if(events != null){

for(int i=0;i<events.length; i++){

switch(events[i].getID()){

case CiscoAddrInServiceEv.ID:

break;

2) Implmentation CISCO et exemple

La premire chose faire est de se "connecter" l'interface JTAPI du Call Manager.


Pour ce faire, il faut crer un objet JtapiPeer l'aide de la mthode statique getJtapiPeer
de l'objet JtapiPeerFactory :

JtapiPeer peer = JtapiPeerFactory.getJtapiPeer(null);

//le paramtre null slectionne l'objet JtapiPeer par dfaut: celui implment par Cisco

Cet objet va nous permettre de nous connecter au Call Manager en fournissant


l'adresse IP du Call Manager et en nous authentifiant en tant qu'utilisateur disposant des
privilges de contrle des postes IP superviser :

Provider provider = peer.getProvider("192.168.1.1, login=login;passwd=passwd");

Note : il est indispensable que l'administrateur Call Manager fournisse


l'utilisateur considr le contrle de tous les postes IP superviser (cf infos utilisateur
dans l'interface d'administration du Call Manager), et qu'il lui active l'utilisation
d'application CTI.

A partir de maintenant, nombre d'vnements JTAPI pourront tre traits par notre
application suivant qu'on dveloppera le code ncessaire.

3) Classes dimplmentation

o La classe GatewayServlet

package fw.homework.xgen.controller;

import java.io.IOException;
import java.io.InputStream;
import java.util.HashMap;
import java.util.Map;
import javax.servlet.ServletConfig;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.servlet.http.HttpSession;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.NodeList;
import org.xml.sax.InputSource;
import com.sun.org.apache.xerces.internal.parsers.DOMParser;
import fw.homework.xgen.exception.UseCaseControllerException;
import fw.homework.xgen.includes.Constant;
import fw.homework.xgen.includes.Globals;
import fw.homework.xgen.includes.Session;
import fw.homework.xgen.util.XmlUtil;

public class GatewayServlet extends javax.servlet.http.HttpServlet implements


javax.servlet.Servlet {

private static final long serialVersionUID = 1L;


private ServletConfig CONFIG;

public GatewayServlet() {
super();
}

protected void doGet(HttpServletRequest request,


HttpServletResponse response) throws ServletException, IOException {
processRequest(request, response);
}

protected void doPost(HttpServletRequest request,


HttpServletResponse response) throws ServletException, IOException {
processRequest(request, response);
}

public void processRequest(HttpServletRequest request,


HttpServletResponse response) throws ServletException, IOException {
//
Map controllers = null;
Globals globals = null;
//
try {
//
globals = (Globals) request.getAttribute("GLOBALS");
//
if (globals == null) {
globals = new Globals();
request.setAttribute("GLOBALS", globals);
}
//
CONFIG = getServletConfig();
//
HttpSession session = Session.initSession(CONFIG, request,
response, globals);
//
controllers = (Map) session.getAttribute("controllers");
//
if ((controllers == null) || (controllers.isEmpty())) {
controllers = getUseCasesControllers(request, response);
session.setAttribute("controllers", controllers);
}
//
String useCase = getInitParameter("useCase");
//
UseCaseController caseController = (UseCaseController) controllers
.get(useCase);
//
if (caseController != null) {
//
CONFIG = getServletConfig();
//
caseController.run(CONFIG, request, response);
} else {
throw new UseCaseControllerException(Constant.NOSUCHCONTROLLER);
}
} catch (Exception exception) {
exception.printStackTrace();
triggerError(request, response, exception);
}
}

public Map getUseCasesControllers(HttpServletRequest request,


HttpServletResponse response) throws ServletException, IOException {
//
Map controllers = new HashMap();
//
try {
//
ServletContext context = CONFIG.getServletContext();
//
InputStream is = context
.getResourceAsStream(Constant.USECASES_XML_PATH);
//
DOMParser parser = new DOMParser();
parser.parse(new InputSource(is));
Document document = parser.getDocument();
//
NodeList useCases = document.getElementsByTagName("useCase");
//
int count = useCases.getLength();
//
for (int i = 0; i < count; i++) {
Element useCase = (Element) useCases.item(i);
String name = XmlUtil.getChildValue(useCase, "name").trim();
//
String controller = XmlUtil
.getChildValue(useCase, "controller").trim();
//
Class controllerClass = Class.forName(controller);
controllers.put(name, controllerClass.newInstance());
}
} catch (Exception exception) {
exception.printStackTrace();
triggerError(request, response, exception);
}
return controllers;
}

public void triggerError(HttpServletRequest request,


HttpServletResponse response, Exception exception)
throws ServletException, IOException {
//
request.setAttribute("THROWABLE", exception);
//
UseCaseController errorController = new ErrorHandlerController();
errorController.run(CONFIG, request, response);
}
}

o Linterface UsecaseController

package fw.homework.xgen.controller;

import java.io.IOException;
import javax.servlet.ServletConfig;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public interface UseCaseController {

public void run(ServletConfig config, HttpServletRequest request,


HttpServletResponse response) throws IOException;
}

o Le descripteur de dploiement

<servlet>
<display-name>CallEvent</display-name>
<servlet-name>CallEvent</servlet-name>
<servlet-class>
fw.homework.xgen.controller.GatewayServlet
</servlet-class>
<init-param>
<param-name>useCase</param-name>
<param-value>CallEvent</param-value>
</init-param>

</servlet>

o Le fichier UsesCases.xml

<useCases>
<useCase>
<name>CallEvent</name>
<controller>
fw.homework.xgen.controller.CallEventController
</controller>
</useCase>
</useCases>

o La classe Jtrace
package fw.homework.xgen.tracer;

import javax.telephony.Address;
import javax.telephony.JtapiPeer;
import javax.telephony.JtapiPeerFactory;
import javax.telephony.Provider;
import javax.telephony.ProviderObserver;
import javax.telephony.Terminal;
import javax.telephony.callcontrol.CallControlCallObserver;
import javax.telephony.events.AddrEv;
import javax.telephony.events.CallEv;
import javax.telephony.events.ConnEv;
import javax.telephony.events.Ev;
import javax.telephony.events.ProvEv;
import javax.telephony.events.ProvInServiceEv;
import javax.telephony.events.ProvShutdownEv;
import javax.telephony.events.TermConnEv;
import javax.telephony.events.TermEv;
import javax.telephony.media.MediaCallObserver;
import com.cisco.cti.util.Condition;
import com.cisco.jtapi.extensions.CiscoAddressObserver;
import com.cisco.jtapi.extensions.CiscoJtapiVersion;
import com.cisco.jtapi.extensions.CiscoTerminalObserver;

public class JTrace extends TraceWindow {

private static final long serialVersionUID = 1L;


public static String PROVIDER_STRING = "10.10.30.2;login=xxx;passwd=xxxxx";
private Provider provider;
private Condition provInService = new Condition();
private Condition provOutOfService = new Condition();

public JTrace() {
print("JTrace" + ": " + new CiscoJtapiVersion());
print("Opening " + PROVIDER_STRING + "...\n");
initJtapi(PROVIDER_STRING);
}

public static void main(String[] args) {


new JTrace();
}

public void dispose() {


if (provider != null) {
println("Shutting down...");
provider.shutdown();
provOutOfService.waitTrue();
println("Provider is shut down...");
System.exit(0);
}
}

private void initJtapi(String providerString) {


// TraceWindow trace = new TraceWindow(providerString);
try {
JtapiPeer peer = JtapiPeerFactory.getJtapiPeer(null);

ProviderObjectObserver providerObserver = new ProviderObjectObserver();

provider = peer.getProvider(providerString);

if (provider != null) {
print("Provider name: " + provider.getName() + "\n");
provider.addObserver(providerObserver);
provInService.waitTrue();

Address[] addresses = provider.getAddresses();


if (addresses != null) {
for (int i = 0; i < addresses.length; i++) {
print("Address \"" + addresses[i].getName() + "\"");
MyCallObserver observer = new MyCallObserver(this);
addresses[i].addCallObserver(observer);
addresses[i].addObserver(observer);
addresses[i].getTerminals()[0].addObserver(observer);
// trace.show();
//
print("Address[" + i + "]: " + addresses[i].getName()
+ "\n");
Terminal[] terminals = addresses[i].getTerminals();
if (terminals != null) {
for (int j = 0; j < terminals.length; j++) {
print("\tTerminal[" + j + "]: "
+ terminals[j].getName() + "\n");
}
}
print("\n");
}
print("\n");
}

Terminal[] terminals = provider.getTerminals();


if (terminals != null) {
for (int i = 0; i < terminals.length; i++) {
Terminal curTerm = terminals[i];
print("Terminal[" + i + "]: " + curTerm.getName()
+ "\n");
Address[] address = terminals[i].getAddresses();
if (address != null) {
for (int j = 0; j < address.length; j++) {
print("\tAddress[" + j + "]: "
+ address[j].getName() + "\n");
}
}
print("\n");

}
print("\n");
}
} else {
print("Provider is null\n");
}
} catch (Exception e) {
e.printStackTrace();
print(e.getMessage());
}

private class ProviderObjectObserver implements ProviderObserver {


public synchronized void providerChangedEvent(ProvEv[] eventList) {
try {
if (eventList != null) {
for (int i = 0; i < eventList.length; i++) {
if (eventList[i].isNewMetaEvent()) {
bufPrint("NEW META EVENT_________");
bufPrint(" for: "
+ eventList[i].getProvider().getName()
+ "\n");
}
bufPrint("Received "
+ eventList[i].getClass().getName() + "\n");

ProvEv ev = eventList[i];
switch (ev.getID()) {
case ProvInServiceEv.ID:
provInService.set();
break;
case ProvShutdownEv.ID:
provOutOfService.set();
break;
}
}
} else {
bufPrint("Error: providerChangedEvent was invoked with a null eventList\n");
}
} finally {
flush();
}
}
}
}

class MyCallObserver implements CallControlCallObserver, MediaCallObserver,


CiscoTerminalObserver, CiscoAddressObserver {

private Tracer trace;


public MyCallObserver(Tracer trace) {
this.trace = trace;
}

public synchronized void callChangedEvent(CallEv[] eventList) {


try {
for (int i = 0; i < eventList.length; i++) {
trace.bufPrint("Received " + eventList[i] + " for ");

if (eventList[i] instanceof ConnEv) {


Address address = ((ConnEv) eventList[i]).getConnection().getAddress();
Connection connection = ((ConnEv) eventList[i]).getConnection();
checkPhoneQuota(connection, address);
trace.bufPrint(address.getName());
} else if (eventList[i] instanceof TermConnEv) {
trace.bufPrint(((TermConnEv) eventList[i])
.getTerminalConnection().getTerminal().getName());
} else if (eventList[i] instanceof CallEv) {
trace.bufPrint("callID=" + ((CallEv) eventList[i]).getID());
}
trace.bufPrint("\n");
}
} finally {
trace.flush();
}

public synchronized void addressChangedEvent(AddrEv[] eventList) {


traceGenericEvents(eventList);
}

public synchronized void terminalChangedEvent(TermEv[] eventList) {


traceGenericEvents(eventList);
}

public void traceGenericEvents(Ev[] eventList) {


try {
for (int i = 0; i < eventList.length; i++) {
trace.bufPrint("Received " + eventList[i]);
trace.bufPrint("\n");
}
} finally {
trace.flush();
}
}
}

public void checkPhoneQuota(Connection connection , Address address) {

Quota quota= new Quota(address.getName());


try {
if (quota.quotaExceed()) {
// quota depass, interruption de la communication
connection.disconnect();
}
} catch (DAOException e) {
e.printStackTrace();
} catch (PrivilegeViolationException e) {
e.printStackTrace();
} catch (ResourceUnavailableException e) {
e.printStackTrace();
} catch (MethodNotSupportedException e) {
e.printStackTrace();
} catch (InvalidStateException e) {
e.printStackTrace();
} }

You might also like