1. Déploiement d`une plateforme JAIN SLEE

JAIN SLEE
Comment déployer une plateforme JAIN SLEE
Mise en oeuvre d'une plate-forme implantant la spécification JAIN SLE. Création d'un
composant de traitement d'appels
Pierre Lancastre – Frederic Anjubault
FA06
Option ILR 2006
Plan
Introduction
JAIN SLEE est une application middleware orientée évènement écrite en Java. Sa
tâche principale est de récupérer des évènements envoyés par des ressources
extérieures au serveur JAIN SLEE et de les envoyer aux portions de codes
correspondantes. JAIN SLEE est multi protocole, multi plateforme et possède des
caractéristiques similaires aux EJB mais est plus adapté au monde des
télécommunications avec un faible taux de latence, un fonctionnement asynchrone et
une capacité à gérer de nombreuses requêtes par seconde (plusieurs centaines ou
plusieurs milliers). JAIN SLEE gère des modèles de composant (cycle de vie,
déploiement, persistance, redondance, …) et des composants liés au framework
(timers, management à travers JMX, profile, trace, …).
Les objectifs du projet étaient de mettre en œuvre une plate-forme implantant la
spécification JAIN SLEE et de créer un composant de traitement d’appel. Le projet
s’est déroulé sur deux semaines : la première semaine nous nous sommes
familiarisés avec les plateformes de Rhino et Mobicents (déploiement, utilisation). La
deuxième semaine, nous avons déployé de nombreux exemples et analysé et
adapté le code. Nous verrons dans une première partie comment nous avons réussi
à déployer les plateformes ainsi que les difficultés que nous avons rencontrées. La
création d’un composant n’a pas été réalisée mais nous avons compris et analysé le
fonctionnement de JAIN SLEE à travers la mise en œuvre de plusieurs types
d’utilisation : nous allons présenter dans ce rapport deux exemples simples en
deuxième et troisième partie : une plateforme JAIN SLEE utilisant le protocole SIP et
nous terminerons par un deuxième exemple (Wake Up Call) explicitant les multiples
intérêts pour cette nouvelle technologie dans le monde des télécommunications.
1. Déploiement d’une plateforme JAIN SLEE
Déploiement d’une plateforme Mobicents
Téléchargement du serveur Mobicents :
Pour télécharger le serveur Mobicents, il faut se rendre sur www.mobicents.org et
télécharger la dernière version : " Mobicents Suite x.y.z Released".
Ce fichier zip contient un serveur JBoss et les RA nécessaire au déploiement
d’applications.
Une fois le fichier zip téléchargé, il faut le décompresser dans un nouveau répertoire
(faire attention à ce que le chemin ne contienne pas d’espace).
Pour démarrer le serveur, il faut aller au répertoire racine du serveur et lancer la
commande : ./bin/run –c all –b < 127.0.0.1 ou l’adresse ip la machine >
Pour tester l’interface web du serveur Mobicents, il faut taper dans son navigateur
web : http://localhost:8080/jmx-console
Remarques
Nous avons déployé ce serveur sur une station Windows 2000 Pro avec quelques
difficultés au début car tout n’est pas forcément explicité dans les explications (il faut
installer ant, mettre en place les variables d’environnement pour JBOSS, …). Les
tutoriaux d’installations ne sont pas intuitifs et s’adressent à un public averti. Il nous
donc a fallu un temps d’adaptation pour comprendre comment cette technologie
fonctionne. Un point positif pour Mobicents est qu’il existe un fichier pour le
déploiement du serveur de type « tout en un ». Par contre, l’interface Web de
supervision reste austère et difficile à comprendre. D’ailleurs, nous l’avons que très
peu utilisé. En fait, il y a deux possibilités de déploiement : à partir de l’interface Web
ou en ligne de commande. Nous avons choisi cette seconde option pour configurer
et mettre en place les services. Malgré tout, les nombreux exemples en open source
présent sur le site de Mobicents nous ont permis de réaliser toute la portée de cette
nouvelle technologie.
Plugin Eclipse
Il existe un plugin Eclipse que nous avons utilisé durant le projet pour déployer les
applications.
Déploiement d’une plateforme Rhino
Pré requis d’installation dans le cas de la mise en place d’un Proxy SIP sur une
plateforme JSLEE :
-
Serveur fonctionnant sous Linux (release UBUNTU pour nos tests)
Le service SQL « POSTGRE »
Le service DNS « Bind »
Le serveur JSLEE « Rhino OpenCloud»
L’unité de déploiement SIP fourni avec Rhino
a) Installation de PostGre
1. Télécharger le package disponible sur le site http://www.postgresql.org
2. Décompresser l’archive dans un répertoire appartenant à l’utilisateur
3. Exécuter les commandes ci-dessous :
./configure // lance le script de generation de fichiers d’installation
make // lance le make file pour créer les scripts
su
make install // installe le package
mkdir /usr/local/pgsql/data // on crée un dossier où sera contenu la BD
chown <user_en_cours> /usr/local/pgsql/data // on attribut le dossier à
l’utilisateur en cours
su - <user_en_cours>
/usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data // on initialise le
conteneur de BD
/usr/local/pgsql/bin/postmaster -D /usr/local/pgsql/data >logfile 2>&1 & //
on crée un fichier de log pour contenir les logs renvoyés par le service
/usr/local/pgsql/bin/createdb test // on crée une base de donnée “test”
/usr/local/pgsql/bin/psql test // pour tester le service PGSQL
b) Personnalisation de Bind
1. Installer le service DNS « Bind9 »
2. Configurer le serveur DNS
2.1. Les fichiers de configuration
Les fichiers de configuration de Bind se trouvent dans le répertoire
/etc/bind/. On y trouve notamment le fichier db.root, qui contient les
adresses IP des serveurs DNS racines (i.e. les serveurs centraux du
système DNS de l’ENIC), et le fichier named.conf qui est le fichier de
configuration principal de Bind.
Le répertoire /var/cache/bind/ est destiné à accueillir les fichiers de
zone pour ceux (ici slee.org.zone) qui veulent configurer un serveur
DNS primaire ou secondaire.
2.2 Configurer le serveur DNS primaire «indépendant »
Par défaut, Bind est configuré en tant que serveur DNS "indépendant",
qui n'est primaire ou secondaire pour aucun domaine. Quel est l'intérêt
d'un tel serveur ? Faire office de cache DNS. En effet, le serveur DNS
va retenir dans son cache les correspondances IP-DNS demandées par
les clients, et ne sera pas obligé d'aller chercher à chaque fois auprès
des autres serveurs DNS la réponse aux requêtes.
Par exemple, si vous trouvez que le serveur DNS de votre fournisseur
d'accès est trop long à répondre, vous aurez intérêt à installer un
serveur DNS sur votre ordinateur et configurer votre système pour qu'il
interroge en priorité le serveur local. Pour optimiser les temps de
requêtes, configurez le serveur DNS pour qu'il demande les
enregistrements qu'il n'a pas dans son cache aux serveurs DNS de
votre fournisseur d'accès au lieu d'aller les demander lui-même auprès
des autres serveurs DNS.
Pour cela, éditez le fichier named.conf et décommentez les lignes de la
sous-section forwarders de la section options en y inscrivant les
adresses IPs des serveurs DNS de votre fournisseur d'accès. Le début
du fichier named.conf ressemble alors à cela :
options {
directory "/var/cache/bind";
forwarders {
193.48.251.10;
193.48.251.11;
};
auth-nxdomain no;
};
où 193.48.251.10 et 193.48.251.11 sont les adresses IPs des serveurs
DNS de l’ENIC.
Enfin, modifiez le fichier /etc/resolv.conf et mettez votre serveur en
première position dans la liste des serveurs DNS :
search enic.fr
nameserver <@IP_de_la_machine>
nameserver 193.48.251.10
nameserver 193.48.251.11
2.3 Configurer le serveur DNS pour créer la zone « slee.org »
2.3.1
Modifier le fichier « named.conf »
Ajoutez à la fin du fichier named.conf les lignes suivantes :
zone "slee.org" {
type master;
file "slee.org.zone";
};
où :

sleee.org est le nom de domaine pour lequel votre serveur sera primaire,

slee.org.zone désigne le fichier /var/cache/bind/slee.org.zone où seront stockés les
enregistrements de la zone.
2.3.2
Ecriture du fichier de zone
Le fichier de configuration de la zone se présente comme ci-dessous :
; /var/cache/bind/mondomaine.org.zone
; Fichier de zone "type" pour le domaine "slee.org"
; Tiré de la formation Debian GNU/Linux par Alexis de Lattre
; http://www.via.ecp.fr/~alexis/formation-linux/
; Utiliser la commande
; "named-checkzone mondomaine.org /var/cache/bind/slee.org.zone"
; pour vérifier la validité du fichier de zone.
; Utiliser la commande "named-checkconf" pour verifier la validite du fichier
; de configuration /etc/bind/named.conf
; ATTENTION : ne pas oublier de mettre a jour le "serial" a chaque
; modification des enresgitrements de ce fichier.
; ATTENTION : dans les fichiers de zone, les noms DNS complets doivent se
; terminer par des points (par exemple "master.mondomaine.org.")
; Tous les noms DNS qui ne sont pas complets (i.e. qui ne se terminent
; pas par un point) se terminent implicitement par "mondomaine.org."
; TTL (Time To Live) par d faut.
; Le TTL permet de dire aux serveurs DNS tiers qu'ils ne devront pas
; garder les enregistrements de notre zone en cache au dela de cette
; dur e. On met une journ e (86400 secondes).
$TTL 86400
; ENREGISTREMENT "SOA" (Start Of a zone of Authority).
; Cet enregistrement donne le nom du serveur DNS primaire et l'adresse mail
; a laquelle on peut joindre l'administrateur du domaine.
; Par exemple, le serveur DNS primaire s'appellera "ns0" et
; l'adresse mail de l'administrateur sera <[email protected]>
@
IN
SOA ns0.slee.org. root.dns.slee.org. (
; Serial (ou "Numero de serie") de la zone.
; Il permet aux serveurs secondaires de savoir s'ils ont besoin
; de se mettre
jour en faisant un transfert de zone avec le serveur
; primaire ou non en comparant leurs "serial" pour cette zone.
; Par convention, il est constitue de la date du jour au format AAAAMMJJ
; suivi du nombre de modifications deja effectuees sur le fichier de zone
; dans la journee + 1.
; Par exemple, nous sommes le 1er mai 2003, et c'est la deuxieme fois
; que je modifie le fichier de zone aujourd'hui :
2006060505
; Refresh.
; Intervalle de temps en secondes pendant lequel les serveurs DNS
; secondaires attendent avant de verifier (et eventuellement de
; mettre a jour) l'enregistrement SOA du serveur DNS primaire.
; On met un 1 journee (86400 secondes).
86400
; Retry.
; Intervalle de temps en secondes durant lequel les serveurs DNS
; secondaires attendent avant de reessayer une requete vers le serveur DNS
; primaire si ce dernier n'est pas accessible.
; On met 5 minutes (300 secondes).
300
; Expire.
; Intervalle de temps en secondes durant lequel les serveurs DNS
; secondaires attendent avant de rejeter les informations de zones s'ils
; n'ont pas pu contacter le serveur DNS primaire.
; On met 1 mois (2592000 secondes).
2592000
; TTL (Time To Live) minimum.
; Duree minimum du TTL d'un enregistrement DNS de la zone.
; On met 1 journee (86400 secondes).
86400
)
; ENREGISTREMENTS "NS"
; Ces enregistrements donnent les noms DNS des serveurs primaires
; et secondaires
slee.org.
IN
NS
ns0
slee.org.
IN
NS
ns0
; ENREGISTREMENTS "A"
; Les enregistrements "A" donnent les correspondances DNS <-> IP classiques
; Pour qu'une requete DNS "ns0.slee.org" renvoie "172.27.131.230" qui est l’IP de
notre serveur de test
ns0
IN
A
172.27.131.230
; ENREGISTREMENTS "CNAME"
; Le champ "CNAME" est utilise pour faire des "alias DNS",
; c'est-a-dire avoir une IP qui repond a plusieurs noms DNS.
; Par exemple, pour qu'une requete DNS "www.slee.org" renvoie
; aussi l'IP du serveur de test :
www
mailhost
IN
IN
CNAME ns0
CNAME ns0
; ENREGISTREMENTS "MX"
; Le champ "MX" est utilise pour les envois de mail.
; Quand un serveur de mail doit envoyer un mail a l'adresse
; <[email protected]>, il fait une requete DNS de type "MX" sur
; "slee.org". Il obtient en retour une liste d'adresses IP classees
; avec des priorites. Il essaye alors d'envoyer le mail au serveur
; principale, s'il est injoignable au serveur secondaire, etc...
; Pour les adresses @slee.org, le serveur principal est "ns0",
slee.org.
IN
MX
10
ns0
; ATTENTION : on ne met pas de "MX" sur un "CNAME",
; mais uniquement sur un "A" !
; Si on veut inclure un autre fichier de ce fichier :
;$INCLUDE nom_de_l'autre_fichier
2.3.3. Vérifications et relance
Vérifiez que vous n'avez pas fait d'erreur de syntaxe dans le fichier named.conf:
named-checkconf
Si la commande n'affiche rien, c'est que le fichier named.conf est valide. Ensuite,
vérifiez la syntaxe du fichier de zone :
named-checkzone slee.org /var/cache/bind/slee.org.zone
zone slee.org/IN: loaded serial 2006060505
OK
Si la commande n'affiche aucun message d'erreur, alors il n'y a pas d'erreur de
syntaxe dans le fichier de zone. Vous pouvez alors dire à Bind de relire son fichier de
configuration :
# /etc/init.d/bind9 reload
Attention, si vous faites un restart au lieu d'un reload, le cache de votre serveur
DNS se videra !
c) Installation du serveur Rhino
Utilitaires annexes requis :
La variable d’environnement JAVA_HOME doit être pointée sur le répertoire racine du
Java SDK.
Pour vérifier, entrez les commandes ci-dessous :
$ which java
/usr/local/java/bin/java
$ java -version
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing)
$ export JAVA_HOME=/usr/local/java
$ PATH=$JAVA_HOME/bin:$PATH
_
Apache Ant 1.6.2 doit être installé. La variable d’environnement ANT_HOME doit être
pointée sur le répertoire racine d’Apache Ant. Pour vérifier, entrez les commandes cidessous :
$ which ant
/usr/local/ant/bin/ant
$ ant -version
Apache Ant version 1.6.2 compiled on July 16 2004
$ export ANT_HOME=/usr/local/ant
$ PATH=$ANT_HOME/bin:$PATH
La commande unzip.
$ which unzip
/usr/bin/unzip.
L’utilitaire TAR
$ which tar
/bin/tar
L’utilitaire awk
$ which awk
/bin/awk
L’utilitaire “sed”
$ which sed
/bin/sed
Installation du package RhinoSLEE
Le SDK Rhino SLEE est livré sous forme d’archive compressée tar : RhinoSDK1.4.2.tar. On la décompresse grâce aux commandes ci-dessous :
$ tar xvf RhinoSDK-1.4.2.tar
$ cd rhino-sdk-install
Ceci va créer un répertoire “rhino_sdk-install » contenant les fichiers d’installation. A
partir de ce répertoire, lance le script d’installation « rhino-install.sh”.
On obtient le résultat ci-dessous :
$ ./rhino-install.sh
Open Cloud Rhino SDK Installation
The Rhino SDK install requires access to a PostgreSQL database server,
for storing persistent configuration and deployment information. The
database
settings you enter here are required for the Rhino SDK config files. The
install script can optionally configure the database for you, you will be
prompted for this later in the install process.
Postgres host [localhost]:
Postgres port [5432]:
Postgres user [user]: //entrer le username possédant l’acces a la base SQL
Postgres password:
Postgres password (again):
On définit ensuite le nom de la base de données qui sera crée pour contenir les
tables necessaries pour le fonctionnement de rhino. Ensuite, si tous les prérequis ont
été respectés (JAVA_HOME, etc) l’installeur devrait renseigner automatiquement les
paramètres demandés :
Database name [rhino]:
Enter the directory where you want to install the Rhino SDK.
These two ports are used for accessing the Management MBeans from a Java
RMI
(Remote Method Invocation) client, such as the Rhino SDK command-line
utilities.
Management Interface RMI Registry Port [1199]:
Management Interface RMI Object Port [1200]:
This port is used for accessing the JMX Remote server. The Rhino Web
Console
uses this for remote management.
Management Interface JMX Remote Service Port [1202]:
This port is used for the Web Console (Jetty) server and provides
remote management user interface. This is a secure port (TLS).
Secure Web Console HTTPS Port [8443]:
Enter the location of your Java J2SE/JDK installation.
This must be at least version 1.4.2.
JAVA_HOME directory [/usr/local/java]:
Found Java version 1.4.2_04.
The Java heap size is an argument passed to the JVM to specify the amount
of
main memory (in megabytes) which should be allocated for running the
Rhino SDK. To prevent extensive disk swapping, this should be set to less
than the total memory available at runtime.
Java heap size [512]:
*** Network Configuration ***
The Rhino SDK install will now attempt to determine local network
settings. The hostname detected here is used by the web console. The IP
addresses detected here are used in generating the default security
policy for the management interfaces.
The following network settings were detected. These can be modified after
installation by editing /home/user/rhino/config/config_variables.
Canonical hostname: cyclone
Local IP Addresses: 192.168.62.2 127.0.0.1 192.168.0.22
The Rhino SDK installation needs to use the PostgreSQL interactive
client, psql. Enter the full path to your local psql client here. If you do
not have a psql client installed (e.g. if postgres is running on a remote
host
and not installed on this one), then enter '-' here to skip this question.
You will still need to initialise the database on the remote host using
'init-management-db.sh'.
Location of psql client [/usr/bin/psql]:
*** Confirm Settings ***
Installation directory: /home/user/rhino
Postgres host: localhost
Postgres port: 5432
Postgres user: user
Database name: rhino
JAVA_HOME directory: /usr/local/java
Management Interface RMI/JMX Ports: 1199,1200,1202
Web Console Interface HTTPS Port: 8443
Are these settings correct (y/n)? y
Creating installation directory.
The installer has detected you are running a 1.4.2 JVM. This version of
Sun's
JVM has a bug related to incorrect compilation of a particular list method.
See '/home/user/rhino/config/hotspot_compiler_fix' for more information.
Writing configuration to /home/user/rhino/config/config_variables.
I will now generate the keystores used for secure transport authentication,
Remote management and connections must be verified using paired keys.
/home/user/rhino/rhino-public.keystore
with a storepass of changeit and a shared keypass of changeit
/home/user/rhino/rhino-private.keystore
with a storepass of changeit and a shared keypass of changeit
The behaviour of the Rhino SDK paired key SSL can be configured by editing:
/home/user/rhino/config/rmissl.{service_name}.properties
Creating key pairs for common services
Exporting the certificates into the public keystore for service
distribution
Certificate was added to keystore
Certificate was added to keystore
Certificate was added to keystore
Certificate was added to keystore
Copying the public keystore to the client distribution directory
The Open Cloud Rhino SDK is now installed in /home/user/rhino.
Next Steps:
- Start the Rhino SDK SLEE by running "/home/user/rhino/start-rhino.sh".
- Access the Rhino management console at https://cyclone:8443/
- Login with username admin and password password
- Deploy the example SIP services, see the file
/home/user/rhino/examples/sip/README for more information.
Open Cloud Rhino SDK installation complete.
Initialisation de la mémoire d’exécution de Rhino:
Rhino SLEE SDK utilise une base de données PostgreSQL pour contenir les statuts
des différents composants SLEE. Pour pouvoir l’utiliser, il nous faut initialiser cette
base comme ci-dessous :
Attention: l’exécution de ce script effacera tout possible base existante et donc
effacera toutes les données continues précédemment !
$ ./init-management-db.sh
CREATE DATABASE
You are now connected to database "rhino".
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "versioning_pkey" for table "versioning"
CREATE TABLE
COMMENT
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "keyspaces_pkey" for table "keyspaces"
CREATE TABLE
COMMENT
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "timestamps_pkey" for table "timestamps"
CREATE TABLE
COMMENT
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "registrations_pkey" for table "registrations"
CREATE TABLE
COMMENT
Démarrage du serveur Rhino :
On démarre le serveur Rhino grâce à la commande suivante :
$RHINO_HOME/start-rhino.sh Durant le démarrage de celui-ci, les événements
suivants se produisent :
1. La JVM se lance.
2. Le SDK génére et lit sa configuration
3. Le SDK initialise et synchronise sa mémoire avec le serveur SQL
4. Le SDK initialise les « per-machine MLets » (Management Agents).
5. Le SLEE entre en “RUNNING state”
6. Le SDK Rhino SLEE SDK est prêt à recevoir des commandes d’administration.
Arrêt du serveur Rhino :
On arrête le serveur Rhino grâce à la commande suivante : $RHINO_HOME/stoprhino.sh.
On obtient la sortie suivante :
>./stop-rhino.sh --nice
SLEE shutdown initiated
SLEE stop completed shutdown phase initiated
SLEE shutdown successfully
Interface de management:
Un composant SLEE peut être configure ou managé au biais de la console en ligne
de commande ou de l’interface Web.
On démarre la console comme ci-dessous :
$ cd $RHINO_HOME
$ ./client/bin/rhino-console
Interactive Management Shell
[Rhino (cmd (args)* | help (command)* | bye) #1] State
SLEE is in the Running state
_
On accède à la console web en rentrant l’adresse https://<hostname>:8443 dans
son browser web.
L’utilisateur par défaut est “admin” et le mdp “password”.
Nous pouvons maintenant déployer des services grâce à ces consoles.
d) Déploiement du service SIP
Nous devons tout d’abord éditer le fichier de configuration suivant :
$RHINO_HOME/examples/sip/sip.properties contains these properties.
Pour la mise en place du service sur notre serveur de test, nous devons tout d’abord
changer les parametres comme ci-dessous :
# Proxy SBB configuration
# Add names that the proxy host is known by. The first name in the list
# will be treated as the Proxy's canonical hostname and will be used in
# Via and Record-Route headers inserted by the proxy.
PROXY_HOSTNAMES=ns0.slee.org, 127.0.0.1
# On rentre le DNS de notre serveur de test en tant que proxy
# Add domains that the proxy is authoritative for
PROXY_DOMAINS=ns0.slee.org,slee.org
# On rentre le nom du domaine d’application de notre plateforme de test
#pour lesquels le proxy sera actif
PROXY_LOOP_DETECTION=false
#On désactive la détection de boucle SIP du fait que le serveur fait à la
#fois DNS et JSLEE server. En effet, dans les définitions de la RFC 3261,
#un proxy ne peut pas envoyer une réponse à lui-même ( dans notre
#plateforme de test, les utilisateur s’authentifient en [email protected].
#Les messages qui sont envoyés au proxy sont tout d abord redirigés vers le
#serveur lui-même (à cause du @ns0.slee.org) puis transférés au receveur si
#celui-ci se trouve dans la table de routage du proxy.
Génération et déploiement des services
Pour créer les unités de déploiement des services Registrar, Proxy et Location
lancez “Ant” avec pour cible « build » comme ci-dessous:
user@host:~/rhino/examples/sip$ ant build
Buildfile: build.xml
init:
[mkdir] Created dir: /home/user/rhino/examples/sip/jars/sip/jars
[mkdir] Created dir: /home/user/rhino/examples/sip/jars/sip/classes
compile-sip-examples:
[mkdir] Created dir: /home/user/rhino/examples/sip/jars/sip/classes/sipexamples
[javac] Compiling 37 source files to
/home/user/rhino/examples/sip/jars/sip/classes/sip-ex
amples
sip-ac-location:
[sbbjar] Building sbb-jar: /home/user/rhino/examples/sip/jars/sip/jars/aclocation-sbb.jar
[deployablejar] Building deployable-unit-jar:
/home/user/rhino/examples/sip/jars/sip/jars/sipaclocation-service.jar
[delete] Deleting: /home/user/rhino/examples/sip/jars/sip/jars/ac-locationsbb.jar
sip-jdbc-location:
[sbbjar] Building sbb-jar:
/home/user/rhino/examples/sip/jars/sip/jars/jdbc-location-sbb.ja
r
[deployablejar] Building deployable-unit-jar:
/home/user/rhino/examples/sip/jars/sip/jars/sipjdbclocation-service.jar
[delete] Deleting: /home/user/rhino/examples/sip/jars/sip/jars/jdbclocation-sbb.jar
sip-registrar:
[copy] Copying 2 files to
/home/user/rhino/examples/sip/jars/sip/classes/sip-examples/reg
istrar-META-INF
[sbbjar] Building sbb-jar:
/home/user/rhino/examples/sip/jars/sip/jars/registrar-sbb.jar
[deployablejar] Building deployable-unit-jar:
/home/user/rhino/examples/sip/jars/sip/jars/sipregistrarservice.jar
[delete] Deleting: /home/user/rhino/examples/sip/jars/sip/jars/registrarsbb.jar
sip-proxy:
[copy] Copying 3 files to
/home/user/rhino/examples/sip/jars/sip/classes/sip-examples/pro
xy-META-INF
[sbbjar] Building sbb-jar:
/home/user/rhino/examples/sip/jars/sip/jars/proxy-sbb.jar
[deployablejar] Building deployable-unit-jar:
/home/user/rhino/examples/sip/jars/sip/jars/sipproxyservice.jar
[delete] Deleting: /home/user/rhino/examples/sip/jars/sip/jars/proxysbb.jar
sip-fmfm:
[copy] Copying 4 files to /home/user/rhino/examples/sip/jars/sip/classes/sip-examples/fmf
m-META-INF
[profilespecjar] Building profile-spec-jar: /home/user/rhino/examples/sip/jars/sip/jars/fmfm-p
rofile.jar
[sbbjar] Building sbb-jar: /home/user/rhino/examples/sip/jars/sip/jars/fmfm-sbb.jar
[deployablejar] Building deployable-unit-jar: /home/user/rhino/examples/sip/jars/sip/jars/sipfmfmservice.jar
[delete] Deleting: /home/user/rhino/examples/sip/jars/sip/jars/fmfm-profile.jar
[delete] Deleting: /home/user/rhino/examples/sip/jars/sip/jars/fmfm-sbb.jar
sip-b2bua:
[copy] Copying 3 files to /home/user/rhino/examples/sip/jars/sip/classes/sip-examples/b2b
ua-META-INF
[sbbjar] Building sbb-jar: /home/user/rhino/examples/sip/jars/sip/jars/b2bua-sbb.jar
[deployablejar] Building deployable-unit-jar: /home/user/rhino/examples/sip/jars/sip/jars/sipb2buaservice.jar
[delete] Deleting: /home/user/rhino/examples/sip/jars/sip/jars/b2bua-sbb.jar
build:
BUILD SUCCESSFUL
Total time: 25 seconds
Par défaut, le script déploiera les services Registrar et Proxy et les composants dont
ils dépendent tells que le « SIP Resource Adaptor » et le « Location Service ». Pour
déployer ces exemples, lancez “Ant” avec pour cible « deployexamples » comme cidessous:
user@host:~/rhino/examples/sip$ ant deployexamples
Buildfile: build.xml
init:
build:
management-init:
[echo] OpenCloud Rhino SLEE Management tasks defined
login:
[slee-management] establishing new connection to : 127.0.0.1:1199/admin
deploysipra:
[slee-management] Install deployable unit file:lib/ocjainsip-1.2-ra.jar
[slee-management] Create resource adaptor entity sipra from OCSIP 1.2, Open
Cloud
[slee-management] Bind link name OCSIP to sipra
[slee-management] Activate RA entity sipra
deploy-jdbc-locationservice:
deploy-ac-locationservice:
[slee-management] Install deployable unit file:jars/sip-ac-locationservice.jar
[slee-management] Activate service SIP AC Location Service 1.5, Open Cloud
[slee-management] Set trace level of ACLocationSbb 1.5, Open Cloud to Info
deploylocationservice:
deployregistrar:
[slee-management] Install deployable unit file:jars/sip-registrarservice.jar
[slee-management] Activate service SIP Registrar Service 1.5, Open Cloud
[slee-management] Set trace level of RegistrarSbb 1.5, Open Cloud to Info
undeployfmfm:
[slee-management] Remove profile table FMFMSubscribers
[slee-management] [Failed] Profile table FMFMSubscribers does not exist
[slee-management] Deactivate service SIP FMFM Service 1.5, Open Cloud
[slee-management] [Failed] Could not find a service matching SIP FMFM
Service 1.5, Open Cloud
[slee-management] Wait for service SIP FMFM Service 1.5, Open Cloud to
deactivate
[slee-management] [Failed] Could not find a service matching SIP FMFM
Service 1.5, Open Cloud
[slee-management] Uninstall deployable unit file:jars/sip-fmfm-service.jar
[slee-management] [Failed] Deployable unit file:jars/sip-fmfm-service.jar
not installed
deployproxy:
[slee-management] Install deployable unit file:jars/sip-proxy-service.jar
[slee-management] Activate service SIP Proxy Service 1.5, Open Cloud
[slee-management] Set trace level of ProxySbb 1.5, Open Cloud to Info
deployexamples:
BUILD SUCCESSFUL
Total time: 1 minute 36 seconds
Vérifiez que Rhino SLEE est dans l’état “RUNNING” après le déploiement:
user@host:~/rhino$ ./client/bin/rhino-console
Interactive Rhino Management Shell
Rhino management console, enter 'help' for a list of commands
[Rhino@localhost (#0)] state
SLEE is in the Running state
Les services “Registrar” et “Proxy” sont maintenant déployés et prêts à l’emploi.
Méthode pour tracer les événements sur le prompt du serveur
Commande sur la console pour afficher les messages SIP transitant par le proxy :
setloglevel sip.transport.manager debug
Dorénavant, le terminal du serveur SLEE doit tracer les messages SIP.
Actions à réaliser sur l’interface web pour afficher les messages SIP transitant par le
proxy :
Aller sur la page principale de l’interface web
Sélectionner “SLEE Subsystems” puis “View Trace MBean»
Sur la page “Trace” se trouvent les boutons « setTraceLevel » et
« getTraceLevel ».
Sur la liste déroulante à coté de “setTraceLevel”, sélectionner le composant à
deboguer, ici le SBB SIP Proxy. Sélectionner le niveau de trace « finest » qui est le
plus détaillé.
Appuyez sur le bouton “setTraceLevel”. Dorénavant, le SBB Proxy SBB va
générer des informations de log détaillés, tels que le contenu des messages SIP
qu’ils reçoivent et envoient.
2. Exemple SIP
Matériel utilisé
-
-
Un portable sous Linux jouant le rôle de serveur DNS et PROXY SIP au biais
du serveur d’exécution JSLEE « Rhino OpenCloud »
Une station sous Windows 2000 executant le client de Messagerie
instantanée MSN Messenger 4.6 rattaché au serveur DNS de test (entrez l’IP
du serveur en tant que DNS primaire dans la configuration de la carte réseau)
Une station sous Windows 2000 exécutant le SIPPhone « SJPhone » rattaché
au serveur DNS de test
Explication de la procédure de test
Pour notre test, nous avons voulu faire communiquer deux logiciels fournis par
différents fournisseurs et ayant des vocations différentes. Ceci afin de montrer
l’interopérabilité lorsque leur fonctionnement repose sur la plateforme JSLEE. En
effet, le protocole SIP étant standardisé, nous avons pu réaliser des communications
de type VoIP grâce au service Proxy déployé sur notre serveur. Pour cela, il faut
configurer ces logiciels comme ci-dessous :
Configuration de msn :
-
lancer MSN Messenger 4.6 et allez dans les options, puis dans « comptes ».
Sélectionner le service « SIP » et entrer comme nom d’utilisateur
« [email protected] »
Allez dans les propriétes avancées de cette rubrique et rentrez comme nom
de serveur : ns0.slee.org. Pensez à spécifier le port(@IP :PORT) si vous avez
changé le port d’écoute dans la configuration du Proxy..
Configuration de SJPhone :
-
-
Lancer SJPhone et allez dans les options Profile options
Dans proxy domain entrez le nom du serveur « ns0.slee.org » et comme port
« 5060 » (ou celui que vous avez mis en remplacement du port par défaut
dans la configuration du proxy)
Dans User domain, entrez « ns0.slee.org »
Ne pas cocher « Use separate registrar » (la fonction n’est pas supportée par
l’exemple déployé)
Une fois les machines configurées, la procédure de test s’effectue comme décrit sur
les schémas ci-dessous :
1) Enregistrement du poste sjphone sur le proxy
2) Enregistrement du poste msn sur le proxy
3) Les 2 stations sont enregistrées sur le proxy
4) Illustration du rôle du DNS
5) Illustration de la communication entre les 2 stations
Une fois que les 2 stations sont enregistrées sur le proxy, elles peuvent réaliser des
communications SIP par le biais de leur logiciel. Par exemple, on veut que la station
sjphone appelle la station msn. Dans le logiciel SJPhone, on entre comme
destinataire « [email protected] ». Des lors, le logiciel envoie une requête SIP de
type « INVITE » au serveur proxy ns0.slee.org. Celui-ci regarde si il a l’autorité sur le
domaine ns0.slee.org (ici oui) puis transfère le message à la station [email protected]
vu que son @IP est contenue dans la table de translation sur service Proxy. Ensuite,
la machine [email protected] envoie une trame pour le sjphone acquittant la réception
de l’invitation. Cette trame sera relayée par le proxy. Une fois la trame d’acquitement
recue, le sjphone sait que la station msn est joignable et formule une demande de
communication vocale. S’ensuit alors un process de « ringing ». Des que la machine
msn accepte l’appel (envoie d’un acquittement SIP à sjphone), la communication
vocale commence (au biais du protocole RTP).
Le test de cette plateforme SIP reposant sur le protocole JAIN SLEE a été concluant.
Nous avons mis en place ce test à l’aide de deux logiciels différents mais ce type
d’implantation aurait pu être déployé avec des PDA, des téléphones mobiles ou
d’autres ordinateurs utilisant différents systèmes d’exploitations tout en sachant,
même si nous ne l’avons pas testé, que le temps de réponse est vraiment idéal pour
ce type d’application. Cette portabilité multi plateforme et les performances en terme
de temps de réponse sont de réels atouts de JAIN SLEE. Nous allons maintenant
expliciter le fonctionnement interne en analysant le code d’une application au
fonctionnement simple : le Wake Up Call.
3. Service Wake Up Call
Le service JAIN SLEE Wake Up Call permet de comprendre comment écrire
rapidement une application pour le protocole SIP.
Ce service a pour rôle de recevoir des messages des SIP UA (SIP User Agents) au
format “TIME TEXT “ (un nombre suivi d’un espace puis du texte). Tout autre type de
message envoyé à l’application génère une erreur. Le nombre envoyé est le délai en
seconde, il permet de déclencher un timer qui commence à compter à partir du
moment ou le message est reçu par le service wake up. Après que le délai soit
expiré, le timer génère automatiquement un message envoyé au client avec la partie
texte seulement qui a été envoyée dans le message original.
Nous avons fait fonctionner ce service avec des clients SIP (SJ Phone et Windows
Messenger).
Déploiement et utilisation
Pour mettre en oeuvre ce service JAIN SLEE sous Windows 2000, nous avons suivi
les étapes suivantes :
- Récupération du code source des exemples mobicents :
http://sourceforge.net/project/showfiles.php?group_id=102670&package_id=1
65277
- Installation de Java, Ant et du plugin eclipse JAIN SLEE
- Lancement de ant pour déployer la solution et récupérer le wake-up-sbb.jar
- Lancement du serveur (nous avons utilisé Rhino Slee)
- Déploiement du jar dans le serveur
- Lancement et configuration des clients SIP SJ Phone et Windows Messenger
4.6
- Envoi d’un message à [email protected]. Par exemple « 10 COUCOU ! »
- Après quelques secondes (ici 10) le SIP phone doit recevoir un message
« COUCOU ! » de [email protected]
Code source de l’application
Dans cet exemple, nous allons nous intéresser aux trois fichiers principaux qui
composent l’application :
a) un service SLEE : wakeup-service.xml
Pour faire fonctionner le service wake up nous avons besoin d’un point d’entrée.
Cela est réalisé à travers ce fichier de définition de service. Il permet de signaler au
conteneur SLEE que nous avons déployé et activé un nouveau service qui va
accepter de recevoir certains types d’évènement. Le rôle du conteneur SLEE est de
garantir le transport de tous les évènements auquel le service WakeUp a souscrit.
Le fait que les composants soient asynchrones et que leur comportement peut être
définit de manière très précise permet une grande évolutivité et un control précis
notamment affecter des priorités aux services de communications. On peut par
exemple imaginer que les appels d’urgence (numéros 18, 17) peuvent être implanté
avec une plus grande priorité de manière très simple avec un conteneur SLEE.
Voici à présent le code de notre fichier xml :
<service-xml>
<service>
<description>Wake up service</description>
<service-name>Wake Up Service</service-name>
<service-vendor>FA06</service-vendor>
<service-version>1.0</service-version>
<root-sbb>
<description>This Sbb send a wake up call to the
user.</description>
<sbb-name>Wake Up Sbb</sbb-name>
<sbb-vendor>FA06</sbb-vendor>
<sbb-version>1.0</sbb-version>
</root-sbb>
<default-priority>0</default-priority>
</service>
</service-xml>
Dans le conteneur SLEE, le service WakeUp est uniquement identifié par le tuple
(service-name, service-vendor, service-version). Le SBB racine doit être référencé
par un identifiant unique (sbb-name,sbb-vendor, sbb-version).
Le descripteur de service est compris dans l’unité de déploiement du SLEE avec
l’archive SBB qui sera généré : c’est le fichier wakeup-DU.jar qui aura la structure
suivante :
/wakeup-service.xml
/META-INF/deployable-unit.xml (ce service liste les archives SLEE à déployer)
/jars/WakeUp-sbb.jar, wakeup-service.xml)
b) un Service Building Block – WakeUpSbb
WakeUpSbb est le SBB racine du service. Son rôle est d’accepter les évènements
de type message SIP, d’analyser le texte reçu et de lancer un wakeup timer. Il va
aussi écouté les évènements timer et envoyer un SIP MESSAGE en retour à l’UA qui
a envoyé le message.
c) une interface pour le contexte d’activité – WakeUpSbbActivityContextInterface
Cette interface java est une vue du contexte d’activité. L’interface a deux propriétés :
contact et body. Le contact enregistre l’adresse physique du SIP phone utilisé. Le
body va stocker le message texte envoyé par l’utilisateur. Le conteneur SLEE va
d’abord créer une instance d’objet qui implémente cette interface. Ensuite on le lie à
un timer, ce qui va permettre de récupérer les données quand celui-ci est terminé.
Vue détaillée du code
Le WakeUpSBB est implémenté dans la classe WakeUpSBB et est déclaré au
conteneur SLEE grâce au fichier descriptif sbb-jar.xml. Ces deux fichiers sont
intégrés dans une archive jar : WakeUp-sbb.jar qui possède la structure suivante :
/META-INF/sbb-jar.xml – Le fichier descriptif du SBB
/org/mobicents/* - Les classes Java
sbb-jar.xml
Intéressons nous au fichier sbb-jar.xml qui declare les points suivants :
- un identifiant unique pour le SBB (Wake Up Sbb, NIST, 1.0)
- Sa classe Java d’implantation
(org.mobicents.slee.examples.wakeup.WakeUpSbb), c’est une classe
abstraite. Le conteneur SLEE créer une sous-classe et l’instancie lors de
l’exécution. La méthode abstraite implémentée par le conteneur SLEE permet
au runtime de l’application de bénéficier de nombreuses informations et
permet au conteneur SLEE d’avoir une persistance des SBB de manière
transparente. Cette technique est empruntée des spécifications des EJB.
- L’interface du contexte d’activité qui sera utilisé pour les actions du timer
(org.mobicents.slee.examples.wakeup.WakeUpSbbActivityContextInterface)
- La liste d’évènements auquel le SBB souhaite des notifications :
o SIP MESSAGE event (javax.sip.message.Request.MESSAGE) Cet
évènement est marqué en tant qu’évènement initial, cela signifie que
les évènements MESSAGE reçus par le service WakeUp vont créer
une nouvelle instance du SBB racine qui aura son propre contexte
d’activité associé. Dans notre cas, nous aurons une seule instance de
ce SBB lors du cycle de vie du service.
o SLEE Timer event (javax.slee.facilities.TimerEvent). C’est l’évènement
qui va initier un message wake up à renvoyer à l’UA emetteur.
- Une référence au SIP Ressource Adaptor (jain-sip). Le SBB utilisera ce SIP
RA pour interragir avec l’UA.
WakeUpSBB.java
Cette classe java possède une douzaine de méthodes, nous allons analyser celles
qui sont spécifiques au service déployé et qui sont différentes d’autres services qui
utilisent SIP.
public void onMessageEvent(javax.sip.RequestEvent event,
ActivityContextInterface aci)
Cette méthode est appelée quand une requête MESSAGE est reçue par le SLEE.
Dans un premier temps, la méthode accuse réception du message à l’UA. Elle utilise
le contexte d’activité créer par le serveur pour interagir avec le client pour encapsuler
une réponse SIP.
// Notifiy the client that we received the SIP MESSAGE request
ServerTransaction st = (ServerTransaction) aci.getActivity();
Response response = messageFactory.createResponse(Response.OK,
request);
st.sendResponse(response);
Dans un second temps, la méthode crée un jeton (NullActivity) et l’associe à
l’instance courante du SBB. Ce même jeton sera alors envoyé au timer quand un
appel à la méthode du SBB onTimerEvent() sera planifiée.
//
CREATE A NEW NULL ACTIVITIY
NullActivity timerBus =
this.nullActivityFactory.createNullActivity();
// ATTACH ITSELF TO THE NULL ACTIVITY
// BY USING THE ACTIVITY CONTEXT INTERFACE
ActivityContextInterface timerBusACI =
this.nullACIFactory.getActivityContextInterface(timerBus);
timerBusACI.attach(sbbContext.getSbbLocalObject());
Ensuite, le code analyse le message entrant et en extrait le temps en seconde et le
corps du message.
// PARSING THE MESSAGE BODY
String body = new String(request.getRawContent());
int i = body.indexOf(" ");
String timerValue = body.substring(0,i);
int timer = Integer.parseInt(timerValue);
String bodyMessage = body.substring(i+1);
Puis le SLEE créer une vue sur le contexte d’activité du jeton que l’on vient de
déclarer (timerBusACI) :
// SETTING VALUES ON THE ACTIVITY CONTEXT
// USING THE SBB CUSTOM ACI
WakeUpSbbActivityContextInterface myViewOfTimerBusACI =
this.asSbbActivityContextInterface(timerBusACI);
En utilisant le WakeUpSbbActivityContextInterface, on enregistre le corps du
message dans le jeton (NullActivity) créer pour cela.
myViewOfTimerBusACI.setBody(bodyMessage);
Ensuite, on recherche l’adresse de l’UA pour renvoyer le wake up call :
// The From field of each SIP MESSAGE has the UA Address of Record
(logical address),
// which can be mapped to a current physical contact address. The
mapping is provided by the LocationService,
// which works together with the SIP Registrar service.
FromHeader fromHeader =
(FromHeader)request.getHeader(FromHeader.NAME);
Address fromAddress = fromHeader.getAddress();
URI contactURI =
findLocalTarget(fromHeader.getAddress().getURI());
Address contactAddress = addressFactory.createAddress(contactURI);
ContactHeader contactHeader =
headerFactory.createContactHeader(contactAddress);
On enregistre le contact dans le contexte d’activité du jeton :
myViewOfTimerBusACI.setContact(contactHeader);
Pour finir, un timer est crée et est planifié en utilisant le SLEE timer facility. Le jeton
est alors lié au timer afin qu’il soit récupéré facilement par la suite.
// SETTING THE TIMER BY USING THE VALUE
// IN THE SIP MESSAGE BODY
TimerOptions options = new TimerOptions();
options.setPersistent(true);
this.timerFacility.setTimer(timerBusACI,
null,
System.currentTimeMillis()+timer*1000,
options);
public void onTimerEvent(TimerEvent? event, ActivityContextInterface?
aci)
Lorsque le timer arrive à sa fin, le SLEE timer facility génère un évènement de type
timer. Tous les SBB qui sont liés au jeton (NullActivity) et qui étaient associés au
timre vont recevoir cet évènement.
Cette méthode extrait tout simplement les données contact et body du jeton …
// RETRIEVING STORED VALUE FROM THE ACTIVITY CONTEXT INTERFACE
WakeUpSbbActivityContextInterface myViewOfACI =
this.asSbbActivityContextInterface(aci);
Header contact = myViewOfACI.getContact();
String body = myViewOfACI.getBody();
... et les passe en argument à la méthode sendWakeCall.
// SENDING BACK THE WAKE UP CALL
sendWakeUpCall(contact, body);
private void sendWakeUpCall(Header toContact, String body)
Cette méthode permet de composer un nouveau SIP MESSAGE addressé à
toContact avec le texte body et l’envoie.
Notons que pour envoyer le message à l’UA, la méthode utilise le fournisseur de SIP
RA comme cela est décrit dans le sbb-jar.xml.
Le fournisseur SIP est référencé lorsque le conteneur SLEE met en place le contexte
SBB (voir serSbbContext()).
// Getting JAIN SIP Resource Adaptor interfaces
fp = (SipFactoryProvider)
myEnv.lookup("slee/resources/jainsip/1.1/provider");
provider = fp.getSipProvider();
Le fournisseur (provider) est utilisé plus tard dans la méthode sendWakeUpCall()
pour établir une transaction SIP avec l’UA et envoyer un message :
ClientTransaction ct = provider.getNewClientTransaction(req);
ct.sendRequest();
Remarques
Le service Wake Up Call montre comment créer un simple service SIP en utilisant le
modèle de programmation JAIN SLEE. Il nous a permit de bien comprendre les
bases du fonctionnement d’un programme de ce type. Le chapitre qui vient d’être
présenté est inspiré des explications présentes sur le site de mobicents mais a été
adapté et traduit à ce que nous avons mis en œuvre durant notre projet.
Conclusion
Les objectifs fixés pour ce projet n’ont pas tous été remplis : nous avons réussi à
mettre en place une plateforme JAIN SLEE, y déployer des exemples et les faire
fonctionner. Nous n’avons pas créé de composant de traitement d’appel mais les
nombreux exemples que nous avons mis en œuvre et la bonne compréhension du
code nous porte à croire que la création de ce composant est à notre portée après
un temps d’analyse et de compréhension non négligeable. En effet, la mise en place
d’exemples simples comme le service Wake Up nous a permis d’appréhender des
programmes plus complexes.
JAIN SLEE est une nouvelle technologie qui va permettre un rapprochement entre le
monde des télécommunications et celui de l’Internet afin de créer de nouveaux
services appelés NGS (Next Generation Service). Il aura été très intéressant pour
nous durant ces deux semaines de projet de découvrir les nombreuses possibilités
d’utilisation et le fonctionnement d’une technologie porteuse d’avenir.
Ce rapport avait pour but de
Nous conseillons donc de bien lire les documentations et les tutoriaux auxquels nous
faisons référence dans la bibliographie
Nous retrouverons peut être dans quelques années
Il aura été très ontLes services qui
Références et bibliographie
http://wiki.java.net/bin/view/Communications/MobicentsExamplesWakeUp
Annexes