Sc´ enario d’impl´ ementation

In document L UNIVERSITÉ BORDEAUX I (Page 123-132)

CHAPITRE

8.3 Impl´ ementation

8.3.1 Sc´ enario d’impl´ ementation

112

Chapitre 8. Impl´ementation dans un environnement IP de nouvelle g´en´eration

!

"#!#$%!

!

"#$!

!

"#$"$%!

!

"##!

!

"#$%$&!

!

"#$%$&!

!

"#$!%&'!

#()*+,!

Figure 8.2 – Infrastructure IMS open source

8.3. Impl´ementation 113

8.3.1.2 Le graphe causal utilis´e pour le service VoIP

L’impl´ementation de l’algorithme est bas´ee sur la plateforme IMS pr´esent´ee dans le chapitre4et la section8.3.1.1ci-dessus. Le graphe causal sur lequel est bas´e cette impl´ementation diff`ere de celui pr´esent´e dans l’article [Lu et al.2010]. En effet, le graphe causal de l’article (voir la Figure 8.3) se base sur un diagnostic global qui regroupe les composants suivants : les bases de donn´ees HSS et SLF et un serveur d’application.

Alarm unknown IMPU in SLF IMPU unknown

in SLF

SLF no synchronizaton

IMPU barring in SLF Client barring

in SLF Unknown client

in SLF(No account)

Resynchroni -zation SLF

Unknown client in HSS (No account)

Client Barring in HSS

Alarm unknown IMPU in AS IMPU unknown

in AS

AS no synchronizaton

IMPU barring in AS Client barring in Unknown client in AS

AS(No account)

Resynchro-nization AS Test of

unknown client

Test of client barring Client No payment No subscriber

Figure 8.3 – Le graphe causal global

Cependant, l’´etude du cœur du r´eseau OpenIMS, nous a conduit `a la conclusion qu’il n’est pas possible d’int´egrer la base de donn´ees SLF dans notre architecture.

Nous avons donc envisag´e de restreindre ce graphe causal `a seulement deux compo-sants : HSS et AS. Il fallait ainsi changer l’alarme «Unknown IMPU in SLF» par l’alarme «Unknow IMPU in HSS». Le nouveau graphe causal est le suivant :

114

Chapitre 8. Impl´ementation dans un environnement IP de nouvelle g´en´eration

Alarm unknown IMPU in HSS

IMPU barring in HSS Unknown client

in HSS(No account)

Unknown client in HSS (No account)

Client Barring in HSS

Alarm unknown IMPU in AS IMPU unknown

in AS

AS no synchronizaton

IMPU barring in AS Client barring in

AS Unknown client in

AS(No account)

Resynchro-nization AS Test of

unknown client

Test of client barring Client No payment No subscriber

Figure 8.4 – Le graphe causal restreint `a HSS et AS

Cette solution a ´egalement ´et´e abandonn´ee car nous ne trouvions aucun sc´enario permettant de coller `a cette mod´elisation. En effet, les deux alarmes ne peuvent pas ˆetre d´eclench´ees en mˆeme temps. Le seul sc´enario permettant de d´eclencher l’alarme«Unkown IMPU in HSS»est d’appeler une personne qui n’existe pas dans la base de donn´ees. L’appel sera de toute fa¸con termin´e avant d’atteindre le serveur d’application.

Un autre probl`eme ´egalement rencontr´e ´etait celui du d´eclenchement de l’alarme

«Unkown IMPU in AS». En effet, aucun service de VoIP n’est bloquant au niveau du serveur d’application. Les services comme Voice Mail,call transfer,push to talk, click to call ne d´eclenchent pas d’alarmes lorsque le client veut passer un appel alors qu’il n’est pas abonn´e `a un de ces services.

La solution trouv´ee pour d´eclencher cette alarme est de concevoir un service VoIP qui n´ecessite une liste d’utilisateurs associ´ee au serveur d’application. Ainsi, le serveur d’application utilise son propre serveur d’authentification pour autoriser l’utilisateur et lui offrir des services adapt´es `a son profil. Un AS concentre toute l’intelligence de services comme le serveur d’appels, de messagerie instantan´ee, de

