Création et intégration des services de téléphonie sur IP « JAIN

Création et intégration
des services de téléphonie
sur IP
« JAIN »
Réalisé par : Ayman HENTATI
Encadré par : Mr. Zied CHOUKAIR
Dédicaces
À l’âme de mon papa, que dieu le bénisse...
À ma maman, la plus exquise des mères...
À mon bienveillant frère Haitham...
À ma chère sœur Amal...
À ma chère Taouba...
À tous mes amis qui m'ont réchauffés le cœur
par leurs e-mails dans toute cette période et
qui m’ont soutenu à la mort de mon père:
Amine, Ahmed, Sebti, Sinda, Khaoula,
Khaled, Walid, Raouya, Abdallah,
Anas, Saousan, Salma…
Avant-propos
Ce présent travail a été réalisé au sein de SUP’COM. Il s’inscrit dans le cadre de mon projet de
fin d’études à l’école supérieure des communications de Tunis (SUP’COM).
Au terme de ce travail, je tiens à rendre un grand hommage à mon encadreur Mr. Zied
CHOUKAIR qui m’a suivi durant ces trois mois de travail, m’apportant attention et rigueur dans
l’analyse des résultats obtenus.
Je tiens également à remercier Mr Mounir FRIKHA, Chef de département à 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
présence et de juger ce travail.
Enfin, je veux exprimer de mes fonds, ma reconnaissance à ma mère pour l'amour dont elle
m'a entouré, pour son aide et ses sacrifices.
Résumé :
Dans le passé, quand un client demandait un nouveau service, l’opérateur de réseaux devait demander
à l’équipementier ou au fournisseur de services de fournir de nouveaux paramètres dans les réseaux. Donc, les
opérateurs dépendaient fortement de leurs équipementiers car ils étaient les seuls à être capables
de modifier les réseaux. De plus, les fournisseurs de services ont toujours tendance à développer
des services propriétaires suivant leurs propres normes. Ces contraintes rendent les modifications
et la création de nouveaux services difficiles et très longues.
La technologie JAIN, basé sur la plateforme JAVA, introduit la portabilité des services entre
systèmes et permet de remplacer toutes les interfaces propriétaires par d’autres qui sont standards
Dans ce contexte, notre travail consiste à concevoir une plate-forme de messagerie en se basant
sur les spécifications de JAIN.
Mots clés :
NGN, JAIN, JAIN SLEE, SBB, SIP, Messagerie instantanée, Présence, Adaptateur de ressource
Glossaire
API
Une Interface de programmation (en anglais Application Programming
Interface) définit la manière dont un composant informatique peut
communiquer avec un autre.
Activity
Une activité représente un ensemble d’événements.
AC
(Activity Context)
Un contexte d'activité représente l'activité fondamentale dans la SLEE. Elle
tient également les attributs en commun que les entités SBB veulent partager
Event
Un évènement est un composant logique qui permet de diffuser
l'information entre les différentes entités de la SLEE
EJB
(Enterprise Java Bean)
C’est le composant le plus élémentaire dans la J2EE.
IM
(Instant Messaging)
Messagerie synchrone qui permet de recevoir et d'envoyer instantanément
des messages.
JAIN
(Java API for Integrated Network)
C’est une initiative au sein de la Java Community Process, dont l'objectif est le
développement d'interfaces de programmation permettant la création de
services de téléphonie (voix et données).
J2EE
(Java to Enterprise Edition)
C’est une spécification pour le langage de programmation Java de Sun plus
particulièrement destiné aux applications d'entreprise.
JCP
Le Java Community Process (JCP) est une organisation créée par Sun en
1998. Son but est de coordonner l'évolution du langage Java et des
technologies qui lui sont associées.
OSA
(Open Services Architecture)
C’est une architecture de services ouverte quia été spécifié par le 3GPP
destinée aux services mobiles.
Parlay
C’est la couche API de OSA
Presence
C’est un système de notification de présence, indiquant si les individus de la
liste de contacts sont simultanément en ligne et leur disponibilité pour
discuter.
Proxy
Il s'occupe de relayer les appels, il agit à la fois comme client et serveur.
RA
(Resource Adaptor)
Assure le mapping entre les messages protocolaires et les événements.
Registrar
Cet équipement associe un utilisateur à un identifiant unique connu par les
tierces personnes.
SBB
(Service Building Bloc)
C’est le composant le plus élémentaire dans la SLEE.
SLEE
(Service Logic Execution Environment)
C’est une spécification pour le langage de programmation Java de Sun plus
particulièrement destiné aux applications de communications. Elle est
destiné pour héberger des services temps réels de type Voix/Donné.
3GPP
(Third Generation Partnership Project)
Une organisation internationale qui permet l’établissement des spécifications
techniques pour l’ensemble de système de la téléphonie 3 G.
UML
(Unified Modeling Language)
C’est un langage servant à décrire des modèles d’un système (réel ou logiciel)
avec des notations. UML se base sur les concepts orientés objets.
Table des matières
INTRODUCTION GENERALE
Partie I : CONCEPTS GENERAUX
Chapitre1 : Les réseaux NGN
Introduction :........................................................................................................................................................1
I. Architecture du réseau NGN :..................................................................................................................1
II. Le réseau d’accès :........................................................................................................................................2
II.1. Les réseaux d’accès fixes :....................................................................................................................2
II.2. Les technologies radio locale :.............................................................................................................2
II.3. Les réseaux d’accès mobiles :...............................................................................................................3
III. La couche transport :...................................................................................................................................3
IV. La couche contrôle : ....................................................................................................................................4
IV.1. Les entités fonctionnelles du cœur du réseau : ................................................................................4
IV.1.1. La Média Gateway (MG) : ........................................................................................................4
IV.1.2. La Signalling Gateway (SG) : ....................................................................................................4
IV.1.3. Le serveur d’appel : ....................................................................................................................4
IV.2. Les Familles protocolaires : .................................................................................................................5
V. La couche service : .......................................................................................................................................6
Conclusion :............................................................................................................................................................6
Chapitre2 : La technologie JAIN
Introduction : ........................................................................................................................................................7
I. Aperçu historique de JAIN : ......................................................................................................................7
II. Avantages et intérêts de JAIN : ................................................................................................................8
II.1. La portabilité des services : ..................................................................................................................8
II.2. La convergence du réseau : ..................................................................................................................9
II.3. La sécurité de l’accès au réseau : ..........................................................................................................9
III. L’Architecture et les interfaces JAIN : ....................................................................................................9
III.1. Les couches d’abstractions : .................................................................................................................9
III.2. Principe des interfaces JAIN : ............................................................................................................10
III.3. L’architecture de JAIN : ......................................................................................................................11
IV. Les différentes APIs de JAIN : ...............................................................................................................12
V. JAIN SIP API : ............................................................................................................................................13
VI. JAIN SLEE : ................................................................................................................................................13
VI.1. La spécification de JAIN SLEE : .....................................................................................................14
VI.1.1. Le modèle d’évènement : ........................................................................................................15
VI.1.2. Le modèle de composant : .......................................................................................................16
VI.1.3. La capacité d’administration : ..................................................................................................17
VI.1.4. La capacité de ressource : .........................................................................................................17
VI.2. Les composantes de bases du JAIN SLEE : ..................................................................................18
VI.2.1. L’adaptateur de ressource : ......................................................................................................18
VI.2.2. Le routeur d’évènements : .......................................................................................................19
VI.2.3. L’évènement : .............................................................................................................................19
VI.2.4. L’activité et le contexte d’activité : ..........................................................................................19
VI.2.5. Les composants SBB (Service Building Block): ...................................................................20
VI.2.6. Les composants de gestion et de contrôle des services : ....................................................20
VII.
JAIN et OSA/Parlay : .........................................................................................................................21
Conclusion ..........................................................................................................................................................22
Partie II : ANALYSE, CONCEPTION ET REALISATION DU PROJET
Chapitre 3 : Analyse des besoins
Introduction : .....................................................................................................................................................24
I. Identification des besoins : .....................................................................................................................24
II. Modèles des besoins : ...............................................................................................................................25
II.1. Acteurs : ...............................................................................................................................................25
II.2. Les diagrammes de cas d’utilisation : ...............................................................................................25
II.2.1. L’adaptateur de ressource : ......................................................................................................25
II.2.2. Les services : ..............................................................................................................................25
II.2.3. Le client de messagerie instantanée : .....................................................................................26
II.3. Modèle de l’interface homme machine de SUP Messenger : .......................................................26
II.4. Les diagrammes d’activités : ..............................................................................................................27
II.4.1. L’adaptateur de ressource : ......................................................................................................27
II.4.2. Les services : ..............................................................................................................................28
II.4.3. Le client de messagerie instantanée : .....................................................................................29
Conclusion : ........................................................................................................................................................29
Chapitre 4 : Conception
Introduction : .....................................................................................................................................................30
I. Conception générale : ...............................................................................................................................30
II. Conception détaillée : ...............................................................................................................................31
II.1. Représentation statique : ....................................................................................................................31
II.1.1. Les diagrammes de paquetages : .............................................................................................32
II.1.1.1. Diagramme de paquetages de SUP Messenger : ..........................................................32
II.1.1.2. Diagramme de paquetages de SIPRA : .........................................................................33
II.1.1.3. Diagramme de paquetages des services : ......................................................................33
II.1.2. Les diagrammes de classes : ....................................................................................................34
II.1.2.1. Diagramme de classes de SUP Messenger : .................................................................35
II.1.2.2. Diagramme de classes de SIPRA : .................................................................................36
II.1.2.3. Diagramme de classes des services : ..............................................................................37
II.2. Représentation dynamique : ..............................................................................................................38
Conclusion : ........................................................................................................................................................38
Chapitre 5 : Réalisation et présentation
Introduction : .....................................................................................................................................................39
I. Atelier de travail : .......................................................................................................................................39
I.1. Rational Rose : ........................................................................................................................................39
I.2. Java : .........................................................................................................................................................39
I.3. Le plugin EclipSLEE : ..........................................................................................................................40
I.4. Le serveur Mobicents : ..........................................................................................................................40
II. Scénario : ......................................................................................................................................................40
Conclusion : ........................................................................................................................................................44
CONCLUSION GENERALE ...........................................................................................................45
ANNEXE A ................................................................................................................................................... 46
ANNEXE B.................................................................................................................................................... 54
BIBLIOGARPHIE.....................................................................................................................................57
Liste des figures
Figure 1.1 : Principe d’architecture d’un réseau NGN..............................................................................................2
Figure 2.1 : Architecture de base de JAIN.................................................................................................................7
Figure 2.2 : Passage des systèmes propriétaires aux systèmes ouverts.....................................................................8
Figure 2.3 : Les différentes couches et APIs de JAIN..............................................................................................10
Figure 2.4 : Exemple d’introduction d’une interface JAIN......................................................................................10
Figure 2.5 : Architecture en couche de JAIN............................................................................................................11
Figure 2.6 : Les différentes JAIN SIP API ...............................................................................................................13
Figure 2.7 : Le modèle d’évènement de JAIN..........................................................................................................16
Figure 2.8 : Architecture de JAIN SLEE..................................................................................................................18
Figure 2.9 : Rôle de l’adaptateur de ressource..........................................................................................................19
Figure 2.10 : L’activité et le contexte d’activité.........................................................................................................20
Figure 3.1 : Diagramme de cas d’utilisation de SIPRA ............................................................................................25
Figure 3.2 : Diagramme de cas d’utilisation des services.........................................................................................26
Figure 3.3 : Diagramme de cas d’utilisation de SUP Messenger..............................................................................26
Figure 3.4 : Modèle de l’interface homme machine du SUP Messenger..................................................................27
Figure 3.5 : Diagramme d’activité de SIPRA............................................................................................................27
Figure 3.6 : Diagramme d’activité des services.........................................................................................................28
Figure 3.7 : Diagramme d’activité de SUP Messenger.............................................................................................29
Figure 4.1 : Architecture générale du projet..............................................................................................................31
Figure 4.2 : Diagramme de paquetage de SUP Messenger......................................................................................32
Figure 4.3 : Diagramme de paquetage des services .................................................................................................34
Figure 4.4 : Diagramme de classes de SUP Messenger............................................................................................35
Figure 4.5 : Diagramme de classes de SIPRA ..........................................................................................................36
Figure 4.6 : Diagramme de classes du Proxy............................................................................................................36
Figure 4.7 : Diagramme de classes du Registrar.......................................................................................................37
Figure 4.8 : Diagramme de classes du Presence service ..........................................................................................37
Figure 4.9 : Diagramme de séquence de tout le système .........................................................................................38
Figure 5.1 : Démarrage du serveur ............................................................................................................................40
Figure 5.2 : Déploiement du SIPRA..........................................................................................................................41
Figure 5.3 : Déploiement des services.......................................................................................................................41
Figure 5.4 : Interface de démarrage du premier client .............................................................................................41
Figure 5.5 : Etat du client après la connexion ..........................................................................................................42
Figure 5.6 : Interface de démarrage du deuxième client..........................................................................................42
Figure 5.7 : Initiation d’une session de chatting.......................................................................................................42
Figure 5.8 : Spécification de l’adresse du correspondant..........................................................................................42
Figure 5.9 : Aymen commence à envoyer le premier message.................................................................................43
Figure 5.10 : Mohamed reçoit le message de Aymen................................................................................................43
Liste des tableaux
Tableau 2.1: Comparaison entre le système de communication et le système d’entreprise ………………....14
Tableau 4.1: Définition des paquetages et des classes de SUP Messenger……………...……………………32
Tableau 4.2: Définition des classes de SIPRA.........................................................................................…....33
Tableau 4.3: Définition des classes des différents paquetages des services......................................…..........33
Introduction Générale
L’environnement de service des opérateurs de télécommunications est aujourd’hui
particulièrement complexe avec l’intégration de services très divers provenant du monde Internet.
Cette complexité provient du mariage entre les télécommunications et l’informatique. Le réseau
intelligent autour du réseau téléphonique a longtemps été le vecteur de cette intégration et a permis
un certain succès à ce mariage avec l’arrivée de services comme la carte prépayée ou le numéro vert.
Cependant, modifier un service ou créer un nouveau service accessible par le réseau téléphonique
nécessite la modification de tous les noeuds du réseau qui sont des commutateurs très complexes.
De plus, les fournisseurs de services ont toujours tendance à développer des services
propriétaires suivant leurs propres normes. Ces contraintes rendent les modifications et la création de
nouveaux services difficiles et très longues dans le contexte d’un marché très concurrentiel comme
aujourd’hui. D’ailleurs, ces services sont très coûteux du fait de la complexité et du nombre de
commutateurs à modifier dans le réseau.
C'est dans ce contexte que la technologie JAIN, basé sur la plateforme JAVA, introduit la
portabilité des services entre systèmes et permet des accès sécurisés aux ressources des différents
réseaux. Elle constitue ainsi une architecture de nouvelle génération qui permet de remplacer toutes
les interfaces propriétaires par d’autres qui sont standards. En effet, la spécification des APIs JAIN
se fait au sein du JCP (Java Community Process) ce qui permet à tout ce qui est intéressé de
participer.
Dans ce cadre, notre travail consiste à proposer un prototype de plate-forme de messagerie
basée sur ces spécifications.
Partie I :
CONCEPTS GENERAUX
Les réseaux NGN
Chapitre 1
Les réseaux NGN
Introduction :
L’évolution progressive du monde des télécoms vers des réseaux et des services de nouvelle
génération est aujourd’hui une tendance forte qui suscite l’intérêt d’une majorité d’acteurs. Elle
résulte de la conjonction d’un ensemble de facteurs favorables dont :
•
les évolutions profondes du secteur des télécommunications ;
•
le développement de gammes de services nouveaux ;
•
les progressions technologiques d’envergure dans le domaine des réseaux de données.
Il en résulte de ce contexte et afin de s’adapter aux grandes tendances qui sont la recherche de
souplesse d’évolution du réseau, la distribution de l’intelligence dans le réseau, et l’ouverture à des
services tiers, une évolution vers un nouveau modèle de réseaux et de services appelé NGN
(Next Generation Networks).
Les NGN sont basés sur une évolution progressive vers le « tout IP » et sont modélisées en
couches indépendantes dialoguant via des interfaces ouvertes et normalisées.
Les réseaux de télécommunications traditionnels évolueront vers un modèle ouvert, distribué,
fortement basé sur le protocole IP et la transmission en mode paquet en général. Cette évolution
technologique, tout en étant transparente pour les utilisateurs, se fera de manière progressive
pour les opérateurs. .
Ce chapitre présentera une étude descriptive de l’ensemble de ces nouveaux concepts
globalement désignés sous l’appellation NGN. Il inclut aussi une synthèse des évolutions
technologiques majeures et le détail des nouveaux concepts liés aux NGN.
I. Architecture du réseau NGN :
Les réseaux de nouvelle génération peuvent être présentés comme un concept permettant de
définir et déployer des réseaux évolutifs et favorisant pour les fournisseurs de services et les
opérateurs la création et la gestion de services innovants. Les services doivent être évolutifs et
accessibles indépendamment du réseau d’accès utilisé.
Le NGN est caractérisé par plusieurs éléments essentiels :
•
Un cœur de réseau unique et mutualisé pour tous types d’accès et de services ;
•
Une architecture de cœur de réseau en trois couches : Transport, Contrôle et Services.
•
Une évolution du transport en mode paquet (une convergence progressive vers le tout
IP) ;
-1-
Les réseaux NGN
•
Des interfaces ouvertes et normalisées entre chaque couche, et notamment au niveau des
couches contrôle et services afin de permettre la réalisation de services indépendants du
réseau ;
•
Le support d’applications multiples, multimédia, temps réel, en mobilité totale, adaptables
à l’utilisateur et aux capacités des réseaux d’accès et des terminaux ;
•
La prise en compte de réseaux d’accès multiples ;
•
La prise en compte de terminaux multiples.
Figure1.1 : Principe d’architecture d’un réseau NGN
II. Le réseau d’accès :
Ce paragraphe présente les principales technologies d'accès actuellement connues dont la
généralisation contribuera à alimenter le besoin et le développement des NGN.
II.1. Les réseaux d’accès fixes :
Les réseaux d'accès fixes s'adaptent progressivement au support de services de données à
haut débit:
•
Le réseau téléphonique commuté, initialement support des services voix, a permis une
ouverture à des services voix/données haut débit grâce aux technologies xDSL
accessibles aux nouveaux opérateurs par le biais du dégroupage de la boucle locale.
•
L'accès Ethernet, initialement conçu pour fournir des services de données (IF) en
entreprises, voit son usage s'étendre en termes de débit, de périmètre d'utilisation et de
services transportés (voix et donnée, multimédia).
II.2. Les technologies radio locale :
Plusieurs technologies permettent de fournir des services voix et données fixes en utilisant
un accès radio. On citera notamment la boucle locale radio. les réseaux locaux sans fil et
Bluetooth. Ces technologies assez récentes, seront l’objet de mutations et développements très
importants.
Quant aux réseaux satellitaires, plusieurs tentatives de déploiement déjà
relativement anciennes ont mené à des échecs (avant tout d'ordre économique du fait des coûts
-2-
Les réseaux NGN
particulièrement élevés de déploiement), mais ils pourraient, dans les prochaines années, trouver
enfin leur place parmi les réseaux d'accès effectivement utilisés pour fournir des services « fixes
».
II.3. Les réseaux d’accès mobiles :
Plusieurs réseaux d'accès radio fournissant des services de radiocommunications mobiles
publics sont présentés.
Le GSM est une technologie historiquement orientée vers les services voix et données bas
débit mature et très largement répandue, mais évolue actuellement avec l'ajout de services de
transmission de données en mode paquet (GPRS), et à court terme avec l'émergence de la
nouvelle génération « convergente » voix/données/multimédia: l'UMTS.
III.
La couche transport :
La couche Transport gère l'acheminement du trafic vers sa destination. Les principales
évolutions du réseau de transport concernent les technologies de transmission et de
commutation utilisées sur les liaisons qui interconnectent les réseaux d'accès au coeur de réseau.
Maintenant, la question pertinente est de savoir comment les backbones sont susceptibles
d'évoluer afin de supporter un très haut débit, et surtout le transport unifié de flux mixtes
voix/donnée/multimédia avec une qualité de service adéquate.
Tout d'abord il faut distinguer entre le niveau réseau de transmission et le niveau réseau de
commutation dans un «réseau de transport» (couche transport)
•
Le réseau de transmission correspond au réseau physique de liens et de nœuds qui
desservent une zone (un immeuble, une ville, une région, un pays ou un continent).
•
Le réseau de commutation correspond à certains noeuds qui permettent d'acheminer une
communication à travers le réseau de transmission en fonction de sa destination.
Dans les architectures traditionnelles, un opérateur possède (ou loue) un réseau de
transmission sur lequel s'appuient en général plusieurs réseaux de commutation, le premier est
consacré uniquement à la commutation de la voix, le second pour la commutation de données.
Ainsi, pour les NGN, on parvient à fusionner ces deux réseaux en un seul. Si l'on visualise les
technologies mises en jeu en s'appuyant sur le modèle en couches OSI (Open System
Interconnection), la séparation entre réseau de transmission et réseau de commutation est très
nette.
Pour la mise en oeuvre de ces réseaux de transport « de nouvelle génération », on peut mettre
en évidence deux évolutions majeures des réseaux de transport au niveau des réseaux de
transmission et des réseaux de commutation.
Concernent les réseaux de transmission, les techniques dominantes sont remises en cause.
-3-
Les réseaux NGN
En effet, le multiplexage TDM (Time Division Multiplexing), utilisée en grande majorité dans les
réseaux actuels, est une technique de transmission adaptée pour la commutation de circuits alors
que la tendance actuelle est de migrer les réseaux de transmission actuels vers un réseau de
transmission unique, neutre, voire favorable à la commutation de paquets et donc on assiste
aujourd'hui à des nombreux développements autour du multiplexage WDM et aussi à des
plusieurs évolutions liées à l'optique et au WDM.
IV.
La couche contrôle :
Les évolutions au niveau de la couche contrôle sont majeures. Plusieurs nouveaux
mécanismes et protocoles sont mis en jeu et donc une nouvelle architecture qui découle. La
couche Contrôle se compose de serveurs dits « Softswitch » gérant d'une part les mécanismes de
contrôle d'appel (pilotage de la couche transport, gestion des adresses), et d'autre part l'accès aux
services (profils d'abonnés, accès aux plates-formes de services à valeur ajoutée).
IV.1. Les entités fonctionnelles au cœur du réseau :
IV.1.1. La Média Gateway (MG) :
Les Gateways ont un rôle essentiel: elles assurent non seulement l'acheminement du
trafic, mais aussi l'inter fonctionnement avec les réseaux externes et avec les divers réseaux
d'accès. La Media Gateway est située au niveau du transport des flux média entre le réseau RTC
et les réseaux en mode paquet, ou entre le coeur de réseau NGN et les réseaux d'accès. Elle a
pour rôle le codage et la mise en paquets du flux média reçu du RTC et vice versa (conversion du
trafic TDM IP) et aussi la transmission, suivant les instructions du Media Gateway Controller,
des flux média reçus de part et d'autre.
IV.1.2. La Signalling Gateway (SG) :
La fonction Signalling Gateway a pour rôle de convertir la signalisation échangée entre le
réseau NGN et le réseau externe interconnecté selon un format compréhensible par les
équipements chargés de la traiter, mais sans l'interpréter (ce rôle étant dévolu au Media Gateway
Controller). Notamment, elle assure l'adaptation de la signalisation par rapport au protocole de
transport utilisé. Cette fonction est souvent implémentée physiquement dans le même
é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 d’appel :
Dans un réseau NGN, c'est le MGC qui possède « l'intelligence ». Il gère:
•
L'échange des messages de signalisation transmise de part et d'autre avec les passerelles de
signalisation, et l'interprétation de cette signalisation.
•
Le traitement des appels: dialogue avec les terminaux H.323, SIP voire MGCP,
-4-
Les réseaux 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 du
réseau, etc.
•
La réservation des ressources dans le MG et le contrôle des connexions internes au MG
(commande des Media Gateways).
Donc dans l'architecture des réseaux NGN, le serveur d'appel, aussi appelé Softswitch ou
Media Gateway Controller (MGC) est le nœud central qui supporte l'intelligence de
communication.
IV.2. Les Familles protocolaires :
La convergence des réseaux voix/données ainsi que le fait d'utiliser un réseau en mode
paquet pour transporter des flux multimédia, ayant des contraintes de « temps réel », a nécessité
l'adaptation de la couche Contrôle, En effet ces réseaux en mode paquet étaient généralement
utilisés comme réseau de transport mais n'offraient pas de services permettant la gestion des
appels et des communications multimédia. Cette évolution a conduit à l'apparition de nouveaux
protocoles, principalement concernant la gestion des flux multimédia, au sein de la couche
Contrôle.
On peut classer les protocoles de contrôle en différents
groupes:
•
Les protocoles de contrôle d'appel permettant l'établissement, généralement à l'initiative
d'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
développé à l'IETF.
•
Les protocoles de commande de Media Gateway qui sont issus de la séparation entre les
couches Transport et Contrôle permettent au Softswitch ou Media Gateway Controller
de gérer les passerelles de transport ou Media Gateway. MGCP (Media Gateway Control
Protocol) de l'IETF et H.248/MEGACO, développé conjointement par l'UIT et l’IETF,
sont actuellement les protocoles prédominants.
•
Les protocoles de signalisation entre les serveurs de contrôle (ou Media Gateway
Controller) permettant la gestion du plan contrôle au niveau du coeur de réseau avec des
protocoles tels que BICC (Bearer Independant Call Control), SIP-T (SIP pour la
téléphonie) et H.323. L'interconnexion avec les réseaux de signalisation SS7 se fait
généralement via des passerelles de signalisation ou Signalling Gateways par l'utilisation
de protocole tel que SIGTRAN.
De plus, l'interconnexion de ces réseaux de données avec les réseaux existants de téléphonie
-5-
Les réseaux NGN
(TDM avec signalisation SS7) a nécessité le développement de protocoles dédiés à
l'interconnexion des réseaux et au transport de la signalisation SS7 sur des réseaux en mode
paquet.
V. La couche service :
Actuellement, les services sont dédiés à un type de réseau; services Réseau Intelligent sur le
réseau téléphonique pour les terminaux téléphoniques (fixes ou mobiles), et services mail, web,
news sur les réseaux IP.
L'apparition des nouveaux réseaux d'accès tels que l'UMTS, le GPRS, I'xDSL, l'Ethernet
longue distance, et la multiplication des terminaux communicants (téléphone mobile
GPRS/UMTS, PDA) et la convergence des coeurs de réseaux, poussent à une transformation de
l'architecture des plates-formes de services.
Cette nouvelle architecture doit offrir la possibilité aux clients d'accéder aux services, quelle
que soit la nature des terminaux et le type de protocole utilisé pour accéder aux plates-formes de
services, via un réseau 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 représente encore à ce jour un sujet relativement
amont, notamment du point de vue des opérateurs 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 confrontés à des problématiques de financement et de pérennité, 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 apparaît comme un processus inévitable
du fait de la convergence voix/données/image et fixe/mobile. Elle a déjà attiré l’intérêt d’un
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 présenter JAIN qui un exemple d’architecture de réseau
NGN. On va scruter tous les détails qui se rapportent à cette technologie. On va surtout mettre
l’accent sur le point fort de cette architecture : le développement des services.
-6-
La technologie JAIN
Chapitre 2
La technologie JAIN
Introduction :
JAIN est un ensemble d’API (Application Program Interfaces) JAVA qui permet de
développer rapidement de nouveaux services pour des réseaux de télécommunication voix ou
données, indépendamment des serveurs utilisés (matériel). De plus, JAIN étant basé sur la
plateforme JAVA, il introduit la portabilité des services entre systèmes et permet des accès
sécurisés aux ressources des différents réseaux.
La technologie JAIN change radicalement le marché des télécommunications en permettant
le passage de systèmes fermés et propriétaires à des systèmes ouverts offrant une interconnexion
totale des différents réseaux existant (PSTN, IP, ATM, GSM, WLAN). Ceci peut être constaté
dans la figure 2.1 qui donne un premier aperçu sur l’architecture de JAIN
Actuellement, plus de 80 entreprises font partie et sont actives dans la communauté de
développement de la technologie JAIN sous le contrôle de SUN, qui garantit ainsi la qualité des
nouvelles APIs, leur homogénéité et leur compatibilité à long terme.
Figure 2.1 : Architecture de base de JAIN
I. Aperçu historique de JAIN :
Créé par SUN en 1998, JAIN étend la plate-forme JAVA à l’industrie des fournisseurs de
services. Son but est de répondre aux exigences des réseaux de télécommunication de la nouvelle
génération, en offrant des API permettant de développer des applications et services pour les
réseaux intelligents. Les développements des API JAIN sont menés 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 matériels, des fournisseurs d’équipements réseaux,
des fournisseurs de protocoles et des développeurs de services.
-7-
La technologie JAIN
La communauté de JAIN travail en étroite collaboration avec d’autre groupement
d’entreprises tel que l’ETSI, le Parlay Group et 3GPP afin de garantir des API de qualités.
II. Avantages et intérêts de JAIN :
Actuellement les solutions viennent d’un vendeur qui fournit dans une grande boite
totalement propriétaire du matériel, logiciel du serveur et des services. Les clients dépendent
donc de ce vendeur, il en résulte des coûts d’extensions et de maintenances élevés.
Avec JAIN on obtient une solution ou les différentes parties du serveur proviennent de
vendeurs différents, le client peut ainsi choisir les différentes parties en fonction de ses besoins.
La figure 2.2 présente la transition entre les systèmes actuels propriétaires fermés à des
systèmes ouverts dans lesquels chaque couche est séparée, introduisant de ce fait la liberté
d’action à tous les niveaux.
Figure 2.2 : Passage des systèmes propriétaires aux systèmes ouverts
Le fondement de JAIN s’appuie essentiellement sur la portabilité de la plate-forme JAVA.
Ceci s’est traduit par la standardisation de la couche de signalisation en des APIs qui visent à
enrichir le cœur du langage JAVA et qui a servi pour définir un environnement de création, de
test et de déploiement de nouveaux services de télécom. Dés lors, la portabilité des services, la
convergence du réseau ainsi que la sécurité d’accès au réseau, introduites par la définition de ces
APIs, représentent le point fort de JAIN :
II.1.
La portabilité des services :
Dans le domaine des télécoms, on n’a jamais parlé de la portabilité de services vu que les
interfaces restaient propriétaires jusqu’à l’avènement des concepts NGN.
En fait, les coûts de développement des services étaient élevés puisqu’il faut respecter les
contraintes de compatibilité. Par rapport à tous ces problèmes JAIN permet au développeurs de
services télécoms de franchir toutes ces barrières et leur fournir des APIs Java assurant l’intégrité
des réseaux tout en uniformisant leurs interfaces.
-8-
La technologie JAIN
II.2.
La convergence du réseau :
Les services télécoms actuels sont spécifiques à un seul type de réseau (PSTN, Paquet,
Wireless) malgré qu’ils soient déjà interconnectés.
Le modèle d’appel JAIN représente un haut niveau d’abstraction des protocoles de
signalisation et des méthodes d’accès au service. Ceci est obtenu grâce à l’ensemble des primitives
prédéfinies par les nouveaux APIs permettant d’observer, d’initialiser, de traiter et de manipuler
l’appel indépendamment de sa nature et de son contenu.
II.3.
La sécurité de l’accès au réseau :
Le nouveau bouquet de service fourni par JAIN peut être hébergé soit par une plate-forme
appartenant au réseau de l’opérateur soit chez une tierce personne qui est généralement une
société de prestation de services télécoms. Pour le deuxième cas de figure, la communauté de
JAIN a définit l’interface JAIN Parlay. Cette interface permet à ce genre de services d’accéder aux
ressources réseaux de l’opérateur et de bénéficier de quelques fonctions spécifiques sans toucher
à la sécurité et l’intégrité du réseau. En remarque donc que cette interface agit comme un firewall
pour protéger le réseau de l’opérateur de toute menace extérieure.
III. L’Architecture et les interfaces JAIN :
Avant de scruter l’architecture de JAIN, faut il tout d’abord, présenter la communauté qui a
définit les notions de base de cette technologie. En fait, il s’agit de deux groupes de recherches.
Le premier est spécialisé dans la définition des interfaces standards pour les différents protocoles
de signalisation d’où le nom PEG (Protocol Expert Group). Alors que la spécification des APIs
requis pour la création des services était dédié au AEG (Application Expert Group). Cette
« divergence » brossée à travers cette séparation ne va pas contourner les objectifs de JAIN
puisque la spécialisation à mon sens permet de créer des gens plus compétents dans le domaine.
Ce qui va entraîner plus de précision et de performance au niveau des spécifications.
III.1. Les couches d’abstractions :
Il a donc été nécessaire de définir un environnement d’exécution indépendant du protocole
de signalisation. Pour cela, plusieurs couches d’abstraction ont été crées, il définit aussi une
librairie de composant, d’outils de développement et un environnement de création de services
Comme nous l’avons dit, JAIN définit des couches d’abstractions, elles sont au nombre de trois :
•
Network layer:
Il s’agit d’une couche définissant le protocole de communication choisit.
9 Télécommunication : Réseaux intelligent (AIN/IN) ou SS7 avec beaucoup de
protocole ISUP, TCAP, NAP …
9 Wireless : SS7 avec des applications mobiles (MAP)
-9-
La technologie JAIN
9 VoIP : SIP, MGCP, Megaco, H.323
•
Signaling layer:
Il s’agit d’une couche représentant les logiciels chargés de la gestion des communications.
9 Télécommunication : Signaling Service Point (SSP)
9 Wireless : Mobile Switching Centers (MSC)
9 VoIP : Proxy, redirect serveur, H 323 gatekeeper, media gateway controllers
•
Service layer :
Il s’agit d’une couche représentant les services de base.
9 Télécommunication : Service Contrôle Points (SCP)
9 Wireless : Base Station Controllers (BSC), Home Location Registers (HLR) …
9 VoIP : Serveur d’applications internet
Figure 2.3 : Les différentes couches et APIs de JAIN
III.2. Principe des interfaces JAIN :
JAIN propose des API qui interface les différentes couches des réseaux. Ainsi, un
développeur de services peut créer des services en se basant sur l’interface utilisée, sans se soucier
des primiti propriétaires primitifs du matériel.
Figure 2.4 : Exemple d’introduction d’une interface JAIN
-10-
La technologie JAIN
III.3. L’architecture de JAIN :
La couche protocolaire de JAIN est définit par la standardisation des protocoles, tels que :
SIP, MGCP, H.323, TCAP, INAP, etc., en des interfaces standard. Dès lors, la couche
application peut utiliser des ‘’Protocol Stack’’ de différents fournisseurs. Ce qui assure un niveau
de portabilité élevé pour les services.
En outre, la couche application fournit un modèle d’appel unique pour les différents
protocoles supportés par la couche soujacente. L’idée fondamentale est de procurer pour des
sessions de différentes natures (multimédia, multi protocole,…) une machine d’état unique afin
d’accéder aux services. Celle-ci est accessible via les APIs JCC/JCAT.
Admettant que l’architecture de la technologie JAIN est plus au moins claire, on va
s’intéresser maintenant à la couche service afin de découvrir le comportement du service dans les
différents niveaux.
En fait, une application ou un service au niveau protocolaire peut communiquer directement
avec les adaptateurs de JAIN. Ces derniers sont des méthodes de classe Java, des événements, ou
des interfaces de Java qui encapsulent les ressources du réseau. Les ressources peuvent être
implémentées en Java, C, C++, et ainsi de suite, alors qu’un adaptateur de ressource doit être
obligatoirement conforme aux spécifications de JAIN.
Ce niveau le plus bas de l'abstraction ne fournit aucun dispositif à l'application pour traiter
différents types de protocoles. Par exemple, une application qui a besoin d'une session enjambant
INAP et SIP devra manipuler les deux protocoles.
Un service ou une application au prochain niveau d'abstraction de JAIN, le niveau de
contrôle d’appel JAIN ou le niveau des services de confiances, ne doit pas se rendre compte que
certaines sessions emploient des protocoles différents. Donc, les fournisseurs qui vendent un
produit conforme au JCC doivent fournir trace des échanges entre le contrôleur d’appel JAIN et
un ou plusieurs adaptateurs protocolaires.
Figure 2.5 : Architecture en couche de JAIN
-11-
La technologie JAIN
La figure 2.5 illustre d’une façon claire notre analyse citée ci-dessus.. En effet, elle nous
permet de découvrir toutes les composantes constituants chaque couche. On remarque par
exemple des rectangles qui porte la lettre ‘’A’’. Ces derniers représentent les différents types
d’adaptateurs. D’autres cercles qui portent tantôt la lettre ‘’S’’ pour dire service tant tôt la lettre
‘’P’’ pour dire politique de service. On remarque la présence d’autres composantes tel que « JAIN
Call Control », l’interface « JAIN Parlay », sans oublier, bien entendu, la « SLEE container » qu’on
peut le voir comme l’orchestre de tous ces éléments. La SLEE est la partie la plus valorisante
dans notre projet puisqu’elle va héberger nos services. Pour cette raison on a consacré toute une
partie pour le détailler.
IV. Les différentes APIs de JAIN :
La technologie de JAIN permet l'intégration de l'Internet et des protocoles du réseau
intelligent, désignés sous le nom « réseaux intégrés ». Deux types d’APIs ont été définis : des
APIs relatives à la standardisations des interfaces d’accès aux services et une autre classe d’APIs
propre au conteneurs d’applications.
Les interfaces standard mettent à la disposition du langage de programmation Java tous les
protocoles de télécoms. En revanche, les conteneurs d'applications fournissent un
environnement standard d'exécution pour des services de télécommunication. Ces services
emploient typiquement ces interfaces standard pour des communications par l'intermédiaire des
adaptateurs de ressources.
SIP, un protocole actuellement populaire au monde des télécoms, parce qu'il possède
l’avantage de ne pas être attaché à un médium particulier et est sensé être indépendant du
protocole de transport des couches basses. De plus il peut être étendu et s’adapter aux évolutions
futures. Pour cette raison JAIN offre le JAIN SIP 1.1 APIs en tant qu'élément du Java APIs pour
les communications. En utilisant le SIP, on peut développer nos propres services comme par
exemple le fameux « SIP Gateway », qui est nécessaire pour créer et contrôler les connexions.
Les spécifications définissent 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 prévues pour développer tout type de services. Elles peuvent interagir avec d’autres
sources de données tout en garantissant une bonne sécurité, il est en effet possible de confiner les
servlets à n’utiliser que les ressources de la machine virtuelle.
La JAIN SLEE a pour vocation de permettre la création de services disponibles, fiables et
modulaires qui sont portables entre les vendeurs JAIN SLEE.
Dans notre projet on va s’intéresser à JAIN SLEE. En fait, nos services seront par la suite
-12-
La technologie JAIN
hébergés par ce type de conteneur. Pour cette raison nous allons consacrer toute une partie de ce
chapitre afin de détailler ce composant. Mais faut il tout d’abord mettre l’accent sur JAIN SIP
API puisque dans notre application on a opté pour le protocole SIP.
V. JAIN SIP API :
La communauté Java n’a pas tardé de s'intéresser à SIP. Il en découle de nombreuses
implémentations du protocole pour différents supports. La première implémentation fut JAIN.
Elle permet d'avoir un contrôle très fin sur les messages.
L'API inclue un ensemble d'objets et d'interfaces qui fournissent des abstractions de haut
niveau pour représenter les concepts SIP, libérant le programmeur des détails fins comme la
gestion des transactions, mais permettant l'accès aux champs importants du message SIP (From,
To, Request- URI, Contact). Ainsi, l'API a pour but de permettre aux applications d'avoir un
contrôle sur la signalisation SIP tout en cachant toute la complexité sous-jacente qui n'est pas
appropriée pour les développeurs.
Figure 2.6 : Les différentes JAIN SIP API
La figure ci-dessus montre qu’en plus de JAIN SIP il existe d’autre APIs qui sont :
•
JAIN SIP Lite, il s’agit d’une API haut niveau fournissant une abstraction du stack SIP,
elle peut être utilisée pour créer un agent SIP.
•
JAIN SIP Servelts.
Actuellement seule la spécification de JAIN SIP est disponible, elle est fournie avec une bonne
documentation qui décrit toutes les méthodes de l’interface.
VI. JAIN SLEE :
La plate-forme JAIN SLEE permet aux exploitants de réseaux d'intégrer des services dans les
infrastructures en place, ce qui permet de protéger les investissements existants tout en
développant des applications futures en utilisant les outils standards de Java. Dés lors, elle est en
train d'être adoptée à l'échelle mondiale par les exploitants de réseaux de téléphonie fixe ou de
sans fil.
-13-
La technologie JAIN
VI.1. La spécification de JAIN SLEE :
La spécification JAIN SLEE fournit une norme permettant aux développeurs java d'élaborer
et de déployer des services dans des systèmes en temps réel comme les réseaux de transmission
vocale ou de données ou les systèmes d'automatisation industrielle.
En fait, les systèmes de communications sont des systèmes asynchrones basés sur le modèle
d’évènement. Contrairement aux systèmes d’entreprises qui utilisent typiquement les méthodes
d’invocations directes. Une architecture existante d'entreprise est définie par les spécifications de
« Entreprise JavaBeans ».
Le tableau ci-dessous fournit une vue d'ensemble des différentes caractéristiques des systèmes
d'entreprises et de communications.
Tableau 2.1: Comparaison entre le système de communication et le système d’entreprise
Comme le montre ce tableau, il y a des différences substantielles entre les systèmes de
communications et les systèmes d'entreprises. Les spécifications d'EJB répondent aux exigences
des systèmes d'entreprises. Alors que la SLEE répond aux exigences des systèmes de
communications actuels.
Bien que les conteneurs existants de J2EE traitent également les événements asynchrones
(JMS), ils n'ont pas été conçus pour ça. Une SLEE, d'autre part, a été spécifiquement conçue
pour les systèmes de télécommunications à haute fréquence et qui sont complètement
asynchrones. Ainsi, une SLEE remplit les exigences des systèmes de communications bien
meilleurs que n'importe quel conteneur d'EJB.
-14-
La technologie JAIN
Pour répondre aux exigences des systèmes de communications et incorporer d'autres
conditions principales des serveurs d'applications conduits par les événements les fonctions
suivantes ont été identifiées en tant que motivateurs principaux pour la spécification de JAIN
SLEE :
•
Le modèle d'événement
•
Le modèle de composant
•
La capacité d’administration
•
La capacité de ressource
VI.1.1. Le modèle d’évènement :
L’acheminement d'événements entre les ressources de données et les composants de la
SLEE, y compris l’acheminement d'événements entre composants, est la fonction de base du
SLEE.
Le modèle d'événement de la SLEE est basé sur un modèle « publish/subscribe » (semblable
à JMS). Ce modèle découple les producteurs d'événements des sources d'événements par
l'intermédiaire d'un mécanisme d'adressage indirect qui conduit l'événement des sources aux
consommateurs, et désigné sous le nom du mécanisme d’acheminement d'événements de la
SLEE. Ce mécanisme décrit comment un événement émis par un producteur d'événement est
conduit et fourni grâce au routeur d’évènements à une ou plusieurs instances des composants
intéressées par cet évènement.
Plus précisément, Les consommateurs d'événement s’attachent à un ou plusieurs « Activity
Context » afin de spécifier l’ensemble d’événements dont ils ont besoin. Par ailleurs, les
producteurs d'événements publient des événements auprès des «Activity Context ». Dés lors, un
producteur d'événements ne se rend pas directement compte de ses consommateurs d'événement
et un consommateur d'événement ne se rend pas directement compte de ses producteurs
d'événement. Les «Activity Context » définis par la SLEE maintiennent les échanges entre les
producteurs d'événement ainsi que leurs consommateurs.
La figure ci-dessous illustre ce que on vient de citer.
-15-
La technologie JAIN
Figure 2.7 : Le modèle d’évènement de JAIN
Le modèle d'événement de SLEE a les avantages suivants :
•
Favorise un découplage du producteur d'événement du consommateur d'événement. Ceci
facilite la fixation des pannes, car une erreur au niveau du producteur d’évènement aura
moins de chance pour se propager jusqu’au consommateur d'événement et vice versa.
•
Permet au SLEE de savoir les rapports les consommateurs d'événement et leurs
producteurs. Ceci permet au SLEE de fournir des dispositifs à valeurs ajoutées
importants tels que le “garbage collection” des consommateurs d'événements qui ne
recevront plus des événements.
•
Améliore la robustesse car les producteurs d'événement ne doivent pas mettre en
application le code de distribution d'événement qui est conforme aux modèles ou aux
conventions documentées.
•
L'application a un modèle flexible de distribution d'événement qui reçoit seulement les
événements d'intérêt. Certaines applications peuvent exiger seulement la distribution
d'événements d'un type spécifique, alors que d'autres applications exigent la distribution
d'événements d’un type différent.
VI.1.2. Le modèle de composant :
Le modèle de composant est visé aux applications asynchrones. Ce modèle élimine des
références directes entre les producteurs d'événements (les ressources du réseau) et les
consommateurs d'événements (les composants d'applications).
-16-
La technologie JAIN
Un composant de SLEE s'appelle un module de service (SBB : Service Building Block).Il est
hébergé par le conteneur de la SLEE. Un SBB est conforme à certaines restrictions de
programmation. Le conteneur lui représente un environnement d'exécution et lui fournit
l'infrastructure de service suivante :
•
La gestion du cycle de vie de la ressource
•
La sécurité
•
La persistance
•
Les transactions
Un descripteur de déploiement permet une association entre l'infrastructure des services et les
SBBs hébergés par le conteneur au temps de déploiement.
Les composants de SLEE reçoivent des demandes sous forme d'événements qui représentent
typiquement une occurrence exigeant le traitement d'une application. Elle diffuse l'information
décrivant l'occurrence, telle que la source d'événement. Un composant actif dans le SLEE peut
employer des événements pour signaler, appeler, ou communiquer avec d'autres applications
fonctionnant dans la SLEE.
Le modèle de composant du SLEE modélise l'interface externe d'une application comme un
ensemble d'événements que l'application peut recevoir. Chaque type d'événement est manipulé
par sa propre méthode pour imposer une interface bien définie.
VI.1.3. La capacité d’administration :
Afin d'administrer et de contrôler les différents éléments d’un système, un administrateur a
besoin de manipuler les valeurs qui caractérisent la configuration de ce système.
Le SLEE définit des interfaces de gestion en utilisant MBean’s (Managed Beans)
conformément aux spécifications du JMX (Java Management Extentions). Un MBean est une
représentation externe d'un domaine fonctionnel et physique d'un système.
VI.1.4. La capacité de ressource :
Les applications développées dans le SLEE doivent communiquer avec des ressources du
réseau. Une ressource représente un système qui est externe à la SLEE (tel que des protocoles
stacks ou des bases de données). Ces ressources ne sont pas nécessairement développées en Java
ce qui implique qu’ils ne supportent pas le modèle évènementiel. Pour résoudre ce problème
d’interopérabilité, l'architecture JSLEE définit comment les applications hébergées par la SLEE
peuvent interagir avec ces ressources à travers les adaptateurs de ressources.
-17-
La technologie JAIN
VI.2. Les composantes de bases du JAIN SLEE :
L’API du SLEE défini une interface standard pour le développement d’applications de
télécommunications portables. Les spécifications de cet API ont été menées par David Ferry de
la société “ Open Cloud” et Swee Lim de la société “Sun Microsystems”. Le vote d'approbation
finale a accepté les spécifications du 17 février, 2004.
En plus des sociétés qui ont mené ces spécifications le groupe d'experts pour ce JSR ainsi
d’autres compagnies telles que Siemens AG, IBM, Motorola, et NTT Corporation.
JAIN SLEE intègre un modèle d'événement avec un composant de programmation tout en
incorporant aussi des interfaces d'administration par l'intermédiaire de JMX, un adaptateur de
ressources pour le réseau, des interfaces de profils génériques, un système de gestion de
persistance pour les états de redondance, des systèmes de contrôle d'accès concurrent comme les
minuteries, des systèmes d'alarmes, un système de suivi d'utilisation et des traces.
La figure ci-dessous présente l’architecture de JAIN SLEE et les relations entre ses différents
composants :
Figure 2.8 : Architecture de JAIN SLEE
VI.2.1. L’adaptateur de ressource :
Les adaptateurs de ressource communiquent avec les systèmes externes au SLEE, tels que, les
composants du réseaux, les protocoles stacks, les bases de données, etc. Selon l'architecture du
SLEE, un adaptateur de ressource est une implémentation 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 déclare tous les types d'événements qui peuvent être
produits ainsi que toutes les activités que l’adaptateur peut introduire. Quand un adaptateur de
ressources passe un événement au SLEE, il doit fournir son objet et son type et une activité qui
-18-
La technologie JAIN
l’encapsule (Voir figure). Les spécifications n'énoncent pas comment cette information est passée
au SLEE.
Figure 2.9 : Rôle de l’adaptateur de ressource
VI.2.2. Le routeur d’évènements :
Les spécifications de SLEE définissent comment un événement émis par un producteur
d'événement est conduit et fourni à un ou plusieurs composants qui lui sont intéressés. Pour ce
faire la SLEE est équipée d’un routeur logique d’évènements. Celui-ci reçoit des événements émis
de tous les producteurs d'événements et les achemine aux différentes instances correspondantes.
VI.2.3. L’évènement :
Les objets d'événements diffusent l'information entre les différentes entités du SLEE.
Seulement les SBB consomment et produisent des événements, alors que toutes les autres entités
telles que les adaptateurs de ressources, la SLEE elle-même peuvent seulement les produire.
Chaque événement est représenté par un objet d'événement (sous-classe de java.lang.Object) et
un type. Le type d'événement détermine comment le SLEE conduira l'événement, par exemple,
quels sont les objets SBB qui doivent recevoir l'événement. Un SBB reçoit les évènements du
contexte d’activité qui lui est attaché.
Le développeur doit définir une méthode abstraite pour l’exécution de chaque évènement que le
SBB en a besoin. Cette méthode est généralement exécutée par la SLEE. Dans le cas d’un
évènement initiateur la SLEE doit crée un objet SBB avant de lui acheminer l’évènement.
VI.2.4. L’activité et le contexte d’activité :
Les classes d’activités comprennent les deux entités logiques, activité et contexte d'activité, et
leurs représentations d'objet en Java, objet d'activité et objet d’interface de contexte d'activité
Une activité représente un ensemble d’événements. La représentation 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-
La technologie JAIN
représente un appel téléphonique.
Figure 2.10 : L’activité et le contexte d’activité
Un contexte d'activité représente l'activité fondamentale dans la SLEE et tient également les
attributs en commun que les entités SBB veulent partager. Les objets SBB peuvent accéder aux
contextes d'activité par l'objet interface de contexte d'activité.
Un SBB peut utiliser une interface de contexte d’activité générique comme il peut étendre
cette interface pour définir des attributs supplémentaires qu’il veut partager avec d’autres objets.
Les objets d'activités sont produits par des événements de réseau. Les adaptateurs de
ressources écoutent ces événements et créent les objets d’activités appropriées. Ces objets sont
placés dans le contexte d'activité du SLEE. Dès lors, le SLEE est maintenant responsable de la
livraison des événements produits aux objets du SBB. Vice versa, un objet du SBB peut accéder à
l'interface du contexte d'activité pour obtenir l'accès à l'objet d'activité courante.
VI.2.5. Les composants SBB (Service Building Block):
Le SBB est le composant le plus élémentaire dans la SLEE. Il est inspiré de l’EJB sur lesquels
se basent les systèmes d’entreprise « J2EE ».
Un composant SBB définit :
•
Les types d’événements qu’il peut recevoir et traiter.
•
Des méthodes pour traiter chaque type d’événement.
•
Les relations ‘’Child ‘’ qui le rattache à des composantes SBB ‘’Child’’.
•
Les données qu’il désire partager avec les autres composants par l’intermédiaire d’un
ensemble d’attributs d’activity context.
Le développeur d’un SBB implémente ce qu’on appelle un SBB Abstract Class de l’interface
SBB déjà définie dans les spécifications de la SLEE.
VI.2.6. Les composants de gestion et de contrôle des services :
Pour contrôler efficacement les services, les échanges d'événement et les ressources, il est
-20-
La technologie JAIN
nécessaire de surveiller et mesurer l'exécution, l'utilisation et la disponibilité de ces attributs, tout
en estimant leurs situations futures. Les spécifications de la SLEE définissent un certain nombre
de composantes qui peuvent être employées pour répondre à ces exigences.
•
Le temporisateur : cette fonction procure à des applications la possibilité d'effectuer des
actions périodiques, ou lancer des actions et des contrôles à un temps postérieur pour
s’assurer qu’ils ont été bien accomplies. Le temporisateur contrôle un certain nombre de
temporisateurs, dont chacun est indépendant des autres.
•
Le service d'alarme : des alarmes sont employées pour informer des applications de
gestion qu'un changement inattendu d'état s'est produit dans un élément de réseau. Les
composants de SBB emploient le service d'alarme pour produire des avis d'alarme
destinés à la consommation par des clients de gestion externe au SLEE. L'envoi des
alarmes aux applications de gestion est automatiquement déclenché quand un état
particulier devient vrai. Ces clients de gestion peuvent être une console de gestion de
réseau ou un moteur de politique de gestion.
•
Service de mesure des statistiques : les statistiques sont des caractéristiques de
l’application ou du réseau qui sont périodiquement demandées par les applications de
gestion. Un client de gestion peut employer les paramètres de ce service pour surveiller le
taux d'utilisation de chaque application.
•
Composant de gestion de profil : Ce service permet aux applications de rechercher des
profils stockés dans des tables de profil. Les profils contiennent des données stockées
dans la SLEE.
VII. JAIN et OSA/Parlay :
A peu près au même moment où la communauté JAIN se mettait en place et débutait ses
travaux, British Telecom (BT), Microsoft, Nortel, Siemens et Ulticom formaient le Parlay Group,
qui a donné le jour à une panoplie d’APIs orientée objet et indépendante du langage
d’exploitation, afin de faciliter la création de services dans les réseaux publics de tous types. Les
APIs d’applications définies par le groupe Parlay doivent permettre un accès ouvert mais sécurisé
à un ensemble de fonctionnalités aujourd’hui rendues par les différents réseaux privés ou publics.
Il est attendu de la publication de ces APIs qu’elles soient utilisées par une plus grande
communauté de développeurs afin de dynamiser le développement de nouveaux services de
télécommunications, nous l’avons déjà dit.
Mais pour ce faire, les spécifications que définit Parlay ont besoin d’un modèle architectural
standardisé permettant aussi de tenir en compte des abonnés mobiles, et le modèle OSA
-21-
La technologie JAIN
développé conjointement par le 3GPP s’est avéré idéal pour une mise en commun des efforts du
Parlay Group avec le groupe de travail du 3GPP, qui ont dès lors collaboré à l’édification d’un
standard commun OSA/Parlay.
OSA/Parlay n’offre pas seulement la possibilité aux opérateurs d’ouvrir leurs réseaux à des
parties tierces, mais s’adresse également aux opérateurs câblés comme aux opérateurs sans fils, en
proposant sans différenciation aucune une nouvelle méthode peu coûteuse, rapide et efficace
pour créer leurs propres services en fonction de la demande qu’ils perçoivent.
Au premier abord et avec raison, le lecteur pourra penser que Parlay et JAIN sont en
compétition, étant donné les nombreuses similarités dans les buts qu’ils se sont fixés. Mais s’ils
ont été en compétition à leurs débuts, cela n’a pas duré, les deux parties s’étant rapidement
rendues comptes que la collaboration apporterait plus à chacun que la compétition.
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 indépendant du langage
utilisé.
• Parlay propose des APIs de services uniquement: contrairement à JAIN, Parlay ne dispose pas
d’APIs pour communiquer directement avec les protocoles réseaux, car ce n’est 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 s’exécutant en dehors de l’espace de confiance
(trusted space) du fournisseur de services, via différents mécanismes de sécurités intégrés à
Parlay.
Conclusion :
La technologie JAIN a un potentiel immense. Elle bouleverse complètement le marché des
télécommunications en permettant un accès direct au développement de services par tous les
acteurs de télécommunications dans le monde indépendamment des systèmes.
Avec le principe adopté par la communauté JAIN qui supprime les différences entre réseaux
et qui apporte la sécurité, il n’existe plus que deux limites à la création de services. La première est
physique, c’est la taille du réseau mondial, la seconde est l’imagination.
A ce stade, la première partie est achevée. On va par la suite passer à la partie la plus
valorisante du rapport : l’étape d’analyse, de conception et de réalisation du projet.
-22-
Partie II
Partie II :
Analyse, Conception et Réalisation
-23-
Analyse des Besoins
Chapitre 3
Analyse des besoins
Introduction :
Comme tout processus de réalisation d’un projet, on va commencer par la première phase qui
est l’analyse. En effet, elle consiste à présenter, dans un premier lieu, le cahier des charges,
ensuite l’identification des besoins, pour en tirer à la fin les diagrammes correspondants tels que
les diagrammes des cas d’utilisation et le diagramme d’activité.
I. Identification des besoins :
Au cours de ce projet, on se propose de mettre en place une plate-forme de messagerie
instantanée utilisant JAIN. Parmi les traitements possibles cette plate-forme doit effectuer des
actions spécifiques lorsqu’un appel est initié ou bien mettre à jour les informations du centre
d’appel.
Notre travail consiste à développer un prototype de service de messagerie instantanée
utilisant JAIN. Pour ce faire, on a déjà signalé que notre étude sera basée essentiellement sur la
dernière version des spécifications JAIN SLEE 1.0. En outre, on a décidé que notre prototype
traitera du SIP vue que c’est un protocole d’avenir qui se caractérise par sa rapidité et sa
simplicité.
Par rapport à ça, on se retrouve face aux besoins suivants :
(1). Il faut tout d’abord développer un adaptateur de ressource SIP qui permet de passer
du monde protocolaire à base des messages SIP au monde événementiel qui caractérise la JSLEE.
Ceci permet au développeur de service de bénéficier par la suite d’une abstraction de la couche de
signalisation SIP. Seulement, il faut comme même tenir compte des types d’événements qui vont
encapsuler les messages SIP.
(2). Par référence à l’architecture SIP, on doit développer les services suivants :
™ Un service Proxy qui va s’occuper 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 présence et de messagerie instantanée pour gérer les informations
en présence des différents utilisateurs déjà inscrits dans le Registrar et pour
acheminer leurs messages.
-24-
Analyse des Besoins
On doit rappeler que ces services vont être hébergés par la JSLEE. On doit donc les développer
selon le modèle événementiel en tenant compte du type d’événement qui vont être générés par
l’adaptateur de ressource.
(3). On se propose de développer un client de messagerie instantanée pour valider les
services. Ce client doit permettre à un utilisateur donné de s’inscrire auprès du Registrar. Comme
s’il aura une adresse logique qu’il peut la communiquer à tout le monde. En plus, ce client permet
essentiellement d’ouvrir une session de chatting avec un autre utilisateur qui doit être déjà inscrit.
II. Modèles des besoins :
D’après la partie précédente, on peut distinguer trois centres d’intérêts dans ce projet. Chacun
d’entre eux demande une analyse détaillée à part. Dés lors, on a décidé d’étudier au fur et à
mesure chaque composant tout seul.
II.1. Acteurs :
Un acteur est une catégorie d’utilisateurs, il représente un rôle joué par une personne, un
logiciel, un matériel, un automate qui exploite les données du système et qui interagit avec.
II.2. Les diagrammes de cas d’utilisation :
Un cas d’utilisation modélise un service rendu par le système. Il exprime les interactions
acteurs/systèmes et apporte une valeur ajoutée à l’acteur concerné, un cas d’utilisation est donc
une abstraction d’une partie du comportement du système.
II.2.1. L’adaptateur de ressource :
Dans ce cas il y a deux types d’acteurs : Les ressources du réseau et les SBBs. Les
composantes du réseau envoient à l’adaptateur de ressource des requêtes encapsulées dans des
messages SIP. Alors que les SBBs envoient des requêtes sous forme d’événements.
Mapping entre message
SIP et Evénement
inclut
Création d'une AC
Network Resource
SBBs
Figure 3.1 : Diagramme de cas d’utilisation de SIPRA
II.2.2. Les services :
Dans cette partie, les différents cas d’utilisation identifiés sont :
•
L’acheminement des messages de signalisation.
•
Association de l’utilisateur à un identifiant unique.
•
Transfert des IM.
-25-
Analyse des Besoins
•
Notification des changements des états des autres utilisateurs.
Ainsi le diagramme de cas d’utilisation déduit est le suivant :
Acheminier les messages de
signalisation
Association à un identifiant unique
User
Transfert des IM
inclut
Notification des changements des
états des autres utilisateurs
Collecte des informations de
présence
Figure 3.2 : Diagramme de cas d’utilisation des services
II.2.3. Le client de messagerie instantanée :
Le client de messagerie instantanée permet à son utilisateur de s’enregistrer auprès d’un
service Registrar. Puis Il demander d’initier une session de chatting avec un autre utilisateur, luimême doit être déjà présent.
Ainsi le diagramme de cas d’utilisation déduit est le suivant :
User
Enregistrement
inclut
Ouvrir une session
de IM
inclut
Authentification
Ajouter un contact
Se déconnecter
Figure 3.3 : Diagramme de cas d’utilisation de SUP Messenger
II.3. Modèle de l’interface homme machine de SUP Messenger :
Ce modèle est applicable seulement pour le client de messagerie instantanée « SUP
Messenger ». En fait, tous les composants qui restent vont être déployés à travers des
commandes dos.
-26-
Analyse des Besoins
Interface d’authentification
Interface d’ajout de contact
Interface d’envoi et de
réception des IM
Figure 3.4 : Modèle de l’interface homme machine du SUP Messenger
II.4. Les diagrammes d’activités :
Les diagrammes d'activité sont utilisés pour montrer la façon dont les traitements sont
créés, comment ils démarrent, les nombreux chemins décisionnels qu'ils peuvent emprunter, ainsi
que les opérations effectuées en parallèle. Un diagramme d'activité ne modélise pas en général
l’exact comportement interne d'un programme (comme le fait le diagramme de séquences) mais
montre plutôt les traitements et les étapes généraux à un haut niveau d'abstraction.
II.4.1. L’adaptateur de ressource :
Ecouter les messages
SIP
Recevoir un message
Scruter les champs du
message
SI
la méthode est
connue
Ignorer le message
Non
Oui
Créer une activité
Figure 3.5 : Diagramme d’activité de SIPRA
-27-
Analyse des Besoins
II.4.2. Les services :
Recevoir une demande d’enregistrement
Enregistrer l’utilisateur et lui associer
un identifiant
Emettre un acquittement
Recevoir une demande d’initiation
d’une session d’IM
Vérifier la
présence du
correspondant
Non
Oui
Mettre à jour les informations
de présence
Envoyer une notification
à la source et ouvrir une session
d’IM
Acheminer les messages de la
conversation
Figure 3.6 : Diagramme d’activité des services
-28-
Analyse des Besoins
II.4.3. Le client de messagerie instantanée :
Figure 3.7 : Diagramme d’activité de SUP Messenger
Conclusion :
A ce stade, l’analyse des besoins est achevée, et comme les différents cas d’utilisation ainsi
que les activités sont extraites, la phase de conception dispose maintenant de la matière d’œuvre
pour mener sa mission.
-29-
Conception
Chapitre 4
Conception
Introduction :
La conception constitue la deuxième phase dans le processus de réalisation de notre projet.
Elle permet de représenter les notions saillantes des différentes parties, et ainsi de formaliser les
connaissances préliminaires de tous les composants, notamment par l’exploitation des
diagrammes de classes.
I. Conception générale :
L’analyse des besoins, dans la section précédente, trace les grandes lignes de l’architecture de
chaque composant du projet. En effet, six modules principaux sont envisagés et qui interagissent
derrière l’interface Homme Machine du client de messagerie SUP Messenger.
Les deux premiers modules représentent le cœur de SUP Messenger. En fait, on distingue
un module qui permet de gérer les sessions de chatting appelé ‘’Messenger’’. Alors que le
deuxième module a pour mission de collecter les informations de présence des différents
utilisateurs et de notifier le client en cas de changements de leurs états.
Les quatre modules restants doivent être déployés du côté du serveur d’application une fois il
est actif.
En premier lieu, chaque message envoyé par une ressource du réseau à la SLEE doit être
adapté à l’environnement d’exécution du service en question. Autrement dit, il faut prévoir un
module qui assure le passage du monde protocolaire à base des messages SIP au monde
événementiel. Pour ce faire, on a déjà prévu un adaptateur de ressource qu’on a appelé SIPRA.
Puis, les événements qui vont être générés par le SIPRA arrivent au niveau du routeur
d’événements de la SLEE. Ce dernier va les acheminer au ‘’SBB root’’ du service Proxy qui
décidera selon leurs types vers quel service faut il encore les envoyer.
Dans notre cas, le client doit tout d’abord demander une connexion auprès du serveur de
messagerie instantanée. 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 d’être
joignable le temps qu’il est connecté. Une fois que le client est identifié le Registrar donne la main
au service de présence pour achever son enregistrement.
En ce moment, le client peut initier une session de chatting. Il va donc se renseigner sur l’état
de son correspondant (On line ou Off line) avant de lui envoyer un message.
-30-
Conception
En conclusion, tous les modules qui constituent le noyau de l’application, sont présentés dans
la figure ci-dessous :
IHM
Registrar
Se connecter
Presence
Envoyer un
IM
SIPRA
Afficher l’état
Proxy
Messenger
Presence
Utilisateur
Figure 4.1 : Architecture générale du projet
II. Conception détaillée :
Selon la méthodologie UML suivie dans ce projet, la conception détaillée se base
essentiellement sur la présentation statique par les diagrammes de classe et dynamique par le
diagramme de séquence.
II.1. Représentation statique :
Un diagramme de classes représente la structure du système sous la forme de classes et de
relations entre ces classes. Une classe est une description abstraite d’un ensemble d’objets ayant :
- des propriétés similaires,
- un comportement commun,
- des relations communes avec d’autres objets,
- des sémantiques communes.
Les importantes relations pouvant exister entre les classes sont l’héritage, la composition et
l’association.
On peut regrouper ces classes en paquetages.
Les paquetages sont des éléments d'organisation des modèles. Il permettent de :
•
Regrouper des éléments de modélisation, selon des critères purement logiques.
•
d'encapsuler des éléments de modélisation (ils possèdent une interface).
•
structurer un système en catégories (vue logique) et sous-systèmes (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 indépendantes. Nous allons donc détailler chacune à part.
-31-
Conception
II.1.1. Les diagrammes de paquetages :
II.1.1.1. Diagramme de paquetages de SUP Messenger :
On a déjà signalé dans la partie précédente que SUP Messenger se compose de deux modules
qu’on a appelé respectivement Messenger et Presence. Chacun d’entre eux comporte un
ensemble de classes résumées dans le tableau ci-dessous :
Paquetages
Messenger
Classes
Spécifications
AlertInstantMessaging
Génère les messages d’erreur
AuthenticationProcess
Gère la procédure d’authentification de l’utilisateur
ChatFrame
Représente la boîte de dialogue de l’utilisateur
ChatSession
Gère une session de chatting
ChatSessionManager
Gère plusieurs sessions de chatting
InstantMessagingFrame
Représente la première fenêtre de démarrage
ListenerInstantMessaging Détecter la réception d’un message
XMLParser
Gère les différentes infos du client enregistré dans un
fichier XML
Presence
IMAckProcessing
Permet de traiter un acquittement
IMByeProcessing
Permet de traiter la demande fermeture d’une session
IMMessageProcessing
Permet de traiter la demande d’envoi d’un message
IMNotifyProcessing
Permet de traiter une notification
IMRegisterProcessing
Permet de traiter la demande d’enregistrement
IMSubscribeProcessing
Permet de traiter la demande d’inscription auprès du
serveur de présence
IMUserAgent
C’est le cœur de l’application.
PresenceManager
Gère les informations de présence
Presentity
Fournit les informations de présence
Subscriber
Demande de notification des changements des
informations de présence
Tableau 4.1: Définition des paquetages et des classes de SUP Messenger
uses
sup.sip.Presence
Sup.Sip.Messenger
uses
Figure 4.2 : Diagramme de paquetage de SUP Messenger
-32-
Conception
II.1.1.2. Diagramme de paquetages de SIPRA :
L’adaptateur de ressource est composé d’un seul paquetage appelé SIPRA. Il comporte les
classes suivantes :
Classes
Spécifications
ActivityContextInterfaceFactoryImp Implémente l’interface ActivityContextInterfaceFactory
SipRaActivityHandle
Acheminer les événements de l’activité à une interface
unique AC
SIPRaFactory
SIPRaProvider
Créer les transactions clients et serveurs et envoyer les
requêtes et les réponses
SipResourceAdaptor
Assure le mapping SIP Message et événement SIP.
SipRaStack
Gère les Listing Point côté réseau ainsi que le
SipRaProvider
Interfaces
Spécifications
ResourceAdaptorSbbInterface
Permet aux composantes SBB d’interagir avec le SIPRA
ActivityContextInterfaceFactory
Fournit l’interface Java du SIPRA avec l’Activité
Tableau 4.2: Définition des classes de SIPRA
II.1.1.3. Diagramme de paquetages des services :
Paquetages
Proxy
Classes
Spécifications
ProxySbb
Définit les différents types d’événements
SIP supportés par ce service ainsi que
leurs traitements
SipProxySbb
Gère les transactions client et serveur
ProxySbbActivityContextInterface
Fournit
l’interface
Java
de
l’objet
ProxySbb
Registrar
LocationService
Gère les informations de localisation du
client
LocationServiceException
Traite
les
exceptions
possibles
au
moment d’exécution
Registrar
Définit le processus d’enregistrement du
client
RegistrarSbb
Définit les différents types d’événements
SIP supportés par ce service ainsi que
leurs traitements
-33-
Conception
RegistrarActivityContextInterface
Fournit
l’interface
Java
de
l’objet
RegistrarSbb
Presence
PresenceSbb
Définit les différents types d’événements
SIP supportés par ce service ainsi que
leurs traitements
PresentityManager
Gère les informations de présence des
clients
Subscriber
Envoi des demandes de notification pour
tout changement d’état des informations
de présence
Notifier
Gère les notifications
PresenceActivityContextInterface
Fournit
l’interface
Java
PresenceSbb
Tableau 4.3: Définition des classes des différents paquetages des services
uses
Proxy
uses
Registrar
Presence
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-
de
l’objet
-35-
ChatSessionManager
1..1
n
1..1
XMLParser
1..1
1..1
1..1
AlertInstantMessaging
n
1..1
ChatFrame
InstantMessagingFrame
Subscriber
PresenceManager
Presentity
IMACKProcessing
SUP.SIP.Messenger
n
AuthenticationProcess
1..1
1..1
IMUserAgent
IMByeProcessing
Figure 4.4 : Diagramme de classes de SUP Messenger
ListenerInstantMessaging
IMSubscribeProcessing
IMRegisterProcessing
IMNotifyProcessing
IMMessageProcessing
SUP.SIP.Presence
n
ChatSession
Conception
Conception
II.1.2.2. Diagramme de classes de SIPRA :
<<Interface>>
ResourceAdaptorSbbInterface
SipRaStack
SIPRaFactory
SIPRaProvider
<<Interface>>
ActivityContextInterfaceFactory
SipResourceAdaptor
ActivityContextInterfaceFactoryImpl
Figure 4.5 : Diagramme de classes de SIPRA
II.1.2.3. Diagramme de classes des services :
ProxySBB
1..1
1..1
<<Interface>>
ProxySbbActivityContextInterface
SIPProxySBB
Figure 4.6 : Diagramme de classes du Proxy
-36-
SipRAActivityHandle
Conception
RegistrarActivityContextInterface
1..1
1..1
LocationService
RegistrarSBB
0..1
0..1 LocationServiceException
0..1
0..1
Registrar
Figure 4.7 : Diagramme de classes du Registrar
PresenceSBB
1..1
1..1
1..1
1..n
Subscriber
PresentityManager
n
<<Interface>>
PresenceActivityContextInterface
n
n
n
Notifier
Figure 4.8 : Diagramme de classes du Presence service
II.2. Représentation dynamique :
-37-
Conception
SIPRA
User Agent1
Register SIP Message
Proxy
Registrar
Presence
User Agent2
Mapping
to Register event
Register
Register
200 Ok
200 Ok
Ack SIP Message
Subscribe SIP Message
Subscribe
Subscribe
200 Ok
200 Ok
Ack SIP Message
Notify
Notify
Notify SIP Message
Ack SIP Message
200 Ok
200 Ok
Message SIP Message
Message1
Message2
200 Ok
200 Ok
Message SIP Message
Ack SIP Message
Ack SIP Message
Figure 4.9 : Diagramme de séquence de tout le système
Conclusion
Ainsi la conception du projet est achevée et les différents modules architecturaux et fonctionnels
sont bien définis pour être implémentés. Dès lors, la phase suivante sera l’implémentation de ces
différents modules.
-38-
Réalisation et présentation
Chapitre 5
Réalisation et présentation
Introduction :
L’implémentation constitue la dernière étape dans le processus de réalisation de ce projet.
Pour cela, on présentera par la suite un scénario complet qui va parcourir toutes les étapes de la
mise en place du serveur ainsi que le déploiement des différents composants.
Mais tout d’abord, on va présenter notre atelier de travail.
I. Atelier de travail :
Notre atelier se compose d’un outil d’analyse et de conception « Rational Rose », un
environnement de développement orienté objet « Java », un plugin pour le développement de
service conforme aux spécifications de JAIN SLEE 1.0 et une plate-forme de VOIP libre certifié
pour JSLEE 1.0.
I.1. Rational Rose :
Rational Rose est conçue pour fournir un ensemble complet d’outils de modélisation
graphique, d’analyse et de conception dans le développement de logiciels basés sur les modèles
UML (Unified Modeling Language), COM (Component Object Modeling), OMT (Object Modeling
Technique) et Booch ("93method for visual modeling").
Rational Rose utilise la modélisation graphique pour raisonner sur des problèmes complexes
en s’appuyant sur des modèles organisés. Un modèle facilite la compréhension du problème et
permet de décrire les caractéristiques essentielles d’un système.
On a profité des avantages majeurs de cet outil afin de bien modéliser notre projet qui est
basé essentiellement sur le modèle orienté objet.
I.2. Java :
Le choix des bons outils de travail est une tâche critique sur laquelle repose le bon
déroulement de l'étape de conception. Pour la réalisation de ce projet on était obligé d’utiliser la
plate-forme de développement Java vue que JAIN n’est qu’une extension pour celle-ci.
En outre, Ce choix est justifié par le fait que ce langage :
•
utilise le concept orienté objet et s'apprête parfaitement à notre cas.
•
permet la création d'interfaces graphiques sophistiquées (menus déroulants, boutons,
cases à cocher,...) essentielles pour la conception de l'interface graphique de
SUP_Messenger.
•
inclue le concept du modèle évènementiel. .
-39-
Réalisation et présentation
•
présente le grand avantage d'être portable sur plusieurs plates-formes (Windows,
Linux,...).
Tous ces avantages se conforment aux spécifications de JAIN qu’on a déjà présentées dans la
première partie de ce rapport.
I.3. Le plugin EclipSLEE :
EclipSLEE est un environnement graphique de création de service pour le développement
rapide des services à valeur ajoutée 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 basée sur un modèle événementiel de haute scalabilité
et un modèle de composant très robuste. C’est la première et la seule plate-forme de VOIP libre
qui a été certifiée pour SLEE 1.0.
Mobicents complète J2EE et assure la convergence voix/vidéo/donné dans les réseaux de
nouvelle génération. Elle va nous servir pour valider notre application.
II. Scénario :
Afin de mettre en évidence notre travail, on se propose, dans ce paragraphe, de présenter un
scénario qui va présenter les différentes phases de déploiement de chaque composant.
Etape 1 : Démarrer le serveur
Ceci se fait par la commande suivante : run –c all –b 127.0.0.1
Figure 5.1 : Démarrage du serveur
Etape 2 : Déployer l’adaptateur de ressource :
Après avoir démarrer le serveur, on doit déployer le SIPRA par la commande : ant deploySIPRA
-40-
Réalisation et présentation
Figure 5.2 : Déploiement du SIPRA
Etape 3 : Déployer les services :
Une fois le SIPRA est bien installé on doit déployer les services grâce à la commande :
ant deplyservice
Figure 5.3 : Déploiement des services
Etape 4 : Démarrer le premier client :
Figure 5.4 : Interface de démarrage du premier client
-41-
Réalisation et présentation
Etape 5 : Se connecter au serveur :
Figure 5.5 : Etat du client après la connexion
Etape 6 : Faire de même pour l’autre client :
Figure 5.6 : Interface de démarrage du deuxième client
Etape 7: Initier une session de chatting de l’un à l’autre.
Figure 5.7 : Initiation d’une session de chatting
Etape 8: Spécifier l’adresse du correspondant :
Figure 5.8 : Spécification de l’adresse du correspondant
-42-
Réalisation et présentation
Etape 9 : Commencer la discussion :
.
Figure 5.9 : Aymen commence à envoyer le premier message
Figure 5.10 : Mohamed reçoit le message de Aymen
-43-
Réalisation et présentation
Conclusion :
Ce chapitre a été consacré à l’implémentation des différents composants du projet. En outre,
On a suivi les différentes étapes nécessaires pour faire fonctionner toute la chaîne SIP.
En fin, il faut avouer que ce travail ne représente qu’un cas d’utilisation de la SLEE. En effet,
cette nouvelle technologie présente un domaine très vaste pour le déploiement des services de
future génération.
-44-
Conclusion Générale
Conclusion Générale
L’étude détaillée des notions de bases permettant d’aborder ce sujet a constitué la première
étape à satisfaire. Aussi, a –t-on établi dans une seconde partie le modèle architectural
d’implémentation de ce projet. L’analyse, la conception et la réalisation ont été les axes de travail
adoptés lors de la dernière partie.
Au terme de ce travail, on est de plus en plus conscient de la richesse du sujet et de ses
perspectives d’extension. D’ailleurs, on n’a pas développé un service qui tient compte de la
transmission de la voix tel que VOICE CHAT ou bien le cas des systèmes IVR. Dès lors, On
projette de développer d’avantage cette nouvelle problématique dans nos futurs travaux.
-45-
Conclusion Générale
Annexe A
Le Protocoles SIP
I. Histoire du protocole SIP :
Le protocole SIP tel qu'il est connu est la réunion de deux protocoles s'inspirant des protocoles
de gestion de vidéoconférence. D'un côté SIPv1, un mécanisme pour mettre en place des
communications point à point ou multicast. Ce protocole reposait sur des échanges de message
en mode texte. Son concept prédominant était l'enregistrement auprès de serveurs de conférence.
De l'autre côté, le protocole SCIP (Simple Conference Invitation Protocol) avait le même but
mais se basait sur le protocole HTTP (Hyper Text Transfert Protocol) reprenant notamment les
codes de réponse. L'identification des utilisateurs se faisait grâce à des adresses e-mails dans le but
de leur fournir un identifiant unique quelque soit le mode de communication choisi. Le RFC2543
premièrement établi a été rendu obsolète par le RFC3261 publié en Juin 2002.
II. Architecture de SIP :
Les éléments de base autour de SIP sont peu nombreux. L'entité avec laquelle l'utilisateur
interagit est appelée le client. Il peut être soit matériel soit logiciel. Un client matériel est appelé
un hard phone, il ressemble à un téléphone classique mais embarque une pile SIP. Un client
logiciel est un soft phone, il émule sur un ordinateur les fonctions d'un téléphone. Les autres
éléments 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 décrit à la figure A.1.
Figure A.1. Principe de l'enregistrement
-46-
Conclusion Générale
Serveur Location : Cet équipement est une table de correspondance entre une adresse
symbolique et une adresse physique. Un utilisateur s'inscrit auprès du Registrar en lui spécifiant
une adresse physique. C'est cette adresse physique qui va être enregistrée 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 reçoit des requêtes. 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 concernés 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 gèrent des états ou non. Sans gestion des états, le serveur traite chaque
message arrivant comme nouveau, il est indépendant du précèdent et aucune trace des messages
-47-
Conclusion Générale
n'est gardée. Dans ce cas, les réponses ne peuvent être associées aux requêtes. L'autre solution,
peut-être plus intéressante en termes de programmation, est beaucoup plus lourde puisqu'on ne
considère plus chaque message indépendamment 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
problème avec cette alternative est que la gestion des états consomme beaucoup de ressources :
mémoire notamment.
Elle est donc difficilement applicable dans les installations de très grande envergure comme les
opérateurs.
III. Messages SIP :
Le protocole SIP repose sur le même modèle de transactions que HTTP à base de
requêtes/réponses. Ces transactions consistent en un échange de messages, dont vous pouvez
voir un exemple à la figure A.4 qui sont constitués de différents en-têtes spécifiant l'appelant,
l'appelée, le sujet de l'appel et la route empruntée pour la délivrance de ce message. Chaque
transaction est constituée d'une requête qui invoque une méthode particulière sur le serveur et
d'au moins une réponse. Il existe six méthodes dans le noyau SIP qui sont décrites par la figure
A.5.
REGISTER sip:borabora.enseirb.fr SIP/2.0
Via: SIP/2.0/UDP 147.210.177.88:5060;rport;branch=z9hG4bK16C8CB9433A5
From: Laurent BURGy <sip:[email protected]>;tag=3341381679
To: Laurent BURGy <sip:[email protected]>
Contact: "Laurent BURGy" <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 44319 REGISTER
Expires: 1800
Max-Forwards: 70
User-Agent: X-Lite release 1103a
Content-Length: 0
Figure A.4.Exemple de message SIP
Figure A.5.Les six méthodes du noyau SIP
-48-
Conclusion Générale
Les réponses reprennent les codes définis dans la norme HTTP. Les codes sont constitués de
trois chapitres dont le premier caractérise la classe de réponse. Les réponses 1XX sont des
réponses provisoires ou informationnelles. Les réponses 2xx, 4XX, 5XX et 6XX sont des
réponses finales. La classe 2xx indique un succès. Les classes 4xx, 5xx, 6xx indiquent des erreurs
soit du client, soit du serveur ou un échec global. La classe 3xx est un peu à part puisqu'elle
indique une redirection temporaire ou définitive.
Le protocole SIP peut également être étendu, ce qui consiste à ajouter des en-têtes ou des codes
de réponse. Un exemple d'extension est SIMPLE. SIMPLE apporte le support de la messagerie
instantanée à SIP. Cette extension est notamment utilisée dans Windows Messenger. Elle ajoute
principalement une méthode pour s'enregistrer auprès d'un serveur à des événements particuliers.
Ainsi, l'utilisateur peut être notifié de la connexion d'un de ses contacts. Le corps des messages
est transporté grâce à une nouvelle méthode MESSAGE.
IV. Comportements de clients et serveurs SIP :
Le protocole SIP a été défini pour utiliser à la fois les protocoles de transport TCP et UDP.
De plus il fournit son propre mécanisme pour fiabiliser les sessions.
Fiabilisation des requêtes :
Les serveurs reçoivent une ou plusieurs copies des requêtes et retransmettent la réponse
appropriée. Après avoir reçu une requête CANCEL d’un client, un PS renvoie une requête
CANCEL sur toutes les branches n'ayant pas encore reçu de réponse finale.
Quand un UAS reçoit une requête, il compare le CALL-ID de cette requête à ceux des appels
en cours :
· Si le CALL-ID correspond à l’un d’eux, il compare alors le tag de l’URL TO de la requête
avec celui de l’appel en cours et rejette la requête s'ils ne correspondent pas. L’UAS compare
également le tag de l’URL FROM de la requête avec ceux des appels existant. S'il correspond
à l’un d’enx, les Cseq sont alors comparés. Si le Cseq de la requête est inférieur ou égal à celui
de l’appel courant, la requête est une retransmission, sinon, c’est une nouvelle requête. Dans
ce cas, si le champ d’en-tête de la nouvelle requête ne correspond à aucun de ceux des appels
existants, un nouvel appel est créé.
· Si le CALL-ID ne correspond à aucun d’eux, un nouvel appel est créé.
Fiabilisation des réponses :
Avant d’envoyer une réponse finale, un serveur doit constamment envoyer des réponses
provisoires. En effet, si un PS, RS, UAS ou RG ne peut pas répondre à une requête dans les
200 ms, il doit renvoyer une réponse provisoire (code1xx) dès que possible. Les réponses
sont associées aux requêtes grâce aux en-têtes TO, FROM, CALL-ID, Cseq et le premier Via
-49-
Conclusion Générale
d'en-tête. Elles doivent donner fin aux retransmissions des requêtes même si ces dernières
possèdent un en-tête Via leur demandant d'acheminer les réponses jusqu'au client final.
Il arrive qu’un PS reçoive une réponse ne le concernant pas (le PS n’a pas enregistré de
requête y correspondant). Si le champ d’en-tête Via indique que le prochain serveur auquel
sera transmis la réponse utilise TCP, alors le PS contacté ouvre une connexion TCP à cette
adresse. Ainsi, les PS doivent se préparer à recevoir des réponses aux entrées où sont
ouvertes des connexions TCP passives, même lorsque beaucoup de réponses arrivent aux
entrées où sont ouvertes des connexions TCP actives. Notons qu’une connexion TCP est
dite active lorsqu’elle a été initialisée par un PS et passive lorsqu’elle est acceptée par un PS
mais ouverte par une autre entité.
Les réponses de code 100 ne doivent pas être retransmises alors que les autres réponses de
code 1xx peuvent l’être après que le serveur a retransmis les réponses en cours. Les réponses
de code 2xx sont retransmises en accord avec le champ d’en-tête Via et une fois qu’un PS a
reçu une telle réponse, il ne doit pas retransmettre de réponse d’autres codes (1xx et 3xx à
6xx). Les réponses de code 3xx à 6xx sont retransmises par chaque PS jusqu’à ce que la
prochain PS traversé jusqu'au client envoie un acquittement ACK ou un message
d’annulation CANCEL.
Un PS doit conserver l’état d’une transaction pendant au moins 32 secondes après réception
de la première réponse définitive autre que la réponse OK (code 200) afin de pouvoir
retransmettre cette réponse.
Pour transporter des messages SIP, l’on a vu que les protocoles TCP et UDP (unicast et
multicast) étaient utilisés. Les protocoles de transport ont besoin des adresses source et
destination afin d’établir des connexions. Dans une même connexion, plusieurs sessions
SIP peuvent être ouvertes.
Cas de sessions unicast transportées par UDP :
Les réponses sont retournées à l’adresse listée dans le champ d’en-tête Via et non à l’adresse
source de la requête directement.
Cas de sessions multicast transportées par UDP :
Un client recevant une requête en multicast ne doit pas vérifier si l’identificateur de machine,
contenu dans la requête URI, correspond avec son propre identificateur de machine mais doit
renvoyer sa réponse en multicast aussitôt. Une telle réponse conserve alors le même temps de
vie (ttl) que la requête, contenu dans le champ d’en-tête Via de cette dernière. Pour éviter
toute inondation de réponses, un serveur ne doit pas envoyer de requête en multicast avec
un code d’état autre que 2xx ou 6xx. De plus, le serveur retardera sa réponse d’une durée
-50-
Conclusion Générale
aléatoire et uniformément distribuée entre 0 et 1 seconde. Enfin, il ne doit pas non plus
répondre à des requêtes CANCEL.
Cas de sessions transportées par TCP :
Une simple connexion TCP peut transporter plusieurs transactions SIP. Une transaction
contient aucune ou plusieurs réponses provisoires, suivies de une ou plusieurs réponses
définitives. Le client maintient la connexion ouverte au moins jusqu’à ce que la première
réponse définitive lui soit retournée. Si la connexion est fermée avant, elle sera traitée comme
une requête CANCEL par le serveur. De même, le serveur ne devrait pas fermer une
connexion TCP avant qu’il n’ait envoyé sa réponse finale, mais peut le faire s’il le souhaite.
Cependant, c’est le client qui est responsable de la fermeture de la connexion.
V. SIP face à ses concurrents :
V.1.
H.323 :
La norme H323 est le principal concurrent de SIP pour la transmission de sons, données et vidéo
en temps réel sur les réseaux IP. Normalisé depuis 1996, elle fait partie de la série H.32x qui traite
de la vidéoconférence au travers des différents réseaux et concerne les réseaux LAN et Internet.
Elle a été développée par l’IUT pour des réseaux ne garantissant pas une qualité de service, tandis
que SIP est né de l’IETF. Le magazine 01Réseaux de décembre 1999 parle de l’affrontement entre
le " mastodonte " H.323 contre le " sournois " SIP.
L’avantage incontesté d’H.323 réside dans sa maturité, il existe en effet de nombreux produits
(plus de 30) utilisant ce standard approuvé maintenant internationalement, adopté par de grandes
entreprises telles Cisco, IBM, Intel, Microsoft, Netscape, etc. Si l'on considère les cinq principaux
logiciels de visioconférence : Picturel 550 (adaptation de Netmeeting de Microsoft), Proshare 500
(adaptation de Netmeeting de Microsoft), Trinicon 500 plus (PC Conférence), Smartstation
(adaptation de Netmeeting de Microsoft), Cruiser 150 (Meetingpoint 4.0), tous utilisent sur IP la
norme H.323. La conséquence directe de la compatibilité de tous les logiciels de communication
avec la norme H.323 est un niveau d’interopérabilité très élevé, grand point fort d'H.323. En
effet, cela permet à plusieurs utilisateurs d'échanger des données audio et vidéo sans faire
attention aux types de média qu'ils utilisent.
Cette norme détermine quatre entités fonctionnant ensemble :
ƒ
le terminal
ƒ
la passerelle (gateway)
ƒ
le Multipoint Control Unit (MCU)
ƒ
le gatekeeper
-51-
Conclusion Générale
Le terminal est la machine qui permet la communication : il peut être un PC multimédia ou bien
un téléphone adapté à IP. La passerelle relie le réseau de voix sur IP et le réseau téléphonique
commuté (RTC). La MCU gère les conférences en multicast (à plus de 3 utilisateurs). Et enfin le
gatekeeper (garde barrière) combine des fonctions d'administration de la bande passante avec
celles de PBX virtuels. Il établit la relation entre les alias des terminaux (adresse H.323 de
l'utilisateur) et leur adresses IP. Comme pour SIP les adresses de type email sont possibles, ainsi
que les numéros de téléphone.
V.2.
MEGACO :
La convergence de la voix et des données conduit l'évolution d'une nouvelle génération de
réseaux et crée l'opportunité d'un nouveau marché. HSS (Hughes Software Systems), par
exemple, a développé une série de protocoles pour suivre la convergence des différentes
technologies. MEGACO en est issu.
Megaco peut être combiné avec Multiquick Voice (marque déposée par HSS) afin d'apporter une
solution rapide de voix sur réseaux de paquets (IP) ou de mettre en place une passerelle avec les
réseaux téléphoniques existant (RTC).
Ce protocole gère l'interface entre le Media Gateway Controller (MGC, traîte la signalisation) et
les Media Gateway (MG, convertit les signaux audio en paquets) définis par l'architecture H.323
adopté par l'IETF et l'ITU.
Megaco est au centre des solutions d'intégration de voix sur IP et peut être intégré à des produits
comme les commutateurs de centraux, les passerelles, les serveurs d'accès au réseau, les modems
PABx…pour développer une solution de convergence de voix et de données.
L'un de ses avantages est sa portabilité à travers les OS (Operating Systems) et les plateformes.
En effet, les ports d'entrée sont standardisés pour les environnements suivant : Sun-Solaris,
Windows NT et Vx Works.
VI. Perspectives d’avenir de SIP :
Il est évidant que H.323 est omniprésent dans la communication temps réel sur IP, lui offrant
une grande interopérabilité. L’avenir du protocole SIP n’est pas très radieux. Pourtant les atouts
de SIP sur ses concurrents sont réels et non négligeables.
Premièrement, SIP se caractérise comme étant un protocole plus rapide. Tout d’abord la
séparation entre ses champs d’en-tête et son corps du message facilite le traitement des messages
et diminue leur temps de transition dans le réseau. De plus, le nombre des en-têtes est limité (36
au maximum et en pratique, moins d'une dizaine d'en-têtes sont utilisées simultanément), ce qui
allège l'écriture et la lecture des requêtes et réponses.
-52-
Conclusion Générale
Deuxièmement, SIP est un protocole indépendant de la couche transport : il peut aussi bien
s’utiliser avec TCP que UDP. De plus, il sépare les flux de données de ceux la signalisation : en
effet, une requête et sa réponse peuvent prendre deux chemins différents, ce qui rend plus souple
l'évolution "en direct" d'une communication (arrivée d'un nouveau participant, changement de
paramètres…).
Enfin, la description de SIP est beaucoup plus simple que celle d'H.323 (153 pages de RFC
contre 736), il est plus léger et donc plus facile à mettre en œuvre, sans être moins complet pour
autant. C'est pour cela que la revue 01Réseaux de décembre 1999 se montre optimiste quant à
l'avenir de SIP :
" La rapidité des processus de standardisation de l’IETF fait qu’en septembre 1999 toute
l’industrie rassemblée à Atlanta pour le salon VON (Voice over the Net) a employé des produits
utilisant SIP consacrant ainsi la mort prochaine du "dinosaure" H.323 ". HSS dont nous avons
parlé ci-dessus (c.f. Megaco) a développé une solution utilisant le protocole SIP : Protoquick SIP
Stack et nous montre ainsi que SIP, même s'il n'est pas encore appliqué, a de l'avenir devant lui.
VII. Problème de la mobilité et URI :
Avec la téléphonie classique, nous appelions un lieu, le numéro de téléphone faisant office
d'adresse pour un routage basique : la région, l'agglomération, le centre d'acheminement, la prise.
Avec l'avènement du téléphone portable, le numéro n'indiquait plus un lieu mais un équipement.
Malgré tout, nous ne sommes jamais sûrs de pouvoir réellement contacter la bonne personne.
Aujourd'hui la téléphonie sur IP tend à faire exploser le nombre des équipements pouvant jouer
le rôle d'un téléphone. Ainsi, il ne sera pas rare de disposer de trois ou quatre équipements que
l'on pourra enregistrer pour recevoir des appels. Il devient de plus en plus difficile de contacter
une personne puisqu'on ne sait pas quel équipement est apte à recevoir l'appel. La solution est
l'utilisation d'URIs, Uniform Resource Indicator, qui ont le même format que des adresses emails. Elles contiennent principalement un nom d'utilisateur et un nom de domaine. Quand il
s'enregistre auprès du serveur Registrar, l'utilisateur spécifie l'adresse IP de l'équipement sur
lequel il est connecté. L'URI de l'utilisateur est ensuite associée à cet adresse IP et il est seulement
connu de l'extérieur par cet URI.
-53-
Conclusion Générale
Annexe B
La messagerie instantanée
I. Histoire de la messagerie :
Les hommes cherchent à communiquer depuis longtemps, mais ils n'ont pas toujours été aussi
efficaces qu'aujourd'hui.
En 1800, envoyer un message de Londres à Calcutta prenait deux ans. On écrivait une lettre et la
confiait à un bateau à voiles, qui naviguait le long des côtes occidentales de l'Europe, de l'Afrique,
passait le cap de Bonne Espérance, remontait le long des côtes orientales de l'Afrique, puis à
travers l'océan Indien... avec probablement des arrêts dans presque tous les ports.
En 1914, envoyer le même message prenait un mois. Le canal de Suez était désormais ouvert et
les bateaux à vapeur traversaient la mer Méditerranée pour atteindre la mer Rouge, grande
innovation.
Dans les années 80, FedEx et autres étaient capables de transmettre le même message en deux
jours par avion.
Au début des années 90, quand Internet a été ouvert à l'utilisation commerciale, l'utilisation de l'email s'est généralisée, avec un temps de transport de l'ordre de 10 minutes, dépendant du nombre
et de l'engorgement des de serveurs intermédiaires (vérifications anti-spam et anti-virus) et de la
fréquence avec laquelle vous relevez votre boîte aux lettres.
Puis la messagerie instantanée apparut. Elle apporta :
•
la vitesse : chaque message passait de Londres à Calcutta en quelques dixièmes de
secondes (et presque toujours en moins d'une seconde)
•
le statut : on peut savoir quand la personne avec qui on veut parler est en ligne, et si elle
est en face de son ordinateur ou s'est absentée.
•
la discussion en temps réel : on peut discuter en temps réel avec son interlocuteur,
quasiment comme dans une conversation téléphonique.
II. Présentation du service d’IM :
Les services de messagerie instantanée combinent l'accès à un service permettant d'envoyer et de
recevoir des messages instantanément et l'accès à une liste de contacts référencés par l'utilisateur,
dont la disponibilité est précisée par les outils d'accès au service. On distingue plusieurs types de
services.
-54-
Conclusion Générale
II.1.
Les services de messagerie fixe :
Ce sont les services les plus nombreux. Ils sont en général accessibles à travers des logiciels
spécifiques, appelés clients, qui sont en général accessibles gratuitement. Après enregistrement
des utilisateurs, ces logiciels leur permettent d'échanger des messages, le plus souvent texte, en
temps réel.
Les grands noms du secteur sont MSN, avec son client MSN Messenger, AOL, avec AOL
Instant Messaging, Yahoo!, avec Yahoo! Messenger.
II.2.
Les services de messagerie mobile :
Ces services, encore rares, constituent un champ d'expérimentation encore réel pour la plupart
des opérateurs de services mobiles à ce jour. Etant peu diffusés, ces services reposent sur les
mêmes caractéristiques fonctionnelles que les services fixes. Toutefois, dans le cas des mobiles,
les messages envoyés et/ou les messages reçus sont facturés aux utilisateurs, de même que dans
certains cas l'accès au service.
Dans ce domaine, le fournisseur d'infrastructures, d'accès, de services est bien souvent le même.
En effet, dans bien des cas, ces trois rôles sont tenus par l'"opérateur mobile".
Ces services pourraient être mis en oeuvre en intégrant différentes solutions techniques:
•
En utilisant l'envoi et la réception de SMS ou de MMS à partir d'un client logiciel présent
sur le terminal de l'abonné,
•
En utilisant l'envoi de trames XML (XMPP), au dessus d'une session TCP/IP en mode
GPRS (chaque trame, ou message, pouvant en ce cas être facturé)
•
En utilisant des sessions SIP sur IP, également mises en place au dessus d'une session
GPRS (dans ce cas, chaque trame sera facturée également).
III. Architecture du service d’IM :
La messagerie instantanée requiert l'emploi d'un logiciel client qui se connecte à un serveur de
messagerie instantanée. Elle diffère du courrier électronique du fait que les conversations se
déroulent instantanément (quasiment en temps réel, les contraintes temporelles n'étant pas fortes
dans ces systèmes).
Conformément à la RFC 2778 la plupart des services modernes offrent un système de
notification de présence, indiquant si les individus de la liste de contacts sont simultanément en
ligne et leur disponibilité pour discuter. Ce qui veut dire que les nouveaux systèmes de messagerie
instantanée supportent deux services détaillés ci-dessous :
-55-
Conclusion Générale
III.1. Le service de présence :
Ce service est composé de deux types de clients qui peuvent êtres combinés lors de leur
implémentation mais qu’on va les traiter séparément.
Le premier type de client s’appelle « PRESENTITY ». Il fournit les informations de présences
« PRESENCE INFORMATION » au service afin d’être sauvegardées et distribuées. Alors que
l’autre type de client est appelé « WATCHER ». Celui-ci reçoit les informations de présences de la
part du service de différentes manières qui dépendent de son type. En fait, il y a deux types de
« WATCHER » :
•
Les FETCHER qui demandent simplement les informations de présences présente dans
le PRESENTITY.
•
Les SUBSCRIBER qui demandent du service les notifications concernant tout
changement des informations de présences.
PRESENCE SERVICE
PRESENTITY
WATCHER
Figure B.1. Architecture du service de présence
III.2.
Le service de messagerie instantanée :
De même le service de messagerie a deux types de client comme il est présenté par la figure cidessous :
•
Les SENDER qui fournissent les messages au service afin de les envoyés.
•
Les INSTANT INBOX qui reçoivent les messages captés par le service.
INSTANT MESSAGING
SENDER
INSTANT INBOX
Figure B.2. Architecture du service de messagerie instantanée
-56-
Conclusion Générale
Bibliographie
Articles
[1] D. Tait, J. de Keijzer, and R. Goedman,“ JAIN: A NewApproach to Services in
Communication Networks ”, IEEE Communications Magazine 2000.
[2] R. Bhat e R.Gupta , “ JAIN Protocol APIs ” , IEEE Communications Magazine, January
2000 .
[3] C. Harris, “ JAIN SIP Release 1.0 Specification”, Sun Microsystems 2001.
[4] G. De Marco, P. Asprino, A. Fresa, M. Longo, ’’ Developing new generation network
services’’
[5] M. Day Lotus and J. Rosenberg Dynamicsoft, H. Sugano Fujitsu, la RFC 2778, ‘’A Model for
Presence and Instant Messaging’’, February 2000,
[6] Sun Microsystems, “The JAIN APIs”
[7] Tao Sun and William D. Tucker, ‘’A SoftBridge with Carrier Grade Reliability Using JAIN
SLEE’’
[8] S. B. Lim and D Ferry, “JAIN SLEE 1.0 Specification, final release“, Sun Microsystems, Inc.
and Open Cloud Limited March 2004
[9] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley,
E. Schooler, la RFC 3261 ’’ SIP: Session Initiation Protocol’’, June 2002
[10] Schweizer Laurent, ‘’ Script et APIs pour la gestion des serveurs SIP’’, June 2002
[11] Swee Boon Lim and David Ferry, ‘’JAIN SLEE 1.0 Specification, Proposed final draft 1’’,
June 2004.
[12] Swee Lim, Phelim O’Doherty, David Ferry and David Page, ’’ JAIN JAIN™ SLEE
Tutorial’’
[13] Phelim O'Doherty and Mudumbai Ranganathan, ’’JAINTM SIP API Specification’’
Sites Internet
http://www.jcp.org/
http://www.dev-java.net/
http://www.jainslee.org
http://java.sun.com/products/jain/article_slee_principles.html
http://java.sun.com/products/jain/JAIN-SLEE-Tutorial.pdf
http://www.chez.com/jaaayyy/html/ProjetSIP/
-57-