IP MULTIMEDIA SUBSYSTEM

IMS
L’architecture IMS marque le développement d’un nouveau type de réseau
qui s’inscrit à la croisée d’IP et des télécoms. Comme son nom l’indique,
IMS définit un sous-réseau multimédia ou plutôt un réseau parallèle aux
réseaux actuels. Son ambition est le traitement des flux et services
multimédias dans une optique de convergence, quel que soit le réseau
d’accès utilisé (GSM, Wi-Fi, Ethernet, UMTS, WiMAX, etc.), quelle que soit
sa nature (fixe ou mobile), et quel que soit le type de terminal considéré
(ordinateur, PDA, téléphone, etc.).

Cette plate-forme révolutionne le monde des télécoms et accélère la

profonde mutation de se secteur en ce qu’elle exploite le protocole IP pour
gérer les communications entre les entités mises en place.
L’architecture IMS vise à déployer une plate-forme dans laquelle chaque
service peut être géré par un seul serveur, et ce quel que soit le réseau
d’accès. La vision de l’IMS consiste à affirmer haut et fort que les réseaux
d’accès, s’ils diffèrent, ne sont jamais que des points d’entrée et de sortie
permettant de joindre les terminaux des correspondants.

Au centre, le réseau coeur est différent, alors que rien ne le justifie. L’idée est
de faire converger tous les réseaux d’accès vers un même réseau coeur, et
donc, quel que soit le réseau d’accès utilisé, de disposer des mêmes
couches de transport de l’information, de contrôle des flux et d’accès aux
services.

La vision d’opérateur verticale, dans laquelle les composants sont

monolithiques et indissociables, est remplacée par une vision horizontale,
dans laquelle les composants sont flexibles et modulaires. Les fonctions
communes à l’ensemble des réseaux (comme l’authentification, la facturation
et la fourniture des services) sont mutualisées dans des ressources
partagées et centralisées.
L’architecture IMS

IMS propose une approche modulaire qui permet de distinguer des niveaux
de traitements différents.
Quatre couches (ou « plans ») peuvent être identifiées, chacune d’elles
étant liée à un domaine spécifique

Architecture de l’IMS
La couche d’accès.

Elle 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), , xDSL (xDigital
Subscriber Line), Wi-Fi (Wireless Fidelity), WiMax (Worldwide
Interoperability for Microwave Access) et les réseaux fixes.

La couche transport.

Elle 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.
La couche contrôle

Elle 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 application.

Elle 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.
La couche de contrôle

La couche de contrôle est constituée de différentes entités logiques .

Toutes ces entités constituent le socle de l’architecture IMS et, à ce titre, 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. Ces entités sont les suivantes :
• HSS et SLF

• CSCF ( P-CSCF, I-CSCF et S-CSCF)

• MRF (réparti en MRFC et MRFP)

• BGCF

• MGW, MGCF et SGW

• TrGW et IMS-ALG

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

HSS (Home Subscriber Server) : la base de données des utilisateurs

Le serveur HSS est une entité centralisée qui stocke une base de données
contenant l’ensemble des profils des utilisateurs. Il comporte, entre autres et
pour chaque utilisateur, les informations suivantes :

• Localisation des terminaux des utilisateurs abonnés.

• Identité complète des utilisateurs susceptibles d’accéder au réseau IMS.
• Paramètres permettant leur authentification et les informations d’autorisation
d’accès.
• Ensemble des services auxquels ils ont souscrits.
• 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.
CSCF (Call State Control Function) : les trois gestionnaires d’appels

Les CSCF sont des serveurs de contrôle de sessions, qui utilisent le

protocole de signalisation SIP pour communiquer. Ils sont les organes de
traitement des références dans l’architecture IMS et réalisent les fonctions
permettant d’orienter et de contrôler une session.

Concrètement, lorsqu’un utilisateur se connecte, il peut accéder à un

réseau qui n’est pas celui de l’opérateur chez qui il a souscrit un service. Il
faut donc que l’utilisateur emprunte le réseau pour assurer sa connectivité,
tout en cherchant à se relier à des entités appartenant à son opérateur,
pour avoir accès aux services de son contrat.

Il existe trois types de CSCF