8.3. Impl´ementation 115

serveur vid´eo, etc. Chaque serveur peut avoir son profil de souscription, si l’AS ne connait pas l’utilisateur dans sa base de donn´ees, il ne peut pas lui offrir de service et sa demande de service est rejet´ee.

Cette solution nous a amen´es `a adapter le graphe causal pour notre impl´ emen-tation (voir la figure 8.5).

Alarm unknown IMPU in AS1 IMPU unknown

in AS1

AS1 No synchronizaton

IMPU barring in AS1 Client barring

in AS1 Unknown client

in AS1 (No account)

Unknown client in HSS (No account)

Client Barring in HSS

Alarm unknown IMPU in AS2 IMPU unknown

in AS2

AS2 No synchronizaton

IMPU barring in AS2 Client barring in AS2 Unknown client

in AS2 (No account)

Resynchro-nization AS2 Test of

unknown client

Test of client barring Client No payment No subscriber

Resynchro-nization AS1

HSS diagnostiqueur

AS1 diagnostiqueur

AS2 diagnostiqueur

Figure 8.5 – Le graphe causal utilis´e

Dans le cadre de l’architecture autonome que nous avons pr´esent´ee au chapitre 7, la mise `a jour du graphe causal est r´ealis´ee par le gestionnaire autonome de haut niveau. Celui-ci doit ˆetre capable de modifier le graphe causal en fonction des ressources disponibles (absence de la base de donn´ees de SLF dans notre cas).

Un changement a aussi ´et´e effectu´e au niveau des liens de causalit´e de ce graphe.

Le lien entre les nœuds«IMPU barring in AS»et«Alarm unknown IMPU in AS»a

´

et´e remplac´e par un lien de type«possible». En fait, un client peut ˆetrebarringpour un service sans pour autant ˆetre la cause de d´eclenchement de l’alarme d’«Alarm unknown IMPU in AS».

Un diagnostiqueur sera donc install´e au niveau du HSS. Un autre sera ex´ecut´e sur chaque serveur d’application (AS SIP) (voir la figure 8.5). Nous pouvons soit

116

Chapitre 8. Impl´ementation dans un environnement IP de nouvelle g´en´eration

utiliser deux serveurs d’application diff´erents ou bien deux services diff´erents ayant chacun sa propre base de donn´ees.

Le d´eveloppement `a ´et´e fait avec le langage Java. Un graphe causal est g´en´er´e par un fichier Dot1 comme pr´esent´e dans l’annexeA.

8.3.1.3 D´eploiement du service VoIP

Le service de VoIP que nous avons choisi pour notre impl´ementation, nomm´e CallControl, permet de contrˆoler la dur´ee d’appels pour les personnes qui sont abon-n´ees `a ce service et qui sont pr´esents dans la base de donn´ees du serveur d’applica-tion.

Le d´eveloppement de ce service est assur´e par la conception d’uneSip Servlet qui sera d´eploy´ee dans notre serveur d’application Mobicents. La logique de ce service est assur´ee par l’impl´ementation des m´ethodes doInvite etdoBye.

Le d´eploiement de ce service se fait directement par l’interface administrative de Mobicents2. Cette interface est pr´esent´ee dans la figure 8.6.

Figure 8.6 – Interface administrative de Mobicents

