SlideShare une entreprise Scribd logo
GAGLO Kokou Mise en place d’une plateforme de formation IMS
11
AAAA mon oncle Isaac Jogues GAGLO
DEDICACESDEDICACES
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
3
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
4
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.
GAGLO Kokou Mise en place d’une plateforme de formation IMS
5
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
6
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
7
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
8
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
9
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
10
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
11
Figure A.8.7 : Analyse graphique de la demande VoD par James......................................xix
GAGLO Kokou Mise en place d’une plateforme de formation IMS
12
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
13
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
14
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
15
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
A l’heure actuelle, les télécoms évoluent vers les réseaux NGN (Next Generation
Network) dont est issu l’IMS. Ainsi, il va de soi que les opérateurs, spécifiquement africains,
pensent à migrer leurs infrastructures. Il se pose alors la question de compétence dans ce
RTN, de part sa vocation, a pris conscience du besoin à venir dans le domaine des
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 & caisse
Dé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
A l’heure actuelle, les télécoms évoluent vers les réseaux NGN (Next Generation
que les opérateurs, spécifiquement africains,
pensent à migrer leurs infrastructures. Il se pose alors la question de compétence dans ce
RTN, de part sa vocation, a pris conscience du besoin à venir dans le domaine des
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
17
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
Mise en place d’une plateforme de formation IMS
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
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 (Unlicensed Mobile Access),
xDSL (xDigital Subscriber Line), Wi-Fi (Wireless Fidelity), WiMax (Worldwide
Mise en place d’une plateforme de formation IMS
18
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
les réseaux d’accès, on peut citer les plus classiques : GSM (Global System for Mobile
communications), UMTS (Universal Mobile Telecommunications System), CDMA
nsed Mobile Access),
Fi (Wireless Fidelity), WiMax (Worldwide
CHAPITRE 2
GAGLO Kokou Mise en place d’une plateforme de formation IMS
19
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
20
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).
Mise en place d’une plateforme de formation IMS
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
de l’enregistrement, l’établissement des sessions et forment le mécanisme de routage SIP. En
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
mesure d'effectuer. Les deux entités sont en mesure de libérer sessions au nom de l'utilisateur
SCF 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
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
Figure 2.2 : Les serveurs CSCF
Mise en place d’une plateforme de formation IMS
21
(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
de l’enregistrement, l’établissement des sessions et forment le mécanisme de routage SIP. En
'envoyer des données de charge à une fonction de
CSCF et S-CSCF sont en
mesure d'effectuer. Les deux entités sont en mesure de libérer sessions au nom de l'utilisateur
-CSCF reçoit une
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
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
22
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
23
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,
GAGLO Kokou Mise en place d’une plateforme de formation IMS
24
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é.
GAGLO Kokou Mise en place d’une plateforme de formation IMS
25
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 ;
GAGLO Kokou Mise en place d’une plateforme de formation IMS
26
• 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.
GAGLO Kokou Mise en place d’une plateforme de formation IMS
27
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 IMS
GateWay)
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
Mise en place d’une plateforme de formation IMS
sinon, comme l’appareil n’est pas compatible avec le réseau du correspondant qu’il
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.
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
plan de signalisation (couche contrôle). Nous allons décrire chacune d’elles.
Figure 2.5 : Interfonctionnement avec le RTC
La passerelle de flux multimédia IMS-MGW (IMS
GateWay)
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
Mise en place d’une plateforme de formation IMS
28
correspondant qu’il
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
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
plan de signalisation (couche contrôle). Nous allons décrire chacune d’elles.
MGW (IMS-Media
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 le
GAGLO Kokou Mise en place d’une plateforme de formation IMS
29
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
Mise en place d’une plateforme de formation IMS
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
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.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
Comme les messages qu’une station peut envoyer à une autre sont de deux types (flux de
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
Mise en place d’une plateforme de formation IMS
30
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
communiquent avec IPv6. De cette manière, le réseau IMS se charge d’effectuer la transition
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
Comme les messages qu’une station peut envoyer à une autre sont de deux types (flux de
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,
GAGLO Kokou Mise en place d’une plateforme de formation IMS
31
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.
Mise en place d’une plateforme de formation IMS
est le protocole fédérateur de l’architecture IMS. Il est en quelque sorte la glue
aux différents composants de communiquer entre eux de manière homogène.
, 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
Mise en place d’une plateforme de formation IMS
32
ture IMS. Il est en quelque sorte la glue qui permet
aux différents composants de communiquer entre eux de manière homogène.
, 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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
33
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.
GAGLO Kokou Mise en place d’une plateforme de formation IMS
34
• 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.
GAGLO Kokou Mise en place d’une plateforme de formation IMS
35
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.
GAGLO Kokou Mise en place d’une plateforme de formation IMS
36
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).
GAGLO Kokou Mise en place d’une plateforme de formation IMS
37
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
38
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.
GAGLO Kokou Mise en place d’une plateforme de formation IMS
39
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.
Mise en place d’une plateforme de formation IMS
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 identité privée et un profil de
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.
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.
Mise en place d’une plateforme de formation IMS
40
Lorsqu'un utilisateur souscrit à un abonnement IMS chez un opérateur, l'opérateur lui assigne
identité privée et un profil de
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.
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.
Mise en place d’une plateforme de formation IMS
L'identification publique
Cette partie indique les identités publiques de l'utilisateur qui sont concernées par le profil de
vice. 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
CSCF d'interdire l'utilisation de cette identité publique dans une com
IMS autre que l'enregistrement ou le réenregistrement.
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
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
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 requête est transmise vers un AS
Figure 2.10 : Structure d'un IFC
Mise en place d’une plateforme de formation IMS
41
Cette partie indique les identités publiques de l'utilisateur qui sont concernées par le profil de
vice. 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
CSCF d'interdire l'utilisation de cette identité publique dans une communication
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 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
L'information sur le déclenchement des services se présente sous la forme d'une IFC (Initial
requête est transmise vers un AS
GAGLO Kokou Mise en place d’une plateforme de formation IMS
42
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
43
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
44
• « 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.
GAGLO Kokou Mise en place d’une plateforme de formation IMS
45
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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
46
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 :friends@example.com 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
GAGLO Kokou Mise en place d’une plateforme de formation IMS
47
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.
GAGLO Kokou Mise en place d’une plateforme de formation IMS
48
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.
GAGLO Kokou Mise en place d’une plateforme de formation IMS
49
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:alice@example.com/friends 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:resource-lists">
<list name="friends">
<entry uri="sip:bob@example.com">
<display-name>Bob</display-name>
</entry>
<entry uri="sip:sarah@example.com">
GAGLO Kokou Mise en place d’une plateforme de formation IMS
50
<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.
GAGLO Kokou Mise en place d’une plateforme de formation IMS
51
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
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS
Mise en place d’une plateforme de formation IMS

Contenu connexe

Tendances

IP Multimedia Subsystem (IMS)
IP Multimedia Subsystem (IMS)IP Multimedia Subsystem (IMS)
IP Multimedia Subsystem (IMS)
Papa Cheikh Cisse
 
conception et réalisation d'une application de gestion des rapports téléphoni...
conception et réalisation d'une application de gestion des rapports téléphoni...conception et réalisation d'une application de gestion des rapports téléphoni...
conception et réalisation d'une application de gestion des rapports téléphoni...
ismailbou
 
Évaluation de l'interface radio UMTS/HSPA
Évaluation de l'interface radio UMTS/HSPAÉvaluation de l'interface radio UMTS/HSPA
Évaluation de l'interface radio UMTS/HSPA
mey006
 
Trunk VoiP Asterisk strongsawn openvpn
Trunk VoiP Asterisk strongsawn openvpnTrunk VoiP Asterisk strongsawn openvpn
Trunk VoiP Asterisk strongsawn openvpn
Yaya N'Tyeni Sanogo
 
Architecture d'un réseau GSM 2G (Téléphonie Mobile)
Architecture d'un réseau GSM 2G (Téléphonie Mobile)Architecture d'un réseau GSM 2G (Téléphonie Mobile)
Architecture d'un réseau GSM 2G (Téléphonie Mobile)
Assia Mounir
 
Securisation de la VoIP sous Asterisk: solution avec Asterisk, OpenVPN et Ope...
Securisation de la VoIP sous Asterisk: solution avec Asterisk, OpenVPN et Ope...Securisation de la VoIP sous Asterisk: solution avec Asterisk, OpenVPN et Ope...
Securisation de la VoIP sous Asterisk: solution avec Asterisk, OpenVPN et Ope...
Stephen Salama
 
Rapport stage fin d'études
Rapport stage fin d'étudesRapport stage fin d'études
Rapport stage fin d'études
Albert IBANEZ
 
TELEPHONIE SUR IP
TELEPHONIE SUR IPTELEPHONIE SUR IP
TELEPHONIE SUR IP
El hadji Idrissa Thiam
 
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
Massimo Russo
 
Connexion point à point (ppp, hdlc)
Connexion point à point (ppp, hdlc)Connexion point à point (ppp, hdlc)
Connexion point à point (ppp, hdlc)
EL AMRI El Hassan
 
Tp voip
Tp voipTp voip
Tp voip
amalouwarda
 
ETUDE ET MISE EN PLACE DE LA SOLUTION VOIP OVER LTE, DIMENSIONNEMENT ET MESUR...
ETUDE ET MISE EN PLACE DE LA SOLUTION VOIP OVER LTE, DIMENSIONNEMENT ET MESUR...ETUDE ET MISE EN PLACE DE LA SOLUTION VOIP OVER LTE, DIMENSIONNEMENT ET MESUR...
ETUDE ET MISE EN PLACE DE LA SOLUTION VOIP OVER LTE, DIMENSIONNEMENT ET MESUR...
Sidali Bhs
 
Umts
UmtsUmts
Etude de la VoIP
Etude de la VoIPEtude de la VoIP
Etude de la VoIP
Chiheb Ouaghlani
 
Curriculum vitae pour technicien superieur en réseaux et télécommunication
Curriculum vitae pour technicien superieur en réseaux et télécommunicationCurriculum vitae pour technicien superieur en réseaux et télécommunication
Curriculum vitae pour technicien superieur en réseaux et télécommunication
Anis Nouri
 
Réseaux-de-transport_RTC (2).pdf
Réseaux-de-transport_RTC (2).pdfRéseaux-de-transport_RTC (2).pdf
Réseaux-de-transport_RTC (2).pdf
FtiguOuatt
 
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISKETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
bamaemmanuel
 
COUPLAGE ENTRE Asterisk et OpenIMSCore
COUPLAGE ENTRE Asterisk et OpenIMSCoreCOUPLAGE ENTRE Asterisk et OpenIMSCore
COUPLAGE ENTRE Asterisk et OpenIMSCore
Abdou Lahad SYLLA
 
éTude et mise_en_place_d'une_solution_voip_sécurisée
éTude et mise_en_place_d'une_solution_voip_sécuriséeéTude et mise_en_place_d'une_solution_voip_sécurisée
éTude et mise_en_place_d'une_solution_voip_sécurisée
Saad Jouhari
 

Tendances (20)

IP Multimedia Subsystem (IMS)
IP Multimedia Subsystem (IMS)IP Multimedia Subsystem (IMS)
IP Multimedia Subsystem (IMS)
 
conception et réalisation d'une application de gestion des rapports téléphoni...
conception et réalisation d'une application de gestion des rapports téléphoni...conception et réalisation d'une application de gestion des rapports téléphoni...
conception et réalisation d'une application de gestion des rapports téléphoni...
 
Évaluation de l'interface radio UMTS/HSPA
Évaluation de l'interface radio UMTS/HSPAÉvaluation de l'interface radio UMTS/HSPA
Évaluation de l'interface radio UMTS/HSPA
 
Trunk VoiP Asterisk strongsawn openvpn
Trunk VoiP Asterisk strongsawn openvpnTrunk VoiP Asterisk strongsawn openvpn
Trunk VoiP Asterisk strongsawn openvpn
 
Architecture d'un réseau GSM 2G (Téléphonie Mobile)
Architecture d'un réseau GSM 2G (Téléphonie Mobile)Architecture d'un réseau GSM 2G (Téléphonie Mobile)
Architecture d'un réseau GSM 2G (Téléphonie Mobile)
 
Securisation de la VoIP sous Asterisk: solution avec Asterisk, OpenVPN et Ope...
Securisation de la VoIP sous Asterisk: solution avec Asterisk, OpenVPN et Ope...Securisation de la VoIP sous Asterisk: solution avec Asterisk, OpenVPN et Ope...
Securisation de la VoIP sous Asterisk: solution avec Asterisk, OpenVPN et Ope...
 
Rapport stage fin d'études
Rapport stage fin d'étudesRapport stage fin d'études
Rapport stage fin d'études
 
TELEPHONIE SUR IP
TELEPHONIE SUR IPTELEPHONIE SUR IP
TELEPHONIE SUR IP
 
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
 
Connexion point à point (ppp, hdlc)
Connexion point à point (ppp, hdlc)Connexion point à point (ppp, hdlc)
Connexion point à point (ppp, hdlc)
 
Tp voip
Tp voipTp voip
Tp voip
 
Rapport PFE VoIP
Rapport PFE VoIPRapport PFE VoIP
Rapport PFE VoIP
 
ETUDE ET MISE EN PLACE DE LA SOLUTION VOIP OVER LTE, DIMENSIONNEMENT ET MESUR...
ETUDE ET MISE EN PLACE DE LA SOLUTION VOIP OVER LTE, DIMENSIONNEMENT ET MESUR...ETUDE ET MISE EN PLACE DE LA SOLUTION VOIP OVER LTE, DIMENSIONNEMENT ET MESUR...
ETUDE ET MISE EN PLACE DE LA SOLUTION VOIP OVER LTE, DIMENSIONNEMENT ET MESUR...
 
Umts
UmtsUmts
Umts
 
Etude de la VoIP
Etude de la VoIPEtude de la VoIP
Etude de la VoIP
 
Curriculum vitae pour technicien superieur en réseaux et télécommunication
Curriculum vitae pour technicien superieur en réseaux et télécommunicationCurriculum vitae pour technicien superieur en réseaux et télécommunication
Curriculum vitae pour technicien superieur en réseaux et télécommunication
 
Réseaux-de-transport_RTC (2).pdf
Réseaux-de-transport_RTC (2).pdfRéseaux-de-transport_RTC (2).pdf
Réseaux-de-transport_RTC (2).pdf
 
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISKETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
ETUDES ET DÉPLOIEMENT DUNE SOLUTION VOIP BASÉE SUR ASTERISK
 
COUPLAGE ENTRE Asterisk et OpenIMSCore
COUPLAGE ENTRE Asterisk et OpenIMSCoreCOUPLAGE ENTRE Asterisk et OpenIMSCore
COUPLAGE ENTRE Asterisk et OpenIMSCore
 
éTude et mise_en_place_d'une_solution_voip_sécurisée
éTude et mise_en_place_d'une_solution_voip_sécuriséeéTude et mise_en_place_d'une_solution_voip_sécurisée
éTude et mise_en_place_d'une_solution_voip_sécurisée
 

Similaire à Mise en place d’une plateforme de formation IMS

Rapport version finale kouakou aboua pokou alexis
Rapport version finale kouakou aboua pokou alexis Rapport version finale kouakou aboua pokou alexis
Rapport version finale kouakou aboua pokou alexis
abouaalexis
 
Rapport final cbi
Rapport final cbiRapport final cbi
Rapport final cbiMan Foru
 
Memoire license iii
Memoire license iiiMemoire license iii
Memoire license iii
Gilles Kouamé
 
Memoire_Nguessan.docx
Memoire_Nguessan.docxMemoire_Nguessan.docx
Memoire_Nguessan.docx
AmadouMbaye11
 
Business Intelligence system
Business Intelligence system Business Intelligence system
Business Intelligence system
Basma Saad
 
Déportation d'une connexion Internet via WiFi
Déportation d'une connexion Internet via WiFiDéportation d'une connexion Internet via WiFi
Déportation d'une connexion Internet via WiFi
Siriki Coulibaly
 
portail_captif.pdf
portail_captif.pdfportail_captif.pdf
portail_captif.pdf
nabila201151
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
Aicha OUALLA
 
Rapport finiale
Rapport finialeRapport finiale
Rapport finiale
marwenbencheikhali
 
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA...
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA...Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA...
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA...
Bachir Benyammi
 
VPN & QOS dans LES Réseaux Informatiques.pdf
VPN & QOS dans LES Réseaux Informatiques.pdfVPN & QOS dans LES Réseaux Informatiques.pdf
VPN & QOS dans LES Réseaux Informatiques.pdf
Clement BAVOUA TEKEU
 
Étude et Mise en Place de Monitoring
Étude et Mise en Place de Monitoring Étude et Mise en Place de Monitoring
Étude et Mise en Place de Monitoring
ImnaTech
 
Rapport de stage bts
Rapport de stage btsRapport de stage bts
Rapport de stage bts
LOUKOU JOEL ANGA
 
TFC_KATSHINDA_MBEMBA_GRACE_2017_2018
TFC_KATSHINDA_MBEMBA_GRACE_2017_2018TFC_KATSHINDA_MBEMBA_GRACE_2017_2018
TFC_KATSHINDA_MBEMBA_GRACE_2017_2018
GRACEKATSHINDA
 
Stage de Perfectonnement Génie Electrique (1) mm 24
Stage de Perfectonnement Génie Electrique (1) mm 24Stage de Perfectonnement Génie Electrique (1) mm 24
Stage de Perfectonnement Génie Electrique (1) mm 24
DhaouiMastour
 
Mise en place de ftp au sufop
Mise en place de ftp au sufopMise en place de ftp au sufop
Mise en place de ftp au sufop
ImnaTech
 
Étude et mise en place d'un serveur FTP au sufop
Étude et mise en place d'un serveur FTP au sufopÉtude et mise en place d'un serveur FTP au sufop
Étude et mise en place d'un serveur FTP au sufop
iferis
 
rapport final djoukwe kepngue donald
rapport final djoukwe kepngue donaldrapport final djoukwe kepngue donald
rapport final djoukwe kepngue donald
donald djoukwe
 
Étude et mise en place d'un serveur messengerie
Étude et mise en place d'un serveur messengerie Étude et mise en place d'un serveur messengerie
Étude et mise en place d'un serveur messengerie
iferis
 
M01 metier formation tri
M01 metier formation triM01 metier formation tri
M01 metier formation tri
Rachid Bouzakri
 

Similaire à Mise en place d’une plateforme de formation IMS (20)

Rapport version finale kouakou aboua pokou alexis
Rapport version finale kouakou aboua pokou alexis Rapport version finale kouakou aboua pokou alexis
Rapport version finale kouakou aboua pokou alexis
 
Rapport final cbi
Rapport final cbiRapport final cbi
Rapport final cbi
 
Memoire license iii
Memoire license iiiMemoire license iii
Memoire license iii
 
Memoire_Nguessan.docx
Memoire_Nguessan.docxMemoire_Nguessan.docx
Memoire_Nguessan.docx
 
Business Intelligence system
Business Intelligence system Business Intelligence system
Business Intelligence system
 
Déportation d'une connexion Internet via WiFi
Déportation d'une connexion Internet via WiFiDéportation d'une connexion Internet via WiFi
Déportation d'une connexion Internet via WiFi
 
portail_captif.pdf
portail_captif.pdfportail_captif.pdf
portail_captif.pdf
 
Rapport de stage
Rapport de stageRapport de stage
Rapport de stage
 
Rapport finiale
Rapport finialeRapport finiale
Rapport finiale
 
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA...
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA...Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA...
Étude et réalisation d’une application de contrôle d’un PC à distance en JAVA...
 
VPN & QOS dans LES Réseaux Informatiques.pdf
VPN & QOS dans LES Réseaux Informatiques.pdfVPN & QOS dans LES Réseaux Informatiques.pdf
VPN & QOS dans LES Réseaux Informatiques.pdf
 
Étude et Mise en Place de Monitoring
Étude et Mise en Place de Monitoring Étude et Mise en Place de Monitoring
Étude et Mise en Place de Monitoring
 
Rapport de stage bts
Rapport de stage btsRapport de stage bts
Rapport de stage bts
 
TFC_KATSHINDA_MBEMBA_GRACE_2017_2018
TFC_KATSHINDA_MBEMBA_GRACE_2017_2018TFC_KATSHINDA_MBEMBA_GRACE_2017_2018
TFC_KATSHINDA_MBEMBA_GRACE_2017_2018
 
Stage de Perfectonnement Génie Electrique (1) mm 24
Stage de Perfectonnement Génie Electrique (1) mm 24Stage de Perfectonnement Génie Electrique (1) mm 24
Stage de Perfectonnement Génie Electrique (1) mm 24
 
Mise en place de ftp au sufop
Mise en place de ftp au sufopMise en place de ftp au sufop
Mise en place de ftp au sufop
 
Étude et mise en place d'un serveur FTP au sufop
Étude et mise en place d'un serveur FTP au sufopÉtude et mise en place d'un serveur FTP au sufop
Étude et mise en place d'un serveur FTP au sufop
 
rapport final djoukwe kepngue donald
rapport final djoukwe kepngue donaldrapport final djoukwe kepngue donald
rapport final djoukwe kepngue donald
 
Étude et mise en place d'un serveur messengerie
Étude et mise en place d'un serveur messengerie Étude et mise en place d'un serveur messengerie
Étude et mise en place d'un serveur messengerie
 
M01 metier formation tri
M01 metier formation triM01 metier formation tri
M01 metier formation tri
 

Plus de Kokou Gaglo

Prise en main de Jhipster
Prise en main de JhipsterPrise en main de Jhipster
Prise en main de Jhipster
Kokou Gaglo
 
IP Multimedia Subsystem : Démarrer avec Mobicents JainSLEE (Partie 1)
IP Multimedia Subsystem : Démarrer avec Mobicents JainSLEE (Partie 1)IP Multimedia Subsystem : Démarrer avec Mobicents JainSLEE (Partie 1)
IP Multimedia Subsystem : Démarrer avec Mobicents JainSLEE (Partie 1)
Kokou Gaglo
 
Mybatis : Spring Data à la rescousse
Mybatis : Spring Data à la rescousse Mybatis : Spring Data à la rescousse
Mybatis : Spring Data à la rescousse
Kokou Gaglo
 
Spring Batch
Spring BatchSpring Batch
Spring Batch
Kokou Gaglo
 
Intégration continue et déploiement continue avec Jenkins
Intégration continue et déploiement continue avec JenkinsIntégration continue et déploiement continue avec Jenkins
Intégration continue et déploiement continue avec Jenkins
Kokou Gaglo
 
Java - Lombok
Java - LombokJava - Lombok
Java - Lombok
Kokou Gaglo
 
MyBatis, une alternative à JPA.
MyBatis, une alternative à JPA.MyBatis, une alternative à JPA.
MyBatis, une alternative à JPA.
Kokou Gaglo
 
Contributions aux environnements de développement de services de télécoms da...
Contributions aux environnements de développement de  services de télécoms da...Contributions aux environnements de développement de  services de télécoms da...
Contributions aux environnements de développement de services de télécoms da...
Kokou Gaglo
 
Design pattern
Design patternDesign pattern
Design pattern
Kokou Gaglo
 
Programmation evénementielle
Programmation evénementielleProgrammation evénementielle
Programmation evénementielleKokou Gaglo
 

Plus de Kokou Gaglo (11)

Prise en main de Jhipster
Prise en main de JhipsterPrise en main de Jhipster
Prise en main de Jhipster
 
IP Multimedia Subsystem : Démarrer avec Mobicents JainSLEE (Partie 1)
IP Multimedia Subsystem : Démarrer avec Mobicents JainSLEE (Partie 1)IP Multimedia Subsystem : Démarrer avec Mobicents JainSLEE (Partie 1)
IP Multimedia Subsystem : Démarrer avec Mobicents JainSLEE (Partie 1)
 
Mybatis : Spring Data à la rescousse
Mybatis : Spring Data à la rescousse Mybatis : Spring Data à la rescousse
Mybatis : Spring Data à la rescousse
 
Spring Batch
Spring BatchSpring Batch
Spring Batch
 
Intégration continue et déploiement continue avec Jenkins
Intégration continue et déploiement continue avec JenkinsIntégration continue et déploiement continue avec Jenkins
Intégration continue et déploiement continue avec Jenkins
 
Java - Lombok
Java - LombokJava - Lombok
Java - Lombok
 
MyBatis, une alternative à JPA.
MyBatis, une alternative à JPA.MyBatis, une alternative à JPA.
MyBatis, une alternative à JPA.
 
Contributions aux environnements de développement de services de télécoms da...
Contributions aux environnements de développement de  services de télécoms da...Contributions aux environnements de développement de  services de télécoms da...
Contributions aux environnements de développement de services de télécoms da...
 
Design pattern
Design patternDesign pattern
Design pattern
 
Serveur http
Serveur httpServeur http
Serveur http
 
Programmation evénementielle
Programmation evénementielleProgrammation evénementielle
Programmation evénementielle
 

Dernier

Les écrans informatiques au fil du temps.pptx
Les écrans informatiques au fil du temps.pptxLes écrans informatiques au fil du temps.pptx
Les écrans informatiques au fil du temps.pptx
abderrahimbourimi
 
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
Horgix
 
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
OCTO Technology
 
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'universitéDe l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
Université de Franche-Comté
 
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptxPRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
AlbertSmithTambwe
 
Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024
UNITECBordeaux
 
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
OCTO Technology
 
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Laurent Speyser
 
COURS D'ADMINISTRATION RESEAU SOUS WINDOWS
COURS D'ADMINISTRATION RESEAU  SOUS WINDOWSCOURS D'ADMINISTRATION RESEAU  SOUS WINDOWS
COURS D'ADMINISTRATION RESEAU SOUS WINDOWS
AlbertSmithTambwe
 

Dernier (9)

Les écrans informatiques au fil du temps.pptx
Les écrans informatiques au fil du temps.pptxLes écrans informatiques au fil du temps.pptx
Les écrans informatiques au fil du temps.pptx
 
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
MongoDB in a scale-up: how to get away from a monolithic hell — MongoDB Paris...
 
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
Le Comptoir OCTO - Équipes infra et prod, ne ratez pas l'embarquement pour l'...
 
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'universitéDe l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
De l'IA comme plagiat à la rédaction d'une « charte IA » à l'université
 
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptxPRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
PRESENTATION DE L'ACTIVE DIRECTORY SOUS WINDOWS SERVEUR.pptx
 
Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024Le support de présentation des Signaux 2024
Le support de présentation des Signaux 2024
 
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
Le Comptoir OCTO - Qu’apporte l’analyse de cycle de vie lors d’un audit d’éco...
 
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
Ouvrez la porte ou prenez un mur (Agile Tour Genève 2024)
 
COURS D'ADMINISTRATION RESEAU SOUS WINDOWS
COURS D'ADMINISTRATION RESEAU  SOUS WINDOWSCOURS D'ADMINISTRATION RESEAU  SOUS WINDOWS
COURS D'ADMINISTRATION RESEAU SOUS WINDOWS
 

Mise en place d’une plateforme de formation IMS

  • 1. GAGLO Kokou Mise en place d’une plateforme de formation IMS 11 AAAA mon oncle Isaac Jogues GAGLO DEDICACESDEDICACES
  • 2. 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
  • 3. GAGLO Kokou Mise en place d’une plateforme de formation IMS 3 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
  • 4. GAGLO Kokou Mise en place d’une plateforme de formation IMS 4 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.
  • 5. GAGLO Kokou Mise en place d’une plateforme de formation IMS 5 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
  • 6. GAGLO Kokou Mise en place d’une plateforme de formation IMS 6 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
  • 7. GAGLO Kokou Mise en place d’une plateforme de formation IMS 7 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
  • 8. GAGLO Kokou Mise en place d’une plateforme de formation IMS 8 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
  • 9. GAGLO Kokou Mise en place d’une plateforme de formation IMS 9 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
  • 10. GAGLO Kokou Mise en place d’une plateforme de formation IMS 10 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
  • 11. GAGLO Kokou Mise en place d’une plateforme de formation IMS 11 Figure A.8.7 : Analyse graphique de la demande VoD par James......................................xix
  • 12. GAGLO Kokou Mise en place d’une plateforme de formation IMS 12 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
  • 13. GAGLO Kokou Mise en place d’une plateforme de formation IMS 13 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
  • 14. GAGLO Kokou Mise en place d’une plateforme de formation IMS 14 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
  • 15. GAGLO Kokou Mise en place d’une plateforme de formation IMS 15 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
  • 16. 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 A l’heure actuelle, les télécoms évoluent vers les réseaux NGN (Next Generation Network) dont est issu l’IMS. Ainsi, il va de soi que les opérateurs, spécifiquement africains, pensent à migrer leurs infrastructures. Il se pose alors la question de compétence dans ce RTN, de part sa vocation, a pris conscience du besoin à venir dans le domaine des 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 & caisse Dé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 A l’heure actuelle, les télécoms évoluent vers les réseaux NGN (Next Generation que les opérateurs, spécifiquement africains, pensent à migrer leurs infrastructures. Il se pose alors la question de compétence dans ce RTN, de part sa vocation, a pris conscience du besoin à venir dans le domaine des 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
  • 17. GAGLO Kokou Mise en place d’une plateforme de formation IMS 17 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é.
  • 18. 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 Mise en place d’une plateforme de formation IMS 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 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 (Unlicensed Mobile Access), xDSL (xDigital Subscriber Line), Wi-Fi (Wireless Fidelity), WiMax (Worldwide Mise en place d’une plateforme de formation IMS 18 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 les réseaux d’accès, on peut citer les plus classiques : GSM (Global System for Mobile communications), UMTS (Universal Mobile Telecommunications System), CDMA nsed Mobile Access), Fi (Wireless Fidelity), WiMax (Worldwide CHAPITRE 2
  • 19. GAGLO Kokou Mise en place d’une plateforme de formation IMS 19 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
  • 20. GAGLO Kokou Mise en place d’une plateforme de formation IMS 20 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
  • 21. 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). Mise en place d’une plateforme de formation IMS 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 de l’enregistrement, l’établissement des sessions et forment le mécanisme de routage SIP. En 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 mesure d'effectuer. Les deux entités sont en mesure de libérer sessions au nom de l'utilisateur SCF 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 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 Figure 2.2 : Les serveurs CSCF Mise en place d’une plateforme de formation IMS 21 (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 de l’enregistrement, l’établissement des sessions et forment le mécanisme de routage SIP. En 'envoyer des données de charge à une fonction de CSCF et S-CSCF sont en mesure d'effectuer. Les deux entités sont en mesure de libérer sessions au nom de l'utilisateur -CSCF reçoit une 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 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
  • 22. GAGLO Kokou Mise en place d’une plateforme de formation IMS 22 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
  • 23. GAGLO Kokou Mise en place d’une plateforme de formation IMS 23 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,
  • 24. GAGLO Kokou Mise en place d’une plateforme de formation IMS 24 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é.
  • 25. GAGLO Kokou Mise en place d’une plateforme de formation IMS 25 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 ;
  • 26. GAGLO Kokou Mise en place d’une plateforme de formation IMS 26 • 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.
  • 27. GAGLO Kokou Mise en place d’une plateforme de formation IMS 27 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.
  • 28. 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 IMS GateWay) 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 Mise en place d’une plateforme de formation IMS sinon, comme l’appareil n’est pas compatible avec le réseau du correspondant qu’il 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. 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 plan de signalisation (couche contrôle). Nous allons décrire chacune d’elles. Figure 2.5 : Interfonctionnement avec le RTC La passerelle de flux multimédia IMS-MGW (IMS GateWay) 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 Mise en place d’une plateforme de formation IMS 28 correspondant qu’il 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 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 plan de signalisation (couche contrôle). Nous allons décrire chacune d’elles. MGW (IMS-Media 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 le
  • 29. GAGLO Kokou Mise en place d’une plateforme de formation IMS 29 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.
  • 30. 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 Mise en place d’une plateforme de formation IMS 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 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.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 Comme les messages qu’une station peut envoyer à une autre sont de deux types (flux de 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 Mise en place d’une plateforme de formation IMS 30 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 communiquent avec IPv6. De cette manière, le réseau IMS se charge d’effectuer la transition 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 Comme les messages qu’une station peut envoyer à une autre sont de deux types (flux de 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,
  • 31. GAGLO Kokou Mise en place d’une plateforme de formation IMS 31 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 :
  • 32. 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. Mise en place d’une plateforme de formation IMS est le protocole fédérateur de l’architecture IMS. Il est en quelque sorte la glue aux différents composants de communiquer entre eux de manière homogène. , 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 Mise en place d’une plateforme de formation IMS 32 ture IMS. Il est en quelque sorte la glue qui permet aux différents composants de communiquer entre eux de manière homogène. , 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
  • 33. GAGLO Kokou Mise en place d’une plateforme de formation IMS 33 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.
  • 34. GAGLO Kokou Mise en place d’une plateforme de formation IMS 34 • 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.
  • 35. GAGLO Kokou Mise en place d’une plateforme de formation IMS 35 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.
  • 36. GAGLO Kokou Mise en place d’une plateforme de formation IMS 36 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).
  • 37. GAGLO Kokou Mise en place d’une plateforme de formation IMS 37 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
  • 38. GAGLO Kokou Mise en place d’une plateforme de formation IMS 38 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.
  • 39. GAGLO Kokou Mise en place d’une plateforme de formation IMS 39 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)
  • 40. 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. Mise en place d’une plateforme de formation IMS 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 identité privée et un profil de 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. 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. Mise en place d’une plateforme de formation IMS 40 Lorsqu'un utilisateur souscrit à un abonnement IMS chez un opérateur, l'opérateur lui assigne identité privée et un profil de 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. 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
  • 41. 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. Mise en place d’une plateforme de formation IMS L'identification publique Cette partie indique les identités publiques de l'utilisateur qui sont concernées par le profil de vice. 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 CSCF d'interdire l'utilisation de cette identité publique dans une com IMS autre que l'enregistrement ou le réenregistrement. 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 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 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 requête est transmise vers un AS Figure 2.10 : Structure d'un IFC Mise en place d’une plateforme de formation IMS 41 Cette partie indique les identités publiques de l'utilisateur qui sont concernées par le profil de vice. 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 CSCF d'interdire l'utilisation de cette identité publique dans une communication 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 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 L'information sur le déclenchement des services se présente sous la forme d'une IFC (Initial requête est transmise vers un AS
  • 42. GAGLO Kokou Mise en place d’une plateforme de formation IMS 42 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
  • 43. GAGLO Kokou Mise en place d’une plateforme de formation IMS 43 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
  • 44. GAGLO Kokou Mise en place d’une plateforme de formation IMS 44 • « 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.
  • 45. GAGLO Kokou Mise en place d’une plateforme de formation IMS 45 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
  • 46. GAGLO Kokou Mise en place d’une plateforme de formation IMS 46 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 :friends@example.com 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
  • 47. GAGLO Kokou Mise en place d’une plateforme de formation IMS 47 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.
  • 48. GAGLO Kokou Mise en place d’une plateforme de formation IMS 48 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.
  • 49. GAGLO Kokou Mise en place d’une plateforme de formation IMS 49 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:alice@example.com/friends 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:resource-lists"> <list name="friends"> <entry uri="sip:bob@example.com"> <display-name>Bob</display-name> </entry> <entry uri="sip:sarah@example.com">
  • 50. GAGLO Kokou Mise en place d’une plateforme de formation IMS 50 <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.
  • 51. GAGLO Kokou Mise en place d’une plateforme de formation IMS 51 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