Mise en place d’une plateforme de formation IMS

GAGLO Kokou Mise en place d’une plateforme de formation IMS

1 1

A A A A mon oncle Isaac Jogues GAGLO

DEDICACES DEDICACES

GAGLO Kokou Mise en place d’une plateforme de formation IMS 2

Je voudrais avant toutes choses rendre grâce à l’Eternel sans qui ce travail ne saurait

aboutir. Que son Saint Nom soit glorifié pour les siècles sans fin.

J’adresse également mes sincères remerciements à :

� Son Excellence Isaac Jogues GAGLO, Evêque d’Aneho (TOGO) ;

� Mon père, Feu Jean Marie Koffi GAGLO ;

� Ma mère Patience Ayéwa LODONOU ;

� Docteur Samuel OUYA notre professeur encadreur et maitre de stage, pour sa

rigueur, sa disponibilité et ses nombreuses recommandations ;

� Tous les professeurs de l’ESMT et de l’ESP qui ont assuré ma formation ;

� Tout le personnel de Réseaux et Techniques Numériques ;

� Mon groupe de travail (JACAT team) composé de Terence VIGAN, Coura SY,

Akofa AMEGANDJIN, Marthe Eva NDIAYE ;

� Ma famille, GAGLO, LODONOU, EKLU, KOUTOGLO ;

� Toute la Communauté Arbre de Vie Divine de Dakar ;

� Aux Sœurs Aimée de Jésus DAMAWUZAN, Marie Delphine KALI et Gildas

PLAKOO ;

� Aux Pères Georges SOKPO et Patrick GABA ;

� Ma promotion téléinformatique IGTT2 2009/2011

Toutes les personnes qui de près ou de loin, ont contribué à la réalisation de ce document

MERCI A TOUS!

REMERCIEMENTS


PRESENTATION DE l’ESMT

L’Ecole Supérieure Multinationale des Télécommunications (ESMT) est une institution

multinationale qui accueille 17 nationalités en formation initiale et continue liée au Sénégal

par un accord de siège qui lui confère un statut diplomatique.

L’ESMT recouvre plusieurs domaines dont :

les diplômes de Technicien Supérieur :

• diplôme de technicien supérieur en télécommunications : spécialités

technique et commerciale ;

• diplôme de technicien supérieur en téléinformatique : en partenariat avec

l’Ecole Supérieure Polytechnique de Dakar ;

• diplôme de technicien supérieur en réseaux et données ;

les diplômes d’Ingénieur :

• diplôme d’ingénieur des travaux télécoms (IGTT) : spécialités technique et

commerciale ;

• diplôme d’ingénieur téléinformatique, en partenariat avec l’ESP de Dakar ;

• diplôme d’ingénieur de conception ;

les diplômes Mastères :

• mastère en gestion des télécommunications ;

• mastère en réseaux télécoms ;

• mastère en téléinformatique en partenariat avec l’ESP de Dakar ;

les certifications :

• CISCO ;

• GVF ;

• FOA ;

• NSOFT ;

• Alcatel-Lucent ;

Elle est en cours de le devenir pour Oracle.

AVANT-PROPOS


PRESENTATION DE L’ESP

le département Génie Chimique ;

le département Génie Civil ;

le département Génie Electrique ;

le département de Gestion ;

le département Génie Mécanique ;

le département Génie Informatique.

Soucieux de la demande des entreprises évoluant dans le domaine de l’informatique et

des télécommunications, l’Ecole Supérieure Polytechnique (ESP) et l’Ecole Supérieure

Multinationale des Télécommunications (ESMT) ont mis en place une formation d’ingénieur

Technologue en Téléinformatique.

Dans le cadre de la formation qui s’étale sur deux ans, l’étudiant devra effectuer un

stage de quatre à six mois dans une entreprise ou un laboratoire ou il mettra à profit ses acquis

théoriques à l’issu duquel il devra présenter un mémoire de fin de cycle qui est le fruit du

travail effectué dans la structure d’accueil.

C’est dans cette optique que nous avions effectué un stage de 06 mois à Réseaux et

Techniques Numériques qui nous a value le thème : Mise en place d’une plateforme de

formation IMS.


AVANT-PROPOS ................................................................................................................ 3

Table des Matières ........................................................................................................... 5

Sigles et Abréviations ........................................................................................................ 8

Table des Figures .............................................................................................................. 9

Table des Tableaux ......................................................................................................... 12

Introduction .................................................................................................................... 13

1. ................................................................................................ PRESENTATION GENERALE

....................................................................................................................................... 14

1.1. Présentation de l’entreprise Réseaux et Technique Numérique ......................... 14

1.1.1. Mission de RTN .......................................................................................... 14

1.1.2. Domaine d’activité ..................................................................................... 14

1.1.3. Organigramme de RTN ............................................................................... 16

1.2. Présentation du sujet ........................................................................................ 16

1.3. Problématique .................................................................................................. 16

1.3.1. Objectifs ..................................................................................................... 17

2. .......................................................................... ETUDE DE L’IP MULTIMEDIA SUBSYSTEM

....................................................................................................................................... 18

2.1. Architecture du réseau IMS ............................................................................... 18

2.2. Description des entités IMS et leurs fonctionnalités ........................................... 20

2.2.1. la gestion de session et le routage (CSCF) .................................................... 21

2.2.1.1. Proxy Call Session Control Function (P-CSCF) ........................................... 22

2.2.1.2. Interrogating Call Session Control Function (I-CSCF) ................................. 23

2.2.1.3. Serving Call Session Control Function (S-CSCF) ......................................... 24

2.2.1.4. Emergency Call Session Control Function (E-CSCF) ................................... 25

2.2.2. HSS (Home Subscriber Server) : la base de données .................................... 25

2.2.3. MRF (Multimedia Resource Function) ......................................................... 27

2.2.4. BGCF (Breakout Gateway Control Function) ................................................ 27

2.2.5. IMS-MGW, MGCF et SGW ........................................................................... 28

2.2.5.1. La passerelle de flux multimédia IMS-MGW (IMS-Media GateWay) ......... 28

2.2.5.2. Le contrôleur de passerelle MGCF (Media Gateway Control Function) ..... 29

2.2.5.3. La passerelle de signalisation SGW (Signaling GateWay) .......................... 29

2.2.6. TrGW et IMS-ALG ....................................................................................... 30

2.2.7. Les serveurs d’application .......................................................................... 31

2.3. Les principaux protocoles et leurs interfaces ..................................................... 31

Table des Matières


2.3.1. Les principaux protocoles ........................................................................... 31

2.3.2. Les interfaces ............................................................................................. 32

2.3.2.1. Interface Gm ........................................................................................... 33

2.3.2.2. Interface Mw .......................................................................................... 33

2.3.2.3. Interface ISC (IMS Service Control) .......................................................... 34

2.3.2.4. Interface Cx ............................................................................................ 34

2.3.2.5. Interface Sh ............................................................................................ 35

2.3.2.5.1. La localisation .................................................................................... 35

2.3.2.5.2. La gestion des données des utilisateurs .............................................. 35

2.3.2.5.3. L’authentification des utilisateurs ...................................................... 36

2.3.2.5.4. Gestion des données .......................................................................... 36

2.3.2.5.5. Souscription/Notification ................................................................... 36

2.4. Les identités IMS ............................................................................................... 37

2.5. Enregistrement d’un terminal dans le réseau ..................................................... 38

2.6. La fourniture de services dans l’IMS .................................................................. 39

2.6.1. Le profil utilisateur ..................................................................................... 40

2.6.2. Le profil de service ..................................................................................... 40

2.6.2.1. L'identification publique ......................................................................... 41

2.6.2.2. La politique media .................................................................................. 41

2.6.2.3. Le déclenchement des services ................................................................ 41

3. ............................................................................................................ LES SERVICES IMS

....................................................................................................................................... 43

3.1. Présence ........................................................................................................... 43

3.1.1. Le service de présence dans l’IMS ............................................................... 43

3.1.2. Publication des informations de présence ................................................... 45

3.1.3. Souscription au service de présence ........................................................... 46

3.2. Gestion de groupe ............................................................................................. 47

3.2.1. XML Configuration Access Protocol ............................................................. 47

3.2.2. La liste de ressources .................................................................................. 48

3.3. Push to Talk Over Cellular.................................................................................. 50

3.3.1. Architecture du PoC.................................................................................... 51

3.3.1.1. Le serveur PoC ........................................................................................ 52

3.3.1.2. Le client PoC ........................................................................................... 53

3.4. IPTV .................................................................................................................. 53

3.4.1. Architecture de l’IPTV ................................................................................. 54

3.4.2. Description de la plateforme IPTV basée sur l’IMS...................................... 54

4. MISE EN PLACE DE LA PLATEFORME IMS ................................................................ 56

4.1. Architecture de la plateforme ............................................................................ 56


4.2. Présentation et installation des logiciels utilisés ................................................ 56

4.2.1. OpenIMSCore ............................................................................................. 56

4.2.1.1. Les CSCFs ................................................................................................ 58

4.2.1.1.1. Le P-CSCF ........................................................................................... 58

4.2.1.1.2. L’I-CSCF .............................................................................................. 58

4.2.1.1.3. Le S-CSCF ........................................................................................... 59

4.2.1.2. Le HSS ..................................................................................................... 59

4.2.1.3. Installation d’OpenIMSCore .................................................................... 60

4.2.2. OPENSIPS ................................................................................................... 61

4.2.2.1. Installation et configuration .................................................................... 61

4.2.2.2. Création de l’AS de présence au niveau du HSS ........................................ 61

4.2.2.3. Simulation du service de présence .......................................................... 63

4.2.3. OPENXCAP ................................................................................................. 65

4.2.3.1. Installation et configuration .................................................................... 66

4.2.3.2. Simulation du service de mobilité............................................................ 67

4.2.4. La Video à la Demande (VoD) ..................................................................... 70

4.2.4.1. Serveur media avec VLC media player ..................................................... 70

4.2.4.1.1. Installation et configuration ............................................................... 70

4.2.4.1.2. Simulation des flux RTSP .................................................................... 70

4.2.4.2. IPTV AS avec UCT Advanced IPTV ............................................................ 71

4.2.4.2.1. Installation et configuration ............................................................... 71

4.2.4.2.2. Création de l’AS VoD au niveau du HSS ............................................... 71

4.2.4.2.3. Simulation du service VoD .................................................................. 73

CONCLUSION .................................................................................................................. 75

BIBLIOGRAPHIE || WEBOGRAPHIE .................................................................................. 76

ANNEXES ........................................................................................................................... i

A.1 Mise en place du plan de contrôle IMS et figures de l’interface FHoSS ......................... iv

A.2 Installation d’OPENSIPS ............................................................................................. vii

A.3 Installation d’ OPENXCAP .............................................................................................x

A.3.1 Installation ............................................................................................................x

A.3.2 Configuration ....................................................................................................... xi

A.4 Installation du media server VLC ................................................................................ xii

A.5 Installation de UCT Advanced IPTV ............................................................................ xii

A.6 Installation de l’outil Siremis ..................................................................................... xiii

A.7 Installation et paramétrage des clients IMS ............................................................... xiv

A.8 Quelques captures Wireshark des flux échangés sur notre réseau IMS ....................... xvi


Nous présentons ici certains sigles et abréviations que nous utiliserons dans le document.

Abréviations Descriptions

3GPP Third Generation Partnership Project

AS Application Server

CS Circuit Switched

CSCF Call Session Control Function

HSS Home Subscriber Server

GPRS General Packet Radio Service

HTTP Hypertext Transfer Protocol

I-CSCF Interrogating Call Session Control Function

IFC Initial Filter Criteria

IMS IP Multimedia Subsystem

IP Internet Protocol

MGCP Media Gateway Control Protocol

MRFP Media Resource Function Processor

NGN Next Generation Networks

P-CSCF Proxy Call Session Control Function

RTP Real Time Transport Protocol

S-CSCF Serving Call Session Control Function

SER SIP Express Router

SIP Session Initiation Protocol

SLF Subscriber Locator Function

UA User Agent

UE User Equipment

URI Universal Resource Identifier

VoIP Voice over IP

XML eXtensible Markup Language

Sigles et Abréviations


Figure 1.1 : Organigramme de RTN ................................................................................. 16

Figure 2.2 : Les serveurs CSCF .......................................................................................... 21

Figure 2.4 : Structure du HSS ........................................................................................... 26

Figure 2.5 : Interfonctionnement avec le RTC ................................................................... 28

Figure 2.6 : Les serveurs IMS-ALG et TrGW ...................................................................... 30

Figure 2.7 : Les interfaces dans l’architecture IMS ............................................................ 32

Figure 2.8 : Processus d’enregistrement d’un terminal ..................................................... 39

Figure 2.9 : Structure d’un profil utilisateur ..................................................................... 40

Figure 2.10 : Structure d'un IFC ........................................................................................ 41

Figure 3.1 : Aperçu de la présence ................................................................................... 43

Figure 3.2 : Architecture de la présence ........................................................................... 45

Figure 3.3 : Publication de présence ................................................................................ 45

Figure 3.4 :Souscription aux informations de présence .................................................... 46

Figure 3.5 : Les opérations XCAP ..................................................................................... 48

Figure 3.6 : Exemple de flux de souscription avec RLS ...................................................... 49

Figure 3.8 : Exemple de liste de ressources ...................................................................... 50

Figure 3.9 : Push to Talk Over Cellular ............................................................................. 51

Figure 3.10 :Architecture du PoC ..................................................................................... 52

Figure 3.11 :Architecture du server PoC ........................................................................... 53

Figure 3.12 : Architecture de réseaux convergents offrant les services d’IPTV ................... 54

Figure 4.1 : Architecture de la plateforme ....................................................................... 56

Figure 4.2 : Architecture de l’OpenIMSCore ..................................................................... 57

Figure 4. 3: Open IMS Proxy-CSCF .................................................................................... 58

Figure 4. 4 : Open IMS Interrogating-CSCF ....................................................................... 59

Figure 4. 5 : Open IMS Serving-CSCF ................................................................................ 59

Figure 4. 6 : Open IMS HSS .............................................................................................. 60

Figure 4.7 : Paramétrage du Service Profile de présence ................................................. 61

Figure 4.8 : Paramétrage de l’Application Server de présence .......................................... 62

Table des Figures


Figure 4.9 Le Trigger Point de présence ........................................................................... 62

Figure 4.10 : Paramétrage de l’Initial Filter Criteria de présence ...................................... 63

Figure 4.11 : L’utilisateur Alice souscrit aux informations de présence de Bob .................. 63

Figure 4.12 : L’utilisateur Bob souscrit aux informations de présence d’Alice .................... 64

Figure 4.13 : Liste des Watchers ...................................................................................... 65

Figure 4.14 : Liste des Presentities ................................................................................... 65

Figure 4.15 : SIP SIMPLE Server ....................................................................................... 66