Il est aussi possible de g´erer l’ensemble des services `a d´eployer sur un mˆeme 1. http ://www.graphviz.org/

2. http ://localhost :8001/admin-console/.

8.3. Impl´ementation 117

serveur d’application3. L’interface de gestion est pr´esent´ee dans la figure 8.7.

Figure 8.7 – Interface de gestion des Sip Servlets deMobicents

8.3.1.4 Configuration du profil de service

A chaque usager IMS est associ´e un profil d’usager dans le HSS. Un profil d’usager consiste en un ensemble de profils de service. Le profil de service est une collection d’informations sp´ecifique `a l’utilisateur, stock´ee en permanence dans le HSS. Il est transf´er´e du HSS `a un S-CSCF allou´e `a l’aide de deux op´erations user datahandling operations:Server-Assignment Answer(SAA) etPush-Profile-Request (PPR). Il est d´efini dans un document XML, dans un AVP Diameter.

Un profil de service est compos´e d’une liste de iFC (initial Filter Criteria).

Un crit`ere de filtrage (voir la Figure 8.8) est une information statique correspon-dant `a une souscription d’un usager `a un service du domaine IMS. Il comprend les informations suivantes :

– AS address : Adresse du serveur d’application `a contacter (adresse SIP).

– Priority : Priorit´e du crit`ere de filtrage indiquant sa position dans la liste.

3. http ://localhost :8001/sip-servletmanagement/org.mobicents.servlet.management.Sip ServletsManagement/SipServletsManagement.html

118

Chapitre 8. Impl´ementation dans un environnement IP de nouvelle g´en´eration

– Trigger Point : Un Trigger Point est compos´e de 1 `a N instances de SPT (Service Point Trigger). Des SPT peuvent ˆetre combin´es `a l’aide d’op´erateurs logiques (AND, OR, NOT, etc.).

– Default handling : Correspond `a la prise en charge par d´efaut si l’entit´e S-CSCF n’arrive pas `a contacter l’AS.

– Optionnal Service Information: Information de service facultative rajou-t´ee au contenu de la m´ethode SIP avant qu’elle ne soit achemin´ee `a l’AS.

Initial  Filter  Criteria         Priority:  integer  

Pro,ilePartIndicator:  enumerated  

Trigger  Point   ConditionTypeCNF:  boolean    

Service  Point  Trigger   Condition  Negated:  boolean   Group:  list  of  integer    

Application  Server   ServerName:  Sip  URL   Default  Handling:  enumerated  

Service  Information   ServiceInfo:string  

Figure 8.8 – Crit`eres de filtrage initiaux (IFC)

Le profil de service est obtenu par l’entit´e S-CSCF aupr`es du HSS `a travers l’interfaceCx lorsque l’usager s’enregistre au sous-syst`eme IMS.

Lorsqu’une entit´e S-CSCF re¸coit une requˆete SIP concernant un usager donn´e, elle ´evalue les crit`eres de filtrage associ´es `a cet usager un `a un selon leur ordre de priorit´e. Si la requˆete SIP v´erifie le crit`ere de filtrage, l’entit´e S-CSCF achemine la requˆete SIP au serveur d’application correspondant.

Si l’entit´e S-CSCF ne peut joindre le serveur d’application (AS) associ´e `a un crit`ere de filtrage (i.e, Serveur d’application hors service), elle applique une prise en charge par d´efaut, indiqu´ee dans le crit`ere de filtrage par le param`etre ”Default call handling” dont la valeur peut ˆetre :

– Continue, continuer `a analyser les crit`eres de filtrage de plus basse priorit´e dans la liste.

– Release, abandonner l’analyse des autres crit`eres de filtrage et lib´erer le dialogue.

8.3. Impl´ementation 119

Avec OpenIMS Core, ce profil de service peut ˆetre configur´e directement sur l’interface administrative du HSS. On cr´ee donc un profil pour notre service et on d´efinit la liste de ses abonn´es. Le profil que nous avons cr´ee est illustr´e dans la figure 8.9.

Figure 8.9 – Profil de service pour le service d´eploy´e sur Mobicents

120

Chapitre 8. Impl´ementation dans un environnement IP de nouvelle g´en´eration

In document L UNIVERSITÉ BORDEAUX I (Page 123-132)