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