Les serveurs CSCF
P-CSCF (Proxy-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.

Le serveur P-CSCF est en charge de localiser et contacter les autres entités.

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.
I-CSCF (Interrogating-CSCF)

Le serveur I-CSCF constitue, pour une session d’un utilisateur, le point

d’entrée dans le réseau de l’opérateur auquel l’utilisateur a souscrit un
contrat de service. Par exemple, si un utilisateur est dans un réseau qui
n’appartient pas à son opérateur, il peut emprunter ce réseau en utilisant un
intermédiaire (le serveur P-CSCF), lequel redirige ses requêtes vers une
entité du réseau de son opérateur (le serveur I-CSCF). Cette redirection est
réalisée, même si l’utilisateur est dans le réseau de son opérateur, mais,
dans ce cas, son intérêt est moindre.

Le serveur I-CSCF n’est que le point d’entrée du réseau d’un opérateur. Il ne

réalise pas de traitements pour répondre aux requêtes des utilisateurs, mais
se contente de désigner des entités qui le font (les serveurs S-CSCF).

Le rôle du I-CSCF est donc essentiellement de masquer le réseau de

l’opérateur en fournissant un simple point d’entrée et d’aiguiller les requêtes
de ses abonnés vers les serveurs adéquats.
Concrètement, c’est grâce au P-CSCF que le serveur I-CSCF peut être
sollicité : l’utilisateur, qui connaît uniquement le domaine de son
opérateur, envoie cette information vers le P-CSCF auquel il est
connecté. Avec le domaine mentionné par l’utilisateur, le P-CSCF peut
effectuer une requête DNS pour déterminer l’adresse IP du serveur I-
CSCF et peut alors contacter le serveur I-CSCF.

Le I-CSCF assure également des fonctionnalités de facturation et de

pare-feu pour protéger le réseau de l’opérateur puisqu’il se place à
l’entrée de celui-ci.

Le I-CSCF peut être relié à d’autres I-CSCF appartenant à d’autres

opérateurs, afin de permettre les communications entre les utilisateurs
d’opérateurs distincts.
S-CSCF (Serving-CSCF)

Le serveur S-CSCF doit assurer la gestion de la session d’un utilisateur. Plus

précisément, tous les messages de signalisation SIP émis ou reçus par le
terminal IMS de l’utilisateur traverseront le S-CSCF attribué à la session du
terminal et seront traités par ce dernier.

Le serveur S-CSCF est déterminé grâce au serveur I-CSCF (et toujours par
l’intermédiaire du P-CSCF) : après que le P-CSCF a contacté le I-CSCF, ce
dernier assigne un S-CSCF pour servir l’utilisateur, en fonction des S-CSCF
disponibles, afin de répartir au mieux la charge supportée par chacun d’entre
eux. Il en informe alors le P-CSCF, de manière que ce dernier puisse
ultérieurement s’adresser directement au S-CSCF.
Une fois désigné pour servir la session d’un utilisateur, le premier rôle du S-
CSCF est de récupérer auprès de la base HSS, et avec le protocole Diameter,
l’ensemble des paramètres de profil de l’utilisateur pour l’enregistrer,
l’authentifier et vérifier ses droits d’accès.

De plus, il met à jour, dans cette même base HSS, l’état courant des
sessions dont il a la charge, afin de pouvoir localiser l’utilisateur dans ses
déplacements (en sauvegardant leur adresse IP), modifier les préférences de
ce dernier, mais aussi avoir l’historique de ses communications (utile à la
facturation, par exemple).

Le S-CSCF est de plus l’entité chargée d’effectuer le routage des appels. En

particulier, si l’adresse de destination n’est pas une adresse SIP, mais, par
exemple, un numéro de téléphone standard, le serveur S-CSCF fournit les
fonctionnalités de conversion pour joindre les passerelles téléphoniques.

Enfin, le S-CSCF est chargé d’effectuer l’interaction avec les serveurs

d’applications en commutant les requêtes de l’utilisateur vers les serveurs
adéquats.
MRF (Multimedia Resource Function) : pour la gestion des conférences

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 de et 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 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.
BGCF (Breakout Gateway Control Function) : pour la liaison avec le réseau
RTC

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.

• 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) responsables d’effectuer la liaison et auxquelles le
BGCF relaie toute la signalisation qu’il reçoit.
IMS-MGW, MGCF et SGW : pour l’interfonctionnement avec le réseau RTC

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.
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).