Figure 4.16 : Liste de contact de Samuel connecté sur un poste 1 ..................................... 67

Figure 4.17 : Liste de contact de Samuel connecté un poste 2 .......................................... 68

Figure 4.18 : Liste de contact des utilisateurs stockée par le XMDS .................................. 69

Figure 4.19 : Détails du fichier properties-resource-list.xml de Samuel ............................. 69

Figure 4.20 : Utilisation du navigateur firefox pour visualiser la vidéo référencée par ‘clip’

....................................................................................................................................... 70

Figure 4.21 : Flux vidéo précédent ouvert avec le lecteur totem de Linux .......................... 70

Figure 4.22 : Paramétrage du Service Profile de l’IPTV .................................................... 71

Figure 4.23 : Paramétrage de l’Application Server de l’IPTV ............................................. 72

Figure 4.24 : Paramétrage du Trigger Point de l’IPTV ....................................................... 72

Figure 4.25 : Paramétrage de l’Initial Filter Criteria de l’IPTV ........................................... 73

Figure 4.26 : Demande du service IPTV par l’utilisateur James ......................................... 74

Figure A.1.1 : Interface de connexion au HSS .................................................................... vii

Figure A.1.2 : Page d’accueil du HSS ................................................................................. vii

Figure A.6.1 : Interface web d’installation de Siremis ....................................................... xiv

Figure A.7.1: UCTIMSCLIENT (Ubuntu 8.04)....................................................................... xv

Figure A.7.2: MERCURO IMS CLIENT (Windows XP) .......................................................... xv

Figure A.7.3 : myMOSTER ................................................................................................ xvi

Figure A.8.1 : Capture générale de tous les appels VoIP dans le réseau ............................ xvi

Figure A.8.2 : Enregistrement de Bob ............................................................................. xvii

Figure A.8.3 : Bob appelle Alice ...................................................................................... xvii

Figure A.8.4 : Analyse graphique de l’appel de Bob vers Alice ........................................ xviii

Figure A.8.5 : Chat entre Bob et Alice ............................................................................ xviii

Figure A.8.6 : Utilisation du service VoD de James ......................................................... xviii


Figure A.8.7 : Analyse graphique de la demande VoD par James ...................................... xix


Tableau 2.1: Les interfaces IMS ......................................................................................... ii

Tableau 2.1 (suite): Les interfaces IMS ............................................................................... ii

Tableau 2.2: Commandes Cx ............................................................................................ iii

Tableau 2.2 (suite): Commandes Cx ................................................................................... iv

Tableau 2.3 : Commandes Sh............................................................................................. iv

Table des Tableaux


Le monde de la télécommunication est en train de subir un changement fondamental et les éléments catalyseurs de ce changement sont les technologies d’Internet. L’utilisation du protocole IP (Internet Protocol) pour la voix, les données, le multimédia est en train d’entrainer la convergence dans les réseaux ; que ce soit le fixe, le mobile, le sans fil et autres.

La convergence des réseaux est le moyen par lequel les opérateurs faciliteront à leurs clients un accès facile à leurs services et leurs proposeront des applications innovantes (VoIP, vidéoconférence, messagerie instantanée, jeux multi-joueurs,…). C’est ce défi de convergence entre fixe et mobile que relève la technologie IMS (IP Multimedia Subsystem) en permettant d’être joignable où que l’on soit, sur un ordinateur comme sur un mobile ou autre terminale bénéficiant de l’étendue de l’offre multimedia.

C’est ainsi que RTN, intervenant dans le domaine des télécoms, anticipe l’avènement effectif de la convergence en mettant en place une plateforme de formation IMS qui ciblera non seulement les opérateurs qui migreront leurs réseaux vers cette technologie mais également toute autre structure s’y intéressant.

Dans le but de restituer le travail effectué, ce document est divisé en quatre (4) chapitres. Le premier chapitre présentera la structure d’accueil (RTN), le second exposera la technologie IMS. Le troisième quant présentera les services IMS, ensuite viendra enfin le quatrième chapitre qui détaillera la séquence de déploiement de la plateforme.

Introduction


1. PRESENTATION GENERALE

Ce chapitre fera l’objet de présentation de la structure Réseaux et Techniques Numériques où nous avons effectué notre stage. Il définit également le contexte de notre sujet, sa problématique ainsi que ses objectifs.

1.1. Présentation de l’entreprise Réseaux et Technique Numérique

Réseaux et Techniques Numériques (R.T.N) est une société dirigée par une équipe de

professionnels qualifiés, spécialisée en logiciels libres et centrée sur les services

informatiques, techniques numériques et télécommunications.

Cette société offre une gamme de formations se basant sur des supports de cours, fruits de

recherches approfondies. Ces supports testés et avérés permettent aux apprenants d’être

aussitôt opérationnels.

1.1.1. Mission de RTN

La mission de RTN vise à accroître la compétitivité de ses clients par la valorisation

des composantes informatiques, logicielles et réseaux constituants le système d'information de

ces derniers. Cela leur confère des gains importants en produisant plus et mieux à budget

réduit, grâce à l’exploitation de la puissance des logiciels libres existants et ceci, sans rupture

des cycles d'exploitation de service de ces entreprises et sans remise en cause

organisationnelle. Leur principal objectif est de conseiller et de former le personnel des

entreprises qui veulent disposer des logiciels libres et adaptés à leurs besoins minimisant ainsi

les coûts d' investissements en réseaux informatiques tout en leur apportant une sécurité

avancée.

1.1.2. Domaine d’activité

La société RTN offre une palette de solutions dans le domaine de la technologie de

l’information et de la communication. Les solutions de RTN sont orientées Open Source et

réalisées selon les besoins et l'exploration des opportunités d'entreprise. Elles répondent par

conséquent aux problèmes réels.

RTN met également un accent particulier sur les suites bureautiques de Linux

(traitement de texte, tableurs et logiciels de présentation de conférence et de traitement

CHAPITRE 1


d’images), le développement des services à valeurs ajoutées, les serveurs sécurisés libres

(DNS, APACHE, DHCP, LDAP, SENDMAIL, POSTFIX, WEBMAIL, VPN, etc.) et

l’interconnexion des réseaux Linux et Windows, participant ainsi à la cohabitation et

l’harmonisation des réseaux hétérogènes Linux-Windows.

RTN intervient dans les domaines suivants :

• Formation et encadrement des personnels des entreprises;

• Mise à niveau du personnel des entreprises sur les technologies de l’information et de

la communication ;

• Conseils et orientations professionnelles pour la gestion d’un réseau d’entreprise

dynamique ;

• Formation de professionnels spécialisés en câblage de réseaux informatiques.

RTN dispense également un éventail de formations dont la liste non exhaustive est la

suivante :

• Certification Linux Professional Institute (LPI)

• Certification Cisco CCNA

• Téléphonie sur IP avec le protocole SIP

• Téléphonie sur IP avec le protocole H323

• Mise en place de la ToIP avec l’IPX open source Asterisk (SIP, SCCP, UNISTIM)

• Mise en place de la ToIP avec le Call Manager de Cisco

• Messagerie collaborative

• Les services réseaux

GAGLO Kokou

1.1.3. Organigramme de RTN

Figure 1.1

1.2. Présentation du sujet

A l’heure actuelle, les télécoms évoluent vers les réseaux NGN (Next Generation

Network) dont est issu l’IMS. Ainsi, il

pensent à migrer leurs infrastructures. Il se pose alors la question de compétence dans ce

domaine.

1.3. Problématique

RTN, de part sa vocation, a pris conscience du besoin à venir dans le domaine des

NGN. Ainsi, que ce soit les opérateurs ou que ce soit les régulateurs télécoms, ces

Service accueil, info,

animation scolaire

Bureau des étudiants

Service Ressource

Technique et Documentaire

Mise en place d’une plateforme de formation IMS

Organigramme de RTN

Figure 1.1 : Organigramme de RTN

Présentation du sujet


Network) dont est issu l’IMS. Ainsi, il va de soi que les opérateurs, spécifiquement africains,



que ce soit les opérateurs ou que ce soit les régulateurs télécoms, ces

CA

DG (mme ouya)

Direction Formation

Recherche

EC2LT

Service scolarité ,

recouvrement & caisseDépartements

commissions

permanentes ou adhoc

conseil de la vie

scolaire et des études (DFR).

Service Recherche,

deploiement & formation

Service comptabilité

finance

Mise en place d’une plateforme de formation IMS 16


que les opérateurs, spécifiquement africains,



que ce soit les opérateurs ou que ce soit les régulateurs télécoms, ces entités

conseil de la vie

scolaire et des études

Service comptabilité Service marketing,

communication, op. commerciales


auront besoin que leurs ingénieurs soient formés pour une migration du réseau existant pour le

premier, que leur personnel ait le bagage nécessaire afin de décider de ce qui sera de la

réglementation de ce secteur pour le second.

C’est dans ce but que RTN a mis en place un laboratoire chargé d’effectuer des

recherches dans le domaine de l’IMS. C’est de cette dynamique que découle notre travail qui

consiste à mettre en place une plateforme de formation IMS qui permettra à l’apprenant de :

• comprendre le concept de l’IMS ;

• d’étudier toutes les entités constitutives d’une architecture IMS ;

• se familiariser avec les protocoles utilisés par la technologie IMS ;

• simuler un réseau IMS ;

• mettre en place des services et les greffer au cœur IMS ;

• d’analyser les flux générés dans un réseau IMS.

1.3.1. Objectifs

Notre travail consistera à mettre en place la plateforme de formation IMS, à

documenter toutes les étapes de la mise en place. Nous étudierons les divers

protocoles utilisés dans un réseau IMS, les interactions entre tous les composants de ce

dernier. Nous étudierons également les différents types de services supportés par

l’IMS, puis nous en implémenterons quelques uns au dessus du réseau IMS qui sera

déployé.

GAGLO Kokou

2. ETUDE DE L’IP MULTIMEDIA SUBSYSTEM

2.1. Architecture du réseau IMS

Figure 2.1 : Le modèle à quatre couche de l’a

IMS propose une approche modulaire qui permet de distinguer des niveaux de

