HENTATI_AYMAN

8/7/2019 HENTATI_AYMAN

1/70


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


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.


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


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/20010101004602


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%A9cification


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/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


9/70


10/70


11/70


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.


13/70

Partie I :

CONCEPTS GENERAUX


14/70


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-


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-


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-


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-


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-


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-


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-


22/70


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


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-


36/70

Partie II

Partie II :

Analyse, Conception et Ralisation

-23-


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-


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-


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-


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%E9quences


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-


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-


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-


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-


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-


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


leurs traitements

-33-


47/70

Conception

RegistrarActivityContextInterface Fournit linterface Java de lobjet

RegistrarSbb

PresenceSbb Dfinit les diffrents types dvnements


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-


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-


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-


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-


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-


52/70

Ralisation et prsentation

Chapitre 5


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-


53/70


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-


54/70


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-


55/70


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-


56/70


Etape 9 : Commencer la discussion :

.

Figure 5.9 : Aymen commence envoyer le premier message

Figure 5.10 : Mohamed reoit le message de Aymen

-43-


57/70


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-


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-


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-


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-


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

Documents

HENTATI_AYMAN