8/7/2019 HENTATI_AYMAN
1/70
8/7/2019 HENTATI_AYMAN
2/70
Ddicaces
lme de mon papa, que dieu le bnisse... ma maman, la plus exquise des mres...
mon bienveillant frre Haitham... ma chre sur Amal...
ma chre Taouba...
tous mes amis qui m'ont rchauffs le curpar leurs e-mails dans toute cette priode etqui mont soutenu la mort de mon pre:
Amine, Ahmed, Sebti, Sinda, Khaoula,Khaled, Walid, Raouya, Abdallah,
Anas, Saousan, Salma
8/7/2019 HENTATI_AYMAN
3/70
Avant-propos
Ce prsent travail a t ralis au sein de SUPCOM. Il sinscrit dans le cadre de mon projet de
fin dtudes lcole suprieure des communications de Tunis (SUPCOM).
Au terme de ce travail, je tiens rendre un grand hommage mon encadreur Mr. Zied
CHOUKAIR qui ma suivi durant ces trois mois de travail, mapportant attention et rigueur dans
lanalyse des rsultats obtenus.
Je tiens galement remercier Mr Mounir FRIKHA, Chef de dpartement SUPCOM pour le
soutien moral qu'il m'a donn.
Un grand remerciement aux membres de jury qui ont bien voulu nous honorer de leur
prsence et de juger ce travail.
Enfin, je veux exprimer de mes fonds, ma reconnaissance ma mre pour l'amour dont ellem'a entour, pour son aide et ses sacrifices.
8/7/2019 HENTATI_AYMAN
4/70
Rsum :
Dans le pass, quand un client demandait un nouveau service, loprateur de rseaux devait demander lquipementier ou au fournisseur de services de fournir de nouveaux paramtres dans les rseaux. Donc, les
oprateurs dpendaient fortement de leurs quipementiers car ils taient les seuls tre capablesde modifier les rseaux. De plus, les fournisseurs de services ont toujours tendance dvelopperdes services propritaires suivant leurs propres normes. Ces contraintes rendent les modificationset la cration de nouveaux services difficiles et trs longues.La technologie JAIN, bas sur la plateforme JAVA, introduit la portabilit des services entresystmes et permet de remplacer toutes les interfaces propritaires par dautres qui sont standardsDans ce contexte, notre travail consiste concevoir une plate-forme de messagerie en se basantsur les spcifications de JAIN.
Mots cls :NGN, AIN, AIN SLEE, SBB, SIP, Messa erie instantane, Prsence, Ada tateur de ressource
8/7/2019 HENTATI_AYMAN
5/70
Glossaire
API Une Interface de programmation (en anglais Application Programming
Interface) dfinit la manire dont un composant informatique peutcommuniquer avec un autre.
Activity Une activit reprsente un ensemble dvnements.
AC (Activity Context)
Un contexte d'activit reprsente l'activit fondamentale dans la SLEE. Elle
tient galement les attributs en commun que les entits SBB veulent partager
Event Un vnement est un composant logique qui permet de diffuser
l'information entre les diffrentes entits de la SLEE
EJB (Enterprise Java Bean)
Cest le composant le plus lmentaire dans la J2EE.
IM (Instant Messaging)
Messagerie synchrone qui permet de recevoir et d'envoyer instantanment
des messages.
JAIN (Java API for Integrated Network)
Cest une initiative au sein de la Java Community Process, dont l'objectif est le
dveloppement d'interfaces de programmation permettant la cration de
services de tlphonie (voix et donnes).
J2EE (Java to Enterprise Edition)
Cest une spcification pour le langage de programmationJava de Sun plus
particulirement destin aux applications d'entreprise.
JCP Le Java Community Process (JCP) est une organisation cre par Sun en
1998. Son but est de coordonner l'volution du langage Java et des
technologies qui lui sont associes.OSA (Open Services Architecture)
Cest une architecture de services ouverte quia t spcifi par le 3GPP
destine aux services mobiles.
Parlay Cest la couche API de OSA
Presence Cest un systme de notification de prsence, indiquant si les individus de la
liste de contacts sont simultanment en ligne et leur disponibilit pour
discuter.
Proxy Il s'occupe de relayer les appels, il agit la fois comme client et serveur.
http://www.dicofr.com/cgi-bin/n.pl/dicofr/definition/20010101004602http://fr.wikipedia.org/wiki/Java_Community_Processhttp://fr.wikipedia.org/wiki/Sp%C3%A9cificationhttp://fr.wikipedia.org/wiki/Langage_de_programmationhttp://fr.wikipedia.org/wiki/Langage_de_programmation_Javahttp://fr.wikipedia.org/wiki/Sun_Microsystemshttp://fr.wikipedia.org/wiki/Sun_Microsystemshttp://fr.wikipedia.org/wiki/1998http://fr.wikipedia.org/wiki/Java_%28langage%29http://fr.wikipedia.org/wiki/Java_%28langage%29http://fr.wikipedia.org/wiki/1998http://fr.wikipedia.org/wiki/Sun_Microsystemshttp://fr.wikipedia.org/wiki/Sun_Microsystemshttp://fr.wikipedia.org/wiki/Langage_de_programmation_Javahttp://fr.wikipedia.org/wiki/Langage_de_programmationhttp://fr.wikipedia.org/wiki/Sp%C3%A9cificationhttp://fr.wikipedia.org/wiki/Java_Community_Processhttp://www.dicofr.com/cgi-bin/n.pl/dicofr/definition/200101010046028/7/2019 HENTATI_AYMAN
6/70
RA (Resource Adaptor)
Assure le mapping entre les messages protocolaires et les vnements.
Registrar Cet quipement associe un utilisateur un identifiant unique connu par les
tierces personnes.
SBB (Service Building Bloc)
Cest le composant le plus lmentaire dans la SLEE.
SLEE (Service Logic Execution Environment)
Cest une spcification pour le langage de programmationJava de Sun plus
particulirement destin aux applications de communications. Elle est
destin pour hberger des services temps rels de type Voix/Donn.
3GPP (Third Generation Partnership Project)
Une organisation internationale qui permet ltablissement des spcifications
techniques pour lensemble de systme de la tlphonie 3 G.
UML (Unified Modeling Language)
Cest un langage servant dcrire des modles dun systme (rel ou logiciel)
avec des notations. UML se base sur les concepts orients objets.
http://fr.wikipedia.org/wiki/Sp%C3%A9cificationhttp://fr.wikipedia.org/wiki/Langage_de_programmationhttp://fr.wikipedia.org/wiki/Langage_de_programmation_Javahttp://fr.wikipedia.org/wiki/Sun_Microsystemshttp://fr.wikipedia.org/wiki/Sun_Microsystemshttp://fr.wikipedia.org/wiki/Langage_de_programmation_Javahttp://fr.wikipedia.org/wiki/Langage_de_programmationhttp://fr.wikipedia.org/wiki/Sp%C3%A9cification8/7/2019 HENTATI_AYMAN
7/70
Table des matires
INTRODUCTION GENERALE
Partie I : CONCEPTS GENERAUX
Chapitre1 : Les rseaux NGN
Introduction :........................................................................................................................................................1
I. Architecture du rseau NGN :..................................................................................................................1II. Le rseau daccs :........................................................................................................................................2
II.1. Les rseaux daccs fixes :....................................................................................................................2II.2. Les technologies radio locale :.............................................................................................................2II.3. Les rseaux daccs mobiles :...............................................................................................................3
III.La couche transport :...................................................................................................................................3IV.La couche contrle : ....................................................................................................................................4
IV.1.Les entits fonctionnelles du cur du rseau :................................................................................4IV.1.1.La Mdia Gateway (MG) : ........................................................................................................4IV.1.2.La Signalling Gateway (SG) : ....................................................................................................4IV.1.3.Le serveur dappel : ....................................................................................................................4
IV.2.Les Familles protocolaires : .................................................................................................................5V. La couche service : .......................................................................................................................................6Conclusion :............................................................................................................................................................6
Chapitre2 : La technologie JAIN
Introduction : ........................................................................................................................................................7
I. Aperu historique de JAIN : ......................................................................................................................7II. Avantages et intrts de JAIN : ................................................................................................................8
II.1. La portabilit des services : ..................................................................................................................8II.2. La convergence du rseau : ..................................................................................................................9II.3. La scurit de laccs au rseau : ..........................................................................................................9
III.LArchitecture et les interfaces JAIN : ....................................................................................................9III.1.Les couches dabstractions : .................................................................................................................9III.2.Principe des interfaces JAIN : ............................................................................................................10III.3.Larchitecture de JAIN : ......................................................................................................................11
8/7/2019 HENTATI_AYMAN
8/70
IV.Les diffrentes APIs de JAIN : ...............................................................................................................12V. JAIN SIP API : ............................................................................................................................................13VI.JAIN SLEE : ................................................................................................................................................13
VI.1.La spcification de JAIN SLEE : .....................................................................................................14VI.1.1. Le modle dvnement : ........................................................................................................15VI.1.2.Le modle de composant : .......................................................................................................16VI.1.3.La capacit dadministration : ..................................................................................................17VI.1.4.La capacit de ressource : .........................................................................................................17
VI.2.Les composantes de bases du JAIN SLEE : ..................................................................................18VI.2.1.Ladaptateur de ressource : ......................................................................................................18VI.2.2.Le routeur dvnements : .......................................................................................................19VI.2.3.Lvnement : .............................................................................................................................19VI.2.4.Lactivit et le contexte dactivit : ..........................................................................................19VI.2.5.Les composants SBB (Service Building Block): ...................................................................20VI.2.6.Les composants de gestion et de contrle des services : ....................................................20
VII.
JAIN et OSA/Parlay : .........................................................................................................................21Conclusion ..........................................................................................................................................................22
Partie II : ANALYSE, CONCEPTION ET REALISATION DU PROJET
Chapitre 3 : Analyse des besoins
Introduction : .....................................................................................................................................................24
I. Identification des besoins : .....................................................................................................................24II. Modles des besoins :
...............................................................................................................................25
II.1. Acteurs : ...............................................................................................................................................25II.2. Les diagrammes de cas dutilisation : ...............................................................................................25
II.2.1. Ladaptateur de ressource : ......................................................................................................25II.2.2. Les services : ..............................................................................................................................25II.2.3. Le client de messagerie instantane : .....................................................................................26
II.3. Modle de linterface homme machine de SUP Messenger : .......................................................26II.4. Les diagrammes dactivits : ..............................................................................................................27
II.4.1. Ladaptateur de ressource : ......................................................................................................27
8/7/2019 HENTATI_AYMAN
9/70
8/7/2019 HENTATI_AYMAN
10/70
8/7/2019 HENTATI_AYMAN
11/70
8/7/2019 HENTATI_AYMAN
12/70
Introduction Gnrale
Lenvironnement de service des oprateurs de tlcommunications est aujourdhui
particulirement complexe avec lintgration de services trs divers provenant du monde Internet.
Cette complexit provient du mariage entre les tlcommunications et linformatique. Le rseau
intelligent autour du rseau tlphonique a longtemps t le vecteur de cette intgration et a permis
un certain succs ce mariage avec larrive de services comme la carte prpaye ou le numro vert.
Cependant, modifier un service ou crer un nouveau service accessible par le rseau tlphoniquencessite la modification de tous les noeuds du rseau qui sont des commutateurs trs complexes.
De plus, les fournisseurs de services ont toujours tendance dvelopper des services
propritaires suivant leurs propres normes. Ces contraintes rendent les modifications et la cration de
nouveaux services difficiles et trs longues dans le contexte dun march trs concurrentiel comme
aujourdhui. Dailleurs, ces services sont trs coteux du fait de la complexit et du nombre de
commutateurs modifier dans le rseau.
C'est dans ce contexte que la technologie JAIN, bas sur la plateforme JAVA, introduit la
portabilit des services entre systmes et permet des accs scuriss aux ressources des diffrents
rseaux. Elle constitue ainsi une architecture de nouvelle gnration qui permet de remplacer toutes
les interfaces propritaires par dautres qui sont standards. En effet, la spcification des APIs JAIN
se fait au sein du JCP (Java Community Process) ce qui permet tout ce qui est intress de
participer.
Dans ce cadre, notre travail consiste proposer un prototype de plate-forme de messagerie
base sur ces spcifications.
8/7/2019 HENTATI_AYMAN
13/70
Partie I :
CONCEPTS GENERAUX
8/7/2019 HENTATI_AYMAN
14/70
8/7/2019 HENTATI_AYMAN
15/70
Les rseaux NGN
Des interfaces ouvertes et normalises entre chaque couche, et notamment au niveau descouches contrle et services afin de permettre la ralisation de services indpendants du
rseau ;
Le support dapplications multiples, multimdia, temps rel, en mobilit totale, adaptables lutilisateur et aux capacits des rseaux daccs et des terminaux ;
La prise en compte de rseaux daccs multiples ; La prise en compte de terminaux multiples.
Figure1.1 : Principe darchitecture dun rseau NGN
II.Le rseau daccs :Ce paragraphe prsente les principales technologies d'accs actuellement connues dont la
gnralisation contribuera alimenter le besoin et le dveloppement des NGN.II.1. Les rseaux daccs fixes :Les rseaux d'accs fixes s'adaptent progressivement au support de services de donnes
haut dbit:
Le rseau tlphonique commut, initialement support des services voix, a permis uneouverture des services voix/donnes haut dbit grce aux technologies xDSL
accessibles aux nouveaux oprateurs par le biais du dgroupage de la boucle locale.
L'accs Ethernet, initialement conu pour fournir des services de donnes (IF) enentreprises, voit son usage s'tendre en termes de dbit, de primtre d'utilisation et de
services transports (voix et donne, multimdia).
II.2. Les technologies radio locale :Plusieurs technologies permettent de fournir des services voix et donnes fixes en utilisant
un accs radio. On citera notamment la boucle locale radio. les rseaux locaux sans fil et
Bluetooth. Ces technologies assez rcentes, seront lobjet de mutations et dveloppements trs
importants. Quant aux rseaux satellitaires, plusieurs tentatives de dploiement dj
relativement anciennes ont men des checs (avant tout d'ordre conomique du fait des cots
-2-
8/7/2019 HENTATI_AYMAN
16/70
Les rseaux NGN
particulirement levs de dploiement), mais ils pourraient, dans les prochaines annes, trouver
enfin leur place parmi les rseaux d'accs effectivement utiliss pour fournir des services fixes
.
II.3. Les rseaux daccs mobiles :Plusieurs rseaux d'accs radio fournissant des services de radiocommunications mobiles
publics sont prsents.
Le GSM est une technologie historiquement oriente vers les services voix et donnes bas
dbit mature et trs largement rpandue, mais volue actuellement avec l'ajout de services de
transmission de donnes en mode paquet (GPRS), et court terme avec l'mergence de la
nouvelle gnration convergente voix/donnes/multimdia: l'UMTS.
III. La couche transport :La couche Transport gre l'acheminement du trafic vers sa destination. Les principales
volutions du rseau de transport concernent les technologies de transmission et de
commutation utilises sur les liaisons qui interconnectent les rseaux d'accs au coeur de rseau.
Maintenant, la question pertinente est de savoir comment les backbones sont susceptibles
d'voluer afin de supporter un trs haut dbit, et surtout le transport unifi de flux mixtes
voix/donne/multimdia avec une qualit de service adquate.
Tout d'abord il faut distinguer entre le niveau rseau de transmission et le niveau rseau de
commutation dans un rseau de transport (couche transport)
Le rseau de transmission correspond au rseau physique de liens et de nuds quidesservent une zone (un immeuble, une ville, une rgion, un pays ou un continent).
Le rseau de commutation correspond certains noeuds qui permettent d'acheminer unecommunication travers le rseau de transmission en fonction de sa destination.
Dans les architectures traditionnelles, un oprateur possde (ou loue) un rseau de
transmission sur lequel s'appuient en gnral plusieurs rseaux de commutation, le premier est
consacr uniquement la commutation de la voix, le second pour la commutation de donnes.Ainsi, pour les NGN, on parvient fusionner ces deux rseaux en un seul. Si l'on visualise les
technologies mises en jeu en s'appuyant sur le modle en couches OSI (Open System
Interconnection), la sparation entre rseau de transmission et rseau de commutation est trs
nette.
Pour la mise en oeuvre de ces rseaux de transport de nouvelle gnration , on peut mettre
en vidence deux volutions majeures des rseaux de transport au niveau des rseaux de
transmission et des rseaux de commutation.
Concernent les rseaux de transmission, les techniques dominantes sont remises en cause.
-3-
8/7/2019 HENTATI_AYMAN
17/70
Les rseaux NGN
En effet, le multiplexage TDM (Time Division Multiplexing), utilise en grande majorit dans les
rseaux actuels, est une technique de transmission adapte pour la commutation de circuits alors
que la tendance actuelle est de migrer les rseaux de transmission actuels vers un rseau de
transmission unique, neutre, voire favorable la commutation de paquets et donc on assiste
aujourd'hui des nombreux dveloppements autour du multiplexage WDM et aussi des
plusieurs volutions lies l'optique et au WDM.
IV. La couche contrle :Les volutions au niveau de la couche contrle sont majeures. Plusieurs nouveaux
mcanismes et protocoles sont mis en jeu et donc une nouvelle architecture qui dcoule. La
couche Contrle se compose de serveurs dits Softswitch grant d'une part les mcanismes de
contrle d'appel (pilotage de la couche transport, gestion des adresses), et d'autre part l'accs aux
services (profils d'abonns, accs aux plates-formes de services valeur ajoute).
IV.1.Les entits fonctionnelles au cur du rseau :IV.1.1.La Mdia Gateway (MG) :Les Gateways ont un rle essentiel: elles assurent non seulement l'acheminement du
trafic, mais aussi l'inter fonctionnement avec les rseaux externes et avec les divers rseaux
d'accs. La Media Gateway est situe au niveau du transport des flux mdia entre le rseau RTC
et les rseaux en mode paquet, ou entre le coeur de rseau NGN et les rseaux d'accs. Elle a
pour rle le codage et la mise en paquets du flux mdia reu du RTC et vice versa (conversion du
trafic TDM IP) et aussi la transmission, suivant les instructions du Media Gateway Controller,
des flux mdia reus de part et d'autre.
IV.1.2.La Signalling Gateway (SG) :La fonction Signalling Gateway a pour rle de convertir la signalisation change entre le
rseau NGN et le rseau externe interconnect selon un format comprhensible par les
quipements chargs de la traiter, mais sans l'interprter (ce rle tant dvolu au Media Gateway
Controller). Notamment, elle assure l'adaptation de la signalisation par rapport au protocole detransport utilis. Cette fonction est souvent implmente physiquement dans le mme
quipement que la Media Gateway, d'o le fait que ce dernier terme est parfois employ
abusivement pour recouvrir les deux fonctions MG + SG.
IV.1.3.Le serveur dappel :Dans un rseau NGN, c'est le MGC qui possde l'intelligence . Il gre:
L'change des messages de signalisation transmise de part et d'autre avec les passerelles designalisation, et l'interprtation de cette signalisation.
Le traitement des appels: dialogue avec les terminaux H.323, SIP voire MGCP,
-4-
8/7/2019 HENTATI_AYMAN
18/70
Les rseaux NGN
communication avec les serveurs d'application pour la fourniture des services.
Le choix du MG de sortie selon l'adresse du destinataire, le type d'appel, la charge durseau, etc.
La rservation des ressources dans le MG et le contrle des connexions internes au MG(commande des Media Gateways).
Donc dans l'architecture des rseaux NGN, le serveur d'appel, aussi appel Softswitch ou
Media Gateway Controller (MGC) est le nud central qui supporte l'intelligence de
communication.
IV.2.Les Familles protocolaires :La convergence des rseaux voix/donnes ainsi que le fait d'utiliser un rseau en mode
paquet pour transporter des flux multimdia, ayant des contraintes de temps rel , a ncessit
l'adaptation de la couche Contrle, En effet ces rseaux en mode paquet taient gnralement
utiliss comme rseau de transport mais n'offraient pas de services permettant la gestion des
appels et des communications multimdia. Cette volution a conduit l'apparition de nouveaux
protocoles, principalement concernant la gestion des flux multimdia, au sein de la couche
Contrle.
On peut classer les protocoles de contrle en diffrents
groupes:
Les protocoles de contrle d'appel permettant l'tablissement, gnralement l'initiatived'un utilisateur, d'une communication entre deux terminaux ou entre un terminal et un
serveur; les deux principaux protocoles sont H.323, norme de l'UIT et SIP, standard
dvelopp l'IETF.
Les protocoles de commande de Media Gateway qui sont issus de la sparation entre lescouches Transport et Contrle permettent au Softswitch ou Media Gateway Controller
de grer les passerelles de transport ou Media Gateway. MGCP (Media Gateway Control
Protocol) de l'IETF et H.248/MEGACO, dvelopp conjointement par l'UIT et lIETF,sont actuellement les protocoles prdominants.
Les protocoles de signalisation entre les serveurs de contrle (ou Media GatewayController) permettant la gestion du plan contrle au niveau du coeur de rseau avec des
protocoles tels que BICC (Bearer Independant Call Control), SIP-T (SIP pour la
tlphonie) et H.323. L'interconnexion avec les rseaux de signalisation SS7 se fait
gnralement via des passerelles de signalisation ou Signalling Gateways par l'utilisation
de protocole tel que SIGTRAN.
De plus, l'interconnexion de ces rseaux de donnes avec les rseaux existants de tlphonie
-5-
8/7/2019 HENTATI_AYMAN
19/70
Les rseaux NGN
(TDM avec signalisation SS7) a ncessit le dveloppement de protocoles ddis
l'interconnexion des rseaux et au transport de la signalisation SS7 sur des rseaux en mode
paquet.
V.La couche service :Actuellement, les services sont ddis un type de rseau; services Rseau Intelligent sur le
rseau tlphonique pour les terminaux tlphoniques (fixes ou mobiles), et services mail, web,
news sur les rseaux IP.
L'apparition des nouveaux rseaux d'accs tels que l'UMTS, le GPRS, I'xDSL, l'Ethernet
longue distance, et la multiplication des terminaux communicants (tlphone mobile
GPRS/UMTS, PDA) et la convergence des coeurs de rseaux, poussent une transformation de
l'architecture des plates-formes de services.
Cette nouvelle architecture doit offrir la possibilit aux clients d'accder aux services, quelle
que soit la nature des terminaux et le type de protocole utilis pour accder aux plates-formes de
services, via un rseau de transport unifi, en mode paquet. Le service rendu doit tre adapt aux
besoins et aux moyens des clients.
Conclusion :
Globalement, l'volution vers les NGN reprsente encore ce jour un sujet relativement
amont, notamment du point de vue des oprateurs et dans une moindre mesure des purs
fournisseurs de services.
En effet, la conjoncture actuelle influe fortement sur les positions vis--vis des NGN
puisque les acteurs sont confronts des problmatiques de financement et de prennit, ce qui
les met dans un contexte peu favorable des volutions techniques et l'apparition de nouveaux
business models.
Mais on peut dire que la migration vers les NGN apparat comme un processus invitable
du fait de la convergence voix/donnes/image et fixe/mobile. Elle a dj attir lintrt dun
certain nombre d'acteurs en France, en Europe et dans d'autres continents. Encore faut il
anticiper pour suivre et analyser ses impacts.
Dans le chapitre suivant on va prsenter JAIN qui un exemple darchitecture de rseau
NGN. On va scruter tous les dtails qui se rapportent cette technologie. On va surtout mettre
laccent sur le point fort de cette architecture : le dveloppement des services.
-6-
8/7/2019 HENTATI_AYMAN
20/70
La technologie JAIN
Chapitre 2
La technologie JAIN
Introduction :
JAIN est un ensemble dAPI (Application Program Interfaces) JAVA qui permet de
dvelopper rapidement de nouveaux services pour des rseaux de tlcommunication voix ou
donnes, indpendamment des serveurs utiliss (matriel). De plus, JAIN tant bas sur la
plateforme JAVA, il introduit la portabilit des services entre systmes et permet des accs
scuriss aux ressources des diffrents rseaux.
La technologie JAIN change radicalement le march des tlcommunications en permettant
le passage de systmes ferms et propritaires des systmes ouverts offrant une interconnexiontotale des diffrents rseaux existant (PSTN, IP, ATM, GSM, WLAN). Ceci peut tre constat
dans la figure 2.1 qui donne un premier aperu sur larchitecture de JAIN
Actuellement, plus de 80 entreprises font partie et sont actives dans la communaut de
dveloppement de la technologie JAIN sous le contrle de SUN, qui garantit ainsi la qualit des
nouvelles APIs, leur homognit et leur compatibilit long terme.
Figure 2.1 : Architecture de base de JAIN
I. Aperu historique de JAIN :Cr par SUN en 1998, JAIN tend la plate-forme JAVA lindustrie des fournisseurs de
services. Son but est de rpondre aux exigences des rseaux de tlcommunication de la nouvelle
gnration, en offrant des API permettant de dvelopper des applications et services pour les
rseaux intelligents. Les dveloppements des API JAIN sont mens de front en Asie, en Europe
et aux Etats-Unis par les membres de la communaut. Celle-ci se compose de plus de 80
entreprises comprenant des fournisseurs de matriels, des fournisseurs dquipements rseaux,des fournisseurs de protocoles et des dveloppeurs de services.
-7-
8/7/2019 HENTATI_AYMAN
21/70
La technologie JAIN
La communaut de JAIN travail en troite collaboration avec dautre groupement
dentreprises tel que lETSI, le Parlay Group et 3GPP afin de garantir des API de qualits.
II.Avantages et intrts de JAIN :Actuellement les solutions viennent dun vendeur qui fournit dans une grande boite
totalement propritaire du matriel, logiciel du serveur et des services. Les clients dpendent
donc de ce vendeur, il en rsulte des cots dextensions et de maintenances levs.
Avec JAIN on obtient une solution ou les diffrentes parties du serveur proviennent de
vendeurs diffrents, le client peut ainsi choisir les diffrentes parties en fonction de ses besoins.
La figure 2.2 prsente la transition entre les systmes actuels propritaires ferms des
systmes ouverts dans lesquels chaque couche est spare, introduisant de ce fait la libert
daction tous les niveaux.
Figure 2.2 : Passage des systmes propritaires aux systmes ouverts
Le fondement de JAIN sappuie essentiellement sur la portabilit de la plate-forme JAVA.
Ceci sest traduit par la standardisation de la couche de signalisation en des APIs qui visent
enrichir le cur du langage JAVA et qui a servi pour dfinir un environnement de cration, de
test et de dploiement de nouveaux services de tlcom. Ds lors, la portabilit des services, la
convergence du rseau ainsi que la scurit daccs au rseau, introduites par la dfinition de ces
APIs, reprsentent le point fort de JAIN :
II.1. La portabilit des services :Dans le domaine des tlcoms, on na jamais parl de la portabilit de services vu que les
interfaces restaient propritaires jusqu lavnement des concepts NGN.
En fait, les cots de dveloppement des services taient levs puisquil faut respecter les
contraintes de compatibilit. Par rapport tous ces problmes JAIN permet au dveloppeurs de
services tlcoms de franchir toutes ces barrires et leur fournir des APIs Java assurant lintgrit
des rseaux tout en uniformisant leurs interfaces.
-8-
8/7/2019 HENTATI_AYMAN
22/70
8/7/2019 HENTATI_AYMAN
23/70
La technologie JAIN
VoIP : SIP, MGCP, Megaco, H.323
Signaling layer:Il sagit dune couche reprsentant les logiciels chargs de la gestion des communications.
Tlcommunication : Signaling Service Point (SSP) Wireless : Mobile Switching Centers (MSC) VoIP : Proxy, redirect serveur, H 323 gatekeeper, media gateway controllers
Service layer :Il sagit dune couche reprsentant les services de base.
Tlcommunication : Service Contrle Points (SCP) Wireless : Base Station Controllers (BSC), Home Location Registers (HLR) VoIP : Serveur dapplications internet
Figure 2.3 : Les diffrentes couches et APIs de JAIN
III.2.Principe des interfaces JAIN :JAIN propose des API qui interface les diffrentes couches des rseaux. Ainsi, un
dveloppeur de services peut crer des services en se basant sur linterface utilise, sans se soucier
des primiti propritaires primitifs du matriel.
Figure 2.4 : Exemple dintroduction dune interface JAIN
-10-
8/7/2019 HENTATI_AYMAN
24/70
La technologie JAIN
III.3.Larchitecture de JAIN :La couche protocolaire de JAIN est dfinit par la standardisation des protocoles, tels que :
SIP, MGCP, H.323, TCAP, INAP, etc., en des interfaces standard. Ds lors, la couche
application peut utiliser des Protocol Stack de diffrents fournisseurs. Ce qui assure un niveau
de portabilit lev pour les services.
En outre, la couche application fournit un modle dappel unique pour les diffrents
protocoles supports par la couche soujacente. Lide fondamentale est de procurer pour des
sessions de diffrentes natures (multimdia, multi protocole,) une machine dtat unique afin
daccder aux services. Celle-ci est accessible via les APIs JCC/JCAT.
Admettant que larchitecture de la technologie JAIN est plus au moins claire, on va
sintresser maintenant la couche service afin de dcouvrir le comportement du service dans les
diffrents niveaux.
En fait, une application ou un service au niveau protocolaire peut communiquer directement
avec les adaptateurs de JAIN. Ces derniers sont des mthodes de classe Java, des vnements, ou
des interfaces de Java qui encapsulent les ressources du rseau. Les ressources peuvent tre
implmentes en Java, C, C++, et ainsi de suite, alors quun adaptateur de ressource doit tre
obligatoirement conforme aux spcifications de JAIN.
Ce niveau le plus bas de l'abstraction ne fournit aucun dispositif l'application pour traiter
diffrents types de protocoles. Par exemple, une application qui a besoin d'une session enjambantINAP et SIP devra manipuler les deux protocoles.
Un service ou une application au prochain niveau d'abstraction de JAIN, le niveau de
contrle dappel JAIN ou le niveau des services de confiances, ne doit pas se rendre compte que
certaines sessions emploient des protocoles diffrents. Donc, les fournisseurs qui vendent un
produit conforme au JCC doivent fournir trace des changes entre le contrleur dappel JAIN et
un ou plusieurs adaptateurs protocolaires.
Figure 2.5 : Architecture en couche de JAIN
-11-
8/7/2019 HENTATI_AYMAN
25/70
La technologie JAIN
La figure 2.5 illustre dune faon claire notre analyse cite ci-dessus.. En effet, elle nous
permet de dcouvrir toutes les composantes constituants chaque couche. On remarque par
exemple des rectangles qui porte la lettre A. Ces derniers reprsentent les diffrents types
dadaptateurs. Dautres cercles qui portent tantt la lettre S pour dire service tant tt la lettre
P pour dire politique de service. On remarque la prsence dautres composantes tel que JAIN
Call Control , linterface JAIN Parlay , sans oublier, bien entendu, la SLEE container quon
peut le voir comme lorchestre de tous ces lments. La SLEE est la partie la plus valorisante
dans notre projet puisquelle va hberger nos services. Pour cette raison on a consacr toute une
partie pour le dtailler.
IV. Les diffrentes APIs de JAIN :La technologie de JAIN permet l'intgration de l'Internet et des protocoles du rseau
intelligent, dsigns sous le nom rseaux intgrs . Deux types dAPIs ont t dfinis : des
APIs relatives la standardisations des interfaces daccs aux services et une autre classe dAPIs
propre au conteneurs dapplications.
Les interfaces standard mettent la disposition du langage de programmation Java tous les
protocoles de tlcoms. En revanche, les conteneurs d'applications fournissent un
environnement standard d'excution pour des services de tlcommunication. Ces services
emploient typiquement ces interfaces standard pour des communications par l'intermdiaire des
adaptateurs de ressources.
SIP, un protocole actuellement populaire au monde des tlcoms, parce qu'il possde
lavantage de ne pas tre attach un mdium particulier et est sens tre indpendant du
protocole de transport des couches basses. De plus il peut tre tendu et sadapter aux volutions
futures. Pour cette raison JAIN offre le JAIN SIP 1.1 APIs en tant qu'lment du Java APIs pour
les communications. En utilisant le SIP, on peut dvelopper nos propres services comme par
exemple le fameux SIP Gateway , qui est ncessaire pour crer et contrler les connexions.
Les spcifications dfinissent deux types de conteneurs d'applications Java pour les
communications : les Servlets SIP et la JAIN/SLEE. Les servlets SIP, similaire au servlets HTTP
elles sont prvues pour dvelopper tout type de services. Elles peuvent interagir avec dautres
sources de donnes tout en garantissant une bonne scurit, il est en effet possible de confiner les
servlets nutiliser que les ressources de la machine virtuelle.
La JAIN SLEE a pour vocation de permettre la cration de services disponibles, fiables et
modulaires qui sont portables entre les vendeurs JAIN SLEE.Dans notre projet on va sintresser JAIN SLEE. En fait, nos services seront par la suite
-12-
8/7/2019 HENTATI_AYMAN
26/70
La technologie JAIN
hbergs par ce type de conteneur. Pour cette raison nous allons consacrer toute une partie de ce
chapitre afin de dtailler ce composant. Mais faut il tout dabord mettre laccent sur JAIN SIP
API puisque dans notre application on a opt pour le protocole SIP.
V.JAIN SIP API :La communaut Java na pas tard de s'intresser SIP. Il en dcoule de nombreuses
implmentations du protocole pour diffrents supports. La premire implmentation fut JAIN.
Elle permet d'avoir un contrle trs fin sur les messages.
L'API inclue un ensemble d'objets et d'interfaces qui fournissent des abstractions de haut
niveau pour reprsenter les concepts SIP, librant le programmeur des dtails fins comme la
gestion des transactions, mais permettant l'accs aux champs importants du message SIP (From,
To, Request- URI, Contact). Ainsi, l'API a pour but de permettre aux applications d'avoir uncontrle sur la signalisation SIP tout en cachant toute la complexit sous-jacente qui n'est pas
approprie pour les dveloppeurs.
Figure 2.6 : Les diffrentes JAIN SIP API
La figure ci-dessus montre quen plus de JAIN SIP il existe dautre APIs qui sont :
JAIN SIP Lite, il sagit dune API haut niveau fournissant une abstraction du stack SIP,elle peut tre utilise pour crer un agent SIP.
JAIN SIP Servelts.Actuellement seule la spcification de JAIN SIP est disponible, elle est fournie avec une bonne
documentation qui dcrit toutes les mthodes de linterface.
VI. JAIN SLEE :La plate-forme JAIN SLEE permet aux exploitants de rseaux d'intgrer des services dans les
infrastructures en place, ce qui permet de protger les investissements existants tout en
dveloppant des applications futures en utilisant les outils standards de Java. Ds lors, elle est en
train d'tre adopte l'chelle mondiale par les exploitants de rseaux de tlphonie fixe ou de
sans fil.
-13-
8/7/2019 HENTATI_AYMAN
27/70
La technologie JAIN
VI.1.La spcification de JAIN SLEE :La spcification JAIN SLEE fournit une norme permettant aux dveloppeurs java d'laborer
et de dployer des services dans des systmes en temps rel comme les rseaux de transmission
vocale ou de donnes ou les systmes d'automatisation industrielle.
En fait, les systmes de communications sont des systmes asynchrones bass sur le modle
dvnement. Contrairement aux systmes dentreprises qui utilisent typiquement les mthodes
dinvocations directes. Une architecture existante d'entreprise est dfinie par les spcifications de
Entreprise JavaBeans .
Le tableau ci-dessous fournit une vue d'ensemble des diffrentes caractristiques des systmes
d'entreprises et de communications.
Tableau 2.1: Comparaison entre le systme de communication et le systme dentreprise
Comme le montre ce tableau, il y a des diffrences substantielles entre les systmes de
communications et les systmes d'entreprises. Les spcifications d'EJB rpondent aux exigencesdes systmes d'entreprises. Alors que la SLEE rpond aux exigences des systmes de
communications actuels.
Bien que les conteneurs existants de J2EE traitent galement les vnements asynchrones
(JMS), ils n'ont pas t conus pour a. Une SLEE, d'autre part, a t spcifiquement conue
pour les systmes de tlcommunications haute frquence et qui sont compltement
asynchrones. Ainsi, une SLEE remplit les exigences des systmes de communications bien
meilleurs que n'importe quel conteneur d'EJB.
-14-
8/7/2019 HENTATI_AYMAN
28/70
La technologie JAIN
Pour rpondre aux exigences des systmes de communications et incorporer d'autres
conditions principales des serveurs d'applications conduits par les vnements les fonctions
suivantes ont t identifies en tant que motivateurs principaux pour la spcification de JAIN
SLEE :
Le modle d'vnement Le modle de composant La capacit dadministration La capacit de ressource
VI.1.1. Le modle dvnement :Lacheminement d'vnements entre les ressources de donnes et les composants de la
SLEE, y compris lacheminement d'vnements entre composants, est la fonction de base du
SLEE.
Le modle d'vnement de la SLEE est bas sur un modle publish/subscribe (semblable
JMS). Ce modle dcouple les producteurs d'vnements des sources d'vnements par
l'intermdiaire d'un mcanisme d'adressage indirect qui conduit l'vnement des sources aux
consommateurs, et dsign sous le nom du mcanisme dacheminement d'vnements de la
SLEE. Ce mcanisme dcrit comment un vnement mis par un producteur d'vnement estconduit et fourni grce au routeur dvnements une ou plusieurs instances des composants
intresses par cet vnement.
Plus prcisment, Les consommateurs d'vnement sattachent un ou plusieurs Activity
Context afin de spcifier lensemble dvnements dont ils ont besoin. Par ailleurs, les
producteurs d'vnements publient des vnements auprs des Activity Context . Ds lors, un
producteur d'vnements ne se rend pas directement compte de ses consommateurs d'vnement
et un consommateur d'vnement ne se rend pas directement compte de ses producteursd'vnement. Les Activity Context dfinis par la SLEE maintiennent les changes entre les
producteurs d'vnement ainsi que leurs consommateurs.
La figure ci-dessous illustre ce que on vient de citer.
-15-
8/7/2019 HENTATI_AYMAN
29/70
La technologie JAIN
Figure 2.7 : Le modle dvnement de JAIN
Le modle d'vnement de SLEE a les avantages suivants :
Favorise un dcouplage du producteur d'vnement du consommateur d'vnement. Cecifacilite la fixation des pannes, car une erreur au niveau du producteur dvnement aura
moins de chance pour se propager jusquau consommateur d'vnement et vice versa.
Permet au SLEE de savoir les rapports les consommateurs d'vnement et leursproducteurs. Ceci permet au SLEE de fournir des dispositifs valeurs ajoutes
importants tels que le garbage collection des consommateurs d'vnements qui ne
recevront plus des vnements.
Amliore la robustesse car les producteurs d'vnement ne doivent pas mettre enapplication le code de distribution d'vnement qui est conforme aux modles ou aux
conventions documentes.
L'application a un modle flexible de distribution d'vnement qui reoit seulement lesvnements d'intrt. Certaines applications peuvent exiger seulement la distribution
d'vnements d'un type spcifique, alors que d'autres applications exigent la distribution
d'vnements dun type diffrent.
VI.1.2.Le modle de composant :Le modle de composant est vis aux applications asynchrones. Ce modle limine des
rfrences directes entre les producteurs d'vnements (les ressources du rseau) et les
consommateurs d'vnements (les composants d'applications).
-16-
8/7/2019 HENTATI_AYMAN
30/70
La technologie JAIN
Un composant de SLEE s'appelle un module de service (SBB : Service Building Block).Il est
hberg par le conteneur de la SLEE. Un SBB est conforme certaines restrictions de
programmation. Le conteneur lui reprsente un environnement d'excution et lui fournit
l'infrastructure de service suivante :
La gestion du cycle de vie de la ressource La scurit La persistance Les transactionsUn descripteur de dploiement permet une association entre l'infrastructure des services et les
SBBs hbergs par le conteneur au temps de dploiement.Les composants de SLEE reoivent des demandes sous forme d'vnements qui reprsentent
typiquement une occurrence exigeant le traitement d'une application. Elle diffuse l'information
dcrivant l'occurrence, telle que la source d'vnement. Un composant actif dans le SLEE peut
employer des vnements pour signaler, appeler, ou communiquer avec d'autres applications
fonctionnant dans la SLEE.
Le modle de composant du SLEE modlise l'interface externe d'une application comme un
ensemble d'vnements que l'application peut recevoir. Chaque type d'vnement est manipulpar sa propre mthode pour imposer une interface bien dfinie.
VI.1.3.La capacit dadministration :Afin d'administrer et de contrler les diffrents lments dun systme, un administrateur a
besoin de manipuler les valeurs qui caractrisent la configuration de ce systme.
Le SLEE dfinit des interfaces de gestion en utilisant MBeans (Managed Beans)
conformment aux spcifications du JMX (Java Management Extentions). Un MBean est une
reprsentation externe d'un domaine fonctionnel et physique d'un systme.
VI.1.4.La capacit de ressource :Les applications dveloppes dans le SLEE doivent communiquer avec des ressources du
rseau. Une ressource reprsente un systme qui est externe la SLEE (tel que des protocoles
stacks ou des bases de donnes). Ces ressources ne sont pas ncessairement dveloppes en Java
ce qui implique quils ne supportent pas le modle vnementiel. Pour rsoudre ce problme
dinteroprabilit, l'architecture JSLEE dfinit comment les applications hberges par la SLEE
peuvent interagir avec ces ressources travers les adaptateurs de ressources.
-17-
8/7/2019 HENTATI_AYMAN
31/70
La technologie JAIN
VI.2.Les composantes de bases du JAIN SLEE :LAPI du SLEE dfini une interface standard pour le dveloppement dapplications de
tlcommunications portables. Les spcifications de cet API ont t menes par David Ferry de
la socit Open Cloud et Swee Lim de la socit Sun Microsystems. Le vote d'approbation
finale a accept les spcifications du 17 fvrier, 2004.
En plus des socits qui ont men ces spcifications le groupe d'experts pour ce JSR ainsi
dautres compagnies telles que Siemens AG, IBM, Motorola, et NTT Corporation.
JAIN SLEE intgre un modle d'vnement avec un composant de programmation tout en
incorporant aussi des interfaces d'administration par l'intermdiaire de JMX, un adaptateur de
ressources pour le rseau, des interfaces de profils gnriques, un systme de gestion de
persistance pour les tats de redondance, des systmes de contrle d'accs concurrent comme les
minuteries, des systmes d'alarmes, un systme de suivi d'utilisation et des traces.
La figure ci-dessous prsente larchitecture de JAIN SLEE et les relations entre ses diffrents
composants :
Figure 2.8 : Architecture de JAIN SLEE
VI.2.1.Ladaptateur de ressource :
Les adaptateurs de ressource communiquent avec les systmes externes au SLEE, tels que, les
composants du rseaux, les protocoles stacks, les bases de donnes, etc. Selon l'architecture du
SLEE, un adaptateur de ressource est une implmentation propre au vendeur d'un type
d'adaptateur de ressource. Une instance d'un adaptateur de ressources dans la SLEE s'appelle une
entit d'adaptateur de ressources.
Le type d'adaptateur de ressource dclare tous les types d'vnements qui peuvent tre
produits ainsi que toutes les activits que ladaptateur peut introduire. Quand un adaptateur deressources passe un vnement au SLEE, il doit fournir son objet et son type et une activit qui
-18-
8/7/2019 HENTATI_AYMAN
32/70
La technologie JAIN
lencapsule (Voir figure). Les spcifications n'noncent pas comment cette information est passe
au SLEE.
Figure 2.9 : Rle de ladaptateur de ressource
VI.2.2.Le routeur dvnements :Les spcifications de SLEE dfinissent comment un vnement mis par un producteur
d'vnement est conduit et fourni un ou plusieurs composants qui lui sont intresss. Pour ce
faire la SLEE est quipe dun routeur logique dvnements. Celui-ci reoit des vnements mis
de tous les producteurs d'vnements et les achemine aux diffrentes instances correspondantes.
VI.2.3.Lvnement :Les objets d'vnements diffusent l'information entre les diffrentes entits du SLEE.
Seulement les SBB consomment et produisent des vnements, alors que toutes les autres entits
telles que les adaptateurs de ressources, la SLEE elle-mme peuvent seulement les produire.
Chaque vnement est reprsent par un objet d'vnement (sous-classe de java.lang.Object) et
un type. Le type d'vnement dtermine comment le SLEE conduira l'vnement, par exemple,
quels sont les objets SBB qui doivent recevoir l'vnement. Un SBB reoit les vnements du
contexte dactivit qui lui est attach.
Le dveloppeur doit dfinir une mthode abstraite pour lexcution de chaque vnement que le
SBB en a besoin. Cette mthode est gnralement excute par la SLEE. Dans le cas dunvnement initiateur la SLEE doit cre un objet SBB avant de lui acheminer lvnement.
VI.2.4.Lactivit et le contexte dactivit :Les classes dactivits comprennent les deux entits logiques, activit et contexte d'activit, et
leurs reprsentations d'objet en Java, objet d'activit et objet dinterface de contexte d'activit
Une activit reprsente un ensemble dvnements. La reprsentation Java de cette entit logique
est l'objet d'activit, qui est cr soit par l'adaptateur de ressource ou les quipements de gestion
de la SLEE. JccCall est un exemple d'objet d'activit faisant partie de Java Call Control APIs qui
-19-
8/7/2019 HENTATI_AYMAN
33/70
La technologie JAIN
reprsente un appel tlphonique.
Figure 2.10 : Lactivit et le contexte dactivit
Un contexte d'activit reprsente l'activit fondamentale dans la SLEE et tient galement les
attributs en commun que les entits SBB veulent partager. Les objets SBB peuvent accder aux
contextes d'activit par l'objet interface de contexte d'activit.
Un SBB peut utiliser une interface de contexte dactivit gnrique comme il peut tendre
cette interface pour dfinir des attributs supplmentaires quil veut partager avec dautres objets.
Les objets d'activits sont produits par des vnements de rseau. Les adaptateurs de
ressources coutent ces vnements et crent les objets dactivits appropries. Ces objets sont
placs dans le contexte d'activit du SLEE. Ds lors, le SLEE est maintenant responsable de la
livraison des vnements produits aux objets du SBB. Vice versa, un objet du SBB peut accder
l'interface du contexte d'activit pour obtenir l'accs l'objet d'activit courante.
VI.2.5.Les composants SBB (Service Building Block):Le SBB est le composant le plus lmentaire dans la SLEE. Il est inspir de lEJB sur lesquels
se basent les systmes dentreprise J2EE .
Un composant SBB dfinit :
Les types dvnements quil peut recevoir et traiter. Des mthodes pour traiter chaque type dvnement. Les relations Child qui le rattache des composantes SBB Child. Les donnes quil dsire partager avec les autres composants par lintermdiaire dun
ensemble dattributs dactivity context.
Le dveloppeur dun SBB implmente ce quon appelle un SBB Abstract Class de linterface
SBB dj dfinie dans les spcifications de la SLEE.
VI.2.6.Les composants de gestion et de contrle des services :Pour contrler efficacement les services, les changes d'vnement et les ressources, il est
-20-
8/7/2019 HENTATI_AYMAN
34/70
La technologie JAIN
ncessaire de surveiller et mesurer l'excution, l'utilisation et la disponibilit de ces attributs, tout
en estimant leurs situations futures. Les spcifications de la SLEE dfinissent un certain nombre
de composantes qui peuvent tre employes pour rpondre ces exigences.
Le temporisateur : cette fonction procure des applications la possibilit d'effectuer desactions priodiques, ou lancer des actions et des contrles un temps postrieur pour
sassurer quils ont t bien accomplies. Le temporisateur contrle un certain nombre de
temporisateurs, dont chacun est indpendant des autres.
Le service d'alarme : des alarmes sont employes pour informer des applications degestion qu'un changement inattendu d'tat s'est produit dans un lment de rseau. Les
composants de SBB emploient le service d'alarme pour produire des avis d'alarme
destins la consommation par des clients de gestion externe au SLEE. L'envoi desalarmes aux applications de gestion est automatiquement dclench quand un tat
particulier devient vrai. Ces clients de gestion peuvent tre une console de gestion de
rseau ou un moteur de politique de gestion.
Service de mesure des statistiques : les statistiques sont des caractristiques delapplication ou du rseau qui sont priodiquement demandes par les applications de
gestion. Un client de gestion peut employer les paramtres de ce service pour surveiller le
taux d'utilisation de chaque application.
Composant de gestion de profil : Ce service permet aux applications de rechercher desprofils stocks dans des tables de profil. Les profils contiennent des donnes stockes
dans la SLEE.
VII. JAIN et OSA/Parlay :A peu prs au mme moment o la communaut JAIN se mettait en place et dbutait ses
travaux, British Telecom (BT), Microsoft, Nortel, Siemens et Ulticom formaient le Parlay Group,
qui a donn le jour une panoplie dAPIs oriente objet et indpendante du langage
dexploitation, afin de faciliter la cration de services dans les rseaux publics de tous types. Les
APIs dapplications dfinies par le groupe Parlay doivent permettre un accs ouvert mais scuris
un ensemble de fonctionnalits aujourdhui rendues par les diffrents rseaux privs ou publics.
Il est attendu de la publication de ces APIs quelles soient utilises par une plus grande
communaut de dveloppeurs afin de dynamiser le dveloppement de nouveaux services de
tlcommunications, nous lavons dj dit.
Mais pour ce faire, les spcifications que dfinit Parlay ont besoin dun modle architecturalstandardis permettant aussi de tenir en compte des abonns mobiles, et le modle OSA
-21-
8/7/2019 HENTATI_AYMAN
35/70
La technologie JAIN
dvelopp conjointement par le 3GPP sest avr idal pour une mise en commun des efforts du
Parlay Group avec le groupe de travail du 3GPP, qui ont ds lors collabor ldification dun
standard commun OSA/Parlay.
OSA/Parlay noffre pas seulement la possibilit aux oprateurs douvrir leurs rseaux des
parties tierces, mais sadresse galement aux oprateurs cbls comme aux oprateurs sans fils, en
proposant sans diffrenciation aucune une nouvelle mthode peu coteuse, rapide et efficace
pour crer leurs propres services en fonction de la demande quils peroivent.
Au premier abord et avec raison, le lecteur pourra penser que Parlay et JAIN sont en
comptition, tant donn les nombreuses similarits dans les buts quils se sont fixs. Mais sils
ont t en comptition leurs dbuts, cela na pas dur, les deux parties stant rapidement
rendues comptes que la collaboration apporterait plus chacun que la comptition.
Les deux groupes maintiennent toutefois certaines dissimilitudes, notamment sur les points
suivants :
Parlay ne se limite pas une utilisation de ses API par Java mais se veut indpendant du langage
utilis.
Parlay propose des APIs de services uniquement: contrairement JAIN, Parlay ne dispose pas
dAPIs pour communiquer directement avec les protocoles rseaux, car ce nest pas l son but.
Un autre objectif majeur de Parlay est de fournir un environnement dans lequel des acteurs tiers
(third parties) puissent crire des applications sexcutant en dehors de lespace de confiance(trusted space) du fournisseur de services, via diffrents mcanismes de scurits intgrs
Parlay.
Conclusion :
La technologie JAIN a un potentiel immense. Elle bouleverse compltement le march des
tlcommunications en permettant un accs direct au dveloppement de services par tous les
acteurs de tlcommunications dans le monde indpendamment des systmes.
Avec le principe adopt par la communaut JAIN qui supprime les diffrences entre rseauxet qui apporte la scurit, il nexiste plus que deux limites la cration de services. La premire est
physique, cest la taille du rseau mondial, la seconde est limagination.
A ce stade, la premire partie est acheve. On va par la suite passer la partie la plus
valorisante du rapport : ltape danalyse, de conception et de ralisation du projet.
-22-
8/7/2019 HENTATI_AYMAN
36/70
Partie II
Partie II :
Analyse, Conception et Ralisation
-23-
8/7/2019 HENTATI_AYMAN
37/70
Analyse des Besoins
Chapitre 3
Analyse des besoins
Introduction :
Comme tout processus de ralisation dun projet, on va commencer par la premire phase qui
est lanalyse. En effet, elle consiste prsenter, dans un premier lieu, le cahier des charges,
ensuite lidentification des besoins, pour en tirer la fin les diagrammes correspondants tels que
les diagrammes des cas dutilisation et le diagramme dactivit.
I. Identification des besoins :Au cours de ce projet, on se propose de mettre en place une plate-forme de messagerie
instantane utilisant JAIN. Parmi les traitements possibles cette plate-forme doit effectuer des
actions spcifiques lorsquun appel est initi ou bien mettre jour les informations du centre
dappel.
Notre travail consiste dvelopper un prototype de service de messagerie instantane
utilisant JAIN. Pour ce faire, on a dj signal que notre tude sera base essentiellement sur la
dernire version des spcifications JAIN SLEE 1.0. En outre, on a dcid que notre prototype
traitera du SIP vue que cest un protocole davenir qui se caractrise par sa rapidit et sa
simplicit.
Par rapport a, on se retrouve face aux besoins suivants :
(1). Il faut tout dabord dvelopper un adaptateur de ressource SIP qui permet de passer
du monde protocolaire base des messages SIP au monde vnementiel qui caractrise la JSLEE.
Ceci permet au dveloppeur de service de bnficier par la suite dune abstraction de la couche de
signalisation SIP. Seulement, il faut comme mme tenir compte des types dvnements qui vont
encapsuler les messages SIP.
(2). Par rfrence larchitecture SIP, on doit dvelopper les services suivants : Un service Proxy qui va soccuper de relayer la signalisation des appels. Un service Registrar qui fait associer un utilisateur un identifiant unique connu
par les tierces personnes.
Un service de prsence et de messagerie instantane pour grer les informationsen prsence des diffrents utilisateurs dj inscrits dans le Registrar et pour
acheminer leurs messages.
-24-
8/7/2019 HENTATI_AYMAN
38/70
Analyse des Besoins
On doit rappeler que ces services vont tre hbergs par la JSLEE. On doit donc les dvelopper
selon le modle vnementiel en tenant compte du type dvnement qui vont tre gnrs par
ladaptateur de ressource.
(3). On se propose de dvelopper un client de messagerie instantane pour valider lesservices. Ce client doit permettre un utilisateur donn de sinscrire auprs du Registrar. Comme
sil aura une adresse logique quil peut la communiquer tout le monde. En plus, ce client permet
essentiellement douvrir une session de chatting avec un autre utilisateur qui doit tre dj inscrit.
II.Modles des besoins :Daprs la partie prcdente, on peut distinguer trois centres dintrts dans ce projet. Chacun
dentre eux demande une analyse dtaille part. Ds lors, on a dcid dtudier au fur et
mesure chaque composant tout seul.II.1. Acteurs :Un acteur est une catgorie dutilisateurs, il reprsente un rle jou par une personne, un
logiciel, un matriel, un automate qui exploite les donnes du systme et qui interagit avec.
II.2. Les diagrammes de cas dutilisation :Un cas dutilisation modlise un service rendu par le systme. Il exprime les interactions
acteurs/systmes et apporte une valeur ajoute lacteur concern, un cas dutilisation est donc
une abstraction dune partie du comportement du systme.
II.2.1. Ladaptateur de ressource :Dans ce cas il y a deux types dacteurs : Les ressources du rseau et les SBBs. Les
composantes du rseau envoient ladaptateur de ressource des requtes encapsules dans des
messages SIP. Alors que les SBBs envoient des requtes sous forme dvnements.
Network Resource
Mapping entre message
SIP et Evnement
SBBs
Cration d'une ACinclut
Figure 3.1 : Diagramme de cas dutilisation de SIPRA
II.2.2.Les services :Dans cette partie, les diffrents cas dutilisation identifis sont :
Lacheminement des messages de signalisation.
Association de lutilisateur un identifiant unique.
Transfert des IM.
-25-
8/7/2019 HENTATI_AYMAN
39/70
Analyse des Besoins
Notification des changements des tats des autres utilisateurs.Ainsi le diagramme de cas dutilisation dduit est le suivant :
Acheminier les mess ages de
signalisation
Association un identifiant unique
Transfert des IM
User
Notification des changements des
tats des autres utilisateurs
Collecte des informations de
prsence
inclut
Figure 3.2 : Diagramme de cas dutilisation des services
II.2.3.Le client de messagerie instantane :Le client de messagerie instantane permet son utilisateur de senregistrer auprs dun
service Registrar. Puis Il demander dinitier une session de chatting avec un autre utilisateur, lui-
mme doit tre dj prsent.
Ainsi le diagramme de cas dutilisation dduit est le suivant :
Authentificationinclut
Ajouter un contactinclut
User
Se dconnecter
Ouvrir une session
de IM
Enregistrement
Figure 3.3 : Diagramme de cas dutilisation de SUP Messenger
II.3. Modle de linterface homme machine de SUP Messenger :Ce modle est applicable seulement pour le client de messagerie instantane SUP
Messenger . En fait, tous les composants qui restent vont tre dploys travers des
commandes dos.
-26-
8/7/2019 HENTATI_AYMAN
40/70
Analyse des Besoins
Interface dauthentification
Interface dajout de contact
Interface denvoi et de
rception des IM
Figure 3.4 : Modle de linterface homme machine du SUP Messenger
II.4. Les diagrammes dactivits :Les diagrammes d'activit sont utiliss pour montrer la faon dont les traitements sont
crs, comment ils dmarrent, les nombreux chemins dcisionnels qu'ils peuvent emprunter, ainsique les oprations effectues en parallle. Un diagramme d'activit ne modlise pas en gnral
lexact comportement interne d'un programme (comme le fait le diagramme de squences) mais
montre plutt les traitements et les tapes gnraux un haut niveau d'abstraction.
II.4.1. Ladaptateur de ressource :
Ecouter les messagesSIP
Recevoir un message
Scruter les champs du
message
Figure 3.5 : Diagramme dactivit de SIPRA
SI
la mthode est
connue
Crer une activit
Ignorer le message
Non
Oui
-27-
http://www.alaide.com/dico.php?q=diagramme+de+s%E9quenceshttp://www.alaide.com/dico.php?q=diagramme+de+s%E9quences8/7/2019 HENTATI_AYMAN
41/70
Analyse des Besoins
II.4.2.Les services :
Recevoir une demande denregistrement
Enregistrer lutilisateur et lui associer
un identifiant
Emettre un acquittement
Recevoir une demande dinitiation
dune session dIM
Vrifier la
prsence du
correspondant
Figure 3.6 : Diagramme dactivit des services
Mettre jour les informations
de prsence
Envoyer une notification
la source et ouvrir une session
dIM
Acheminer les messages de la
conversation
Non
Oui
-28-
8/7/2019 HENTATI_AYMAN
42/70
Analyse des Besoins
II.4.3.Le client de messagerie instantane :
Figure 3.7 : Diagramme dactivit de SUP Messenger
Conclusion :
A ce stade, lanalyse des besoins est acheve, et comme les diffrents cas dutilisation ainsi
que les activits sont extraites, la phase de conception dispose maintenant de la matire duvre
pour mener sa mission.
-29-
8/7/2019 HENTATI_AYMAN
43/70
Conception
Chapitre 4
Conception
Introduction :
La conception constitue la deuxime phase dans le processus de ralisation de notre projet.
Elle permet de reprsenter les notions saillantes des diffrentes parties, et ainsi de formaliser les
connaissances prliminaires de tous les composants, notamment par lexploitation des
diagrammes de classes.
I. Conception gnrale :Lanalyse des besoins, dans la section prcdente, trace les grandes lignes de larchitecture de
chaque composant du projet. En effet, six modules principaux sont envisags et qui interagissent
derrire linterface Homme Machine du client de messagerie SUP Messenger.
Les deux premiers modules reprsentent le cur de SUP Messenger. En fait, on distingue
un module qui permet de grer les sessions de chatting appel Messenger. Alors que le
deuxime module a pour mission de collecter les informations de prsence des diffrents
utilisateurs et de notifier le client en cas de changements de leurs tats.
Les quatre modules restants doivent tre dploys du ct du serveur dapplication une fois il
est actif.
En premier lieu, chaque message envoy par une ressource du rseau la SLEE doit tre
adapt lenvironnement dexcution du service en question. Autrement dit, il faut prvoir un
module qui assure le passage du monde protocolaire base des messages SIP au monde
vnementiel. Pour ce faire, on a dj prvu un adaptateur de ressource quon a appel SIPRA.
Puis, les vnements qui vont tre gnrs par le SIPRA arrivent au niveau du routeur
dvnements de la SLEE. Ce dernier va les acheminer au SBB root du service Proxy qui
dcidera selon leurs types vers quel service faut il encore les envoyer.Dans notre cas, le client doit tout dabord demander une connexion auprs du serveur de
messagerie instantane. Pour ce faire, le Proxy va relayer le client au niveau du serveur. Ensuite, il
va demander du service Registrar de lui attribuer un identifiant unique qui lui permet dtre
joignable le temps quil est connect. Une fois que le client est identifi le Registrar donne la main
au service de prsence pour achever son enregistrement.
En ce moment, le client peut initier une session de chatting. Il va donc se renseigner sur ltat
de son correspondant (On line ou Off line) avant de lui envoyer un message.
-30-
8/7/2019 HENTATI_AYMAN
44/70
Conception
En conclusion, tous les modules qui constituent le noyau de lapplication, sont prsents dans
la figure ci-dessous :
Figure 4.1 : Architecture gnrale du projet
II.Conception dtaille :Selon la mthodologie UML suivie dans ce projet, la conception dtaille se base
essentiellement sur la prsentation statique par les diagrammes de classe et dynamique par le
diagramme de squence.
II.1. Reprsentation statique :Un diagramme de classes reprsente la structure du systme sous la forme de classes et de
relations entre ces classes. Une classe est une description abstraite dun ensemble dobjets ayant :
- des propritssimilaires,
- un comportementcommun,
- des relationscommunes avec dautres objets,
- des smantiquescommunes.
Les importantes relations pouvant exister entre les classes sont lhritage, la composition et
lassociation.
On peut regrouper ces classes en paquetages.
Les paquetages sont des lments d'organisation des modles. Il permettent de :
Regrouper des lments de modlisation, selon des critres purement logiques. d'encapsuler des lments de modlisation (ils possdent une interface). structurer un systme en catgories (vue logique) et sous-systmes (vue des composants).Donc les paquetages servent de "briques" de base dans la construction d'une architecture.
Dans notre cas il y a trois parties indpendantes. Nous allons donc dtailler chacune part.
Se connecter
Afficher ltat
Envoyer unIM
Messenger
Presence
SIPRA
Proxy
IHM
Utilisateur
Registrar
Presence
-31-
8/7/2019 HENTATI_AYMAN
45/70
Conception
II.1.1. Les diagrammes de paquetages :II.1.1.1. Diagramme de paquetages de SUP Messenger :
On a dj signal dans la partie prcdente que SUP Messenger se compose de deux modules
quon a appel respectivement Messenger et Presence. Chacun dentre eux comporte un
ensemble de classes rsumes dans le tableau ci-dessous :
Paquetages Classes Spcifications
AlertInstantMessaging Gnre les messages derreur
AuthenticationProcess Gre la procdure dauthentification de lutilisateur
ChatFrame Reprsente la bote de dialogue de lutilisateur
ChatSession Gre une session de chatting
ChatSessionManager Gre plusieurs sessions de chatting
InstantMessagingFrame Reprsente la premire fentre de dmarrage
ListenerInstantMessaging Dtecter la rception dun message
Messenger
XMLParser Gre les diffrentes infos du client enregistr dans un
fichier XML
IMAckProcessing Permet de traiter un acquittement
IMByeProcessing Permet de traiter la demande fermeture dune session
IMMessageProcessing Permet de traiter la demande denvoi dun message
IMNotifyProcessing Permet de traiter une notification
IMRegisterProcessing Permet de traiter la demande denregistrement
IMSubscribeProcessing Permet de traiter la demande dinscription auprs du
serveur de prsence
IMUserAgent Cest le cur de lapplication.
PresenceManager Gre les informations de prsence
Presentity Fournit les informations de prsence
Presence
Subscriber Demande de notification des changements desinformations de prsence
Tableau 4.1: Dfinition des paquetages et des classes de SUP Messenger
sup.sip.Presence Sup.Sip.Messenger
uses
uses
Figure 4.2 : Diagramme de paquetage de SUP Messenger
-32-
8/7/2019 HENTATI_AYMAN
46/70
Conception
II.1.1.2. Diagramme de paquetages de SIPRA :
Ladaptateur de ressource est compos dun seul paquetage appel SIPRA. Il comporte les
classes suivantes :
Classes Spcifications
ActivityContextInterfaceFactoryImp Implmente linterface ActivityContextInterfaceFactory
SipRaActivityHandle Acheminer les vnements de lactivit une interface
unique AC
SIPRaFactory
SIPRaProvider Crer les transactions clients et serveurs et envoyer les
requtes et les rponses
SipResourceAdaptor Assure le mapping SIP Message et vnement SIP.
SipRaStack Gre les Listing Point ct rseau ainsi que le
SipRaProvider
Interfaces Spcifications
ResourceAdaptorSbbInterface Permet aux composantes SBB dinteragir avec le SIPRA
ActivityContextInterfaceFactory Fournit linterface Java du SIPRA avec lActivit
Tableau 4.2: Dfinition des classes de SIPRA
II.1.1.3. Diagramme de paquetages des services :
Paquetages Classes Spcifications
ProxySbb Dfinit les diffrents types dvnements
SIP supports par ce service ainsi que
leurs traitements
SipProxySbb Gre les transactions client et serveur
Proxy
ProxySbbActivityContextInterface Fournit linterface Java de lobjet
ProxySbb
LocationService Gre les informations de localisation duclient
LocationServiceException Traite les exceptions possibles au
moment dexcution
Registrar Dfinit le processus denregistrement du
client
Registrar
RegistrarSbb Dfinit les diffrents types dvnements
SIP supports par ce service ainsi que
leurs traitements
-33-
8/7/2019 HENTATI_AYMAN
47/70
Conception
RegistrarActivityContextInterface Fournit linterface Java de lobjet
RegistrarSbb
PresenceSbb Dfinit les diffrents types dvnements
SIP supports par ce service ainsi que
leurs traitements
PresentityManager Gre les informations de prsence des
clients
Subscriber Envoi des demandes de notification pour
tout changement dtat des informations
de prsence
Notifier Gre les notifications
Presence
PresenceActivityContextInterface Fournit linterface Java de lobjet
PresenceSbb
Tableau 4.3: Dfinition des classes des diffrents paquetages des services
Proxy
PresenceRegistrar
uses uses
Figure 4.3 : Diagramme de paquetage des services
II.1.2. Les diagrammes de classes :II.1.2.1. Diagramme de classes de SUP Messenger :
-34-
8/7/2019 HENTATI_AYMAN
48/70
Conception
ChatFrame
SUP.SIP.Presence
Presentity
Subscriber
SUP
.SIP.Messenger
AlertInstantMessaging
ChatSess
ion
ChatSessionManager
XMLParser
ListenerInstantMessaging
In
stantMessagingFrame
AuthenticationP
rocess
1..1
1..1
Prese
nceManager
IMACKProcessing
IMByeProcessin
g
IMMessageProcessing
IMNotifyProcessing
IMRegisterProcessing
IMUserAge
nt n
n
n
1..1
1..1
1..1
n
1..1
IMSubscribeProces
sing
1..1
1..1
Figure4.4:DiagrammedeclassesdeSUPMessenger
-35-
8/7/2019 HENTATI_AYMAN
49/70
Conception
II.1.2.2. Diagramme de classes de SIPRA :
ActivityContextInterfaceFactoryImpl SipRAActivityHandle
SIPRaProvider
ActivityContextInterfaceFactory
SipResourceAdaptor
ResourceAdaptorSbbInterface
SIPRaFactory
SipRaStack
Figure 4.5 : Diagramme de classes de SIPRA
II.1.2.3. Diagramme de classes des services :
ProxySbbActivityContextInterface
ProxySBB
1..1
1..1
SIPProxySBB
Figure 4.6 : Diagramme de classes du Proxy
-36-
8/7/2019 HENTATI_AYMAN
50/70
Conception
LocationService LocationServiceException
Registrar
RegistrarSBB
RegistrarActivityContextInterface
0..1
0..1
1..1
1..1
0..1 0..1
Figure 4.7 : Diagramme de classes du Registrar
PresenceSBB
Subscriber PresentityManager
Notifier
PresenceActivityContextInterface
nn
n
n
1..1
1..1
1..1
1..n
Figure 4.8 : Diagramme de classes du Presence service
II.2. Reprsentation dynamique :
-37-
8/7/2019 HENTATI_AYMAN
51/70
Conception
Figure 4.9 : Diagramme de squence de tout le systme
ConclusionAinsi la conception du projet est acheve et les diffrents modules architecturaux et fonctionnels
sont bien dfinis pour tre implments. Ds lors, la phase suivante sera limplmentation de ces
diffrents modules.
User Agent1 SIPRA Proxy Registrar Presence User Agent2
Mappingto Register eventRegister SIP Message
RegisterRegister
200 Ok200 Ok
Ack SIP Message
Subscribe SIP Message
Subscribe Subscribe
200 Ok200 Ok
Ack SIP MessageNotify
Notify
Notify SIP Message
Ack SIP Message
200 Ok200 Ok
Message SIP Message
Message1
Ack SIP Message
Message2
200 Ok200 Ok
Message SIP Message
Ack SIP Message
-38-
8/7/2019 HENTATI_AYMAN
52/70
Ralisation et prsentation
Chapitre 5
Ralisation et prsentation
Introduction :
Limplmentation constitue la dernire tape dans le processus de ralisation de ce projet .
Pour cela, on prsentera par la suite un scnario complet qui va parcourir toutes les tapes de la
mise en place du serveur ainsi que le dploiement des diffrents composants.
Mais tout dabord, on va prsenter notre atelier de travail.
I. Atelier de travail :Notre atelier se compose dun outil danalyse et de conception Rational Rose , un
environnement de dveloppement orient objet Java , un plugin pour le dveloppement de
service conforme aux spcifications de JAIN SLEE 1.0 et une plate-forme de VOIP libre certifi
pour JSLEE 1.0.
I.1.Rational Rose :Rational Rose est conue pour fournir un ensemble complet doutils de modlisation
graphique, danalyse et de conception dans le dveloppement de logiciels bass sur les modles
UML (Unified Modeling Language), COM (Component Object Modeling), OMT (Object Modeling
Technique) et Booch ("93method for visual modeling").Rational Rose utilise la modlisation graphique pour raisonner sur des problmes complexes
en sappuyant sur des modles organiss. Un modle facilite la comprhension du problme et
permet de dcrire les caractristiques essentielles dun systme.
On a profit des avantages majeurs de cet outil afin de bien modliser notre projet qui est
bas essentiellement sur le modle orient objet.
I.2.Java :Le choix des bons outils de travail est une tche critique sur laquelle repose le bon
droulement de l'tape de conception. Pour la ralisation de ce projet on tait oblig dutiliser la
plate-forme de dveloppement Java vue que JAIN nest quune extension pour celle-ci.
En outre, Ce choix est justifi par le fait que ce langage :
utilise le concept orient objet et s'apprte parfaitement notre cas. permet la cration d'interfaces graphiques sophistiques (menus droulants, boutons,
cases cocher,...) essentielles pour la conception de l'interface graphique de
SUP_Messenger.
inclue le concept du modle vnementiel. .
-39-
8/7/2019 HENTATI_AYMAN
53/70
Ralisation et prsentation
prsente le grand avantage d'tre portable sur plusieurs plates-formes (Windows,Linux,...).
Tous ces avantages se conforment aux spcifications de JAIN quon a dj prsentes dans la
premire partie de ce rapport.
I.3.Le plugin EclipSLEE :EclipSLEE est un environnement graphique de cration de service pour le dveloppement
rapide des services valeur ajoute de JAIN SLEE. C'est un projet qui a t conduit par la
communaut de Mobicents.
I.4.Le serveur Mobicents :Mobicents est une application serveur base sur un modle vnementiel de haute scalabilit
et un modle de composant trs robuste. Cest la premire et la seule plate-forme de VOIP libre
qui a t certifie pour SLEE 1.0.
Mobicents complte J2EE et assure la convergence voix/vido/donn dans les rseaux de
nouvelle gnration. Elle va nous servir pour valider notre application.
II.Scnario :Afin de mettre en vidence notre travail, on se propose, dans ce paragraphe, de prsenter un
scnario qui va prsenter les diffrentes phases de dploiement de chaque composant.
Etape 1 : Dmarrer le serveur
Ceci se fait par la commande suivante : run c all b 127.0.0.1
Figure 5.1 : Dmarrage du serveur
Etape 2 : Dployer ladaptateur de ressource :
Aprs avoir dmarrer le serveur, on doit dployer le SIPRA par la commande : ant deploySIPRA
-40-
8/7/2019 HENTATI_AYMAN
54/70
Ralisation et prsentation
Figure 5.2 : Dploiement du SIPRA
Etape 3 : Dployer les services :Une fois le SIPRA est bien install on doit dployer les services grce la commande :
ant deplyservice
Figure 5.3 : Dploiement des services
Etape 4 : Dmarrer le premier client :
Figure 5.4 : Interface de dmarrage du premier client
-41-
8/7/2019 HENTATI_AYMAN
55/70
Ralisation et prsentation
Etape 5 : Se connecter au serveur :
Figure 5.5 : Etat du client aprs la connexion
Etape 6 : Faire de mme pour lautre client :
Figure 5.6 : Interface de dmarrage du deuxime client
Etape 7: Initier une session de chatting de lun lautre.
Figure 5.7 : Initiation dune session de chatting
Etape 8: Spcifier ladresse du correspondant :
Figure 5.8 : Spcification de ladresse du correspondant
-42-
8/7/2019 HENTATI_AYMAN
56/70
Ralisation et prsentation
Etape 9 : Commencer la discussion :
.
Figure 5.9 : Aymen commence envoyer le premier message
Figure 5.10 : Mohamed reoit le message de Aymen
-43-
8/7/2019 HENTATI_AYMAN
57/70
Ralisation et prsentation
Conclusion :
Ce chapitre a t consacr limplmentation des diffrents composants du projet. En outre,
On a suivi les diffrentes tapes ncessaires pour faire fonctionner toute la chane SIP.
En fin, il faut avouer que ce travail ne reprsente quun cas dutilisation de la SLEE. En effet,cette nouvelle technologie prsente un domaine trs vaste pour le dploiement des services de
future gnration.
-44-
8/7/2019 HENTATI_AYMAN
58/70
Conclusion Gnrale
Conclusion Gnrale
Ltude dtaille des notions de bases permettant daborder ce sujet a constitu la premire
tape satisfaire. Aussi, a t-on tabli dans une seconde partie le modle architectural
dimplmentation de ce projet. Lanalyse, la conception et la ralisation ont t les axes de travail
adopts lors de la dernire partie.
Au terme de ce travail, on est de plus en plus conscient de la richesse du sujet et de ses
perspectives dextension. Dailleurs, on na pas dvelopp un service qui tient compte de la
transmission de la voix tel que VOICE CHAT ou bien le cas des systmes IVR. Ds lors, On
projette de dvelopper davantage cette nouvelle problmatique dans nos futurs travaux.
-45-
8/7/2019 HENTATI_AYMAN
59/70
Conclusion Gnrale
Annexe A
Le Protocoles SIP
I. Histoire du protocole SIP :Le protocole SIP tel qu'il est connu est la runion de deux protocoles s'inspirant des protocoles
de gestion de vidoconfrence. D'un ct SIPv1, un mcanisme pour mettre en place des
communications point point ou multicast. Ce protocole reposait sur des changes de message
en mode texte. Son concept prdominant tait l'enregistrement auprs de serveurs de confrence.
De l'autre ct, le protocole SCIP (Simple Conference Invitation Protocol) avait le mme but
mais se basait sur le protocole HTTP (Hyper Text Transfert Protocol) reprenant notamment les
codes de rponse. L'identification des utilisateurs se faisait grce des adresses e-mails dans le but
de leur fournir un identifiant unique quelque soit le mode de communication choisi. Le RFC2543
premirement tabli a t rendu obsolte par le RFC3261 publi en Juin 2002.
II.Architecture de SIP :Les lments de base autour de SIP sont peu nombreux. L'entit avec laquelle l'utilisateur
interagit est appele le client. Il peut tre soit matriel soit logiciel. Un client matriel est appel
un hard phone, il ressemble un tlphone classique mais embarque une pile SIP. Un client
logiciel est un soft phone, il mule sur un ordinateur les fonctions d'un tlphone. Les autres
lments sont des serveurs qui forment ce que l'on appelle une plateforme de signalisation.
Serveur Registrar : Cet quipement associe un utilisateur un identifiant unique connu par les
tierces personnes. Un utilisateur doit s'enregistrer pour tre visible comme dcrit la figure A.1.
Figure A.1. Principe de l'enregistrement
-46-
8/7/2019 HENTATI_AYMAN
60/70
Conclusion Gnrale
Serveur Location : Cet quipement est une table de correspondance entre une adresse
symbolique et une adresse physique. Un utilisateur s'inscrit auprs du Registrar en lui spcifiant
une adresse physique. C'est cette adresse physique qui va tre enregistre face l'identifiant de
l'utilisateur.
Serveur Proxy SIP : Le Proxy s'occupe de relayer la signalisation des appels, il agit la fois
comme un client et un serveur puisqu'il met et reoit des requtes. Le comportement d'un
serveur Proxy est illustr par la figure A.2
Figure A.2. Fonctionnement du serveur Proxy
Serveur Redirect : Le redirect permet de rediriger certains appelants vers d'autres serveurs.
Ainsi, les clients concerns s'adresseront directement ces serveurs les fois suivantes, comme on
peut le voir la figure.
Figure A.3.Fonctionnement du serveur
Outre l'utilisation d'un serveur comme Proxy ou redirect, une distinction importante faire entre
les serveurs est s'ils grent des tats ou non. Sans gestion des tats, le serveur traite chaquemessage arrivant comme nouveau, il est indpendant du prcdent et aucune trace des messages
-47-
8/7/2019 HENTATI_AYMAN
61/70
Conclusion Gnrale
n'est garde. Dans ce cas, les rponses ne peuvent tre associes aux requtes. L'autre solution,
peut-tre plus intressante en termes de programmation, est beaucoup plus lourde puisqu'on ne
considre plus chaque message indpendamment mais comme faisant partie d'une transaction.
Ainsi, il faut garder trace de chaque message afin de savoir dans quel tat on se trouve. Le
problme avec cette alternative est que la gestion des tats consomme beaucoup de ressources :
mmoire notamment.
Elle est donc difficilement applicable dans les installations de trs grande envergure comme les
oprateurs.
III. Messages SIP :Le protocole SIP repose sur le mme modl
Recommended