différents. Quatre couches (ou

domaine spécifique (la figure 2.1

l’IMS) :

• la couche accès [B2] définit la manière dont l

les réseaux d’accès, on peut citer les plus classiques : GSM (Global System for Mobile

communications), UMTS (Universal Mobile Telecommunications System), CDMA

2000 (Code Division Multiple Access 2000), UMA (Unlice

xDSL (xDigital Subscriber Line), Wi


ETUDE DE L’IP MULTIMEDIA SUBSYSTEM

Architecture du réseau IMS

Le modèle à quatre couche de l’architecture IMS

IMS propose une approche modulaire qui permet de distinguer des niveaux de

Quatre couches (ou plans) peuvent être identifiées, chacune d’elles étant liée à un

maine spécifique (la figure 2.1 illustre un schéma global de l’architecture en couches

définit la manière dont l’utilisateur se connecte au réseau. Parmi



2000 (Code Division Multiple Access 2000), UMA (Unlicensed Mobile Access),

xDSL (xDigital Subscriber Line), Wi-Fi (Wireless Fidelity), WiMax (Worldwide


rchitecture IMS

IMS propose une approche modulaire qui permet de distinguer des niveaux de traitements

peuvent être identifiées, chacune d’elles étant liée à un

illustre un schéma global de l’architecture en couches de

’utilisateur se connecte au réseau. Parmi



nsed Mobile Access),

Fi (Wireless Fidelity), WiMax (Worldwide

CHAPITRE 2


Interoperability for Microwave Access) et les réseaux fixes, comme Ethernet, ATM, la

fibre optique et le câble, par exemple. Cette liste non exhaustive est susceptible de

contenir n’importe quel réseau d’accès, qu’il soit filaire ou non. Remarquons que les

réseaux supportés ne s’orientent ni vers IP, ni vers les réseaux cellulaires en

particulier, mais visent une large étendue de possibilités. En regroupant différents

types de réseaux d’accès au sein de cette couche, IMS offre un niveau d’abstraction à

la manière dont l’utilisateur se connecte au réseau. Cette vision est à l’origine de l’idée

de convergence des réseaux vers un réseau unique, prônée par l’IMS. Autrement dit,

IMS est indépendant du réseau d’accès, qui n’est qu’un élément assurant la

connectivité de l’utilisateur au réseau cœur.

• la couche transport [B2] permet la connectivité de bout en bout entre les différents

interlocuteurs. Alors que la couche d’accès se contente de connecter un utilisateur au

réseau IMS, la couche transport se charge de l’acheminement des données de

l’utilisateur jusqu’à son (ou ses) correspondant(s). Cela comprend le transport de

l’information par les routeurs et le choix de la route empruntée dans le réseau. C’est le

réseau IP qui est utilisé dans cette couche.

Elle dispose en outre de deux sous-systèmes particuliers :

o NASS (Network Attachment SubSystem) pour la configuration du réseau. Il

permet de disposer dans le réseau de l’équivalent d’un serveur DHCP, afin

d’attribuer des paramètres réseau (au minimum une adresse IP et un masque de

sous réseau) à l’utilisateur, et d’un client, pour les authentifications de

l’utilisateur, réalisées sur son profil.

o RACS (Ressource Admission Control SubSystem) pour le contrôle

d’admission. Il permet d’allouer les ressources sollicitées par les applications

en effectuant, à la demande, des réservations.

• la couche contrôle [B2] assure la gestion et le contrôle du réseau. Elle est en charge

de tous les messages de signalisation dans le réseau, permettant d’ouvrir, de maintenir,

de modifier et de terminer une session entre des utilisateurs. C’est la partie intelligente

du modèle, qui offre toutes les fonctionnalités de gestion des utilisateurs et constitue le

véritable socle de l’IMS. La couche de contrôle est constituée de différentes entités


logiques que nous allons détailler dans les paragraphes suivants. Toutes ces entités

sont indispensables pour le fonctionnement d’un réseau IMS. Elles sont des entités

logiques, ce qui signifie que, malgré leur distinction fonctionnelle, rien n’empêche de

les implémenter (toutes ou certaines) au sein d’un même équipement.

• la couche application [B2] consiste en la fourniture des services, qu’ils soient audio,

vidéo ou textuels. Cette couche implémente tous les services que l’on peut proposer

aux utilisateurs. Elle est la partie la plus ouverte du modèle, puisque le réseau IMS ne

spécifie pas les services eux-mêmes, mais offre une plate-forme de déploiement

unifiée, simple, rapide, productive et sécurisée pour la mise en place de nouveaux

services. Sa description est assez sommaire, mais elle est susceptible d’être enrichie à

l’infini, selon les nouveaux services que l’on souhaite apporter et toutes les

propositions amenées par des développeurs. On peut, notamment, mentionner les

applications classiques de présence, de messagerie instantanée et de push-to-talk.

Nous verrons plus loin les différentes catégories de services que l’IMS permet de

distinguer.

Chaque couche est indépendante, de sorte qu’il est possible, par exemple, d’ajouter librement

de nouveaux services dans la couche applicative, sans tenir compte du réseau d’accès que les

utilisateurs ont employé, ni du terminal qu’ils ont utilisé. Cela dit, il est souhaitable que les

serveurs d’applications adaptent leur réponse en fonction de ces critères : par exemple, une

page Web ne doit pas contenir les mêmes informations ni être formatée de la même manière

selon qu’elle est destinée à être visualisée sur un ordinateur portable ou sur un téléphone

portable.

2.2. Description des entités IMS et leurs fonctionnalités

Cette section décrit les entités IMS et leurs fonctionnalités. Ces entités sont les suivantes :

• CSCF (décliné en P-CSCF, I-CSCF et S-CSCF)

• HSS et SLF

• MRF (réparti en MRFC et MRFP)

• BGCF

GAGLO Kokou

• MGW, MGCF et SGW

• TrGW et IMS-ALG

• Serveur d’applications (SIP, IM

2.2.1. la gestion de session et le routage (CSCF)

Il y a quatre (4) types de

CSCF), Serving-CSCF (S-CSCF), Interrogating

CSCF). Chaque CSCF a des tâches spéciales qui sont décrites

que le P-CSCF, S-CSCF et I-

de l’enregistrement, l’établissement des sessions et forment le mécanisme de routage SIP. En

outre, toutes les fonctions sont en mesure d

chargement hors ligne. Il ya quelques fonctions communes que P

mesure d'effectuer. Les deux entités sont en mesure de libérer sessions au nom de l'utilisateur

(par exemple, lorsque S-CSCF détecte une session pendante ou P

notification indiquant que le porteur des médias est perdu) et sont en mesure de vérifier que le

contenu de la requête SIP ou la réponse est conforme à la politique de l'exploitant et

d'abonnement de l'utilisateur (par exemple le contenu de la Session Description Protocol

(SDP) de charge utile contient les types de médias ou de codecs, qui sont autorisés pour un

utilisateur).


MGW, MGCF et SGW

Serveur d’applications (SIP, IM-SSF et OSA-SCS)

on de session et le routage (CSCF)

Il y a quatre (4) types de Call Session Control Functions (CSCF)

CSCF), Interrogating-CSCF (I-CSCF) et Emergency

Chaque CSCF a des tâches spéciales qui sont décrites plus loin dans le document

-CSCF ont en commun c’est qu’ils jouent tous un rôle au cours


outre, toutes les fonctions sont en mesure d'envoyer des données de charge à une fonction de

chargement hors ligne. Il ya quelques fonctions communes que P-CSCF et S


SCF détecte une session pendante ou P



utilisateur (par exemple le contenu de la Session Description Protocol


Figure 2.2 : Les serveurs CSCF


(CSCF) : Proxy-CSCF (P-

CSCF) et Emergency-CSCF (E-

lus loin dans le document. Ce

CSCF ont en commun c’est qu’ils jouent tous un rôle au cours


'envoyer des données de charge à une fonction de

CSCF et S-CSCF sont en


-CSCF reçoit une



utilisateur (par exemple le contenu de la Session Description Protocol



2.2.1.1. Proxy Call Session Control Function (P-CSCF)

Le serveur P-CSCF constitue le point d’entrée dans le réseau IMS pour tout ce qui concerne la

signalisation d’une session d’un utilisateur. Il est situé dans le réseau auquel le terminal se

connecte, même si ce réseau n’est pas celui de l’opérateur auquel l’utilisateur est abonné. Dès

qu’une requête de signalisation est envoyée depuis un terminal, elle est réceptionnée par un

P-CSCF. Ce dernier est chargé de prendre en charge les requêtes d’un utilisateur et de les

rediriger vers les serveurs concernés (c’est-à-dire les serveurs appartenant à l’opérateur auquel

l’utilisateur a souscrit un service). De même, après avoir envoyé la requête de l’utilisateur au

serveur concerné, c’est le P-CSCF qui relaie la réponse obtenue vers le terminal. Le P-CSCF

est donc un intermédiaire imposé entre le terminal et les autres serveurs.

Dans la pratique, lorsqu’un terminal est connecté au réseau IMS, il initie une étape

d’activation de contexte PDP lui permettant de négocier les paramètres avec lesquels ses

services vont être lancés. Cette étape est indispensable pour pouvoir ensuite émettre et

recevoir des requêtes SIP. Lors de cette étape, le terminal découvre l’adresse du serveur

P-CSCF. Celui-ci sert à aiguiller chacune des requêtes émises par le terminal. Autrement dit,

le terminal s’adresse au P-CSCF pour lui formuler ses requêtes, et c’est le P-CSCF qui est

chargé de les mener à bien. Le P-CSCF est déterminé et attribué pour toute une session, d’une

connexion à la déconnexion d’un utilisateur. Par contre, il peut changer lors de la session

suivante de l’utilisateur. Le serveur P-CSCF n’est pas nécessairement la propriété de

l’opérateur auquel le client a souscrit un service. Au contraire, et c’est tout son intérêt, il peut

être un intermédiaire entre le terminal client IMS et les serveurs de l’opérateur de l’utilisateur.

Considérons un utilisateur qui se trouve physiquement dans une région où son opérateur ne

dispose d’aucune infrastructure pour permettre sa connexion, par exemple à l’étranger. Dans

ce cas, et pour peu que l’opérateur de l’utilisateur ait un contrat avec l’opérateur qui gère cette

région, l’utilisateur peut quand même se connecter en utilisant l’infrastructure du réseau

visité, matérialisé par le P-CSCF de l’opérateur de la région. Le terminal est dans ce cas «

visiteur » dans le P-CSCF qu’il sollicite. Outre sa nécessité physique, le P-CSCF facilite les

facturations entre opérateurs. Bien sûr, le P-CSCF peut aussi être celui de l’opérateur auquel

l’utilisateur à souscrit un abonnement. Ainsi, dans tous les cas, le terminal possède un

interlocuteur virtuel privilégié, auquel il délègue le soin d’aiguiller ses demandes. De cette

manière, le terminal n’a qu’une vision minimale des serveurs du réseau IMS, et c’est au

serveur P-CSCF que revient la charge de localiser et contacter les autres entités. Le réseau de


signalisation est de la sorte protégé par le P-CSCF, qui agit comme un garde-barrière. Il peut

même avoir les fonctionnalités suivantes :

• Contrôle de syntaxe des requêtes SIP.

• Contrôle d’intégrité des données.

• Contrôle d’admission en refusant des appels lorsque le réseau est trop chargé, afin de

ne pas dégrader la qualité des communications existantes.

À ce titre, le rôle du P-CSCF est comparable à celui que joue le proxy SIP dans l’architecture

SIP. Le P-CSCF doit également permettre l’aboutissement des appels d’urgence. De plus, il

est aussi responsable de la gestion de la qualité de service pour l’utilisateur. Outre sa

fonctionnalité d’intermédiaire dans l’acheminement des méthodes SIP entre le terminal de

l’utilisateur et le serveur approprié, le P-CSCF offre des fonctionnalités de

compression/décompression des messages SIP, afin de réduire le temps d’établissement d’une

connexion. Le terminal IMS a la possibilité de compresser ses données, ce qui permet de les

transmettre plus rapidement au P-CSCF qui les décompresse avant de les transmettre aux

entités sollicitées. C’est d’autant plus utile que les réseaux radio (utilisés le plus souvent dans

la couche d’accès) ont généralement une bande passante réduite. L’objectif de la compression

n’est pas vraiment de ne pas gaspiller la bande passante, mais plutôt sa conséquence

immédiate, qui est d’accélérer la transmission du message.

2.2.1.2. Interrogating Call Session Control Function (I-CSCF)

L’I-CSCF est le point de contact dans le réseau de l’opérateur pour toutes les connections

destinées à un utilisateur du même réseau. Les fonctions assignées au I-CSCF sont au nombre

de trois (3) :

• obtenir le nom de l’entité suivante (soit un S-CSCF soit un serveur d'application) chez

le HSS (Home Subscriver Server) ;

• attribution d'une S-CSCF en fonction des possibilités reçues de l'HSS. Cette

attribution de S-CSCF aura lieu quand un utilisateur est en train de s’enregistrer sur le

réseau ou un utilisateur reçoit une requête SIP alors qu'il est déconnecté du réseau,


mais il a souscrit à des services liés à un état non enregistrés (exemple messagerie

vocale) ;

• routage des demandes entrantes vers un S-CSCF attribué ou le serveur d'applications.

2.2.1.3. Serving Call Session Control Function (S-CSCF)

Le S-CSCF est le point focal de l’IMS puisqu’il est responsable du processus

d'enregistrement, de la prise de décisions de routage et du maintien des sessions et du

stockage du profil de service (s). Quand un utilisateur cherche à s’enregistrer, la requête

d’enregistrement est envoiyée au S-CSCF qui télécharge les informations d’authentification

au niveau du HSS. Sur la base des données d'authentification il génère un défi pour l'UE.

Après réception et vérification de la réponse le S-CSCF accepte l’enregistrement et

commence la supervision de l’état de l’enregistrement. Après cela, l’utilisateur est prêt à

initier ou à recevoir les services IMS. En outre, le S-CSCF télécharge les profils de services

auprès du HSS lors du processus d’enregistrement de l’utilisateur. Un profil de service est un

ensemble d'informations spécifiques à l'utilisateur qui est stocké de manière permanente

dans le HSS. Le S-CSCF télécharge le profil de service associé à une identité d’utilisateur

public lorsque cette dernière est connectée à l’IMS. Le S-CSCF utilise ces informations du

profil de service pour décider quel serveur d’application contacter lorsque l’utilisateur envoie

ou reçoit une requête SIP d’un autre utilisateur. Le profil de service contient également des

instructions concernant la politique que le S-CSCF doit appliquer (par exemple l’utilisateur

est autorisé à utiliser les services audio et ne l’est pas pour les services vidéo). Le S-CSCF est

responsable des décisions de routage puisqu'il reçoit tous les flux et transactions. Quand il

reçoit une requête initiée par un UE via le P-CSCF, il doit décider si les serveurs

d'applications sont mis en contact avant envoi de la demande plus loin. S’il y a une possible

interaction entre les serveurs d’applications le S-CSCF soit continue une session dans l’IMS

soit renvoie les requêtes à d'autres domaines (CS ou un autre réseau IP). Lorsque l’UE utilise

un numéro MSISDN (Mobile Station ISDN) pour un appel, le S-CSCF convertit le numéro

MSISDN en un SIP URI (SIP Universal Ressource Identifer) avant d’envoyer la requête

puisque l’IMS ne route pas les requêtes basées sur les numéros MSISDN. Parallèlement,

puisque le S-CSCF connait l’adresse IP de l’UE (lors de l’enregistrement), il envoie les

requêtes qui lui sont destinées via le P-CSCF qui s’occupe de la compression SIP et de la

sécurité.


Figure 2.3 : Les S-CSCF dans le réseau IMS

2.2.1.4. Emergency Call Session Control Function (E-CSCF)

E-CSCF est une fonctionnalité dédiée pour traiter les demandes d'urgence telles que les

sessions IMS vers la police, les pompiers et les ambulanciers. La tâche principale de l’E-

CSCF est de sélectionner un centre d'urgence également connu sous le nom d'un point de

sécurité publique (Public Safety Answering Point) où l’appel d'urgence sera adressé.

Typiquement, un critère de sélection est l'emplacement de l’utilisateur appelant et le type

possible d'urgence (police, garde-côtes). Une fois le centre d’urgence approprié sélectionné

l’E-CSCF y envoie la demande.

2.2.2. HSS (Home Subscriber Server) : la base de données

Le serveur HSS (Home Subscriber Server) est une entité centralisée qui stocke une base de

données contenant l’ensemble des profils des utilisateurs. Il comporte, entre autres et pour

chaque utilisateur, les informations suivantes :

• localisation des terminaux des utilisateurs abonnés ;

• identité complète des utilisateurs susceptibles d’accéder au réseau IMS ;

• paramètres permettant leur authentification et les informations d’autorisation

d’accès ;


• ensemble des services auxquels ils ont souscrits ;

• préférences de services (on peut imaginer toutes sortes de préférences, par exemple la

redirection vers la messagerie d’un utilisateur en fonction de l’heure) ;

• serveur S-CSCF, qui traite les demandes de l’utilisateur (attribué dynamiquement lors

de la connexion de l’utilisateur).

Toutes les données relatives à un même compte utilisateur doivent être stockées sur un même

HSS. Néanmoins, lorsque le nombre d’utilisateurs est important, il est possible de les repartir

au sein de plusieurs HSS. Dans ce cas, il est nécessaire de mettre en place une entité

complémentaire, appelée SLF (Subscription Locator Function), qui a pour rôle de déterminer

le HSS contenant les données relatives à un utilisateur. Les serveurs HSS et SLF

communiquent avec les autres entités du réseau au moyen du protocole Diameter. Le HSS

contient également les fonctionnalités des sous-ensembles de HLR (Home Location Register)

et d’AUC (Authentification Center) requises par un domaine de commutation de paquets

(Packet-Switched , PS) et par un domaine de commutation de circuits(Circuit-Switched , CS).

La structure de l'HSS est illustrée à la figure 2.4.

Figure 2.4 : Structure du HSS

La fonction HLR est nécessaire pour fournir un appui aux entités du domaine PS, comme

SGSN et GGSN. Il permet aux utilisateurs d’accéder aux services du domaine de

commutation de paquets. De la même façon le HLR fournit un soutien pour les entités de

domaine CS, comme les serveurs MSC. Ceci donne l’accès aux services du domaine de

commutation de circuits et prend en charge l'itinérance dans un domaine GSM/UMTS (Global

System for Mobile Communications, UMTS). L’AUC stocke les clés secrètes de chaque

abonné mobile, clés qui sont utilisées pour le chiffrement et l’authentification des mobiles. Le

SLF est utilisé comme un mécanisme de résolution qui permet au I-CSCF, au S-CSCF et au

AS de trouver l’adresse du HSS qui contient les informations à propos d’un utilisateur

lorsqu’il y a plusieurs HSS dans le réseau.


2.2.3. MRF (Multimedia Resource Function)

L’entité MRF (Multimedia Resource Function) permet d’établir un pont de conférence entre

les utilisateurs d’un réseau IMS. Son rôle est de gérer la signalisation vers tous les utilisateurs

d’une conférence, en offrant des facilités d’exploitation, comme la sélection des types de flux

— par exemple, si sa bande passante est faible, il est possible de demander uniquement le flux

audio sur son poste, tandis que d’autres utilisateurs disposeront de la vidéo — et la conversion

des formats de codecs — il est possible d’utiliser des codecs différents pour chaque

utilisateur, le MRF adaptant chaque flux aux exigences de chacun. Le MRF a un

fonctionnement semblable à celui de l’entité MCU (Multipoint Control Unit) consacré à

H.323, si ce n’est qu’il manipule une signalisation SIP.

Comme ce dernier, le MRF se décompose en deux entités logiques :

• MRFC (Multimedia Resource Function Controller) : pour la partie signalisation, et

plus précisément la négociation des paramètres sollicités par chaque utilisateur pour la

mise en oeuvre de la conférence ;

• MRFP (Multimedia Resource Function Processor) : pour la partie traitement des flux

de données, c’est-à-dire l’application des demandes formulées par l’utilisateur dans

les flux.

2.2.4. BGCF (Breakout Gateway Control Function)

BGCF (Breakout Gateway Control Function) est un serveur qui communique en utilisant le

protocole SIP. Il sert à préciser le routage des appels initiés par des terminaux IMS vers des

terminaux fonctionnant en mode commutation de circuits (réseaux filaires traditionnels ou

réseau GSM, par exemple).

En considérant qu’un terminal IMS cherche à joindre un correspondant dans le réseau RTC,

deux cas peuvent se produire, selon la compatibilité de l’appareil :

• si l’appareil qui se connecte est compatible avec le réseau du correspondant qu’il

cherche à joindre, le BGCF se charge de mettre en relation les deux entités.

GAGLO Kokou

• sinon, comme l’appareil n’est pas compatible avec le réseau du

cherche à joindre, le BGCF indique des passerelles spécifiques (de type MGCF,

présentées plus loin) responsables d’effectuer la liaison et auxquelles le BGCF relaie

toute la signalisation qu’il reçoit.

2.2.5. IMS-MGW, MGCF et SGW

Avec l’IMS, il est indispensable d’être ouvert aux réseaux les plus classiques, ce qui inclut

bien évidemment le réseau commuté RTC. Pour ce faire, les trois en

2.5 sont introduites. Il s’agit de l’IMS

Ces trois entités se répartissent sur deux plans : un plan de données (couche transport) et un

plan de signalisation (couche contrôle). Nous allons décrire chacune d’elles.

Figure 2.5

2.2.5.1. La passerelle de flux multimédia IMSGateWay)

Cette entité assure le transport des flux de données d’un réseau IP vers un réseau RTC, en

effectuant la liaison entre un terminal du côté IP et son correspondant du côté RTC, avec


sinon, comme l’appareil n’est pas compatible avec le réseau du correspondant qu’il



toute la signalisation qu’il reçoit.

MGW, MGCF et SGW

il est indispensable d’être ouvert aux réseaux les plus classiques, ce qui inclut

bien évidemment le réseau commuté RTC. Pour ce faire, les trois entités illustrées à la figure

sont introduites. Il s’agit de l’IMS-MGW, du MGCF et du SGW.

ités se répartissent sur deux plans : un plan de données (couche transport) et un


Figure 2.5 : Interfonctionnement avec le RTC

La passerelle de flux multimédia IMS-MGW (IMSGateWay)


effectuant la liaison entre un terminal du côté IP et son correspondant du côté RTC, avec


correspondant qu’il



il est indispensable d’être ouvert aux réseaux les plus classiques, ce qui inclut

tités illustrées à la figure

ités se répartissent sur deux plans : un plan de données (couche transport) et un


MGW (IMS -Media


effectuant la liaison entre un terminal du côté IP et son correspondant du côté RTC, avec le


transcodage correspondant (d’un flux RTP vers un flux TDM). C’est donc une passerelle de

flux de données multimédias qui convertit les flux de données multimédias codés en RTP

(dans le réseau IP) en flux de données multimédias codés en TDM (dans le réseau RTC). Elle

se situe sur la couche transport.

Généralement, cette passerelle possède des fonctionnalités complémentaires de traitement du

média, comme la suppression d’écho.

2.2.5.2. Le contrôleur de passerelle MGCF (Media Gateway Control Function)

Cette entité, qui agit au niveau de la signalisation, assure le passage du mode paquet (IP) au

mode circuit (RTC) en ouvrant, maintenant et fermant des connexions entre les réseaux IP et

RTC et en assurant la conversion des protocoles de signalisation propres à ses réseaux.

Le serveur doit donc convertir un message SIP qui provient du réseau IP en un message ISUP

dans le réseau RTC. Le message ISUP correspondant sera remis à l’entité SGW, présentée

plus loin.

Le MGCF détermine le transcodage des flux de données et contrôle la passerelle de flux

multimédias IMS-MGW. La communication entre le serveur MGCF et le serveur IMS-MGW

se fait au moyen du protocole de signalisation MEGACO/H.248.

Le serveur MGCF doit également informer le serveur S-CSCF des messages de signalisation

qu’il génère pour que ce dernier connaisse les communications et opérations en cours.

2.2.5.3. La passerelle de signalisation SGW (Signaling GateWay)

Comme la précédente, cette entité concerne la partie signalisation. Sa fonction est de

transporter, un message de signalisation ISUP d’un transport SS7 vers SIGTRAN.

Le serveur SGW joue le rôle de passerelle pour la signalisation ISUP. Il est en contact avec

l’entité MGCF qui se charge de remplacer la signalisation ISUP en signalisation SIP.

GAGLO Kokou

2.2.6. TrGW et IMS

Le système IMS doit considérer à la fois un réseau IPv6,

IPv4 existant. Pour permettre une évolution en douceur vers la version 6, IMS

compatibilité avec IPv4 et met en

communications entre des stations qui communiquent ave

communiquent avec IPv6. De cette manière, le réseau IMS se charge d’effectuer la transition

entre les deux protocoles de manière transparente.

Pour cela, les deux entités illustrées à la figure 2.

GateWay) et IMS-ALG (IMS-

Figure

Lorsqu’une station IPv6 communique avec une station IPv4, cette dernière n’est,

capable de comprendre le message qui lui parvient. L’idée co

entité intermédiaire entre ces deux stations afin d’effectuer la conversion du

les versions 4 et 6.

Comme les messages qu’une station peut envoyer à une autre sont de deux types (flux de

données et signalisation), deux entités fonctionnelles sont dévolues à ces tâches : la passerelle

TrGW, qui effectue la translation d’adresses sur les flux de données, et

IMS-ALG, qui effectue la translation d’adresses au niveau de la signalisati


TrGW et IMS -ALG

Le système IMS doit considérer à la fois un réseau IPv6, inévitablement attendu, et un

IPv4 existant. Pour permettre une évolution en douceur vers la version 6, IMS

compatibilité avec IPv4 et met en œuvre des entités spécialement dédiées aux

communications entre des stations qui communiquent avec IPv4 et des stations qui


entre les deux protocoles de manière transparente.

Pour cela, les deux entités illustrées à la figure 2.6 sont introduites : TrGW (T

-Application Layer Gateway).

Figure 2.6 : Les serveurs IMS-ALG et TrGW

Lorsqu’une station IPv6 communique avec une station IPv4, cette dernière n’est,

capable de comprendre le message qui lui parvient. L’idée consiste à mettre en

entité intermédiaire entre ces deux stations afin d’effectuer la conversion du


ignalisation), deux entités fonctionnelles sont dévolues à ces tâches : la passerelle

TrGW, qui effectue la translation d’adresses sur les flux de données, et

ALG, qui effectue la translation d’adresses au niveau de la signalisati


inévitablement attendu, et un réseau

IPv4 existant. Pour permettre une évolution en douceur vers la version 6, IMS assure la

des entités spécialement dédiées aux

c IPv4 et des stations qui


sont introduites : TrGW (Transition

Lorsqu’une station IPv6 communique avec une station IPv4, cette dernière n’est, à priori, pas

nsiste à mettre en place une

entité intermédiaire entre ces deux stations afin d’effectuer la conversion du protocole IP entre


ignalisation), deux entités fonctionnelles sont dévolues à ces tâches : la passerelle

TrGW, qui effectue la translation d’adresses sur les flux de données, et la passerelle

ALG, qui effectue la translation d’adresses au niveau de la signalisation. Autrement dit,


la passerelle TrGW agit sur les messages de données encapsulés par RTP (et les retours

RTCP), tandis que la passerelle IMS-ALG agit sur les messages de signalisation SDP et SIP.

2.2.7. Les serveurs d’application

L'architecture de service consiste en un ensemble de serveurs d'application interagissant avec

le réseau IMS (i.e. S-CSCF) à travers l'interface ISC (IP Multimedia Service Control)

supportée par le protocole SIP.

Les serveurs d'application sont :

• Les serveurs d'application SIP qui exécutent des services (e.g., Push To Talk,

Présence, Conférence, Instant messaging, etc.) et qui peuvent influencer le

déroulement de la session à la demande du service ;

• Le point de commutation au service IMS (IM-SSF, IP Multimedia Service Switching

Function) qui est un type particulier de serveur d'application qui termine la

signalisation SIP sur l'interface ISC d'une part et qui joue le rôle de SSP CAMEL

d'autre part (i.e., il dispose des modèles d'appel O-IM-BCSM et T-IM-BCSM, des

points de détection CAMEL et du protocole CAP) pour interagir avec les plates-

formes de service CAMEL appelées CSE (CAMEL Service Environment) ;

• La passerelle OSA (OSA SCS, OSA Service Capability Server) qui est un type

particulier de serveur d'application qui termine la signalisation SIP sur l'interface ISC

et qui interagit avec des serveurs d'application OSA en utilisant l'API OSA ;

• Un type spécialisé de serveur d'application SIP appelé gestionnaire d'interaction de

service (SCIM, Service Capability Interaction Manager) qui permet la gestion des

interactions entre serveurs d'application SIP.

2.3. Les principaux protocoles et leurs interfaces

2.3.1. Les principaux protocoles

Les trois principaux protocoles utilisés dans l’IMS sont les suivants :

GAGLO Kokou

SIP est le protocole fédérateur de l’architec

aux différents composants de communiquer entre eux de manière homogène.

Diameter, décrit dans la RFC 3588 de l’IETF, est un protocole de type AAA (Authentication,

Authorization, Accounting). Il est

notamment lors de l’enregistrement des utilisateurs et lorsque les profils utilisateur sont

transférés d’une base de données vers les serveurs de traitement (nous décrivons plus loin ces

entités). Il fonctionne en mode client/serveur, donc sous la forme de requêtes et de réponses.

COPS (Common Open Policy Service) est un protocole flexible permettant la mise en

de politiques par une entité centrale appelée PDP (Policy Decision Point), qui sont

sous formes de règles dans des entités appelées PEP (Policy Enforcement

notamment à permettre aux opérateurs de garantir une qualité de

IMS.

2.3.2. Les interfaces

Figure 2.7 : Les interfaces dans l’arc

Le tableau 2.1 (voir annexe)

quelques unes d’entre-elles.


est le protocole fédérateur de l’architecture IMS. Il est en quelque sorte la glue


, décrit dans la RFC 3588 de l’IETF, est un protocole de type AAA (Authentication,

Authorization, Accounting). Il est employé pour la sécurisation des communications,

de l’enregistrement des utilisateurs et lorsque les profils utilisateur sont

base de données vers les serveurs de traitement (nous décrivons plus loin ces

nne en mode client/serveur, donc sous la forme de requêtes et de réponses.

(Common Open Policy Service) est un protocole flexible permettant la mise en

de politiques par une entité centrale appelée PDP (Policy Decision Point), qui sont

sous formes de règles dans des entités appelées PEP (Policy Enforcement

notamment à permettre aux opérateurs de garantir une qualité de service dans une architecture

Les interfaces

Figure 2.7 : Les interfaces dans l’architecture IMS

résume les interfaces IMS. Les paragraphes suivant détaillent


ture IMS. Il est en quelque sorte la glue qui permet


, décrit dans la RFC 3588 de l’IETF, est un protocole de type AAA (Authentication,

employé pour la sécurisation des communications,

de l’enregistrement des utilisateurs et lorsque les profils utilisateur sont

base de données vers les serveurs de traitement (nous décrivons plus loin ces

nne en mode client/serveur, donc sous la forme de requêtes et de réponses.

(Common Open Policy Service) est un protocole flexible permettant la mise en place

de politiques par une entité centrale appelée PDP (Policy Decision Point), qui sont appliquées

sous formes de règles dans des entités appelées PEP (Policy Enforcement Point). COPS sert

service dans une architecture

résume les interfaces IMS. Les paragraphes suivant détaillent


2.3.2.1. Interface Gm

L’interface Gm connecte l’UE (User Equipment) à l’IMS. Il est utilisé pour transporter tous

les messages de signalisation entre l’UE et l’IMS. Les procédures de l’interface Gm peuvent

être divisées en trois (3) catégories principales : l’enregistrement, le contrôle de session et les

transactions [B3] :

• au cours la procédure d’enregistrement l’UE utilise l’interface Gm pour envoyer une

requête d’enregistrement au P-CSCF en indiquant s’il supporte ou non des

mécanismes de sécurité. Durant la procédure d’enregistrement l’UE échange les

paramètres nécessaires pour l’authentification avec le réseau, récupère les identités

implicites de l’utilisateur connecté, négocie les paramètres de sécurité SA (Security

Associations) et démarre une compression SIP possible.

• le contrôle de session contient les mécanismes pour les sessions initiées par le

terminal source et celle initiée par le terminal destination. Dans le cas des sessions

initiées par le terminal source, l’interface Gm est utilisée pour envoyer les requêtes de

l’UE au P-CSCF. Dans le cas des sessions initiées par le terminal destination, elle est

pour envoyer les requêtes du P-CSCF à l’UE.

• Les procédures de transaction sont utilisées pour envoyer les requêtes (à l’instar de

MESSAGE) et pour recevoir les réponses (exemple : 200 OK).

2.3.2.2. Interface Mw

L’interface Gm relie l’UE à l’IMS (le P-CSCF précisément). Il faudra après une interface

basée sur SIP entre les différentes entités CSCF. Cette interface est appelée le Mw. Les

procédures de l’interface Mw peuvent être divisées en trois (3) catégories principales :

l’enregistrement, le contrôle de session et les transactions [B3] :

• Au cours de la procédure d’enregistrement, le P-CSCF utilise l’interface Mw pour

envoyer les requêtes venant de l’UE à l’I-CSCF. L’I-CSCF utilise à son tour

l’interface Mw pour envoyer la requête au S-CSCF. La réponse du S-CSCF est

également retournée par l’interface Mw.


• La procédure de contrôle de session contient les mécanismes pour les sessions initiées

par le terminal source et celle initiée par le terminal destination. Dans le cas des

sessions initiées par le terminal source l’interface Mw est utilisée pour envoyer les

requêtes du P-CSCF vers le S-CSCF et du S-CSCF vers l’I-CSCF. Dans le cas des

sessions initiées par le terminal destination l’interface Mw est utilisée pour envoyer les

requêtes de l’I-CSCF vers le S-CSCF et du S-CSCF vers le P-CSCF.

• Les procédures de transaction sont utilisées pour envoyer les requêtes (à l’instar de

MESSAGE) et pour recevoir les réponses (exemple : 200 OK).

2.3.2.3. Interface ISC (IMS Service Control)

Dans l’architecture IMS, les serveurs d’application sont des entités qui hébergent et exécutent

les services comme la présence, le chat et autres. C’est pourquoi il faut une interface pour

envoyer et recevoir les messages SIP entre le S-CSCF et le serveur d’application. Cette

interface est l’ISC basé sur le protocole SIP. Ses procédures peuvent être divisées en deux (2)

catégories principales : celles qui routent les requêtes SIP initiales vers l’AS (Application

Server) et celle qui gèrent les requêtes initiées par l’AS :

• Après le succès de l’enregistrement dans le réseau, le S-CSCF télécharge le profil de

l’utilisateur du HSS. Une fois que le S-CSCF reçoit une requête SIP, il l’analyse puis

décide vers quel AS envoyer la requête. L’AS traite la requête ou l’envoie à un autre

AS.

• L’AS peut initier une requête à base des actions (triggers) internes ou externe. Par

exemple l’initiation de publication d’information de présence d’un certain AS vers le

serveur de présence.

2.3.2.4. Interface Cx

Les données concernant les utilisateurs et les services sont permanemment sauvegardées dans

le HSS. Ces données centralisées sont utilisées par l’I-CSCF et le S-CSCF lorsque les

utilisateurs s’enregistrent ou reçoivent des sessions. Pour ce faire, il existe une interface entre

l’HSS et les CSCF. Cette interface est appelée le Cx et est basée sur le protocole Diameter.


Ces procédures peuvent être divisées en trois catégories : la localisation, la gestion des

données des utilisateurs et l’authentification des utilisateurs. Le tableau 2.2 résume les

commandes Cx disponibles.

2.3.2.5. Interface Sh

Un AS (SIP AS ou OSA SCS) a besoin de données (relatives à une identité particulière de

l’abonné ou relatives à l’identité public d’un service) ou a besoin de savoir à quel S-CSCF

envoyer une requête SIP. Ces genres d’informations sont stockés dans le HSS. C’est pourquoi

il faut une interface entre le HSS et l’AS. Cette interface est la Sh et est basée sur Diameter.

Ces procédures sont divisées en deux (2) catégories : gestion des données et

souscription/notification. Le tableau 2.3 résume les commandes Sh disponibles. Le HSS a une

liste d’AS qui sont autorisés à obtenir ou sauvegarder des données.

2.3.2.5.1. La localisation

Quand l’I-CSCF reçoit une requête SIP REGISTER du P-CSCF via l’interface Mw, la

commande UAR (User-Authorization-Request) est invoquée. A la réception de la commande

UAR, le HSS répond par une commande UAA (User-Authorization-Answer) qui contient le

nom du S-CSCF ou les S-CSCF disponibles selon le statut courant de l’utilisateur. Les S-

CSCF disponibles sont envoyés si c’est la première fois que l’utilisateur se connecte et n’a

pas de S-CSCF associé dans la base HSS. Après cela, l’I-CSCF renvoie une requête SIP

REGISTER au S-CSCF renvoyé ou sélectionné.

2.3.2.5.2. La gestion des données des utilisateurs

Durant la procédure d’enregistrement, les données concernant l’utilisateur et les services

auxquels il a souscrit seront téléchargées depuis le HSS par le S-CSCF. Cependant il est

possible que ces données changent pendant que le S-CSCF sert toujours l’utilisateur. Pour

mettre à jour ces données au niveau du S-CSCF, le HSS initie une commande PPR (Push-

Profile-Request). La mise à jour est effectuée immédiatement.


2.3.2.5.3. L’authentification des utilisateurs

L’authentification des utilisateurs IMS est basée sur un secret partagé préconfiguré. Le secret

partagé et les séquences de nombre sont stockés dans l’ISIM (IP Multimedia Service Identity

Module) ou l’USIM (UMTS Subscriber Identity Module) dans l’UE et dans le HSS dans le

réseau. Parce que le S-CSCF s’occupe de l’authentification de l’utilisateur, il existe un besoin

de transférer des données de sécurité par l’interface Cx. Lorsque le S-CSCF a besoin

d’authentifier un abonné, il envoie une commande MAR (Multimedia-Auth-Request) au HSS.

Le HSS répond par une commande MAA (Multimedia-Auth-Answer). La réponse contient

entre autre l’information d’authentification. Elle inclut un ou plusieurs vecteurs selon

l’algorithme utilisé (exemple Digest-AKAv1-MD5), l’information d’authentification (le

challenge RAND d’authentification et la valeur AUTN prise), l’information d’autorisation

(expected response ou XRES), la clé d’intégrité et la clé de confidentialité

2.3.2.5.4. Gestion des données

La gestion des données donne la possibilité de récupérer des données depuis le HSS. Ces

données peuvent contenir des données relatives au service (transparent ou non transparent),

des informations d’enregistrement, des identités publiques, des filtres, le nom du S-CSCF qui

s’occupe de l’utilisateur, des adresses des entités qui s’occupent de la facturation et même des

informations de localisation provenant de domaines paquets ou circuits. L’AS utilise la

commande UDR (User-Data-Request) pour demander des données et le HSS répond par la

commande UDA (User-Data-Answer).

2.3.2.5.5. Souscription/Notification

Ces procédures de souscription/notification permettent à l’AS d’avoir des notifications quand

une donnée particulière d’un utilisateur spécifique a été mise à jour dans le HSS. L’AS envoie

la commande SNR (Subscribe-Notifications-Request) pour recevoir les notifications et le HSS

répond par la commande SNA (Subscribe-Notifications-Answer).


2.4. Les identités IMS

Le réseau IMS reprend la notion d’identités publique et privée, qui est propre aux réseaux à

commutation de circuits des télécoms. L’identité publique d’un utilisateur désigne un URI

(SIP ou de type téléphonique) affecté publiquement à l’utilisateur et utilisé par les

correspondants de ce dernier pour le désigner, et donc le joindre. Dans la terminologie

télécoms, ce concept est l’équivalent du MSISDN (Mobile Subscriber ISDN Number) [B2].

Par exemple, si un utilisateur dispose d’une adresse professionnelle et d’une adresse privée, il

dispose de deux identités publiques correspondant à chacune de ses adresses.

De plus, même si l’utilisateur ne dispose que d’une adresse privée, celle-ci peut se présenter à

la fois sous la forme d’un URI SIP et d’un URI téléphonique. La première forme (au format

sip:identifiant@operateur) est adaptée au protocole SIP qu’exploite l’IMS et est donc

préférable de manière générale. La seconde (au format tel:+221776814199) est indispensable

pour être joignable à partir de terminaux non-IMS, qui ne disposent que de chiffres pour

joindre leurs correspondants et ne sont joignables que par un numéro d’appel.

L’identité privée d’un utilisateur désigne un identifiant au format NAI (Network Access

Identifier) qui est de type identifiant@operateur. Elle est affectée secrètement à l’utilisateur et

est utilisée par l’opérateur pour désigner ce dernier. Dans la terminologie télécoms, ce concept

est l’équivalent de l’IMSI (International Mobile Subscriber Identifier).

Par exemple, si un utilisateur dispose de plusieurs identités publiques, il peut toutes les gérer à

partir d’un compte unique (d’une identité privée) et donc d’un terminal unique, lequel recevra

les appels destinés à l’utilisateur, et ce quelle que soit l’identité publique avec laquelle les

appels sont adressés. L’identité privée est avant tout utile pour permettre l’identification et

l’authentification de l’abonné par l’opérateur.

De la même manière qu’une identité privée peut être liée à plusieurs identités publiques, une

identité publique peut être liée à plusieurs identités privées. Par exemple, considérons un

utilisateur qui dispose de deux terminaux IMS, le premier étant professionnel, le second privé,

et de deux identités publiques, là aussi, une professionnelle et l’autre privée. Chacun des

terminaux de cet utilisateur sera configuré avec une identité privée. Il peut décider de ne

recevoir, sur le premier terminal, que les appels professionnels (c’est-à-dire liés à son profil


public professionnel), tandis que, sur le second terminal, il décidera de recevoir tous les

appels (c’est-à-dire à la fois ceux liés à son compte professionnel et ceux liés à son compte

personnel).

Ainsi certaines identités privées sont-elles liées à plusieurs identités publiques, et certaines

identités publiques à plusieurs identités privées.

2.5. Enregistrement d’un terminal dans le réseau

L’enregistrement d’un utilisateur dans le réseau est la première action réalisée par un

terminal, dès sa mise en route. Elle est indispensable puisqu’elle permet à la fois d’appeler et

d’être joignable par ses correspondants.

La méthode associée à cette fonctionnalité est REGISTER, du protocole de signalisation SIP.

La figure 2.8 illustre les étapes temporelles liées au scénario d’enregistrement.


Figure 2.8 : Processus d’enregistrement d’un terminal

2.6. La fourniture de services dans l’IMS

L’IMS a une architecture qui se base sur le protocole SIP pour offrir des services et

applications IP dans le réseau paquet. L'IMS fournit les éléments nécessaires à l'invocation

des services: c'est le «service provisionning» qui se base sur deux notions essentielles:

� les profils utilisateurs

� le(s) serveur(s) d'application (AS)

GAGLO Kokou

2.6.1. Le profil utilisateur

Lorsqu'un utilisateur souscrit à un abonnement IMS chez un opérateur, l'opérateur lui assigne

un profil utilisateur. Ce profil utilisateur contient au moins une

service. Il est à noter qu'un abonnement IMS peut concerner plusieurs profils de services ce

qui permet d'avoir des traitements selon les identités publiques par exemple.

2.6.2. Le profil de service

Un profil de service est un ens

utilisateur particulier.

Figure

Ces informations sont transférées du HSS vers le S

opérations qui sont le SAA et PPR

Diameter au format XML. Il est constitué de trois parties.


Le profil utilisateur


un profil utilisateur. Ce profil utilisateur contient au moins une identité privée et un profil de



Le profil de service

Un profil de service est un ensemble d'informations stocké dans le HSS et qui concerne un

Figure 2.9 : Structure d’un profil utilisateur

Ces informations sont transférées du HSS vers le S-CSCF qui sert l'utilisateur à travers deux

et PPR. Le profil de service est transmis sous la forme d'une AVP

est constitué de trois parties.



identité privée et un profil de



emble d'informations stocké dans le HSS et qui concerne un

CSCF qui sert l'utilisateur à travers deux

Le profil de service est transmis sous la forme d'une AVP

GAGLO Kokou

2.6.2.1. L'identification publique

Cette partie indique les identités publiques de l'utilisateur qui sont concernées par le profil de

service. Ces identités peuvent être soit des URI SIP ou des URI téléphoniques. Chaque

identité publique contient une information d'interdiction qui lorsqu'elle est positionnée

indique au S-CSCF d'interdire l'utilisation de cette identité publique dans une com

IMS autre que l'enregistrement ou le réenregistrement.

2.6.2.2. La politique media

Cette information est transportée dans l'autorisation de service du réseau cœur (Core

Network). Elle contient un entier qui indique le profil media auquel l'abonné a sous

S-CSCF (ex. les paramètres SDP) et permet aux opérateurs de définir plusieurs profils

d'abonnés au sein de leur réseau IMS. Le S

statique qui fait la correspondance entre l'entier et le profil media.

pas standardisée et est fonction de l'opérateur.

2.6.2.3. Le déclenchement des services

L'information sur le déclenchement des services se présente sous la forme d'une IFC (Initial

Filter Criteria). Une IFC décrit quand et comment une

particulier.


L'identification publique


vice. Ces identités peuvent être soit des URI SIP ou des URI téléphoniques. Chaque


CSCF d'interdire l'utilisation de cette identité publique dans une com

IMS autre que l'enregistrement ou le réenregistrement.

La politique media


Network). Elle contient un entier qui indique le profil media auquel l'abonné a sous

CSCF (ex. les paramètres SDP) et permet aux opérateurs de définir plusieurs profils

d'abonnés au sein de leur réseau IMS. Le S-CSCF a besoin alors d'une basse de données

statique qui fait la correspondance entre l'entier et le profil media. La valeur de l'entier n'est

pas standardisée et est fonction de l'opérateur.

Le déclenchement des services


Filter Criteria). Une IFC décrit quand et comment une requête est transmise vers un AS

Figure 2.10 : Structure d'un IFC



vice. Ces identités peuvent être soit des URI SIP ou des URI téléphoniques. Chaque


CSCF d'interdire l'utilisation de cette identité publique dans une communication


Network). Elle contient un entier qui indique le profil media auquel l'abonné a souscrit dans le

CSCF (ex. les paramètres SDP) et permet aux opérateurs de définir plusieurs profils

CSCF a besoin alors d'une basse de données

La valeur de l'entier n'est


requête est transmise vers un AS


Le premier champ d'une IFC c'est sa priorité. Le champ priorité définit comment cette IFC

sera évaluée par rapport aux autres IFC appartenant au même profil de service. Le S-CSCF

choisit en premier l'IFC avec la plus grande priorité (plus le champ priorité est moins grand

plus l'IFC est prioritaire).

Après les IFCs, on trouve au plus un « Trigger Point ». Un trigger point est une expression qui

détermine si une requête SIP doit être transmise à un AS spécifique. Il est constitué d'un

ensemble de filtres appelés « Service Point Trigger » (SPT).

Le SPT nous permet d'accéder à différentes informations de la requête SIP :

• la valeur de la Requête URI

• la méthode de la requête (ex : INVITE, MESSAGE)

• la présence ou l'absence d'un en-tête SIP particulier

• le type de session (requête initiée par un utilisateur servi, destinée à un utilisateur

enregistré ou à un utilisateur non enregistré)

• la description de la session (contenu SDP)

Les SPTs peuvent être liées par des expressions logiques (AND, OR, NOT). S'il n'y a aucun

Trigger Point alors toute requête est transmise automatiquement à l'AS.

Après les « Trigger Point » (constitués de SPT), on trouve l'URL de l'AS qui recevra la

requête si les conditions des SPT sont respectées. On trouve aussi un champ qui décrit ce qu'il

faut faire (continuer ou annuler le traitement) au cas où l'AS ne peut pas être contacté.

Chapitre 6 : Déploiement

des services


3. LES SERVICES IMS

3.1. Présence

La présence est faite essentiellement de deux choses : elle implique de mettre à la disposition

des autres mon statut et que le leur aussi me soit disponible.

Figure 3.1 : Aperçu de la présence

3.1.1. Le service de présence dans l’IMS

L’architecture du service de présence (basée sur celle d’OMA : Open Mobile Alliance)

présente les blocs suivants :

• « Presence Server » : un serveur d’application IMS qui gère les informations de

présence chargées par les différentes sources de présence et répond aux réponses de

souscription.

• « Resource List Server » : un serveur d’application IMS qui accepte et gère les

souscriptions aux listes de présence.

CHAPITRE 3


• « XML Document Management Servers » : des serveurs d’application qui sauvegarde

les données relatives au service de présence. Quatre différents AS sont définit :

o Presence XDMS : un serveur qui contient les règles pour les informations de

souscription et les règles pour les informations de publication.

o RLS XDMS : un serveur qui contient la liste des contacts d’un utilisateur.

o Presence Content XDMS : un serveur qui gère les fichiers média pour le

service de présence.

o Shared XDMS : un serveur qui peut être réutilisé par différents serveurs

d’application.

• « Content Server » : une entité qui est capable de gérer les types d’objet MIME pour

la présence en permettant à la source de présence ou au serveur de présence de stocker

des objets de type MIME.

• « Presence source » : une entité qui fournit les informations de présence au service de

présence. La source de présence peut être localisée au niveau du terminal de

l’utilisateur ou dans une entité du réseau.

• « Presence watcher » : une entité qui demande les informations de présence à propos

des ressources.

• « Watcher agent » : une entité qui contrôle l’utilisation des « Presence Watchers »

dans le domaine.

• « Watcher Information Subscriber » : une entité qui demande les informations à

propos des statuts de présence auprès du service de présence

La figure 3.2 présente l’architecture de la présence avec un terminal comme source de

présence.


Figure 3.2 : Architecture de la présence

3.1.2. Publication des informations de présence

Pour publier ou mettre à jour des informations, la source de présence charge les informations

en utilisant la méthode SIP PUBLISH au niveau du serveur de présence.

Figure 3.3 : Publication de présence


3.1.3. Souscription au service de présence

Pour obtenir des informations à propos des autres utilisateurs, le watcher (Alice) souscrit au

service de présence en envoyant une requête SIP SUBSCRIBE dans laquelle il peut être

spécifié un utilisateur particulier ou une liste d’utilisateur donnée (exemple :

sip :[email protected] qui contient les utilisateurs Bob et Sarah). Dans le dernier cas, la

requête sera redirigée vers le RLS qui va autoriser la souscription d’Alice ensuite souscrire

Alice aux informations de Bob et Sarah de façon individuelle.

Figure 3.4 :Souscription aux informations de présence


3.2. Gestion de groupe

La gestion de groupe est un service qui permet aux utilisateurs de stocker des données

spécifiques à un service dans le réseau du fournisseur. Ces données peuvent être créées,

modifiées et supprimer à tout moment par l’utilisateur. Plusieurs services comme la présence,

le PoC (Push to Talk over Cellular), ont besoin de ce support pour l’accès et la manipulation

de certaines données dont ils ont besoin. Comme exemples de ces données on peut citer la

liste des utilisateurs qui sont des potentiels « notifiers », liste qui peut permettre à un autre

utilisateur de souscrire aux informations de présence de ce groupe d’utilisateurs ; le document

contenant les règles d’accès d’un utilisateur spécifique à une ressource ; les données de

configuration pour les services IMS supplémentaires à l’instar du renvoie d’appel vers un

numéro spécifique lorsque l’utilisateur est injoignable.

Les données sont sauvegardées dans le réseau et sont accessibles, manipulables par les

utilisateurs autorisés.

OMA a adopté le terme XDM (XML Document Management) comme synonyme du terme

gestion de groupe. Les services XDM spécifient les documents qui peuvent être partagés par

de multiples services.

Le XCAP (XML Configuration Access Protocol) défini par l’IETF (Internet Engineering

Task Force) a été choisi par OMA et 3GPP (Third Generation Partnership Project) comme le

protocole pour transporter, accéder, lire et manipuler les documents XML qui contiennent les

données.

3.2.1. XML Configuration Access Protocol

Dans l’Extensible Markup Language (XML) Configuration Access Protocol (XCAP) un

utilisateur est capable de charger des informations sur le serveur XCAP qui met ces dernières

à la disposition des serveurs d’application qui les utilisent pour satisfaire la demande d’autres

utilisateurs. Avec XCAP, l’utilisateur est également autorisé à manipuler, ajouter et effacer

ces données. Un exemple de donnée que l’utilisateur peut charger est sa liste de ressources

pour la présence. XCAP utilise le HTTP (HyperText Transfert Protocol) pour charger et lire

les informations générées par les utilisateurs. Ces informations sont représentées à base du

XML.


Il existe quatre (4) opérations héritées du HTTP pour créer (HTTP PUT), chercher (HTTP

GET), modifier (HTTP PUT) et effacer (HTTP DELETE).

Figure 3.5 : Les opérations XCAP

3.2.2. La liste de ressources

Les spécifications SIP à propos du mécanisme notification des événements permet à un

utilisateur de demander des notifications sur l’état d’une ressource lorsqu’il change. Sans

aucun mécanisme cela entrainerait que l’abonné génère des requêtes SIP SUBSCRIBE pour

chaque ressource. Pour contrôler les congestions et gérer la bande passante, il n’est pas bon

d’avoir des terminaux générant de multiples requêtes SUBSCRIBE, une pour chaque

ressource. Pour résoudre ce problème la RFC4662 décrit une extension de notification

d’événements qui donne la possibilité aux utilisateurs de souscrire à une liste de ressources

avec une seule requête SUBSCRIBE. Cette liste est identifiée par un URI et contient zéro ou

plusieurs URI pointant vers des ressources atomiques ou d’autres listes. Dans un système de

présence ces ressources sont les statuts de présences (presentities en anglais). L’entité qui

envoie la requête SUBSCRIBE pour la liste est le RLS (Resource List Server). Le RLS peut

générer des souscriptions individuelles pour chaque ressource de la liste. Cette souscription

peut ou ne pas être des requêtes SIP SUSCRIBE. La figure 3.6 montre la solution.


Figure 3.6 : Exemple de flux de souscription avec RLS

Un client envoyant la requête SUBSCRIBE pour une liste inclut un en-tête Supported avec un

tag d’option avec la valeur ‘eventlist’. Si cette option tag n’est pas incluse et l’URI dans la

requête représente une liste alors le RLS retourne une erreur ‘421 Extension Required’. Si la

souscription est acceptée le RLS génère une requête NOTIFY contenant les informations sur

l’état de la liste. La requête NOTIFY contient l’en-tête Require avec une option tag avec la

valeur ‘evntlist’. Il contient aussi un corps de type MIME ‘multipart/related’ qui en interne

transporte une MIME ‘application/rlmi+xml’ qui contient les meta-informations de la liste de

ressource.

Comme exemple, Alice utilise deux terminaux, un à la maison et un au bureau. Elle crée sa

liste de ressource avec son terminal à la maison et ajoute Bob et Sarah comme ses contacts.

La requête XCAP suivante est créée pour envoyer la liste de ressource (contacts) sur le

serveur :

PUT /resource-lists/users/sip:[email protected]/fri ends HTTP/1.1 Content-Type:application/resource-lists+xml Host: xcap.example.com <?xml version="1.0" encoding="UTF-8"? > <resource-lists xmlns="urn:ietf:params:xml:ns:resour ce-lists" > <list name="friends" > <entry uri="sip:[email protected]" > <display-name >Bob</display-name >

</entry >

<entry uri="sip:[email protected]" >


<display-name >Sarah </display-name > </entry > </list >

</resource-lists >

Alice une fois arrivée au bureau décide d’ajouter John à ses contacts. Elle le fait en utilisant

son terminal au bureau et modifie la liste qu’elle a créée plus tôt à la maison. La figure 3.7

résume l’exemple.

Figure 3.8 : Exemple de liste de ressources

3.3. Push to Talk Over Cellular

Le service Push to Talk Over Cellular permet à un utilisateur de passer des appels d’un

utilisateur à un autre utilisateur ou d’un utilisateur à un groupe d’utilisateurs. L’idée est

simple. L’appelant sélectionne un correspondant ou un groupe qu’il veut joindre, il appuie sur

la touche dédié au PoC et commence à parler. La session établie est temps réelle. Les

sessions Push to Talk sont des communications unidirectionnelles : quand une personne parle

les autres écoutent. Le tour de parole est demandé en appuyant la touche PoC dédiée et est

obtenu selon la règle du premier venu, premier servi. Les appels Push to Talk sont assez

souvent établis sans que les correspondants ne décrochent et utilisent le haut parleur du

téléphone de l’appelé. Un utilisateur peut éventuellement choisir de recevoir un appel Push to

Talk à condition qu’il ait accepté l’invitation. La conservation peut aussi être écoutée à travers

les écouteurs du téléphone si besoin est.


Le service Push to Talk est basé sur du multi ou unicasting. Le client envoie le paquet du

trafic au serveur d’application Push to Talk qui, dans le cas d’un multicasting, duplique le

trafic pour tous les correspondants (voir figure 3.9). Une session de control PoC et les autres

signalisations sont basées sur SIP et le trafic voix est transporté par RTP/RTCP (Real-Time

Transport Protocol/Real-Time Transport Control Protocol).

Le service PoC utilise mieux les ressources radio et les ressources cellulaires que les services

basés sur les circuits. Il fournit une meilleure couverture puisqu’il utilise celle fournie par les

réseaux GSM/WCDMA/CDMA. Les paragraphes qui suivent décrivent le PoC définit par le

standard OMA PoC Release 1.

Figure 3.9 : Push to Talk Over Cellular

3.3.1. Architecture du PoC


Figure 3.10 :Architecture du PoC

L’architecture OMA PoC Release 1 est basée sur des clients PoC, un serveur d’application

PoC et un PoC XML Document Management Server (XDMS). Un PoC XDMS est un serveur

XDMS qui sauvegarde des données spécifiques PoC. En utilisant une interface POC-8 basée

sur XCAP (voir figure 3.10), le serveur PoC peut chercher des documents traitant du PoC et

en utilisant une interface POC-5 (voir figure 3.10), le serveur PoC peut chercher les listes

génériques (exemple les membres de [email protected]) sur un serveur XDMS

simple. Le serveur PoC est connecté au réseau IMS via l’interface ISC.

3.3.1.1. Le serveur PoC

Un serveur PoC est un serveur d’application dans l’architecture IMS qui fournit le service

PoC aux utilisateurs. Il contrôle les procédures de démarrage d’une session, les politiques

définies pour un groupe de sessions PoC( exemple : qui est autorisé à joindre les autres, qui

est autorisé à inviter d’autres membres, qui décide quand un utilisateur particulier doit quitter

la session), fournit les informations à propos des utilisateurs du groupe. Le serveur PoC

s’occupe également de la distribution et l’adaptation du media si besoin est. Bref, le serveur

PoC cumule les trafics associés au service PoC au niveau du plan contrôle et au niveau du

plan utilisateur. Pour ce faire, il utilise les interfaces ISC et Mb.


Dans le standard OMA, deux fonctions ont été attribuées au serveur PoC : la fonction de

participant PoC et celle de contrôle PoC. La tâche d’assignement du serveur PoC est effectuée

durant l’initiation de la session de façon à ce qu’un seul serveur PoC effectue le contrôleur

PoC et un ou plusieurs serveurs PoC jouent le rôle de participants PoC selon le nombre de

sessions participants au PoC (figure 3.11).

La signalisation SIP provenant des clients PoC va toujours vers tous les serveurs PoC qui

jouent le rôle de participants, ils envoient à leur tour la signalisation au serveur PoC qui

s’assure du contrôle.

Figure 3.11 :Architecture du server PoC

3.3.1.2. Le client PoC

Le client PoC selon le standard OMA est une fonctionnalité dédiée à l’UE qui est en mesure

de se connecter lui-même à l’IMS en utilisant des tag ayant des caractéristiques PoC et en

indiquant la version du standard PoC dans la requête SIP REGISTER, d’initier, modifier les

sessions PoC et supporter le service PoC.

3.4. IPTV

La télévision a évolué pendant plusieurs années, ce qui a commencé comme télévision

numérique terrestre ou satellitaire peut maintenant, et grâce à l’évolution technologique, être

délivré à travers un large éventail de réseaux fixes ou mobiles. Le déploiement de la télévision


basé sur IP sur des réseaux d’accès large bande est devenu possible grâce aux différents types

de réseaux d’accès haut débits combinés avec des algorithmes efficaces de codage média. La

plupart des opérateurs télécoms offre des services « Triple Play » qui inclut dans une offre de

services la vidéo, la voix et données. Nous commençons cette partie par la description du

service IPTV basé sur une architecture IMS.

3.4.1. Architecture de l’IPTV

Figure 3.12 : Architecture de réseaux convergents offrant les services d’IPTV

3.4.2. Description de la plateforme IPTV basée sur l’IMS

La plateforme IPTV basé sur l’IMS est une architecture de plateforme de services qui est en

mesure d’offrir les services de la télévision sur IP contrôlés et gérés par le réseau cœur IMS et

acheminés indépendamment sur un réseau de transport IP. Cette architecture spécifie les

fonctions d’IPTV supportées par le réseau IMS et réutilise les mécanismes prédéfinis dans

celle-ci pour l’initiation et le control de service en se basant sur SIP.


Les services IPTV peuvent être divisés en 3 catégories essentielles :

• « Broadcast services (BC) » : les chaines TV et radios en « broadcast » ou « multicast »

sur le réseau

• « Video On Demand » : En général c’est un service « unicast » qui offre à l’abonné sur sa

demande le contenu média qu’il désire.

• « Personal Video Recorder Services » (PVR) : Inclut les services qui permettent

l’enregistrement, la mise en pause et le déplacement dans le temps du contenu média en

direct.

Le déploiement de l’IPTV sur une architecture IMS présente plusieurs avantages. D’une part,

le service IPTV pourra interagir avec d’autres services (présence, chat, …) ce qui apportera

une valeur ajouté pour le client et une nouvelle source de revenue pour l’opérateur. D’autre

part, les opérateurs de télécommunication seront en mesure d’offrir le « quadruple-play » qui

intègre voix, vidéo, donnée et mobilité avec la possibilité d’adapter le service selon le choix

de l’utilisateur.

La figure 3.12 présente l’architecture du service IPTV. Toutes les technologies d’accès

disponibles sont intégrées dans un seul domaine de réseau d’accès convergent.

GAGLO Kokou

4. MISE EN PLACE DE LA

4.1. Architecture de la plateforme

Figure 4.1

4.2. Présentation et installation

4.2.1. OpenIMSCore

L'OpenIMSCore est une implémentation des Call Session Control Functions (CSCFs) et du

HSS (Home Subscriber Server), qui forment ensemble le réseau coeur des architectures

IMS/NGN comme spécifié par le 3GPP, le 3GPP2, l'ETSI TISPAN et le Packet

intiative. Les outils utilisés dans le développement sont tous des outils open source (ex

Express Router (SER) et MySQL).


MISE EN PLACE DE LA PLATEFORME IMS

Architecture de la plateforme

Figure 4.1 : Architecture de la plateforme

et installation des logiciels utilisés

OpenIMSCore

IMSCore est une implémentation des Call Session Control Functions (CSCFs) et du


IMS/NGN comme spécifié par le 3GPP, le 3GPP2, l'ETSI TISPAN et le Packet

intiative. Les outils utilisés dans le développement sont tous des outils open source (ex

MySQL).

CHAPITRE


IMSCore est une implémentation des Call Session Control Functions (CSCFs) et du


IMS/NGN comme spécifié par le 3GPP, le 3GPP2, l'ETSI TISPAN et le PacketCable

intiative. Les outils utilisés dans le développement sont tous des outils open source (ex. le SIP

CHAPITRE 4


Né du domaine de la Recherche & Developpement, le projet OpenIMSCore, initié par

l'institut de recherche allemand FOKUS a pour but de combler le vide dans le monde open

source de l’IMS. Il a aussi pour but de fournir une implémentation de référence du noyau IMS

pour tester cette technologie et mettre en œuvre des concepts qui entourent l’IMS dans le

cadre des travaux de recherche. A travers ce projet, tous les développeurs potentiels des

services IMS devrait avoir une interface complète de contrôle IMS, conforme à 3GPP, ce qui

va leur permettre de s’en servir pour développer et tester leurs services. Cependant, aussi au

niveau de la couche accès, l’OpenIMSCore, vise à susciter le développement de composants

et concepts qui relient le noyau IMS aux divers réseaux d’accès.

L’open source a apporté une puissante innovation au monde de l’internet. Dans cette même

vision, l’institut de recherche FOKUS a tenu à ce que les fonctions de cheminement de noyau

d'IMS soient entièrement et librement disponibles au public pour les développer et les rendre

ajustables aux divers besoins et conditions des petites et moyennes entreprises, universités et

départements R&D des opérateurs et des fournisseurs [B1].

Figure 4.2 : Architecture de l’OpenIMSCore


4.2.1.1. Les CSCFs

Sur le plan fonctionnel, les CSCFs sont des proxys SIP. Ils se basent sur SER qui peut agir

autant que registrar, proxy ou serveur de redirection et supporter des milliers d’appels par

seconde. Grace à sa structure modulaire, il est possible d’y ajouter de nouvelles

fonctionnalités, ce qui permet aux différents CSCFs de se conformer aux spécifications 3GPP.

Des modules supplémentaires sont utilisés pour fournir des fonctions communes comme les

fonctionnalités Diameter et l’accès à la base de donnée [B1].

4.2.1.1.1. Le P-CSCF

Dans l'implémentation actuelle de l'Open IMS, le P-CSCF joue le rôle de pare-feu de niveau

applicatif dans le réseau cœur : seules les entités enregistrées au niveau du réseau sont

autorisées à envoyer des messages sur le réseau IMS et le P-CSCF s'assure de l'identité des

utilisateurs. Après un enregistrement réussi auprès du réseau IMS, les messages utilisateurs

subséquents sont transmis sur la base des informations DNS vers le réseau IMS approprié

[B1].

Figure 4. 3: Open IMS Proxy-CSCF

4.2.1.1.2. L’I-CSCF

L’Interrogating CSCF de l’open source IMS joue le rôle d'un proxy sans mémoire qui

interroge le HSS pour router les messages vers le S-CSCF adéquat. Il implémente donc

l'interface Cx qui le relie au HSS. Il est optimisé pour être rapide et sauvegarde le minimum

d'informations [B1].


Figure 4. 4 : Open IMS Interrogating-CSCF

4.2.1.1.3. Le S-CSCF

Le S-CSCF de l’open source IMS a été implémenté conformément aux standards normatifs de

l’IMS. Il joue un rôle principal sur le plan contrôle en gérant le contrôle de la session IMS

mais aussi l’enregistrement de l’abonné au réseau. Le protocole Diameter a été implémenté

dans l’open source IMS pour permettre la communication entre le S-CSCF et le HSS.

Figure 4. 5 : Open IMS Serving-CSCF

4.2.1.2. Le HSS

Fokus a développé son propre prototype HSS, the Fokus HSS (FHoSS), qui est entièrement

écrit en java et basé sur de l’open source. Les données de l’utilisateur sont sauvegardées dans

une base de données MySQL externe. Elle constitue une base de données pour


l’OpenIMSCore. Il a été aussi fournit une interface web pour faciliter la gestion des

utilisateurs, des serveurs d’applications, des paramètres de configuration…

Figure 4. 6 : Open IMS HSS

Ses deux fonctions principales sont :

• Base de données des abonnés.

o Identification de l'usager.

o Informations de sécurités propres à l'usager.

o Informations de localisation de l'usager.

o Profil de l'usager (services, informations relatives aux services…).

• Equivalent HLR (Home Location Register) d'un réseau GSM.

o Base de donnée standard .

o Protocoles d'authentification AAA (DIAMETER).

o Fonctions de traductions évoluées.

4.2.1.3. Installation d’OpenIMSCore

[Voir annexe A.1–Mise en place du plan de contrôle IMS OpenIMSCore et figures de

l’interface FHoSS]


4.2.2. OPENSIPS

Opensips est un serveur d'application (AS) Open source arrivant à maturité. Opensips a

débuté en 2005 et fait suite au projet Openser.

4.2.2.1. Installation et configuration

[Voir annexe A.2–Installation de OPENSIPS]

4.2.2.2. Création de l’AS de présence au niveau du HSS

Le FHoSS vient par défaut avec le service de présence paramétré. Il est d’ailleurs conseillé

dans la documentation de d’installer le serveur de présence sur la machine où tourne le S-

CSCF. Voici quelques captures du paramétrage de ce service.

Figure 4.7 : Paramétrage du Service Profile de présence


Figure 4.8 : Paramétrage de l’Application Server de présence

Figure 4.9 Le Trigger Point de présence


Figure 4.10 : Paramétrage de l’Initial Filter Criteria de présence

4.2.2.3. Simulation du service de présence

Figure 4.11 : L’utilisateur Alice souscrit aux informations de présence de Bob


Figure 4.12 : L’utilisateur Bob souscrit aux informations de présence d’Alice

Les utilisateurs Bob et Alice ont chacun ajouté l’autre à sa liste de contacts (figure 4.11 et

4.12). Le statut de présence de Bob est automatiquement mis à jour chez Alice lorsqu’il est

changé et vice versa. Les figures 4.13 et 4.14 suivantes nous permettent, grâce à l’outil open

source Siremis (voir son installation en annexe A6), de voir les informations renseignées au

niveau du SGBD (Système de Gestion de Base de Donnée) Mysql pour avoir ainsi une vue

globale sur le serveur de présence.


Figure 4.13 : Liste des Watchers

Figure 4.14 : Liste des Presentities

4.2.3. OPENXCAP

OpenXCAP est une implémentation Open Source d'un serveur XCAP. Il est conçut pour

fonctionner facilement avec Opensips en prévenant ce dernier que quelque chose à changé

dans le document XCAP par un message refreshWatchers et qu'il doit donc agir en

conséquence.


Figure 4.15 : SIP SIMPLE Server

4.2.3.1. Installation et configuration

[Voir annexe A.3–Installation de OPENXCAP]


4.2.3.2. Simulation du service de mobilité

Figure 4.16 : Liste de contact de Samuel connecté sur un poste 1


Figure 4.17 : Liste de contact de Samuel connecté un poste 2

L’utilisateur Samuel s’est connecté sur son poste à la maison (le poste 1 de la figure 4.16) et a

ajouté deux contacts Alice et bob à sa liste de contact. Supposons qu’il parte au travail et se

reconnecte sur son poste au bureau (le poste 2 de la figure 4.17). Grâce au serveur XDMS qui

se trouve dans le réseau, il retrouve intégralement ses contacts. En effet comme présentée sur

les figures 4.18 et 4.19 avec l’outil Siremis, la liste de contact de Samuel a été sauvegardée au

format xml dans une base de données.


Figure 4.18 : Liste de contact des utilisateurs stockée par le XMDS

Figure 4.19 : Détails du fichier properties-resource-list.xml de Samuel


4.2.4. La Video à la Demande (VoD)

4.2.4.1. Serveur media avec VLC media player

Lorsqu'on veut diffuser un flux audio ou vidéo sur internet, le RTSP est un des protocoles les

plus adaptés car il permet de diffuser à n'importe qui sans avoir besoin de définir l'adresse IP

du client à l'avance. C'est ce qui en fait un protocole idéal pour la VoD (Vidéo à la demande).

4.2.4.1.1. Installation et configuration

[Voir annexe A.4 –Installation et configuration du media server VLC]

4.2.4.1.2. Simulation des flux RTSP

Figure 4.20 : Utilisation du navigateur firefox pour visualiser la vidéo référencée par ‘clip’

Figure 4.21 : Flux vidéo précédent ouvert avec le lecteur totem de Linux


4.2.4.2. IPTV AS avec UCT Advanced IPTV

UCT Advanced IPTV est un serveur d’application open source qui représente une mise en

œuvre conforme aux normes des services d’IPTV basée IMS. Il a été crée dans le cadre des

travaux de recherches sur l’IMS du « the Communications Research Group » à l’université

de Cape Town en Afrique du Sud.

L’architecture est montré ci-dessus (figure 3.12), elle met en œuvre l’architecture

OpenIMSCore, un client IMS (dans notre cas UCT IMS Client 1.0.12), le serveur

d’application UCT Advanced IPTV et un serveur média qui supporte RTSP.

4.2.4.2.1. Installation et configuration

[Voir annexe A.5 - Installation de UCT Advanced IPTV]

4.2.4.2.2. Création de l’AS VoD au niveau du HSS

Figure 4.22 : Paramétrage du Service Profile de l’IPTV


Figure 4.23 : Paramétrage de l’Application Server de l’IPTV

Figure 4.24 : Paramétrage du Trigger Point de l’IPTV


Figure 4.25 : Paramétrage de l’Initial Filter Criteria de l’IPTV

4.2.4.2.3. Simulation du service VoD


Figure 4.26 : Demande du service IPTV par l’utilisateur James

Il est à noter que de tous les clients que nous avons testés, il n’y a que l’UCTIMSCLIENT

dans sa version 2.1.012 qui supporte la VoD. De plus il faut obligatoirement que l’utilisateur

ait souscrit au service de VoD pour pouvoir en bénéficier.


Par l’intermédiaire d’IMS, les réseaux mobiles et fixes ne se contentent plus d’être des

réseaux téléphoniques classiques. Ils tendent à converger, chaque équipement passant alors au

tout IP. L’IMS permet d’établir des communications multiutilisateurs, multi-terminaux,

multisessions et multiservices temps-réel et non temps-réel. Il est possible de plus de créer de

nouveaux usages en utilisant des interactions entre ces services.

Etant à ses débuts, les entreprises du secteur, que ce soit les opérateurs, les régulateurs ou les

fournisseurs de services à valeurs ajoutées, auront un grand besoin de formation ou mise à

niveau sur l’IMS. C’est pour satisfaire à ce besoin que la société RTN, en vue de se préparer

pour ce moment, nous a confié l’étude de la mise en place d’une plateforme de formation

IMS. Malgré la rareté de documents (carrément inexistants en français), d’articles sur la

technologie IMS, vue qu’elle est très récente, le peu d’information que nous avons pu

recueillir nous a permis tout le long de ce document d’exposer les divers possibilités de cette

technologie qui s’annonce comme le futur des réseaux existants. Elle permet entre autre

d’avoir la convergence de tous les réseaux existants vers l’IP, de bénéficier des services

autrefois exclusivement réservés à Internet, de favoriser la mobilité et le roaming dans les

réseaux et de créer un autre pôle dans le monde des télécoms : celui des fournisseurs de

service.

Notre travail ne rapporte qu’une infime partie des possibilités que propose le réseau IMS. De

façon non exhaustive, il serait aussi intéressant de se pencher sur la qualité de service qu'il

offre, les possibilités de développement de services SIP Application Server (grâce au couple

Mobicents JainSlee et Java), la facturation et son degré de sécurité, même si après quelques

tests non poussés nous avions remarqués qu’elle était plus sécurisée que la ToIP traditionnelle

puisqu’il nous était impossible par exemple de capturer le flux RTP d’une session d’appel.

CONCLUSION


• Bibliographie

[B1]: IP Multimedia Subsystem Handbook Edited by Syed A. Ahson, Mohammad Ilyas

[B2]: Téléphonie sur IP 2è Edition de Laurent Ouakil et Guy Pujolle

[B3]: The IMS IP Multimedia Concepts and Services Third Edition; Miikka Poikselkä,

Georg Mayer

• Webographie

[W1]: http://www.openimscore.org consulté vers Décembre 2010

[W2]: http://www.openimscore.org/installation_guide consulté vers Décembre 2010

[W3]: http://developer.berlios.de/projects/uctimsclient/ consulté vers Janvier 2011

[W4]: http://uctimsclient.berlios.de/index.html consulté vers Janvier 2011

[W5]: http://uctimsclient.berlios.de/uctiptv_advanced_howto.html consulté vers Janvier

[W6]: http://www.forum-ims.org/viewtopic.php?f=36&t=27 consulté depuis Février 2011

[W7]: http://www.forum-ims.org/viewtopic.php?f=36&t=94 consulté depuis Février 2011

[W8]: http://www.opensips.org/ consulté vers Avril 2011

[W9]: http://openxcap.org/wiki/Installation consulté vers Avril 2011

[W10]: http://openxcap.org/wiki/Configuration consulté vers Avril 2011

[W11]: http://kb.asipto.com/siremis:install20:main consulté vers Août 2011

BIBLIOGRAPHIE ||

GAGLO Kokou Mise en place d’une plateforme de formation IMS

i i

ANNEXES

GAGLO Kokou Mise en place d’une plateforme de formation IMS ii

Tableau 2.1: Les interfaces IMS

Tableau 2.1 (suite): Les interfaces IMS

GAGLO Kokou Mise en place d’une plateforme de formation IMS iii

Tableau 2.2: Commandes Cx

GAGLO Kokou Mise en place d’une plateforme de formation IMS iv

Tableau 2.2 (suite): Commandes Cx

Tableau 2.3 : Commandes Sh

A.1 Mise en place du plan de contrôle IMS et figures de l’interface FHoSS

apt-get install bison mysql-server phpmyadmin flex libxml++2.6-2 libxml++2.6-dev curl libcurl4-gnutls-dev libmysql6 .1-cil libmysqlclient16-dev openjdk-6-jdk mkdir /opt/OpenIMSCore cd /opt/OpenIMSCore mkdir FHoSS svn checkout http://svn.berlios.de/svnroot/repos/op enimscore/FHoSS/trunk FHoSS

GAGLO Kokou Mise en place d’une plateforme de formation IMS v

mkdir ser_ims svn checkout http://svn.berlios.de/svnroot/repos/op enimscore/ser_ims/trunk ser_ims cd FHoSS ant compile deploy cd ../ser_ims make install-libs all ./configurator.sh -> Domain Name:rtn.sn -> IP Adress :192.168.1.35 ->File to change ["all" for everything, "exit" to quit]:all cd ../../ sed -i -e "s/open-ims.test/rtn.sn/g" FHoSS/scripts/ hss_db.sql sed -i -e "s/open-ims.test/rtn.sn/g" FHoSS/scripts/ userdata.sql sed -i -e "s/127.0.0.1/192.168.1.35/g" FHoSS/script s/hss_db.sql sed -i -e "s/127.0.0.1/192.168.1.35/g" FHoSS/script s/userdata.sql mysql -u root -ppasser < FHoSS/scripts/hss_db.sql mysql -u root -ppasser < FHoSS/scripts/userdata.sql mysql -u root -ppasser < ser_ims/cfg/icscf.sql cp ser_ims/cfg/*.cfg . cp ser_ims/cfg/*.xml . cp ser_ims/cfg/*.sh . cd FHoSS/deploy/ sed -i -e "s/open-ims.test/rtn.sn/g" DiameterPeerHS S.xml sed -i -e "s/open-ims.test/rtn.sn/g" hss.properties sed -i -e "s/127.0.0.1/192.168.1.35/g" startup.sh sed -i -e "s/127.0.0.1/192.168.1.35/g" DiameterPeer HSS.xml sed -i -e "s/127.0.0.1/192.168.1.35/g" hss.properti es vim startup.sh

Remplacer

$JAVA_HOME/bin/java -cp $CLASSPATH de.fhg.fokus.hss .main.HSSContainer $1 $2 $3 $4 $5 $6 $7 $8 $9

Par :

/usr/lib/jvm/java-6-openjdk/bin/java -cp $CLASSPATH de.fhg.fokus.hss.main.HSSContainer $1 $2 $3 $4 $5 $ 6 $7 $8 $9 cd ../.. cp ser_ims/cfg/open-ims.dnszone /etc/bind/ cd /etc/bind vim named.conf.default-zones zone "rtn.sn" { type master; file "/etc/bind/rtnims"; }; mv open-ims.dnszone rtnims sed -i -e "s/open-ims.test/rtn.sn/g" rtnims sed -i -e "s/127.0.0.1/192.168.1.35/g" rtnims service bind9 restart nslookup rtn.sn Server: 127.0.0.1 Address: 127.0.0.1#53 Name: rtn.sn Address: 192.168.1.35

On démarre le P-CSCF dans un premier terminal

GAGLO Kokou Mise en place d’une plateforme de formation IMS vi

cd /opt/OpenIMSCore/ ./pcscf.sh

On démarre l’ I-CSCF dans un deuxième terminal

/opt/OpenIMSCore/ ./icscf.sh

On démarre le S-CSCF dans un troisième terminal

cd /opt/OpenIMSCore/ ./scscf.sh

On démarre le HSS dans un quatrième terminal

cd /opt/OpenIMSCore/FHoSS/deploy ./startup.sh

Si la configuration est bonne on devrait avoir :

Pour le P-CSCF une série de :

5(10767) INF:P-CSCF:---------- Registrar Contents begin -------- 5(10767) INF:P-CSCF:---------- Registrar Contents end ---------- 5(10767) INF:P-CSCF:---------- Subscription list begin --------- 5(10767) INF:P-CSCF:---------- Subscription list end -----------

Pour le I-CSCF et le S-CSCF :

14(10823) --- Peer List: --- 14(10823) S[R_Open] hss.rtn.sn:3868 D[ ] 14(10823) [16777216,10415] 14(10823) [16777216,4491] 14(10823) [16777216,13019] 14(10823) [16777217,10415] 14(10823) [16777221,10415]

Pour le HSS :

2011-08-16 20:11:17,794 INFO de.fhg.fokus.hss.main .TomcatServer - startTomcat Tomcat-Server is started. 2011-08-16 20:11:18,912 WARN org.apache.catalina.c onnector.MapperListener - registerEngine Unknown default host: 192.168.1.35

GAGLO Kokou Mise en place d’une plateforme de formation IMS vii

Figure A.1.1 : Interface de connexion au HSS

Le login est hssAdmin et le mot de passe est hss.

Figure A.1.2 : Page d’accueil du HSS

A.2 Installation d’OPENSIPS

apt-get install bison bisonc++ flex libsctp1 libmy sqlclient15-dev libxml2-dev libexpat1-dev libradiusclient-ng-dev l ibradiusclient-ng2 libcurl4-openssl-dev libxmlrpc-c3 libxmlrpc-c3-dev libperl-dev libsnmp-dev libconfuse0 libconfuse-dev build-essential wget http://opensips.org/pub/opensips/1.5.0/src/ope nsips-1.5.0-notls_src.tar.gz

GAGLO Kokou Mise en place d’une plateforme de formation IMS viii

Éditer le Makefile. Cherchez la ligne "exclude_modules=" et supprimer les modules qui nous

intéressent (les modules présents dans la liste ne seront pas compilés) :

jabber, cpl-c, xmpp, rls, mi_xmlrpc, xcap_client , db_mysql, presence, presence_xml, presence_mwi, presence_dialoginfo, p ua, pua_bla, pua_mi, pua_usrloc, pua_xmpp, pua_dialoginfo, perl, snmps tats, peering, carrierroute make make install cp opensips-1.5.0-notls/packaging/debian-etch/opens ips.default /etc/default/opensips cp opensips-1.5.0-notls/packaging/debian-etch/opens ips.init /etc/init.d/opensips vim /etc/default/opensips changer: RUN_OPENSIPS=no en: RUN_OPENSIPS=yes vim /etc/init.d/opensips changer: DAEMON=/usr/sbin/opensips RUN_OPENSIPS=not en : DAEMON=/usr/local/sbin/opensips RUN_OPENSIPS=yes groupadd opensips useradd -g opensips opensips mkdir /var/run/opensips chmod 777 /var/run/opensips chmod 777 /usr/local/etc/opensips/ vim /usr/local/etc/opensips/opensipsctlrc décommenter: # SIP_DOMAIN=opensips.org # DBENGINE=MYSQL # DBHOST=localhost # DBNAME=opensips # DBRWUSER=opensips # DBRWPW=”opensipsrw” # DBROUSER=opensipsro # DBROPW=opensipsro # DBROOTUSER=”root” # USERCOL=”username” # INSTALL_EXTRA_TABLES=ask # INSTALL_PRESENCE_TABLES=ask décommenter et changer: # PID_FILE=/var/run/opensips.pid en : PID_FILE=/var/run/opensips/opensips.pid vim /usr/local/etc/opensips/opensips.cfg commenter : modparam(“usrloc”, "db_mode", 0) Changer : port=5060 en : port=5065

GAGLO Kokou Mise en place d’une plateforme de formation IMS ix

Uncommenter:

#loadmodule “db_mysql.so”

#loadmodule “auth.so”

#loadmodule “auth_db.so”

#loadmodule "presence.so"

#loadmodule "presence_xml.so"

#modparam(“usrloc”, “db_mode”, 2)

#modparam(“usrloc”, “db_url”,

# “mysql://opensips:opensipsrw@localhost/opensips”)

#modparam(“auth_db”, “calculate_ha1 ″, yes)

#modparam(“auth_db”, “password_column”, “password”)

#modparam(“auth_db”, “db_url”,

# “mysql://opensips:opensipsrw@localhost/opensips”)

#modparam("presence|presence_xml", "db_url",

# "mysql://opensips:opensipsrw@localhost/ope nsips")

#modparam("presence_xml", "force_active", 1)

#modparam("presence", "server_address", "sip:192.16 8.1.35:5065")

Changer la route: route { … } par :

route{

# initial sanity checks -- messages with

# max_forwards==0, or excessively long requ ests

if (!mf_process_maxfwd_header("10")) {

sl_send_reply("483","Too Many Hops" );

exit;

};

if (msg:len >= 4096 ) {

sl_send_reply("513", "Message too b ig");

exit;

};

# if the request is for other domain use Us rLoc

# (in case, it does not work, use the follo wing command

# with proper names and addresses in it)

# presence handling

if(method=="PUBLISH"){

route(2);

}

if(method=="SUBSCRIBE"){

route(2);

}

GAGLO Kokou Mise en place d’une plateforme de formation IMS x

route(1);

}

Changer la route de presence: route[2] { } par :

route[2] { if (!t_newtran()) { sl_reply_error(); exit; }; if(is_method("PUBLISH")) { handle_publish(); #t_release(); } else if( is_method("SUBSCRIBE")) { handle_subscribe(); #t_release(); } exit;

}

Exécuter :

opensipsdbctl create

Répondre oui (y) à toutes les questions

mysql> GRANT ALL PRIVILEGES ON *.* TO opensips@loca lhost IDENTIFIED BY

‘opensipsrw’;

mysql> GRANT ALL PRIVILEGES ON *.* TO opensips@127. 0.0.1 IDENTIFIED BY

‘opensipsr’;

Pour le premier lancement, la commande suivante DOIT fonctionner :

sudo opensipsctl start

A.3 Installation d’ OPENXCAP

A.3.1 Installation

apt-get install python-lxml python-application py thon-gnutls python-

mysqldb python-imaging

GAGLO Kokou Mise en place d’une plateforme de formation IMS xi

Ajouter les dépôts suivant :

# AG Projects software deb http://ag-projects.com/ubuntu lucid main deb-src http://ag-projects.com/ubuntu lucid main

Puis

sudo apt-get update sudo apt-get install openxcap sudo apt-get install opensips-mi-proxy (sur la mach ine abritant opensips)

Opensips-mi-proxy remplace le module xml-rpc de Opensips. Ce module est obligatoire pour

la mise à jour des informations de présence au niveau du serveur Opensips suivant le

changement des règles XCAP établies par les utilisateurs.

A.3.2 Configuration

; ; Configuration file for OpenXCAP ; ; The values in the commented lines represent the d efaults built in the ; server software ; [Server] root = http://192.168.1.35:8888/xcap-root backend = OpenSIPS allow_external_references = No disabled_applications = [Authentication] default_realm = rtn.sn trusted_peers = any [TLS] [Database] authentication_db_uri = mysql://opensips:opensipsrw @localhost/opensips storage_db_uri = mysql://opensips:opensipsrw@localh ost/opensips subscriber_table = subscriber xcap_table = xcap [OpenSIPS] xmlrpc_url = http://192.168.1.35:8088 enable_publish_xcapdiff = yes ; ; Configuration file for OpenSIPS MI Proxy ; [OpenSIPS] socket = /var/run/opensips/socket [MIProxy] listen_url = http://192.168.1.35:8888 trusted = any

GAGLO Kokou Mise en place d’une plateforme de formation IMS xii

A.4 Installation du media server VLC

apt-get build-dep vlc libavcodec-unstripped-51

Création d’un fichier (config_vlc) de configuration du serveur media

new clip vod enabled setup clip input "file:///home/james/mediaserver/gi mme.avi" new app vod enabled setup app input "file:///home/james/mediaserver/apo logize.flv" new gotlovu vod enabled setup gotlovu input "file:///home/james/mediaserver /got_2_lov_u.mov" new waccel vod enabled setup waccel input "file:///home/james/mediaserver/ waccel_sa_griffe.mpg" new pcaraibe vod enabled setup pcaraibe input "file:///home/james/mediaserve r/pirate_caraibe.avi"

Script de démarrage du serveur sur le port 5554

#!/bin/bash vlc --ttl 12 --color -I telnet --vlm-conf /home/james/mediaserver/config_vlc --telnet-passwor d passer --rtsp-host 0.0.0.0:5554

A.5 Installation de UCT Advanced IPTV

Installation des parquets libexosip2-4 libexosip2-dev libxml2-dev

Télécharger le paquet deb d’ uctiptv_advanced sur le site https://developer.berlios.de. Pour

que le canal1 pointe sur la video reference par ‘clip’ sur le serveur media il faut configure

l’AS de la manière suivante:

vim /usr/share/uctiptv_advanced/key_value_file

<?xml version="1.0" encoding="UTF-8"?> <key-value_pairs> <key-value_pair> <key>channel1</key> <value>rtsp://iptv.rtn.sn:5554/clip</value> </key-value_pair> <key-value_pair> <key>channel2</key> <value>rtsp://iptv.rtn.sn:5554/app</value> </key-value_pair> <key-value_pair> <key>channel3</key> <value>rtsp://iptv.rtn.sn:5554/gotlovu</value> </key-value_pair> <key-value_pair> <key>waccel</key> <value>rtsp://iptv.rtn.sn:5554/waccel_sa_griffe</v alue>

GAGLO Kokou Mise en place d’une plateforme de formation IMS xiii

</key-value_pair> <key-value_pair> <key>pcaraibe</key> <value>rtsp://iptv.rtn.sn:5554/pcaraibe</va lue> </key-value_pair> </key-value_pairs>

A.6 Installation de l’outil Siremis

siremis-2.0# make apache-conf # siremis apache conf snippet ...

Alias /siremis "/var/www/siremis/siremis" <Directory "/var/www/siremis/siremis"> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny Allow from all <FilesMatch "\.xml$"> Order deny,allow Deny from all </FilesMatch> <FilesMatch "\.inc$"> Order deny,allow Deny from all </FilesMatch> </Directory> GRANT ALL PRIVILEGES ON siremis.* TO siremis@localh ost IDENTIFIED BY 'siremisrw';

Taper l’adresse http://adresseip/siremis

GAGLO Kokou Mise en place d’une plateforme de formation IMS xiv

Figure A.6.1 : Interface web d’installation de Siremis

Il est à noter que Siremis est un outil destiné l’origine à gérer le serveur de présence Kamailio

qui utilise une base de donnée openser. Ceci dit, il faut obligatoirement changer openser qui

est renseignée par défaut par opensips.

A.7 Installation et paramétrage des clients IMS

Qu’importe le système d’exploitation, pour utiliser un client IMS il faudra toujours configurer

le DNS.

GAGLO Kokou Mise en place d’une plateforme de formation IMS xv

Figure A.7.1: UCTIMSCLIENT (Ubuntu 8.04)

Figure A.7.2: MERCURO IMS CLIENT (Windows XP)

GAGLO Kokou Mise en place d’une plateforme de formation IMS xvi

Figure A.7.3 : myMOSTER

A.8 Quelques captures Wireshark des flux échangés sur notre réseau IMS

Figure A.8.1 : Capture générale de tous les appels VoIP dans le réseau

GAGLO Kokou Mise en place d’une plateforme de formation IMS xvii

Figure A.8.2 : Enregistrement de Bob

Figure A.8.3 : Bob appelle Alice

GAGLO Kokou Mise en place d’une plateforme de formation IMS xviii

Figure A.8.4 : Analyse graphique de l’appel de Bob vers Alice

Figure A.8.5 : Chat entre Bob et Alice

Figure A.8.6 : Utilisation du service VoD par James

GAGLO Kokou Mise en place d’une plateforme de formation IMS xix

Figure A.8.7 : Analyse graphique de la demande VoD de James

Technology

Mise en place d’une plateforme de formation IMS