Interfonctionnement avec le réseau RTC

La passerelle de flux multimédia IMS-MGW (IMS-Media 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 le transcodage correspondant (d’un flux
RTP vers un flux TDM).

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.

La passerelle de signalisation SGW (Signaling GateWay)

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.
TrGW et IMS-ALG : pour le support transparent des adresses IPv4

Compatibilité assurée avec des passerelles IPv4-IPv6

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

attendu, et un réseau IPv4 existant. Pour permettre une évolution en
douceur vers la version 6, IMS assure la compatibilité avec IPv4 et met
en oeuvre 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, deux entités sont introduites :

* TrGW (Transition GateWay)

* IMS-ALG (IMS-Application Layer Gateway).

Les serveurs IMS-ALG et TrGW
Lorsqu’une station IPv6 communique avec une station IPv4, cette dernière
n’est, a priori, pas capable de comprendre le message qui lui parvient.
L’idée consiste à mettre en place une entité intermédiaire entre ces deux
stations afin d’effectuer la conversion du protocole IP entre 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 la passerelle IMS-ALG, qui effectue la
translation d’adresses au niveau de la signalisation.

Autrement dit, la passerelle TrGW agit sur les messages de données

encapsulés par RTP (et les retours RTCP), tandis que la passerelle IMS-ALG
agit sur les messages de signalisation SDP et SIP
Les serveurs d’applications

SIP AS (SIP Application Server)

Ces serveurs permettent l’exécution des services nativement implémentés

pour fonctionner avec SIP.
Les services les plus classiques (service de présence, push-to-talk,
messagerie instantanée, etc.) sont généralement implémentés au sein de ces
serveurs.

IM-SSF (IP Multimedia-Service Switching Function)

Pour permettre la mobilité de l’abonné tout en lui garantissant la fourniture de

ses services — même s’il se trouve dans une infrastructure qui n’appartient
pas à son opérateur de services (on parle de roaming pour désigner la
connexion d’un utilisateur à un réseau qui n’est pas celui de son opérateur)
—, il est nécessaire d’avoir une passerelle, appelée IM-SSF, afin de connecter
l’abonné au serveur d’applications de son opérateur.
OSA-SCS (Open Service Access-Service Capability Server)

Ces serveurs fournissent le moyen d’interagir avec les serveurs

d’applications OSA.

OSA a été défini par le 3GPP et l’ETSI comme une architecture de gestion des
services dans un réseau téléphonique de troisième génération.

OSA-SCS permet d’accéder à des services génériques en réalisant l’interface

entre, d’un côté, le serveur S-CSCF (qui communique avec le protocole SIP)
et, de l’autre côté, des serveurs implémentant des applications pensées sur le
modèle générique de l’architecture OSA.
 Communications avec IMS

* 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 REGISTRER, du protocole de

signalisation SIP.
Processus d’enregistrement d’un terminal avec l’IMS
1. Le terminal envoie une requête SIP REGISTER, et reçoit en retour une
réponse 401 UNAUTHORIZED

Le terminal IMS envoie sa requête d’enregistrement au serveur P-CSCF.

Celui-ci ne connaît pas nécessairement le serveur I-CSCF (dans le cas
général, le P-CSCF peut appartenir à un autre opérateur que celui dont
dépend l’abonné). Pour localiser le I-CSCF, le serveur P-CSCF procède à
une requête DNS à partir du nom de domaine que l’utilisateur a fourni.

Une fois localisé, le P-CSCF joint le I-CSCF en lui fournissant la requête de

l’utilisateur, dans laquelle il a ajouté un champ d’entête P-VISITED-
NETWORK-ID. Ce champ contient un identifiant du réseau dans lequel le P-
CSCF se trouve. Il permettra au S-CSCF de vérifier que le réseau visité
bénéficie d’un accord de roaming avec l’opérateur de l’utilisateur.

Un autre champ ajouté par le P-CSCF est le champ d’en-tête PATH qui
spécifie l’adresse SIP du P-CSCF. Cette information permettra de retourner
la réponse à cette requête via ce même serveur P-CSCF.
Lorsque le I-CSCF reçoit la requête, il ignore si elle concerne un utilisateur qui
est déjà enregistré ou s’il s’agit d’un nouvel enregistrement. Le I-CSCF utilise
le protocole Diameter pour contacter la base de données HSS et lui demander,
à partir des identités publiques et privées contenues dans le message de
requête REGISTER, d’authentifier l’utilisateur (requête UAR).

Si l’utilisateur a déjà été enregistré, un serveur S-CSCF lui a déjà été attribué,
et l’adresse de ce serveur est stockée dans la base HSS. Dans ce cas, la base
HSS fournit dans sa réponse (message UAA) l’adresse du S-CSCF qui est en
charge de la session de l’utilisateur. Autrement, et s’il s’agit d’une première
connexion pour l’utilisateur, aucun serveur S-CSCF ne lui a été attribué et la
réponse UAA de la base HSS propose l’ensemble des S-CSCF disponibles
avec leur caractéristiques propres, de manière que le serveur I-CSCF puisse
choisir l’un d’entre eux, selon un critère qu’il détermine librement
(généralement pour répartir la charge des utilisateurs équitablement entre
tous les serveurs S-CSCF).
Considérons dans notre scénario qu’il s’agit d’une première authentification :
le serveur I-CSCF a donc choisi un serveur S-CSCF pour traiter la session
courante de l’utilisateur, et il lui relaie la requête d’enregistrement de
l’utilisateur. Le S-CSCF contacte alors la base HSS pour l’informer qu’il a été
désigné pour prendre en charge la session de l’utilisateur (requête MAR). Il
reçoit en retour une réponse MAA qui, d’une part, confirme l’enregistrement
du S-SCSF affecté à l’utilisateur et, d’autre part, retourne des informations
propres à l’utilisateur, qui vont permettre de générer un challenge pour
authentifier l’utilisateur (ces informations sont appelées vecteurs
d’authentification).

Lorsque le S-CSCF les reçoit, il répond au serveur I-CSCF par un message

SIP 401 UNAUTHORIZED, contenant le challenge sous la forme d’un champ
d’entête appelé WWW-AUTHENTICATE. Ce message de réponse est relayé
conformément au modèle SIP client/serveur, c’est-à-dire de proche en proche,
en passant par tous les émetteurs de requêtes : le I-CSCF d’abord, le P-CSCF
ensuite et le terminal client enfin. Cette liste de serveurs est facilement
déterminée car, lors de l’envoi de la requête REGISTER, les serveurs
traversés ont enregistré leur adresse SIP, grâce au champ d’en-tête PATH.
2. Le terminal envoie une nouvelle requête SIP REGISTER et reçoit en retour
une réponse 200 OK

Lorsque le client reçoit le message de réponse 401, il détecte le challenge qui

s’y trouve et prépare automatiquement une réponse adaptée (sans solliciter
l’utilisateur, mais en exploitant les données contenues dans la carte à puce
UICC, si le terminal client en dispose, ou bien avec des données équivalentes
stockées dans le terminal).

Cette réponse est générée dans une nouvelle requête d’enregistrement

REGISTER. Elle est envoyée en suivant le même processus d’acheminement
que le premier message de requête : le terminal client ne connaît que le
serveur P-CSCF, qui, lui-même, ne peut s’adresser qu’au I-CSCF, qui, à son
tour, sous-traite la demande auprès du serveur S-CSCF.
Remarquons, d’une part, que le serveur I-CSCF contacté peut être différent du
premier, car son adresse est déterminée par une requête DNS effectuée par le
serveur P-CSCF.
Or il est classique que le DNS opère une répartition de charges entre les
serveurs I-CSCF et réponde différemment à chaque requête. D’autre part, le
serveur I-CSCF effectue la même requête (UAR) auprès de la base HSS. En
effet, comme on vient de l’indiquer, non seulement il peut s’agir d’un autre
serveur I-CSCF que celui qui a relayé le premier message, mais, de plus et
surtout, même s’il s’agit du même serveur I-CSCF, ce dernier n’a gardé aucune
trace de la requête précédente et ignore donc à quel serveur S-CSCF adresser
cette requête : c’est la base HSS qui le renseigne dans sa réponse (message
UAA) en lui fournissant l’adresse du serveur S-CSCF en charge de la session
courante.

À réception de la requête, le serveur S-CSCF vérifie l’authentification de

l’utilisateur, en reprenant les vecteurs d’authentification que lui a fournis le
HSS à l’étape précédente et qu’il a stockés. Si les paramètres
d’authentification sont valides, l’authentification est un succès, et le serveur
S-CSCF en informe le HSS (par un message SAR). Dès lors, l’utilisateur peut
appeler et devient joignable à l’adresse qui figure dans le champ d’en-tête
CONTACT de la requête REGISTER, et ce pendant toute la durée mentionnée
dans la valeur de l’en-tête EXPIRES.
Le HSS répond ensuite au S-CSCF en lui envoyant le profil complet de
l’utilisateur, qui est stocké temporairement et servira à paramétrer et
personnaliser les services de cedernier.

Pour terminer, le serveur S-CSCF envoie un message de réponse 200 OK au

terminal pour lui notifier le succès de l’opération d’enregistrement. Ce
message comporte notamment un champ P-ASSOCIATED-URI, qui liste les
adresses SIP que l’utilisateur a enregistrées auprès du HSS (et donc avec
lesquelles il est joignable), et un champ SERVICE-ROUTE, qui précise
explicitement l’adresse URI SIP du serveur S-CSCF que l’utilisateur pourra
contacter directement dans ses requêtes suivantes (bien qu’elles transiteront
obligatoirement avant par le serveur P-CSCF).

Comme précédemment, le message de réponse traverse les entités qui ont

acheminé la requête, c’est-à-dire le I-CSCF, le P-CSCF puis le terminal IMS.
Mise en relation de deux utilisateurs

Une communication implique une première étape de recherche des abonnés,

de vérification des autorisations d’accès, puis de mise en relation entre les
correspondants.

La méthode associée à cette dernière fonctionnalité est INVITE avec le

protocole de signalisation SIP.
Mise en communication de deux terminaux
Nous considérons que l’appelant et l’appelé ont des opérateurs différents et
sont localisés dans des réseaux visités, c’est-à-dire qui n’appartiennent pas
forcement à leur opérateur respectif. C’est le cas le plus général.
Ce scénario de mise en relation de deux terminaux, ou UE (User Equipment),
peut être découpé en sept grandes étapes.

1. Message d’invitation de A vers B, avec deux réponses temporaires : une

réponse 100 pour indiquer la tentative et une réponse 183 pour proposer de
négocier les paramètres de la communication. L’appelant sollicite le terminal
de B et, pour cela, s’adresse au serveur I-CSCF de B, qui le localise après une
requête Diameter.

2. Pour s’assurer que l’émetteur A a bien reçu la réponse 183, celui-ci doit
impérativement envoyer un acquittement temporaire. Comme toute requête
SIP, et conformément au modèle client/serveur, une réponse est envoyée.

3. Le terminal A doit négocier les paramètres de qualité de service pour

garantir sa communication dans le réseau. Cette étape permet aux utilisateurs
d’établir une communication avec une bande passante garantie, et donc un
service de qualité. Elle est nouvelle par rapport au processus habituel
d’établissement de connexion qu’utilise SIP, car la qualité de service est un
élément essentiel avec l’IMS. Le terminal B vérifie que lui aussi a réservé les
ressources nécessaires à la communication dans le réseau et valide la
requête par sa réponse.
4. Dès ce moment, le terminal de B commence à sonner. Cette étape
complète les réponses temporaires à la requête d’invitation par une
réponse 180, elle aussi temporaire.

5. Pour s’assurer que cette réponse est bien reçue du terminal A, ce

dernier doit confirmer la réception par une requête d’acquittement, qui
attend elle-même une réponse.

6. Dès que l’utilisateur du terminal B a répondu (ou que sa messagerie

s’est enclenchée), la réponse définitive 200 est envoyée à la requête initiale
d’invitation.

7. La requête d’acquittement finale valide l’initialisation de la

communication, qui peut dès lors débuter pour permettre aux terminaux de
s’échanger des flux de données multimédias.