Objectif général du cours

A la fin de ce module, l’apprenant doit être capable, d’une part de comprendre les concepts liés à
la téléphonie sur IP, de déployer, d’administrer et de maintenir en fonctionnement un système de
téléphonie pour les PME et d’autre part de comprendre les concepts du réseau IMS, de déployer et
administrer le cœur du réseau IMS ainsi que les services.
 Activité 1

Concepts de base de la téléphonie sur IP

Objectifs spécifiques 1
• Maîtriser les concepts de base de la téléphonie sur IP ;

• Connaître les principaux protocoles et codecs de la téléphonie sur IP ;

• Comprendre les problématiques liées à la téléphonie sur IP.

Contenu
• Introduction à la téléphonie sur IP ;
• Les problématiques liées à la téléphonie sur IP ;
• Les principaux protocoles et codecs de la téléphonie sur IP
Introdcution

La téléphonie sur IP (ToIP) à l'origine était située à la frontière de l'informatique et des

télécommunications. Aujourd'hui, cette technologie est entrain de s'imposer dans le secteur des TIC en
particulier dans les entreprises. La téléphonie est l'un des moyens de communication le plus utilisé des
être humains. On remarque que 80% des communications réalisées par l'homme sont effectuées par
téléphone.
Avant, la transmission de la voix est exclusivement réservée au réseau téléphonique classique ou
RTC (Réseau Téléphonique Commuté).
L'avancée technologique a changé la donne. La transmission de la voix via les réseaux IP
constitue une grande évolution. Cette technologie consiste à faire transiter de la voix sur un réseau d’où
le concept de Téléphonie sur IP ou (Telephony Over IP) en Anglais.

1.1- Problématiques liées à la téléphonie sur IP

La problématique de la ToIP est liée au transport de la voix dans les environnements IP. A
l'origine la téléphonie était destinée au réseau télécoms. L'idée de départ est d'utiliser les techniques de
commutation pour arriver à une fin; celle du transport de la voix téléphonique sur un réseau IP (VoIP).
En fait, la téléphonie se faisait dans un réseau à commutation de circuit, ce qui veut dire qu’on
crée un circuit entre les deux interlocuteurs et que ce circuit est maintenu jusqu'à la fin de la
communication (même s’il existe un temps mort entre les interlocuteurs, ce circuit n’est pas utiliser à
d’autres fins).
Le RTC (Réseau technique Commuté) est un réseau à commutation de circuit qui permet de
créer un canal entre les deux interlocuteurs destinés seulement à la communication. Les opérateurs ont
préféré ce réseau à cause des contraintes de la parole téléphonique, mais la Voix sur IP (VoIP) est
devenue une application classique grâce aux techniques de numérisations et de la capacité des
terminaux.

Cependant, on se demandait peut-on faire de la téléphonie dans un réseau IP?si oui, quelles
sont les contraintes à prendre en compte?
1.2- Les contraintes de la ToIP

Les contraintes de la ToIP sont des éléments à prendre en compte pour s'assurer qu'il est
possible de faire de la téléphonie dans un environnement IP tout en assurant un minimum de qualité de
la parole.

1.2.1 Les contraintes physiques

Les contraintes physiques désignent l'environnement dans lequel l'utilisateur est en production
(émission d'appel). Comme contraintes physiques, nous avons:

- l’écho: l’écho désigne le signale qui revient dans l'oreille de l'émetteur au moment de la production.
Cela peut être dû à un environnement enclavé (bureau très petit, l'air, etc.). Mais pour satisfaire une
bonne qualité de communication, la norme exige que pour que l'écho ne soit pas gênant, il faudrait que
le temps de traversée (lors de la production) ne dépasse pas 28ms soit 56msaller-retour.

1.2.2 Les contraintes temporelles

Lorsque deux interlocuteurs sont en production (communication), la norme exige que pour qu'il y
'ait une bonne qualité de communication, le temps qui sépare le moment de la production et de la
réception ne doit pas dépasser150ms.

L’idée est de dire que si nous voulons respecter cette contrainte temporelle il ne faudrait pas
que le canal établit entre les deux correspondants ne soit pas utilisé par d’autres fins. C’est pourquoi
pour les opérateurs, un bon réseau est celui à commutation de circuit.

Or, on veut déployer la téléphonie dans un réseau IP. Donc il revient à s’interroger sur la
nature d’un réseau IP. De grandes discussions opposaient les informaticiens et les télécommunicants.

Du côté des informaticiens, un bon réseau est un réseau à commutation de paquet dans lequel on ne
s’occupe pas de l’ordre de la transmission des paquets, vu que tous les paquets sont traités de la même
façon au niveau des nœuds du réseau, donc il n’y a pas de privilèges, c’est pourquoi on dit que c’est
un réseau à ‘’BestEffort’’.
  La synchronisation

Les environnements IP sont des réseaux à commutation de paquets. Ils sont aussi qualifiés de
réseau à “Best-Effort” c'est-à-dire que tous les l'on ne se préoccupe pas de l'ordre de transmission
des paquets, vu que tous les paquets sont traités de la même façon au niveau des nœuds du réseau,
donc il n’y a pas de privilèges. Les paquets sont remis au récepteur à des instants quelconques
donc il est nécessaire de faire une resynchronisation des paquets avant de les remettre au codeur
(codec). Cette resynchronisation ne peut se faire que si on stocke les paquets pendant un certain
temps. Le temps pendant lequel les paquets sont stockés est appelé temps de synchronisation. La
norme exige que ce temps ne doive pas dépassé 100ms et doit être supérieur au temps maximal de
traversée. La réalisation d'un algorithme nécessite que le nœud récepteur connaisse le temps
d'entrée dans le réseau en vue de synchroniser en ajoutant le temps maximal de traversée. Dans les
réseaux qui transportent de la parole, on utilise deux types desynchronisation:
 La synchronisation directe: qui consiste à utiliser le même temps
 La synchronisation différentielle: qui consiste à avoir les mêmes horloges tournant à la
même vitesse.
1.2.2 La Signalisation et Protocoles

La signalisation est l'ensemble des processus (méthodes) liées à l'ouverture, l'établissement

et la fermeture de session entre deux utilisateurs.

Une bonne communication n'est possible que si les deux entités en présence s'entendent
sur les règles, et les bases. En réseau, l'ensemble des règles et des bases est appelé protocole.

En téléphonie sur IP, nous distinguons trois protocoles de signalisation standard:

 Le protocole H.323: Très utilisé à l'époque, le protocole H3.323 a été mis en marge au
profit de son successeur, car jugé trop lourd à cause de nombreux en-têtes.

 Le protocole SIP : standard actuel des protocoles de signalisation, SIP est plus utilisé pour
les communications temps réels et ceci même sur le web (WebRTC).
  Le protocole MGCP : C’est un protocole qui est utilisé pour relier deux réseaux IP utilisant deux
protocoles de signalisation différentes (par exemple d’un côté nous avons SIP et de l’autre côté un
réseau H.323). Le protocole MGCP est complémentaire à H.323 ou SIP, et traite des problèmes
d’interconnexion avec le monde téléphonique (SS7,RI)

 Le protocole SCCP (Skinny Client Control Protocol) de Cisco, SCCP est un protocole léger qui
s’occupe de la signalisation entre un téléphone IP et l’Unified Communications Manager
(CUCM) de Cisco. Le flux de données repose quant à lui sur RTP.

 Le protocole IAX (Inter Asterisk eXchnage) : c’est le protocole standard de signalisation propre
à Asterisk. Ce protocole a la capacité de contrôler et de réguler les flux multimédias à un débit
très faible. C’est ce qui le différencie du protocole SIP.

 Le protocole T.38 : Ce protocole intervient dans le transfert des données le plus souvent du fax.
Les données de Fax ne peuvent pas être envoyées sur le réseau de la même manière que les
données d’une communication vocales.

 Le protocole SCCP : De son ancien nom Skinny, SCCP (Skinny Client Control Protocol) a été
développé par Selsius Corporation, SCCP fut racheté par Cisco en 1998. c’est un protocole
léger qui s’occupe de la signalisation entre un téléphone IP et l’Unified Communications
Manager de Cisco. Le flux de données repose quant à lui sur le protocole RTP.

1.2.3 Les CODECs

Les CODECs (Codeurs Décodeurs) sont des composants électroniques permettant aux circuits
intégrés de gérer les différents types de flux numériques. Les codeurs interviennent dans le processus
de numérisation. Le signal échantillonné, quantifié doit être remis aux codeurs (opération de codage). En
téléphonie sur IP, les codecs sont repartis en deux groupes:

• les codecs audio : on peut citer les codecs audios suivants :

◦ G.711, G.729, G.723, GSM, ILBC, OPUS

• les codecs vidéos : on peut citer les codecs vidéos suivants :

◦ H.261, H.263, H.264, MPEG4, VP8, VP9

Le tableau ci-dessous illustre les caractéristiques des différents codecs

Nom du Débit voix (min) Débit max Caractéristiques Algorithmes
CODEC
Kbits/s
Kbits/s

G.711 64 80 à 100 -fréquence - Loi U

d’échantillonnage
8khz
- Loi A
-débit fixe : 64kbits/s

-délai de compression

G.729 6,4 11,8 -fréquence

d’échantillonnage 8khz

-délai de compression:
5ms

G.723 5,3 6,3 -fréquence

d’échantillonnage 8khz

-délai de compression:
37,5ms

NB : Google qui est le concepteur de VP8 l’a placé sous Licence GPL pour supplanter le protocole H.264.
1.2.4 Les protocoles de transport

1.2.4.1 Le protocole TCP

La téléphonie sur IP est une application à forte contrainte. Certains protocoles de transport
ne sont pas adaptés. Il s’agit particulièrement du protocole TCP (Transport Control Protocol). Les
raisons qui expliquent l’exclusion de ce protocole sont dues en particulier aux contraintes
temporelles. TCP est un protocole de transport qui fonctionne en mode connecté (établissement de
connexion et accusé de réception). TCP offre un service de transmission de données fiable avec
détection et correction d’erreurs de bout en bout.

1.2.4.2 Le protocole UDP

UDP (User Datagramme Protocol) contrairement à TCP offre un service de transmission

non fiable c’est-à-dire en mode non connecté. Bien que UDP présente quelques bonnes
caractéristiques, ce protocole ne séquence pas les données, donc ne garantit pas la remise
conforme des données. Le protocole UDP satisfait aux contraintes temporelles de la ToIP, mais
n’est pas adapté à cause du manque de contrôle (aucune garantie que les données transmises
seront arrivées à destination dans leur intégralité). Malgré ces limites, plusieurs applications
reposent sur le protocole UDP telles que:TFTP, SNMP, DNS, RIP,etc.

1.2.4.3 Les protocoles RTP et RTCP

UDP et IP à eux seuls ne suffisent pas pour assurer le transport de la voix. Pour transporter
en temps réel les flux voix et vidéo, UDP n’est plus adapté. C’est pourquoi les protocoles RTP
(Real time Transport Protocol) et RTCP (Real Time Control Protocol) ont été conçus pour appuyer
le protocole UDP. Ces protocoles se situent au niveau de l’application et s’appuient sur le
protocole UDP. Le rôle principal d’UDP est de fournir un moyen de transporter sur le réseau IP les
flux soumis à des contraintes temps réel. Par contre, RTCP est basé sur le contrôle de flux RTP
permettant de transmettre les flux avec une qualité de service (garantie que les paquets émis ont
été arrivés à destination dans leur intégrité).
1.2.5 La qualité de service QoS
Il y a généralement 7 critères pour agir sur la qualité de service (QoS) d’un réseau VoIP :

• (Bande passante: dans contexte d’allocation par connexion ou rate-limit)

◦ codecs utilisés (e.g. G711=64kbps)
◦ intensité (Erlang)
◦ offre symétrique

• Temps de réponse, temps d’attente (latence) pour mesurer le temps écoulé pour la transmission de la
voix. [150-400ms]

• Gigue (Jitter) [<<150ms]

◦ délai entre deux paquets de donnés
◦ permet de mesurer et contrôler l’instabilité du réseau.

• Perte de transmission (Packet loss ) [1-3%]

◦ une communication VoIP peut perdre des paquets.
◦ Le taux de paquets perdus reflète le niveau d’audibilité de la communication.

• Traitement du phénomène d’écho

◦ délai entre l'émission du signal et la réception de ce même signal en réverbération produit par les
composants électroniques des parties analogiques.

• Fiabilité
◦ Disponibilité de service
◦ Solution de survie

• Sécurité
◦ Confidentialité des conversations
◦ Usurpation d’identité

1.2.6 Les ports FXO et FXS

FXS et FXO sont les noms des ports utilisés par des lignes téléphoniques analogiques (aussi connus sous le
sigle POTS – Plain Old Telephone Service).
• FXS – l’interface Foreign eXchange Subscriber est le port qui raccorde la ligne analogique de
l’abonné. En d’autres termes, la « prise murale » qui fournit la tonalité, le courant de charge et la
tension de sonnerie.
 • FXO – l’interface Foreign eXchange Office est le port qui reçoit la ligne analogique d’un opérateur. Il
peut être aussi utilisé pour un raccordement à un port poste d’ un PABX analogique.

Dans le cas où le port FXO est connecté à un port du PABX alors le numéro du poste est le numéro
définit au niveau du port du PABX.

C’est la prise du téléphone ou du fax, ou la (les) prise(s) de votre réseau téléphonique analogique. Le
FXO offre un indicateur d’état raccroché/décroché (fermeture de circuit). Puisque le port FXO est
raccordé à un appareil, tel un téléphone ou un fax, il est souvent appelé « périphérique FXO ».

1.2.7 Passerelles:
Il existe globalement deux catégories de passerelles VoIP :
• Les passerelles VoIP réseau fixe de Télécoms RTC ayant un ou des ports FXO.
• Les passerelles VoIP réseau mobile
Principe de configuration d’une passerelle GSM ou RTC
La configuration des appels entrants se fait au niveau de la passerelle même pour choisir vers quel poste on
route l’appel entrant alors que la configuration des appels sortants se fait au niveau du serveur VoIP.
Pour pouvoir utiliser les ports FXO et FXS on doit leur créer des comptes SIP
◦ les appels sortant sont configurés au niveau du PABX
◦ On crée des comptes SIP à des ports FXS et FXO que nous comptons utiliser
Exemple de passerelle GSM :
GoIP est une passerelle GSM avec 8 puces comme le montre la figure ci-après :
Quelques fonctionnalités intéressantes de la passerelle GoIP:
• gestion des appels sortants
• redirection des appels entrants vers un softphone ou un téléphone IP connecté à un serveur VoIP
• interface graphique d’envoi de sms
• redirection de SMS entrants vers un softphone ou un téléphone IP pour vu que le serveur VoIP gére le
protocole SIMPLE : c’est le cas Asterisk, Kamailio et Freeswitch.
• activation du serveur SMPP pour que la passerelle se comporte comme un centre SMS d’un opérateur
de télécoms : ainsi des passerelles SMS tels que JASMIN et KANNEL peuvent l’utiliser pour envoyer
des SMS.
Exemple de passerelle RTC :
Cette passerelle de Tplink 300Mbps Wireless N VoIP ADSL2+ Modem Router de Modele TD-VG3631 comme
le montre la figure ci-dessous :

Cette passerelle comporte deux ports FXS permettant d’utiliser deux téléphones analogiques classiques ou
deux téléphones analogiques DECT et un port FXO permettant d’y connecter une ligne RTC.
 Activité 2

Étude du protocole SIP

Objectifs spécifiques

A la fin de cette partie, le lecteur doit être capable de:

• Comprendre et maîtriser l’architecture SIP ;

• Connaître les mécanismes de signalisation SIP ;
• Être capable d’interpréter les messages SIP ;
• Être capable de donner les informations des en-têtes des messages SIP.

Contenu

• Historique du protocole SIP ;

• Architecture et fonctionnement du protocole SIP ;
• Composants d’une architecture SIP ;
• En-têtes des messages SIP.
 Le protocole SIP (Session Initialisation Protocol) a été conçu dans le but de standardiser les
sessions de communications multimédias. Il s'agit d'un standard ne permettant pas le transport des données
mais, l'initialisation de sessions. Le transport des données est très souvent attribué au protocole RTP (Real
time Transport). Ce protocole a été conçu pour remplacer le protocole H.323, très complexe

2.1 Historique
Apparu sur le monde de la VoIP (Voix sur IP) en 1996, le protocole SIP contenait un seul type de
requête dédiée à la mise en place d'appel. Il a été normalisé par le groupe de travail «WG MMUSIC»
(Work Group Multiparty Multimédia Session Control) de l'IETF. C'est un protocole de signalisation hors
bande pour le maintien,la modification,la gestion et la fermeture de session interactive entre
utilisateurs,pour la téléphonie et la visioconférence. Le protocole n’assure pas le transport des données
utiles, mais a pour fonction d’établir la liaison entre les interlocuteurs. Il se situe au niveau de la couche
applicative du modèle de référence OSI et fonctionne selon une architecture client-serveur, le client
émettant des requêtes et le serveur exécutant en réponse les actions sollicitées par le client

2.2 Caractéristiques du protocole SIP

Le protocole SIP assure des fonctions telles que la redirection d’appel, la modification des
paramètres associés à la session en cours ou l’invocation de services. Cependant, SIP ne fournit pas
l’implémentation des services, mais propose des moyens génériques permettant de les utiliser. De cette
manière, l’implémentation des services est laissée libre, et seul le moyen d’accéder aux services est
fourni.

2.2.1 La Compatibilité
Le protocole SIP a de grands atouts quant à sa capacité à s’intégrer à d’autres protocoles
standards du monde IP. En tant que standard ouvert, il offre un service modulaire, prévu pour
fonctionner avec différentes applications, telles que la téléphonie, la messagerie instantanée,
 la vidéoconférence, la réalité virtuelle ou même le jeu vidéo. Sa compatibilité repose sur le
fait qu'il fonctionne avec d'autres protocoles tels que:
• RTP (Realtime Transport Protocol), RFC 3550, qui se charge du transport des flux temps
• RTCP (Realtime Transport Control Protocol), qui fournit des informations dynamiques sur l’état du
Réseau.
• RTSP (RealTime Streaming Protocol), pour contrôler la diffusion de flux multimédias en temps réel.

2.2.2 Modularité
Comme expliqué précédemment, le protocole SIP se veut modulaire. Son objectif est de constituer
une brique de base pouvant se combiner avec le maximum d’autres protocoles. C’est la raison pour laquelle
il a été conçu d’une manière indépendante de la couche de transport.

2.2.3 Simplicité
SIP affiche une grande simplicité, comme l'atteste la taille de la spécification du protocole, qui ne
dépasse pas 153 pages dans sa première version (RFC 2543) et 269 pages dans la seconde (RFC 3261), ce
qui reste nettement inférieur aux 763 pages de la spécification H.323.
SIP utilise un langage textuel très proche des protocoles HTTP et SMTP, ce qui facilite son intégration à
Internet. Par comparaison, le protocole H.323 utilise ASN.1, qui est un langage compilé. La simplicité de
SIP en fait un protocole facile à embarquer et un candidat de choix pour les composants légers, dotés de
capacités réduites, comme les Son implémentation est peu gourmande en ressources de traitement. La
simplicité de SIP ne l’empêche nullement d’être véritablement performant. Sa souplesse d'utilisation est
ainsi l'une de ses caractéristiques principales. Il est par exemple possible de modifier une session encours.

2.3 Les composants de l’architecture sip

Le protocole SIP s'appuie sur une architecture purement logicielle. L'architecture SIP repose sur
cinq entités:

• terminal utilisateur ;
• serveur d’enregistrement ;
• serveur de localisation ;
• serveur de redirection ;
• serveur proxy.
 Figure 2.1 : Composants de l’architecture SIP

2.4.1 Terminal utilisateur

Le terminal est l’élément dont dispose l’utilisateur pour appeler et être appelé. Il doit donc permettre
de composer des numéros de téléphone. Il se présente sous la forme d’un composant matériel ou d’un
composant logiciel. Le terminal est appelé UA (User Agent). Il est constitué de deux sous-entités, comme
Une partie cliente, appelée UAC (User Agent Client), chargée d’émettre les requêtes. C’est l’UAC qui initie
un appel. Une partie serveur, appelée UAS (User Agent Server), qui est en écoute, reçoit et traite les
requêtes.
 C’est l’UAS qui répond à un appel. Il gère la signalisation. L’association des requêtes et des
réponses entre deux entités de type UA constitue un dialogue. Parmi les clients SIP, on peut citer
Parmi Les terminaux SIP,

Il y a globalement de deux types de terminaux SIP :

les téléphones IP matériels et les softphones qui sont des terminaux IP logiciels.

Parmi les softphones SIP les plus utilisés on peut citer :

• MicroSIP (version Windows) ;

• Zoiper (sous Android, sous Windows) ;

• CsipSimple (sous android) ;

• X-Lite (sous Windows, sous Linux);

• jitsi (sous Linux et Windows) ;

• PortGo (sous Android, sous Windows) ;

• Boghe IMS client (sous Windows) ;

• Imsdroid (sous Android).

2.4.2 Serveur d’enregistrement

Le serveur d’enregistrement (Registrar Server) offre un moyen de localiser un correspondant
avec souplesse, tout en gérant la mobilité de l’utilisateur. Il peut en outre supporter l’authentification des
abonnés. L’enregistrement d’un utilisateur est constitué par l’association de son identifiant et de son
adresse IP. Un utilisateur peut s’enregistrer sur plusieurs serveurs d’enregistrement en même temps.
Dans ce cas, il est joignable simultanément sur l’ensemble des positions qu’il a renseignées. Un serveur
SIP peut fonctionner suivant deux modes.
• Le mode Sateful: Lorsqu'un serveur SIP fonctionne en sateful, il se souvient des demandes qu'il a
reçu ainsi que les réponses qu'il a envoyées.

• Le mode Apartride: Contrairement au mode sateful, le serveur en mode apartride oublie toutes les
informations une fois qu'il a adressé une demande. Les serveurs SIP en mode sateful sont
susceptibles d'être des dispositifs locaux. A ces fonctions s'ajoutent d'autres fonctions tel que la
redirection.
2.4.3 Le serveur de localisation
Le serveur de localisation (Location Server) agit en complément au serveur d’enregistrement en
permettant la localisation de l’abonné.
Ce serveur contient la base de données de l’ensemble des abonnés qu’il gère. Cette base est renseignée
par le serveur d’enregistrement. Chaque fois qu’un utilisateur s’enregistre auprès du serveur
d’enregistrement, ce dernier en informe le serveur de localisation.

2.4.4 Le serveur de redirection

Il agit comme un intermédiaire entre le terminal appelant et le serveur de localisation. Quand le
terminal veut appeler un autre, il contacte le serveur de redirection pour lui demander la localisation de
l’appelé; une fois la localisation faite, l'information est donnée au terminal appelant qui se charge de
contacter l'appelé. Ainsi le terminal appelant n'a pas besoin de connaître l'adresse du serveur de
localisation.

2.4.5 Le serveur proxy

Serveur Proxy: permet d'initier une communication à la place de l'appelant. Il agit pour le compte
du terminal et remplit les fonctions suivantes:

• Localiser un correspondant ;

• Réaliser éventuellement certains traitements sur les requêtes ;

• Initier, maintenir et terminer une session vers un correspondant.

Lorsqu’un utilisateur demande à un serveur proxy de localiser un correspondant, ce dernier effectue la

recherche, mais, au lieu de retourner le résultat au demandeur (comme le ferait un serveur de redirection),
il utilise cette réponse pour effectuer lui-même l’initialisation de la communication en invitant le
correspondant à ouvrir une session. Donc le serveur proxy peut agir comme un terminal utilisateur. On
distingue deux types de serveurs proxy :
 Proxy statefull, qui maintient pendant toute la durée des sessions l’état des connexions ;
 Proxy stateless, qui achemine les messages indépendamment les uns des autres, sans
sauvegarder l’état des connexions.

On peut citer comme serveurs SIP:

 Kamailio
 OpenSIP
 Asterisk
 Freeswitch
 Clearwater
 OpenIMSCore
Objectifs spécifiques 3/2
A la fin de ce paragraphe, le lecteur doit:
• Être capable de comprendre tous les types de messages SIP ;
• Être capable d’interpréter les réponses SIP.

Contenu
• L’adressage SIP ;
• Les requêtes SIP ;
• Les en-têtes SIP ;
• Les procédures :
◦ Enregistrement

◦ Ouverture de session ;
• La signalisation SIP ;
• Modes de transmission.
3.1 Les messages et les requêtes SIP
Le protocole SIP utilise de nombreuses similitudes tant par les méthodes de transmission que par
les messages avec le protocole HTTP. Ce qui facilite son intégration à internet. D'où le surnom de cousin
de HTTP. Une communication SIP commence par une initialisation.

3.2 L'adressage SIP

L’objectif de l’adressage est de localiser les utilisateurs dans un réseau. C’est l’une des étapes
indispensables pour permettre à un utilisateur d’en joindre un autre. Pour localiser les utilisateurs, il
faut pouvoir les identifier de manière univoque. SIP propose des moyens très performants pour nommer
les utilisateurs, grâce au concept d’URI, classique sur Internet. Un URI définit une syntaxe permettant
de désigner de manière unique, formelle et normalisée une ressource, qu’il s’agisse d’un document
textuel, audio, vidéo ou plus généralement d’une entité logique ou physique. Une ressource décrite par
un URI peut être déplacée ou même supprimée. L’URI correspondant n’en conserve pas moins de
manière permanente la valeur descriptive de la ressource.
Le format d'une adresse SIP est de la forme :

sip :identifiant :[password] @server :[paramètres]

 Le mot-clé sip désigne le protocole utilisé pour la communication

 Identifiant spécifie le mot de passe ou le nom utilisateur

 Password est facultatif, mais on peut l'utiliser pour s'authentifier au serveur.

 serveur, désigne le serveur qui se charge du compte SIP

 paramètres, ce champ est optionnel.

3.3 L'initialisation
Le protocole SIP bien entendu est un protocole qui initie la communication entre deux
agents SIP. Une communication peut s’effectuer directement entre deux correspondants, sans
faire intervenir d’autres entités. Dans ce cas, l’appelant doit connaître la localisation (sous forme
d’adresse IP) de la personne qu’il souhaite contacter.Le principe d'initialisation met en évidence
quatre requêtes de base:

3.4 Les requêtes SIP

Le format générique d'un message SIP est de la forme

Ligne de requête d’état

En-tête
Corps du message

SIP n’utilise que six méthodes fondamentales pour formuler ses requêtes. Cela indique très
nettement la volonté de simplicité de ses concepteurs.
• L'appelant (UAC) envoie un message INVITE (requête INVITE) permet d’initier une communication
en invitant un correspondant à y participer. Ce message contient les paramètres désirés pour établir la
communication.
• Le message ACK: Elle fait suite à l’acceptation d’un appel par l’appelé avec la méthode d’invitation,
envoie la confirmation de la requête ou confirment établissement de la session.
• Le massage OK: Ce message spécifie que les utilisateurs peuvent ouvrir une session. Le canal de
communication est disponible.
• Le message CANCEL: Code d'annulation de réponse, Cette méthode annule une requête dont la
réponse n’est pas encore parvenue au demandeur. Elle ne permet pas d’interrompre une session, mais
indique que la réponse n’est plus attendue et qu’il n’est donc pas nécessaire de traiter la requête.
• Le message BYE: La requête BYE permet de libérer une communication. Cette requête peut être
émise indifféremment par l’appelant ou par l’appelé. Elle n’attend pas d’acquittement, puisqu’une
terminaison d’appel peut être décidée unilatéralement.
• Les réponses aux requêtes sont envoyées sous forme de code. Voici quelques codes de
réponse.
3.5 Les Entêtes SIP
3.5.1 L’en-tête VIA
L’en-tête Via est utilisé pour enregistrer l’itinéraire de la requête et permettre ainsi
l’acheminement de la réponse. L’entité UAC générant une requête enregistre sa propre adresse
dans un en-tête Via. L’ordre des en-têtes Via est important car la réponse doit emprunter le
même chemin, en sens inverse, que la requête.

Les entités PROXY SERVER assurant le relayage de la requête ajoutant un en-tête Via
contenant leur propre adresse à la tête de la liste des en-têtes Via.
L’entité UAS générant une réponse à la requête recopie tous les en-têtes Via et envoie la
réponse à l’adresse indiquée le premier en-tête de la liste.

A la réception d’une réponse, l’entité PROXY SERVER vérifie le premier en-tête de la liste
afin d’assurer qu’il correspond à sa propre adresse, puis le retire et ensuite transfère la réponse
à l’adresse indiquée dans le prochain en-tête Via.
L’en-tête Via contient le nom du protocole, sa version, le type de protocole de transport
( SIP/2.0/UDP, SIP/2.0/TCP, etc.), et des paramètres comme branch.
Les en-têtes UAC et PROXY SERVER ajoutent un paramètre branch qui identifie la
transaction en cours.
Via : SIP/2.0/UDP 192.168.1.208;branch=z9hG4bKnashds7

3.5.2 L’en-tête Form

L’en-tête Form indique la source de la requête. L’en-tête UAC ajoute le paramètre tag qui participe
à l’identification du dialogue.
Form: Aly <sip:aly@ec2lt.sn>;tag=9fxced76sl

3.5.3 L’en-tête To
L’en-tête To indique le destinataire de la requête. Les réponses générées par l’entité UAS contiennent
cet en-tête avec l’ajout d’un paramètre tag.
To: Latyr <sip:latyr@ec2lt.sn>;tag=3flal12fs

La valeur du paramètre tag de l’en-tête To, associé à celle du paramètre tag de l’en-tête From et à celle de
l’en-tête Call-ID identifie la dialogue.
 3.5.4 L’en-tête Call-ID
L’en-tête Call-ID est une partie de l’identification du dialogue entre deux entités UA. L’en-tête Call-
ID doit être unique pour un rappel.

La valeur de l’en-tête Call-ID est créé par l’entité UAC et n’est jamais modifiée par les entités
PROXY SERVER.
Call-ID:3848276298220188511@ec2lt.sn

3.5.5 L’en-tête CSeq

L’en-tête Cseq contient un nombre décimal qui augmente chaque requête, à l’exception des requêtes
CANCEL et ACK, qui utilisent le numéro séquence de la requête INVITE à laquelle elles se réfèrent.
Cseq : 1 INVITE

3.5.6 L’en-tête Contact

L’en-tête Contact est utilisé pour transmettre l’adresse IP de l’émetteur de la requête ou de la réponse. Cette
adresse est mise en cache pour le routage des requêtes subséquentes dans un dialogue.
Le paramètre expires indique le temps de validité de l’enregistrement de l’identité de l’émetteur.
Contact : <sip:Latyr@192.168.1.208>; expires=3600

3.5.7 L’en-tête Max-Forwards

L’en-tête Max-Forwards indique le nombre maximal de sauts qu’une requête peut prendre. La valeur du
champ d’en-tête est décrémenté d’une unité par chaque entité PROXY SERVER qui transfère la requête.
Max-Forwards : 70
Une entité PROXY SERVER, recevant cet en-tête avec une valeur de zéro, supprime le message et renvoie
une réponse 483 Too Many Hops à la source du message.

3.5.8 L’en-tête Content-Type

L’en-tête Content-Type spécifie les types possibles de corps du message associé au messages SIP.
Content-Type: application/sdp

3.5.9 L’en-tête Content-Length

L’en-tête Content-Length indique le nombre d’octets dans le corps du message. Une valeur égale à zéro
indique l’absence de corps de message. Le compte d’octets ne comprend pas le caractère de retour à la ligne
CRLF (Carriage Return Line Feed) qui sépare le message SIP du corps du message.
Content-Length: 151

3.5.10 L’en-tête Route

L’en-tête Route est utilisé pour fournir des informations de routage des requêtes. Deux modes de routage sont
définis, le routage strict et le routage lâche.

Dans le mode de routage strict, la requête doit obligatoirement suivre l’itinéraire décrit dans la liste des en-
têtes Route. L’en-tête PROXY SERVER doit utiliser l’adresse de l’en-tête Route pour remplacer l’identité
URI de la requête avant de transférer la requête.

Dans le mode de routage Lâche, la requête doit être acheminée à travers chaque entité PROXY SERVER
identifiée dans la liste des en-têtes Route, mais peut aussi être routée à travers d’autres entités PROXY
SERVER. L’entité PROXY SERVER ne doit pas modifier l’identité URI de la requête.
Route: <sip: 192.168.1.208;lr>

3.5.11 L’en-tête Record-Route

L’en-tête Record-Route est utilisé pour forcer le routage à travers une entité PROXY SERVER pour toutes les
requêtes subséquentes entre deux entités UA. L’entité PROXY SERVER indique dans cet en-tête son adresse
lors de la requête initiale.l’entité UAS recopie la liste des en-têtes Record-Route dans la réponse. La liste est
transmise à l’entité UAC, sans être modifiée par les entités PROXY SERVER.

Le paramètre lr indique que les entités PROXY SERVER supportent pour les messages SIP le mode de
routage lâche.
Record-Route : <sip:192.168.1.208;lr>

3.5.12 L’en-tête WWW-Authenticate

L’en-tête WWW-Authenticate est utilisé dans la réponse 401 Unauthorized. Il contient un défi
d’authentification (paramètre nonce) de l’entité UAC par l’entité REGISTRAR.

3.5.13 L’en-tête Authorization

L’en-tête Authorization transporte les informations d’authentification (paramètre response) de l’entité UA à
destination de l’entité REGISTRAR. Il est envoyé ensuite à une response 401 Unauthorized contenant un défi.
3.5.14 L’en-tête Proxy-Authenticate
L’en-tête Proxy-Authenticate est utilisé dans la réponse 407 Proxy-Authenticate. Il contient le défi
d’authentification de l’entité UAC par l’entité PROXY SERVER.

3.5.15 L’en-tête Proxy-Authorization

L’en-tête Proxy-Authorization transporte les informations d’authentification de l’entité UA à destination de
l’entité PROXY SERVER. Il est envoyé suite à une réponse 407 Proxy Authentification Required contenant
un défi.

3.5.16 L’en-tête Refer-To

L’en-tête Refer-To est utilisé avec la requête REFER. Il spécifie l’identité SIP URI vers laquelle la
communication doit être tranférée.
Refer-To: Bouki <sip:bouki@ec2lt.sn>

3.5.17 L’en-tête Replaces

Lorsque une entité à reçu la requête REFER, elle génère une requête INVITE pour effectuer le transfert de la
communication. l’en-tête Replaces contient les identifiants du dialogue concerné: en-tête Call-ID, paramètre
tag des en-têtes From et To.

3.5.18 L’en-tête RSeq

L’en-tête Rseq est utilisé dans les réponses de type 1xx à une requête INVITE. Il contient un numéro de
séquence qui identifie la réponse. Il est inséré car la requête INVITE contient l’en-tête Supported prenant la
valeur rell00.
Rseq: 12345

3.5.19 L’en-tête Rack

L’en-tête Rack est utilisé dans la requête PRACK qui acquitte la réception d’une réponse de type 1xx. Il
contient les identifiants de la requête INVITE (Cseq) et de la réponse à valider (Rseq).
Rack: 12345 1 INVITE
4. La description du média
Le protocole SDP (Session Description Protocol) fournit une description de flux média pour lequel
l’établissement de la session est mis en œuvre par le protocole SIP. Le message SDP constitue le corps de
message attaché au message SIP. Il apparaît généralement dans la requête INVITE et dans la réponse 200 OK.
Les paramètres qui caractérisent le flux média sont les suivantes :
• le type de média (audio, vidéo, données)
• le protocole de transport (par exemple RTP) ;
• le format du média (par exemple le type de codec pour la voix et la vidéo) ;
• l’adresse IP à laquelle le média doit être transmis ;
• le numéro du port de destination.
Le message SDP est un ensemble de lignes de format <type>=<valeur>. Le champ <type> contient un
caractère. Le contenu du champ <valeur> dépend du type.

Tableau 4.1: Le message SDP

Champ <type> Description
V Version du protocole. Le contenu du champ <valeur> est <0>
O Identifiant de l’origine et de la session
S Nom de la session. Le contenu du champ <valeur> est <->
C Information sur la connexion
T Temps d’activité de la session. Le contenu du champ <valeur> est <0 0>
M Description du média
A Attribut complémentaire du média

Le champ <valeur> correspondant au champ <0> contient les paramètres suivants :

o=Aly 28908445526 28908445526 IN IP4 192.168.1.208
• le nom de l’utilisateur (Aly)
• l’identifiant de la session ( 28908445526). Cette valeur est fixe lorsque le message SDP est associé au
message SIP ;
• la version de la session (28908445526).La valeur de champ correspond au réseau Internet ;
• le type d’adresse (IP4)
• l’adresse IP de la machine qui a créé la session (192.168.1.208)
Le champ <valeur> correspond au champ <m> contient les paramètres suivants pour l’établissement d’un flux
audio :
• m=audio 49172 RTP/AVP 0
• le type de média (audio)
• le numéro de port auquel le flux audio être transmis (49172). La valeur indiquée est celle du flux RTP.
La valeur suivante est utilisée pour les messages RTCP ;
• le type de protocole de transport (RTP/AVP) ;
• le type de codec (0). Cette valeur est indique à celle utilisé dans le protocole RTP pour définir le type
de codec.
Le champ <valeur> correspond au champ <a> contient les paramètres suivants fournissant une description
complémentaire du flux audio :
a=rtpmap : 0 PCMU/8000
• le type de codec (0). Cette valeur est identique à celle utilisé dans le protocole RTP pour définir le type
de codec ;
• le nom du codec (PCMU) ;
• la fréquence d’échantillonnage(8000)

5. Les procédures
5.1 L’enregistrement
Une entité UA s’enregistre auprès de l’entité REGISTRAR. Elle détermine l’adresse IP de destination de la
manière suivante :
• l’adresse IP est obtenu par configuration, par exemple via un serveur DHCP ;
• L’adresse est l’adresse multicast 224.0.1.75
• l’adresse IP est obtenue en effectuant une résolution DNS (Domain Name System) à partir du nom de
domaine.
L’identité URI de la requête REGISTRAR correspond au nom de l’entité de LOCALISATION SERVER
auprès de laquelle Latyr s’enregistre.
L’en-tête To contient l’identité URI à enregistrer. L’en-tête From contient l’identité de l’entité qui effectue
l’enregistrement. L’en-tête Contact contient l’adresse IP qu’il convient de lier à l’identité SIP URI de L’en-tête
To.

Le dialogue est identifié par l’en-tête Call-ID et le paramètre tag de l’en-tête From.
L’entité REGISTRAR doit authentifier Latyr. Pour cela l’en-tête WWW-Authenticate de la réponse négative
401 Unauthorized contient le défi dans le paramètre nonce et le type de fonction de hachage dans le paramètre
algorithm, qui permettra à Latyr de construire ses données d’authentification.
L’entité REGISTRAR termine l’identification du dialogue en renseignant le paramètre tag de l’en-tête To.
La réponse est envoyée à l’adresse IP contenue dans l’en-tête Via.

L’entité UAS de Latyr transmet une nouvelle requête REGISTRAR dont l’en-tête Authorization contient les
données d’authentification dans le paramètre response.
L’en-tête Call-ID et le paramètre tag de l’en-tête To prennent de nouvelles valeurs.
La valeur de l’en-tête Cseq est incrémentée d’une unité.

L’entité REGISTRAR répond positivement si l’authentification a réussi.

L’entité Contact de la réponse contient le paramètre expires qui spécifie la duré de l’enregistrement.
L’entité REGISTRAR complète l’identification du dialogue en renseignant le paramètre tag de l’en-tête To.
6. Session
6.1 L’établissement de la session
6.1.1 Le routage de la requête initiale
L’entité UA d’Aly utilise une application SIP sur son terminal (sofphone ou hardphone) pour appeler Latyr.
Une entité PROXY SERVER agissant dans leur domaine ec2lt.sn facilite l’établissement de la session.

L’établissement de la session commence par une requête INVITE adressée à l’identité SIP URI de Latyr
(sip:latyr@ec2lt.sn).

La requête contient les en-têtes Via, utilisé pour le routages des réponses, Max-Forwards (valeur égale à 70),
From (identité SIP URI d’Aly et paramètre tag), To (identité SIP de Latyr) Call-ID, Cseq, Contact ( adresse IP
d’Aly), Content-Type (corps de message SDP), Content-Length.

Comme l’entité UA d’Aly ne connaît pas l’adresse IP de Latyr, elle envoie la requête INVITE à son PROXY
SERVER. L’adresse IP de l’entité PROXY SERVER (192168.1.205) peut être configurée manuellement ou
dynamiquement (par exemple par l’intermédiaire du serveur DHCP) dans l’entité UA d’Aly. L’adresse IP de
l’entité PROXY SERVER renseigne l’en-tête Route.
Le corps du message SDP contient les caractéristiques de la session qu’Aly veut établir avec Latyr :
• adresse IP : 192.168.1.205
• numéro de port : 49172
• le type de média : audio
• le type de codec : PCMU
L’entité PROXY SERVER d’Aly requiert l’authentification d’Aly pour l’établissement de la session. L’en-tête
Proxy-Authenticate de la réponse nonce et spécifie l’algorithme de hachage MD5.

L’entité PROXY SERVER complète l’en-tête To en ajoutant le paramètre tag.

L’entité UA d’Aly acquitte la réponse réponse reçue de son PROXY SERVER en envoyant la requête ACK.

L’entité UA d’Aly renvoie la requête INVITE. L’en-tête Proxy-Authorization contient le paramètre response
dont la valeur est calculée à partir de la valeur du champ nonce reçu et du secret d’Aly. La valeur de l’en-tête
Cseq est incrémentée d’une unité.

Il est à noter que le paramètre tag est absent de l’en-tête To car il s’agit d’un nouveau dialogue.

L’entité PROXY SERVER d’Aly authentifie l’entité UA d’Aly si la réponse reçue dans l’en-tête Proxy-
Authorization est identique au calcul effectué localement.

L’entité PROXY SERVER envoie une réponse 100 Trying à l’entité UA d’Aly. La réponse 100 Trying indique
que la requête INVITE a été reçue et que l’entité PROXY SERVER la traite pour assurer son acheminement
vers la cible. Elle permet de confirmer implicitement l’authentification de l’entité UA d’Aly.
Avant de transférer la requête, l’entité PROXY SERVER d’Aly ajoute de nouveaux en-têtes Via et Record-
Route contenant sa propre adresse et décrémente le champ Max-Forwards d’une unité.

L’entité PROXY SERVER reçoit la requête INVITE et qu’elle la traie pour assurer son acheminement vers la
cible.

L’entité PROXY SERVER consulte l’entité LOCALISATION SERVER qui contient l’adresse IP de Latyr.
Elle remplace le nom de domaine de l’identité de Latyr par son adresse IP. Elle ajoute de nouveaux en-têtes
Via et Record Route, décrémente d’une unité la valeur de l’en-tête Max-Forwards et transmet la requête
INVITE vers l’entité UA de Latyr.

L’entité UA de Latyr reçoit la requête INVITE et une sonnerie permet d’avoir Latyr de l’arrivée d’un appel.
6.1.2 Le routage de la requête subséquente
L’entité UA d’Aly envoie un message d’accusé de réception ACK à l’entité UA de Latyr pour confirmer la
réception de la réponse 200 OK. La requête inclut les en-têtes Route qui contiennent la liste des entités
PROXY SERVER que la requête doit traverser. Ces en-têtes sont renseignés à partir du contenu des en-têtes
Record Route reçus dans les réponses.

La requête ACK est relayée par le PROXY SERVER vers l’entité UA de Latyr.
Au cours de la session, Aly ou Latyr peuvent décider de modifier les caractéristiques du média, par exemple
passer d’une session téléphonique à une session visiophonique, par l’envoi d’une nouvelle requête INVITE
(reINVITE) contenant la description des nouveaux médias. Cette nouvelle requête contient les mêmes
identifiants du dialogue afin que l’autre partie sache qu’il s’agit bien d’une modification de la session
existantes.

L’autre partie envoie une réponse 200 OK pour accepter le changement. Le demandeur répond avec un accusé
de réception ACK. Si l’autre partie n’accepte pas le changement, il renvoie une réponse définitive et négative
488 Not acceptable, la requête INVITE ne provoque pas la coupure de l’appel en cours, et la session continue
à utiliser les caractéristiques précédemment négociées.

6.1.3 La libération de la session

6.1.3.1 Cas 1 : la session est établit
A la fin de la communication, si Latyr raccroche le premier, son entité UA envoie un message BYE à son
entité PROXY SERVER.
La requête BYE est relayée par l’entité PROXY SERVER vers l’entité UA d’Aly.

L’entité UA d’Aly confirme la réception de la requête BYE avec une réponse 200 OK, ce qui termine le
dialogue.
La réponse 200 OK est relayée par l’entité PROXY SERVER vers l’entité UA de Latyr

6.1.3.2 Cas 2 : l’appelé ne répond pas

Si Latyr ne répond pas son combiné, Aly peut raccrocher et terminer une session qui n’a pas abouti. L’entité
UA d’Aly provoque la terminaison du dialogue initialisée par la requête INVITE par l’envoi de la requête
CANCEL.
L’entité UA de Latyr répond à la requête CANCEL pour terminer la transaction
L’entité PROXY SERVER transfère la réponse vers l’entité UA d’Aly.
L’entité UA de Latyr termine le dialogue initialisé par la requête INVITE, ce qui provoque l’arrêt de la
sonnerie

L’entité PROXY SERVER d’Aly transfère la réponse à l’entité UA d’Aly, ce qui provoque l’arrêt de la
tonalité de retour de sonnerie.

L’entité UA d’Aly envoie un message d’accusé de réception ACK à l’entité UA de Latyr pour confirmer
la réception de la réponse 487 Request Terminated.
6.1.3.3 Cas 3 : l’appelé ne répond pas
A la réception de la requête INVITE, l’entité UA de Latyr transmet la réponse définitive et négative 486
Busy Here, indiquant que Latyr est en communication et qu’il ne prend pas l’appel.

Libération de la session

L’entité PROXY SERVER transfère la réponse à l’entité UA d’Aly. La réception du message déclenche la
tonalité d’occupation.

L’entité UA d’Aly envoie un message d’accusé de réception ACK à l’entité UA Latyr pour confirmer la
réception de la réponse 486 Busy Here.

3.6 Les Méthodes SIP

Les méthodes SIP sont sont associées à certains codes appelés codes de retour qui indique à
l’utilisateur si une requête SIP a bien été exécutée ou non.
1xx= réponses informatives
100 Trying – tentative en cours
180 Ringing -sonnerie
181 Call Is Being Forwarded –transfert d’appel
182 Queued – file d’attente
183 Session Progress – progrès de session

2xx = réponses
réussies 200 OK
202 accepted: Used for referrals – accepté: utilisé pour orientation

3xx = réponses de redirection

300 Multiple Choices – choix multiples 301
Moved Permanently – déplacé
302 Moved Temporarily – temporairement déplacé 305
Use Proxy – utilisation par proxy
380 Alternative Service – service alternatif

4xx = échecs
400 Bad Request – requête erronée
400 Unauthorized – refusé : seulement utilisé par les registrars. Les proxy doivent employer l’autorisation
par proxy

407 Payment Required (Reserved for future use) – payment nécessaire (Réservé pour utilisation ultérieure)
403 Forbidden -interdit
404 Not Found – introuvable : utilisateur non localisé
405 Method Not Allowed – méthode non autorisée
406 Not Acceptable – requête non acceptable
407 Proxy Authentication Required – authentification proxy nécessaire
408 Request Timeout –délai de demande écoulé : utilisateur non trouvé dans le temps accordé

410 Gone – désinscrit: l’utilisateur a existé mais n’est désormais plus disponible:
413 Request Entity Too Large – requête trop large
414 Request-URI Too Long – requête URI trop longue
415 Unsupported Media Type – type de media non compatible

416 : Unsupported URI Scheme – schéma URI non compatible

420 : Bad Extension- extension erronée: l’extension n’existe pas, le serveur ne comprend pas la requête
421 Extension Required – extension nécessaire
423 Interval Too Brief – intervalle trop court
480 Temporarily Unavailable – momentanément non disponible
481 Call/Transaction Does Not Exist – appel/transaction n’existe pas

482 Loop Detected – boucle détectée

483 Too Many Hops – trop debonds
484 Address Incomplete – adresse incomplète

485 Ambiguous - ambiguë

486 Busy Here - occupé
487 Request Terminated – requête avortée
488 t Acceptable Here – n’est pas acceptable ici

491 Request Pending – requête en attente

493 Undecipherable - indéchiffrable: ne peut pas décrypter le corps S/MIME

5xx = erreurs de serveurs

500 Server Internal Error – erreur interne de serveur
501 Not Implemented: la méthode de requête SIP n’est pas implémentée ici

502 Bad Gateway – mauvaise passerelle

503 Service Unavailable – service non disponible
504 Server Time-out – délai d’attente de serveur
505 Version Not Supported: le serveur n’est pas compatible avec la version du protocole SIP
513 Message Too Large – message trop large
6xx = échecs généraux

3.7 La signalisation
Le processus de signalisation est basé sur une architecture client-serveur. Lorsqu’un
appelant (UAC) envoie une requête à l'URI SIP de la personne appelée. Le client connaît
l'emplacement de l'autre partie. Il peut envoyer la demande directement à l'adresse IP concerné
sinon il peut l'envoyer au serveur IP pour la résolution. Le serveur procède à la résolution de
l'emplacement et renvoie la demande. Au cours de la localisation d'un utilisateur un serveur de
réseau SIP peut procuration ou rediriger l’appel vers des serveurs supplémentaires jusqu'à ce qu'il
arrive à celui qui sait très bien où l’adresse IP de l’utilisateur appelé peut être trouvée. Une fois
trouvé la demande est renvoyée à l'utilisateur. Dans le cas plus simple, le client de téléphonie de
l'utilisateur reçoit la demande, à ce moment son téléphone sonne. Deux cas de figures se
présentent: Si le client ne prend pas l'appel, la session est redirigée vers un serveur de messagerie
vocale. Sinon il prend l'appel en appuyant sur le «*» comme capacité désignée (Les capacités
désignées font références aux options que choisira l'utilisateur).

3.8 Mode de transmission

Le protocole SIP est réservé à des réseaux IP et utilise le port 5060 en TCP/UDP. Il n'a
pas la charge du transport de la voix. Ilne gère alors que l'établissement d'une connexion et la
signalisation. Le canal voix est utilise alors le protocole RTP. La communication entre les agents
SIP s'effectue ainsi.
Lorsqu'un agent SIP s'identifie auprès de son REGISTRAR en fournissant son adresse
SIP. Notons que chaque téléphone dispose d'un UA (User Agent).

Le couple adresse IP-UA est donc transmis au REGISTRAR qui au retour enregistrer la
localisation du dispositif et lui attribuer une URI (Uniform Ressourse Identifier) SIP qui
ressemble e une adresse e- mail. Le REGISTRAR gère les requêtes et inscrit dans la base de
données les UA, afin de garantir qu'un utilisateur est joignable. La requête REGISTRAR doit être
renouvelée entre 60 à 3600s selon la configuration de l'architecture du réseau. Ce mécanisme
assure qu'une requête envoyé sur téléphone va aboutir. Mais si un UA ne s'enregistrer pendant
dans la période donné il sera supprimé dans la base de données.
ATELIER SIP

TP0 :
Installation de deux terminaux SIP (MicroSIP, zoiper, CSIPsimple …) et appels directs entre
deux terminaux et l’impact des codecs audios et vidéos
TP1 :
Appel point à point entre deux terminaux SIP et faire l’analyse des trames
TP2 :
Installation d’un serveur SIP (Asterisk), Création de compte SIP, définition du Dialplan
(Création des numéros) et l’impact et gestion des codecs
TP3 :
Utilisation des applications avancées d’Asterisk (voicemail, voicemailmain, messagesend,
confbridge),
TP4 :
Gestion de centre d’appels avec Asterisk
TP5 :
Installation et configuration de Kamailio
TP6 :
Interconnexion Kamailio et Asterisk
TP7 :
Interconnexion d’un serveur VoIP à un fournisseur VoIP sur Internet
TP8 :
Gestion des NAT avec Kamailio et RTPEngine
NB : Le rapport de l’atelier doit être rendu à la fin du module
 Activité 3

Étude du protocole SCCP

Objectifs spécifiques 4
• Être capable d’installer l’émulateur GNS3 et charger les IOS ;

• Être capable de configurer l’interface d’un routeur sousGNS3 ;

• Savoir configurer un routeur Cisco (Call Manager Express) et les terminaux pour la téléphonie ;

• Être capable d’interconnecter deux Call Manager Express

Contenu

• Activation du Call Manager Express ;

• Interconnexion de deux Call Manager Express
 SCCP (Skinny Client Control Protocol) est le protocole de signalisation développé par Selsius
Corporation Inc. et racheté par Cisco. C'est un protocole très léger qui s’occupe de la signalisation entre
un terminal et le Call Manager. Les flux de données sont transportés par le protocole RTP. Il écoute sur le
port 2000. Ce protocole a été prévu pour des périphériques hardware et autres systèmes embarqués ayant
un processeur relativement important avec des contraires au niveau de la mémoire. Il est réputé pour sa
moindre consommation en bande passante.

4.1 Signalisation dans SCCP

De nombreux messages SCCP existent et sont différents. Nous nous limiterons à l’étude de
quelques uns. Cependant, pour identifier les messages SCCP, il faut utiliser un analyseur de trames et de
protocoles ou un sniffer que vous pouvez brancher à un Switch. Nous avons identifier quelques
messages SCCP dont nous allons donner les significations. Voici quelques messages SCCP capture à
partir de l’analyseur detrames.
• KeepAliveMessage: Message envoyé par les téléphones au Call Manager pour lui prevenir que le lien établit
est toujours actif.
• KeepAliveAckMessage: C’est la réponse aux messages

• KeepAliveMessage: Ce message est envoyé aux téléphones pour les assurer que le lien établit demeureactif

• AlarmMessage: Les téléphones envoient ce message pour prévenir le CME d’une alarme suite à
unproblème.
• RegisterMessage: Il s’agit d’un message d’enregistrement. Ce message est envoyé par le téléphone pour
notifier sa présence auprès du call Manager. Dans les versions antérieures le nom du périphérique se basait
sur son adresse MAC.
• RegisterAckMessage: Ce message est envoyé par le CME aux téléphones IP Cisco pour leurs indiquer leurs
enregistrements ont été effectués avec succès.
• CapabilitiesReqMessage: Le CME envoie ce message aux téléphones pour leur

• ButtonTemplateMessage: Message est envoyé par le CME aux téléphones pour leur demander de faire une
mise à jour de leur bouton.
• ButtonTemplateReqMessage: Ce message est utilisé par le téléphone pour demander une mise à jour de ses
boutons.
ATELIERS SCCP

Atelier 1: Utilisation des téléphones SIP sur un Call Manager Express

Objectifs
A la fin de cet atelier, le candidat doit être capable de :
• utiliser un CME en tant que serveur Registrar SIP ;
• Configurer les téléphones (clients à pour qu'il se connecte au CME

Contenu
• Activer le routeur en tant registrar
• Création de profils et définition de type d'authentification
• Création des numéros de téléphones
• Assignation des numéros aux téléphones
• Configuration des clients
• Test d'appel entre les terminaux

Atelier 2: Interconnexion SIP-

CME Objectif
L’objectif de cet atelier est de réaliser un trunk entre un serveur SIP et un Call Manager Express
Contenu
• Créer un compte au serveur CME sur le serveur SIP
• Activer le CME pour qu'il se connecte au serveur SIP
• Activer le service de téléphonie sur le CME
• Définir le plan de numérotation à envoyer au serveur SIP
• Préciser le codec à utiliser
• Tester la connectivité et les appels
 Activé 4

Le réseau IMS
5.1 Architecture IMS
• P-CSCF,
• I-CSCF
• S-CSCF
• HSS
5.2 Enregistrement
• première phase d’enregistrement,
• deuxième phase d’enregistrement,
• Souscription,
• Notification
5.3 Session entre entités IMS
• établissement de la session,
• terminaison de la session
5.4 Messages diameter
• messages lies à l’enregistrement et au routage,
• messages liés au contrôle du media
5.5 Interfonctionnement avec réseau le CS
• Appel généré par IMS,
• appel généré par le CS,
• libération de communication)
5.6 Profil de service IMS
• structure profil de service,
• IFC
 5.1 L'architecture IMS
Le réseau IMS (IP (Internet Protocol) Multimedia Subsystem) fournit le service téléphonique
lorsque le réseau de mobiles utilise le mode PS (Packet Service) comme le montre la figure 5.1.

Figure 5.1: Positionnement du réseau IMS

Le réseau IMS se connecte aux entités suivantes:

 à l'entité PGW (PDN (Packet Data Network) Gateway) du coeur de réseau EPC (Evolced Packet
Core) du réseau EPS (Evolved Packet System). Le réseau EPS construit deux supports, l'un pour
le transport de la signalisation échangée avec le mobile, l'autre pour le transport du média (voix,
vidéo, données);
 à l'entité PCRF (Policy Charging and Rules Function) pour le contrôle du média;
 à l'entité HSS pour l'accès aux données de profil et de sécurité du mobile;
 aux réseaux téléphoniques fixes PSTN (Public Switched Telephone Network) et mobiles PLMN
(Public Land Mobile Network) pour l'interconnexion.
Le réseau IMS comprend les fonctions suivantes :
 le contôle des sessions CSCF (Call Session Control Function) comprenant les entités P-CSCF
(Proxy-CSCF), S-CSCF (Serving-CSCF), I-CSCF (Interrogating-CSCF) et E-CSCF
(Emergency-CSCF);
 les serveurs d'applications comprenant l'entité AS (Application Server);
 le traitement des flux multimédias MRF (Multimedia Resource Function) comprenant les entités
MRFC (MRF Control Function), MGW (Media Gateway) et SGW (Signaling Gateway);
 la taxation hors connexion pour le postpayé et la taxation en ligne pour le prépayé.

Figure 5.2: Les entités du réseau IMS

5.1.1 Le contrôle des sessions

5.1.1.1 L'entité P-CSCF
L'entité P-CSCF est le premier point de contact du mobile UE au réseau IMS. Elle assure la fonction de
PROXY SERVER. Elle reçoit les requêtes de l'UE ou de l'entité S-CSCF et les transfère respectivement
vers les entités S/I-CSCF ou vers l'UE.
L'entité P-CSCF peut également agir comme une entrantes UA dans des conditions anormales de
fonctionnement, lorsqu'elle doit terminer ou générer des transactions SIP.
Les tâches réalisées par l'entité P-CSCF sont les suivantes:
  elle transfère la requête SIP REGISTER vers l'entité I-CSCF déterminée à partir du nom de
domaine fourni par l'UE. Elle ajoute dans le message un en-tête Path contenant son adresse IP.
Cette adresse est conservée par l'entité S-CSCF ;
 elle transfère la requête SIP INVITE reçue de l'entité S-CSCF (respectivement de l'UE) vers
l'UE (respectivement vers l'entité S-CSCF). Pour effectuer le transfert, l'entité P-CSCF doit
récupérer les adresses IP de l'UE(respectivement de l'entité S-CSCF). La requête SIP INVITE
reçue de l'entité S-CSCF contient l'adresse IP de l'UE en lieu et place de l'identité URI (Uniform
Resource Identifier). La requête SIP INVITE reçue de l'UE contient l'adresse IP de l'entité S-
CSCF dans l'en-tête Route ;
 elle détecte les appels d'urgence et les transfère vers l'entité E-CSCF ;
 elle génère les informations nécessaires à la génération des tickets de taxation ;
 elle établit une association de sécurité IPSec (IP Security) avec l'UE lors de son enregistrement;
 elle contrôle, à partir de messages DIAMETER échangés avec l'entité PCRF, le type de
ressources requis par l'UE en fonction des capacitéa autorisées par le réseau EPS ;
 elle vérifie la disponibilité de la ressource dans le réseau EPS.

5.1.1.2 L'entité I-CSCF

L'entité I-CSCF est le point de contact à l'intérieur du réseau IMS pour certaines transactions provenant
des entités P-CSCF ou S-CSCF. Elle assure la fonction de PROXY SERVER.
Les tâches réalisées par l'entité I-CSCF sont les suivantes:
 à la réception de la première requête SIP REGISTER, elle assigne une entité S-CSCF à L'ue et
transfère la requête à l'entité S-CSCF sélectionnée. Pour effectuer cette fonction, un échange de
messages DIAMETER avec l'entité HSS est nécessaire ;
 à la réception de la seconde requête SIP REGISTER et à la réception de la première requête SIP
INVITE, pour un appel entrant, elle interroge l'entité HSS pour connaître l'adresse IP de l'entité
S-CSCF attribuée à l'UE et lui transfère la requête ;
 elle génère les informations nécessaires à la génération des tickets de taxation

5.1.1.3 L'entité S-CSCF

L'entité S-CSCF fournit à l'UE les services de contrôle de session. Elle assure différents rôles selon le
type de requête reçue:
 celui d'une entité REGISTRAR pour l'enregistrement de l'UE ;
  celui d'une entité LOCATION SERVER pour le stockage de la correspondance entre l'adresse IP
et l'identité URI de l'UE ;
 celui d'une entité PROXY SERVER pour l'établissement d'une session ;
 celui d'une entité UA, dans des conditions anormales de fonctionnement, lorsqu'elle doit
terminer ou générer des transactions SIP.

Les tâches réalisées dans la fonction REGISTRAR sont les suivantes:

 à la réception de la première requête REGISTER, elle contacte l'entité HSS pour récupérer les
données d'authentification de l'UE. Pour effectuer cette fonction, un échange de messages
DIAMETER avec l'entité HSS est nécessaire. Elle répond avec un message 401 Unauthorized
contenant les paramètres utilisés pour l'authentification ;
 à la réception de la seconde requête REGISTER, elle authentifie l'UE et récupère son profil
au-près de l'entité HSS. Elle répond avec un message 200 OK contenant un en-tête Service
Route contenant son adresse IP que l'entité UA conserve en mémoire.

Les tâches réalisées dans la fonction de PROXY SERVER sont les suivantes:
 pour un appel sortant, elle effectue un contrôle sur le service demandé à partir du profil récuperé
lors de l'enregistrement. Elle transfère le requête soit vers l'entité AS, soit vers l'entité I-CSCF
appartenant au réseau IMS de l'UE demandé, soit vers l'entité BGCF si l'UE demandé n'est pas
dans un réseau IMS. L'adresse IP de l'entité AS est contenue dans le profil de l'UE récupéré lors
de l'enregistrement ;
 pour un appel entrant, à la réception de la première requête SIP INVITE provenant de l'entité I-
CSCF, elle effectue un contrôle sur le service demandé. Elle transfère la requête soit vers l'entité
AS, soit vers l'entité P-CSCF. Dans ce dernier cas, elle remplace l'identité URI de la requête par
l'adresse IP de l'UE. L'adresse IP du P-CSCF est récupérée à partir de l'en-tête Path, lors de
l'enregistrement de l'UE ;
 elle génère les informations nécessaires à la génération des tickets de taxation

5.1.1.4 L'entité E-CSCF

L'entité E-CSCF effectue le traitement des appels d'urgence transmis par l'entité P-CSCF et le routage
de la requête vers le centre d'urgence le plus proche de l'UE. Le centre d'urgence peut être raccordé à un
réseau téléphonique fixe ou mobile ou à un autre réseau IMS.
Les tâches réalisées par l'entité E-CSCF sont les suivantes:
 à la réception de la requête SIP INVITE, elle contacte l'entité LRF(Location Retrieval Function)
pour obtenir la localisation de l'UE ou pour la valider si elle est incluse dans la requête;
 sur la base d'informations également fournies par l'entité LRF, elle transfère la requête vers le
centre d'urgence le plus proche.

5.1.2 Les serveurs d'applications

L'entité AS offre des services à valeur ajoutée au réseau IMS. Par exemple, elle héberge et exécute les
compléments de services téléphonique. Elle peut impacter la session SIP en fonction du service requis.
Elle peut être localisée dans le réseau hôte ou être fournie par un tiers.
L'entité S-CSCF doit décider si un serveur d'application est nécessaire pour recevoir des informations
relatives à une requête SIP afin d'assurer le traitement du service approprié. La décision est basée sur les
informations reçues de l'entité HSS lors de l'enregistrement de l'utilisateur.
Le serveur d'applications peut jouer plusieurs rôles dans le traitement d'un message SIP:
 celui d'une entité PROXY SERVER. Dans ce mode, la requête SIP provenant de l'entité S-
CSCF lui est renvoyée. Le serveur d'applications peut ajouter, retirer ou modifier des en-têtes du
message SIP;
 celui d'une entité UAS (UA Server) ou d'un REDIRECT SERVER. Dans ce mode, la réponse du
serveur d'application à la requête SIP provenant de l'entité S-CSCF est du type 2XX, 4xx, 5xx,
6xx (entité UAS) ou 3xx (entité REDIRECT SERVER);
 celui d'une entité UAC (UA Client). Dans ce mode, le serveur d'applications génére la requête
SIP et la transmet à l'entité S-CSCF;
 celui d'une entité B2BUA. Dans ce mode, le serveur d'applications recevant une requête SIP
provenant de l'entité S-CSCF termine le dialogue et génère une nouvelle requête.

5.1.3 Les bases de données

L'entité HSS est une base de données assurant le stockage des données propres à chaque utilisateur. Les
principales données stockées comprennent les identités des utilisateurs, les paramètres d'accès et les
règles d'invocation des serveurs d'applications par l'entité S-CSCF.
Les identités d'utilisateur comprennent les identités publiques et privées. L’identité privée est une
identité attribuée par l'opérateur du réseau IMS. Elle est utilisée pour l'enregistrement. L'identité
publique est l'identité que les autres utilisateurs peuvent utiliser pour établir une session.
Les paramètres d'accès sont utilisés pour l'authentification de l'utilisateur lors de l'enregistrement.
L'information de déclenchement de service est utilisée par l'entité S-CSCF pour transférer une requête
SIP vers un serveur d'applications
L'entité SLF (Subscription Locator Functional) permet aux entités CSCF de trouver l'adresse de l'entité
HSS affectée à un UE, lorsque plusieurs entités HSS sont déployées.

5.2 Enregistrement
Les informations pertinentes nécessaires à l’enregistrement sont obtenues à partir du module ISIM (IMS
Service Identity) contenu dans la carte UICC (Universal Intégrated Circuit Card) du mobile UE.
L’enregistrement s’effectue en deux phases afin d’authentifier le mobile. Si l’authentification du mobile
par le réseau EPS peut être récupérée par le réseau IMS, l’enregistrement s’effectue dans ce cas en une
seule phase.

5.2.1 La première phase d’enregistrement

La première phase d’enregistrement contient les étapes décrites à la figure ci-dessous.

L’entité UA d’Aly envoie à son entité P-CSCF une première requête REGISTRAR contenant son
identité privée aly_private@ec2lt.sn dans le paramètre username de l’en-tête Authorization.

L’entité UA d’Aly fournit le type de réseau mobile et l’identification de la cellule dans l’en-tête P-
Access-Network-Info.

L’entité Security-Client contient les paramètres qui définissent l’association de sécurité IPsec établie
avec l’entité P-CSCF.

Figure 5.3 : La première phase d’enregistrement

 Les en-têtes Require et Proxy-Require contiennent la valeur sec-agree afin d’indiquer que le
mécanisme de sécurité basé sur IPsec est requis. L’en-tête Proxy-Require s’adresse à l’entité P-CSCF.
L’en-tête Require s’adresse à l’entité S-CSCF pour le cas où la requête lui est directement transmise.

L’entité P-CSCF transfère le message REGISTRAR à l’entité I-CSCF, en incluant dans l’en-tête
Path son adresse IP. L’entité P-CSCF peut trouver l’adresse IP de l’entité I-CSCF en faisant une
résolution DNS (Domain Name System) à partir du nom de domaine de l’entité UA d’Aly.

L’entité P-CSCF insert l’en-tête Require contenant la valeur path afin de s’assurer que l’entité
ne supporte pas cet en-tête, elle réplique avec une réponse 420 Bad extension.

L’entité P-CSCF inclut également l’en-tête P-Charging-Vector dont le paramètre icid contient
l’identifiant de taxation.

L’entité P-CSCF déclare dans l’en-tête intergrety-protected que la sécurité n’est pas établit
avec l’entité UA.

L’entité P-CSCF retire les en-têtes Require et Proxy-Require qui contenaient la valeur sec-
agree car la sécurité IPsec sera mise en œuvre par l’entité P-CSCF.

L’entité I-CSCF contacte l’entité HSS pour récupérer la liste des entités S-CSCF qu’il est
possible d’affecter à l’entité UA. Elle effectue la sélection d’une d’une entité S-CSCF vers laquelle elle
transmet la requête REGISTRAR.

L’entité I-CSCF remplace l’identité URI initiale (sip:registrar.ec2lt.sn) par celle de l’entité S-
CSCF (sip:scscf.ec2lt.sn).

L’entité S-CSCF contacte contacte l’entité HSS pour récupérer les données d’authentification du
mobile et lui répond avec un message 401 Unauthorizated. La réponse est transmise à l’entité I-CSCF
dont l’adresse IP est contenue dans le premier en-tête Via.

A ce statde, l’adresse IP de l’entité S-CSCF est enregistrée dans l’entité HSS et celle de l’entité P-CSCF
dans le S-CSCF.

Les données d’authentification du modile sont constituées d’un quintuplet :

• défi RAND transmis au mobile dans le message 401 Unauthorized ;
 • le résultat attendu au défi XRES ;

• le jeton d’authentification du réseau AUTN transmis au mobile dans le message 401

Unauthorized ;

• les clés d’intégrité (IK) et de chiffrement (CK) pour l’établissement de l’association de sécurité
Ipsec entre le mobile et l’entité P-CSCF. Ces clés sont transmises uniquement à l’entité P-CSCF
qui les retire de la réponse 401 Unauthorized avant le transfert à l’entité UA.

L’entité I-CSCF transfère la réponse à l’entité P-CSCF après avoir retiré l’en-tête Via contenant son
adresse IP.

L’entité P-CSCF transfère la réponse à l’entité UA d’Aly après avoir retiré l’en-tête Via contenant son
adresse IP et les clés IK et CK de l’en-tête WWW-Authenticate.

L’entité P-CSCF indique dans l’en-tête Security-Server les paramètres de l’association de sécurité
IPsec établit l’entité UA d’Aly.

A la réception du message 401 Unauthorized, le mobile authentifie le réseau IMS à partir du paramètre
AUTN et calcule la réponse RES au défi RAND sur la base d’un secret contenu dans le module ISIM. Il
calcule également les clés d’intégrité IK et de chiffrement CK.

5.2.2 La seconde phase d’enregistrement

La seconde phase de l’enregistrement correspond aux étapes décrites à la figure ci-dessous.
L’entité UA d’Aly envoie à l’entité P-CSCF une seconde requête REGISTRAR contenant son identité
privée et la réponse RES.

La requête REGISTRAR inclut dans l’en-tête Security-Verify les données de sécurité reçues dans l’en-
tête Security-Server de la réponse 401 Unauthorized.

L’entité P-CSCF transfère le message REGISTRAR à l’entité I-CSCF.

L’entité I-CSCF contacte avec l’entité HSS pour récupérer l’adresse IP du S-CSCF et lui transmet la
requête REGISTRAR.
 Figure 5.4: La seconde phase d’enregistrement

L’entité S-CSCF compare la valeur du RES reçu de l’entité UA avec celle du XRES reçue de l’entité
HSS. Si les deux valeurs sont identiques, le mobile est authentifié.

L’entité S-CSCF contacte le HSS pour récupérer le profil du mobile et répond à l’entité UA avec un
message 200 OK en incluant dans l’en-tête Service Route son adresse IP.

L’enregistrement est effectif pour une durée indiquée dans le paramètre expires de t’en-tête Contact. Le
mobile doit renouveler son enregistrement avant l’expiration de cette temporisation en suivant la même
procédure que l’enregistrement initial.

L’entité S-CSCF indique dans l’en-tête P-Asssociated-URI les identités URI enregistrées
implicitement, en supplément de celle indiquée dans l’en-tête Contact comme le montre la figure ci-
dessous.

Figure 5.5: L’en-tête P-Asssociated-URI

La réponse suit le chemin inverse pris par la requête REGISTRAR, grâce aux en-têtes Via.

5.2.3 La souscription

Les différents échanges relatifs à l’enregistrement de la souscription au service d’événements

d’enregistrement sont décrits à la figure ci-après.

L’entité UA d’Aly génère une requête initiale SUBSCRIBE.

Figure 5.6: La souscription au service d’événement

L’adresse IP de l’entité P-CSCF du domaine (ec2lt.sn), contenue dans l’en-tête Route, est apprise lors de
la configuration du mobile.

L’adresse IP de l’entité S-CSCF du domaine (ec2lt.sn), contenue dans l’en-tête Route, est apprise lors de
l’enregistrement de l’entité UA d’Aly (information provenant de l’en-tête Service Route).

Dans le cas où l’entité UA d’Aly possède plusieurs identités URI, elle renseigne dans l’en-tête P-
Preferred-Identity celle qui est retenue (sip:aly@ec2lt.sn).

Si Aly accepte que son identité soit présentée, elle l’indique dans l’en-tête Privacy (valeur none).

L’entité UA d’Aly définit dans l’en-tête Event le type d’événement qu’elle désire souscrire (valeur reg
pour enregistrement).
L’entité d’Aly annonce dans l’en-tête Expires la durée de la souscription. La valeur ne doit pas être
supérieure à celle indiquée lors de l’enregistrement dans la requête REGISTRAR ou dans la réponse
200 OK.

L’entité UA d’Aly définit le format des notifications d’événements d’enregistrement dans l’en-tête
Accept (valeur application/reginfo+xml).

Figure 5.7 : Format notifications d’événements d’enregistrement dans l’en-tête Accept

L’entité P-CSCF retire les en-têtes Route contenant sa propre adresse IP et Secrity-Verify, ainsi que la
valeur sec-agree. Comme les en-têtes Proxy-Require et Require se retrouvent sans valeur, ils sont
supprimés.

L’entité P-CSCF remplace l’en-tête P-Preferred-Identity par l’en-tête P-Asserted-Identity contenant

l’identité URI d’Aly certifiée.

L’entité P-CSCF rajoute les en-têtes Via, Record Route contenant sa propre adresse IP et P-harging-
Vector. L’en-tête Record Route permet de construire la route empruntée par les requêtes subséquentes.

L’entité S-CSCF autorise la souscription par la réponse 200 OK parce qu’elle fait confiance au contenu
de l’en-tête P-Asserted-Identity inséré par l’entité P-CSCF et qu’Aly a souscrit au service d’événement
d’enregistrement. La réponse 200 Ok est routée à partir des adresses contenues dans les en-têtes Via.

La réception du message 200 OK déclenche une souscription de la part de l’entité P-CSCF afin d’avoir
la connaissance de l’état d’enregistrement de l’entité UA d’Aly.
Comme l’entité P-CSCF n’a pas enregistré d’information de routage durant la phase d’enregistrement, il
ne connaît pas l’adresse IP de l’entité UA d’Aly.

La requête SUBSCRIBE de l’entité P-CSCF est ensuite transmise à l’entité I-CSCF, qui consulte
l’entité HSS pour récupérer l’adresse IP de l’entité S-CSCF, et router en conséquence la requête.

5.2.3 La notification

5.2.3.1 La notification d’enregistrement

les différents échanges relatifs à la réception d’événements relatifs à l’enregistrement sont décrits à la
figure ci-dessous.

L’entité S-CSCF notife l’entité UA d’Aly de l’enregistrement de ses identités URI par l’envoi d’une
requête NOTIFY.

L’entité S-CSCF informe l’état de la souscription dans l’en-tête Subscription-State (valeur active) et de
sa durée dans le paramètre expires comme le montre la figure ci-après.

Figure 5.8: L’état de la souscription dans l’en-tête Subscription-State et de sa durée (expires)

La notification d’éléments d’enregistrement est produite dans un document XML (eXtensible Markup
Language) de type reginfo attaché au message SIP.
 Figure 5.9: Format de données de notification d’éléments d’enregistrement

Chaque élément d’enregistrement du document XML inclut les attributs suivants :

• l’attribut registration aor (Adresse Of Record) suivi l’identité URI d’Aly

• l’attribut id suivi d’une valeur d’identification ;

• l’attribut d’état state de l’enregistrement. L’attribut peut être à l’état active (l’identité URI est
enregistrée) ou terminated (l’identité URI est désenregistrée).

Chaque contact de l’élément d’enregistrement contient à son tour les attibuts suivants :

• l’attribut contact id suivi d’une d’identification du contact ;

• l’attribut d’état state du contact de l’élément ;

• l’attribut qui indique l’événement qui a causé le changement d’état. Cet attribut peut prendre les
valeurs suivantes :

• registered : l’enregistrement a été explicitement effectué par une requête REGISTRAR,

• created : l’enregistrement a été implicitement effectué suite à une requête REGISTRAR,

• deactivate : l’enregistrement a été supprimé par l’entité S-CSCF.

De même, l’entité S-CSCF notife à l’entité P-CSCF l’enregistrement de l’entité UA d’Aly par l’envoi
d’une requête NOTIFY.
5.2.3.1 La notification de désenregistrement

les différents échanges relatifs à la notification d’événements relatifs aux désenregistrements sont
décrits à la figure 5.9.

Le désenregistrement peut être déclenché par le mobile ou par le réseau. Le mobile se désenregistre en
envoyant une requête REGISTER dont le paramètre expires de l’en-tête Contact a une valeur nulle.

Figure 5.9: La notification de désenregistrement

Cette requête déclenche, au niveau de l’entité S-CSCF, l’émission d’une requête NOTIFY à destination,
d’une part, de l’entité UA d’Aly et, d’autres part, de l’entité P-CSCF.

Le désenregistrement par le réseau de l’entité UA d’Aly peut être effectué à l’itiniative de l’entité S-
CSCF ou l’entité HSS. Comme précédemment, l’entité S-CSCF envoie la requête NOTIFY
respectivement à l’entité UA d’Aly et à l’entité P-CSCF.
5.3 La session entre entités IMS

5.3.1 L’établissement de la session

Les différents échanges relatifs à l’établissement de la session sont décrits à la figure.

5.3.1.1 La requête initiale INVITE

L’entité UA d’Aly génère une requête initiale INVITE à destination de l’URI de Latyr.

L’entité UA d’Aly spécifie dans l’en-tête Require que l’entité UA de Latyr doit supporter la
précondition d’établissement avant d’activer la sonnerie du poste.

L’entité UA d’Aly indique dans l’en-tête Supported qu’elle supporte les l’acquittement des réponses
provisoires de type 1xx (valeur 100rel).

L’entité d’Aly indique dans l’en-tête Allow les différents méthodes supportées ( INVITE, ACK,
CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE).
 Figure 5.10: L’établissement de la session

L’entité UA d’Aly envoie une offre SDP dans la requête initiale INVITE à l’entité de Latyr. L’offre
répertorie tous les types de médias (audio, vidéo) qu’Aly souhaite utiliser pour cette session ainsi que la
liste des différents codecs soutenus.

L’entité UA d’Aly indique dans l’offre SDP (a=curr:qos local none, a=curr:qos remote none) que la
préconisation de réservation de ressource n’est pas établie pour les entités UA, local et distante.

L’entité UA d’Aly indique dans l’offre SDP (a=des=qos: mandatory local sendrecv) que la précondition
de réservation de ressource, est obligatoire pour l’entité UA distante.
L’entité P-CSCF du domaine (ec2lt.sn) interagit avec l’entité PCRF pour vérifier les paramètres des
médias autorisés par le réseau EPS. L’entité PCRF examine les codecs contenus dans le message SDP
porté par la requête INVITE.

Si ceux-ci ne peuvent pas être utilisés par le réseau EPS, l’entité P-CSCF transmet à l’entité UA d’Aly
une réponse négative 488 Not Acceptable Here. Ce rejet doit contenir suffisamment d’informations
pour permettre à l’entité UA d’Aly d’initialisation une nouvelle tentative avec les paramètres des médias
autorisés.

L’entité P-CSCF retire les en-têtes Route contenant sa propre adresse IP et Security-Verify, ainsi que la
valeur sec-agree. Comme l’en-tête Proxy-Require se retrouve sans valeur, il est supprimé.

L’entité P-CSCF remplace l’en-tête P-Preferred-Identity par l’en-tête P-Asserted-Identity contenant

l’identité URI d’Aly certifiée.

L’entité P-CSCF rajoute les en-têtes Via, Record Route contenant sa propre adresse IP et P-Charging-
Vector. L’en-tête Record Route permet de construire la route empruntée par les requête subséquentes.

L’entité P-CSCF transfère la requête à l’entité S-CSCF du domaine (ec2lt.sn) dont l’adresse IP est
contenue dans l’en-tête Route.

L’entité HSS a fourni à l’entité S-CSCF, lors de l’enregistrement, le profile de l’utilisateur, contenant les
types des médias autorisés par le service offert. De même, l’entité S-CSCF examine les informations
contenues dans le message SDP porté par la requête INVITE. Si l’entité S-CSCF trouve que ceux-ci ne
sont pas conformes au profil de service, elle transmet à l’entité UA d’Aly une réponse négative 488 Not
Acceptable Here.

L’entité S-CSCF du domaine (ec2lt.sn) retire l’en-tête Route contenant sa propre adresse IP. Elle
récupére le nom de domaine de destination (ec2lt.sn) à partir de l’URI de Latyr et contacte un serveur
DNS pour récupérer l’adresse IP de l’entité I-CSCF du domaine (ec2lt.sn).

L’entité S-CSCF complète l’en-tête P-Charging-Vector en y ajoutant le nom de domaine (ec2lt.sn) à

l’origine de la session.
L’entité S-CSCF rajoute les en-têtes Via et Record Route contenant sa propre adresse IP et transfère la
requête à l’entité I-CSCF du domaine (ec2lt.sn).

L’entité I-CSCF du domaine (ec2lt.sn) contacte l’entité HSS pour récupérer l’adresse IP de l’entité S-
CSCF du domaine (ec2lt.sn) ayant enregistré l’entité UA de Latyr.

L’entité I-CSCF rajoute l’en-tête Via, ne rajoute pas d’en-tête Record Route et transfère la requête à
l’entité S-CSCF du domaine (ec2lt.sn). Les requêtes subséquentes ne transitent donc pas par l’entité I-
CSCF.

L’entité S-CSCF du domaine (ec2lt.sn) vérifie que les types de médias proposés par l’entité UA d’Aly
correspondent aux services offert à Latyr.

L’entité S-CSCF rajoute un en-tête Record Route contenant sa propre adresse IP.

L’entité S-CSCF modifie la requête initiale en remplaçant l’URI de Latyr par son adresse IP. Le lien
entre l’identité URI de Latyr dans l’en-tête P-Called-Party-ID afin que Latyr sache à quelle requête
INVITE se réfère.

L’entité S-CSCF transfère la requête à l’entité P−CSCF du domaine (ec2lt.sn). L’adresse IP de l’entité
P-CSCF attribut à l’entité UA de Latyr a été apprise lors de l’enregistrement (information contenue dans
l’en-tête Path).

L’entité P-CSCF du domaine (ec2lt.sn) vérifie auprès PCRF que les codecs proposés par l’entité UA
d’Aly sont supportés par le réseau EPS de Latyr.

L’entité P-CSCF rajoute un en-tête Record Route contenant sa propre adresse IP et transfère la requête à
l’entité UA de Latyr dont l’adresse IP est incluse dans l’identité URI de la requête.

L’entité UA de Latyr stocke les différents en-têtes Record Route qui lui serviront ultérieurement pour le
routage des requêtes subséquentes.

5.3.1.2 La réponse 183 Session Preogress

L’entité UA de Latyr transmet une réponse 183 Session Progress à l’entité UA d’Aly. Le routage de la
réponse s’effectue sur la base des en-têtes Via reçus.

La réponse 183 Session Progress contient les en-têtes Record Route reçus. Cela permettra à Aly de
récupérer les adresses IP des entités CSCF devant traiter les requêtes subséquentes.
La réponse 183 Session Progress complète l’en-tête To en y ajoutant le paramètre tag.

L’entité UA de Latyr indique la valeur 100rel dans l’en-tête Require pour indiquer que la réponse
nécessite un acquittement de la part de l’entité UA d’Aly. Afin de corréler l’acquittement avec la
réponse, l’entité UA de Latyr insère l’en-tête Rseq.

Dans la réponse 183 Session Progress, l’entité UA de Latyr fournit une réponse SDP dans laquelle elle
retient un type de média parmi ceux proposés par Aly.

L’entité UA de Latyr indique dans le message SDP de la réponse 183 Session Progress qu’une
réservation de ressource est également nécessaire de son côte avant d’établir une session.

L’entité UA d’Aly envoie la requête subséquente PRACK afin d’acquitter la réponse provisoire 183
Session Progress. Elle indique dans des en-têtes Route les adresses IP des entités traitant la requête, à
savoir les entités P/C-CSCF du domaine (ec2lt.sn). Cette requête est acquittée par la réponse 200 OK.

5.3.1.3 La requête UPDATE

Lorsque l’entité UA d’Aly à la confirmation de la réservation de la ressource, elle l’indique à l’entité

UA de Latyr dans une offre SDP contenue dans une requête UPDATE.

Lorsque la réservation de ressource sont effectives à chaque extrémité, le téléphone de Latyr peut sonner
et une réponse 180 Ringing est transmise à l’entité UA d’Aly, générant à son niveau la tonalité de retour
d’appel.

La réception de la réponse 180 Ringing déclenche l’émission de la requête PRACK d’acquittement afin
de se prémunir vis-à-vis de la perte de la réponse 180 Ringing.

Lorsque Latyr décroche, une réponse 200 OK est transmise à l’UE d’Aly qui l’acquitte par la requête
subséquente ACK. La session est alors établit.

5.3.2 La terminaison de la session

Les différents échanges relatifs à la terminaison de la session sont décrits à la figure.

La terminaison de la session peut être déclenchée par les entités UA, P-CSCF ou IMS-GWF, à l’aide de
la méthode BYE.

La terminaison de la session peut être initialisée par n’importe quelle entité UA lorsque la
communication est terminée.
La fonction P-CSCF peut également mettre fin à la session si le mobile n’est plus sous une couverture
radioélectrique. L’entité PCRF fournit cette information à l’entité P-CSCF par l’intermédiaire d’un
message DIAMETER.

L’entité IMS-GWF est un serveur d’applications qui contrôle la session dans le cas du prépayé. Lorsque
le crédit de l’utilisateur est consommé, l’entité IMS-HWF met fin à la session. Cette information peut
également être fournie par l’entité OCS de taxation en ligne. Deux requêtes BYE sont nécessaires pour
terminer la session, une requête à destination de l’entité UA d’Aly, la seconde vers l’entité UA de Latyr.

Figure 5.11: La terminaison de la session

5.4 Les messages DIAMETER

Les messages DIAMETER sont échanges entre, d’une d’une part, les entités CSCF du réseau IMS et,
d’une part, soit l’entité HSS lors de l’enregistrement de l’entité UA ou du routage de la requête SIP, soit
l’entité PCRF pour le contrôle du média.

5.4.1 Les messages liés à l’enregistrement et au routage

La requête UAR et la réponse UAA (User-Authorization-Request Answer) sont utilisées entre les entités
I-CSCF et HSS lors des deux phases d’enregistrement de l’entité UA. A la réception d’une requête
REGISTER, l’entité I-CSCF interroge l’entité HSS afin de récupérer :

• lors de la première phase, la liste des entités S-CSCF qu’il est possible d’attribuer à l’entité UA.

• Lors de la deuxième phase, l’adresse IP de l’entité S-CSCF attribuée à l’entité UA.

La requête MAR et la réponse MAA (Multimedia-Auth-Request/Answer) sont utilisées entre les entités
S-CSCF et HSS lors de la première phase d’enregistrement.

A la réception de la requête REGISTER, l’entité S-CSCF fournit son adresse IP et récupère les données
d’authentification de l’entité UA.

La requête SAR et la réponse SAA (Server-Assignment-Requesr/Answer) sont utilisées entre les entités
S-CSCF et HSS lors de la seconde phase d’enregistrement.

A la réception de la requête REGISTER, l’entité S-CSCF s’enregistre auprès de l’entité HSS et

télécharge l profil de l’entité UA.

La requête RTR et la reponse RTA (Registraton- Ternination-Request/Anwser) sont utilisées entre les
enttités HSS et S-CSCF lorsque l’entité HSS déclenche le désenregistrement de l’entité UA.

La requête LIR et la réponse LIA (Location-Info-Request/Answer) sont utilisées entres les entités I-
CSCF et HSS pour le routage de la requête INVITE. Lors d’un appel entrant, à la réception de la requête
INVITE, l’entité I-CSCF récupère l’identité de l’entité S-CSCF attribuée à l’entité UA de destination.

La requête PPR et la réponse PPA (Push-Profile-Request/Answer) sont utilisées entre les entités HSS et
S-CSCF. Elles permettent à l’entité HSS de notifier une modification du profil de l’entité UA.

5.4.2 Les messages liés au contrôle du média

Les messages liés au contrôle du média sont échangés entre les entités P-CSCF et PCRF lors de
l’établissement d’une session.

La requête AAR (Authorization-Authentication-Request) est utilisée par l’entité P-CSCF pour

transmette à l’entité PCRF les caractéristiques du média négocié dans le message SDP. La requête
contient également le paramètre icid d’identification de taxation généré par l’entité P-CSCF. La requête
est déclenchée par la réception de la réponse 183 Session Progress.
La réponse AAA (Authorization-Authentication-Answer) de l’entité PCRF acquitte la requête. Si les
codecs du média sont autorisés, les opérations suivantes sont déclenchées :

• la réponse AAA contient le paramétre gcid d’identification de taxation généré par l’entité PDN
GW du réseau EPS. Les paramètres icid et gcid permettent de consolider la facture en couplant
les unités de taxation générées par les deux réseaux IMS et EPS ;

• l’entité P-CSCF relaie la réponse 183 Session Progress ;

• l’entité PCRF déclenche la réservation de ressource au niveau du réseau EPS.

La requête STR (Session-Termination-Request) est utilisée par l’entité P-CSCF pour informer l’entité
PCRF de la terminaison de la session SIP. Cette requête est transmise à la réception de la requête BYE.
La réponse STA (Sesssion-Termination-Anwser) de l’entité PCRF acquitte la requête. A la réception de
cette requête, l’entité PCRF libère les ressources immobilisées dans le réseau EPS.

La requête ASR (Abort-Session-Request) est utilisé par l’entité PCRF pour informer l’entité P-CSCF
que les ressources réservées par le réseau EPS ne sont plus disponibles. La réponse ASA (Abort-
Session-Answer) acquitte la requête. A la réception de cette requête, l’entité P-CSCF termine la sesion
SIP en envoyant une requête BYE à chaque entité UA participant à la session.

5.5 L’interconnexion avec le réseau CS

L’entité CS (Circuit Service) correspond à un terminal téléphonique connecté au réseau téléphonique

fixe PSTN ou mobile PLMN fonctionnant en mode CS.

L’interconnexion entre le réseau IMS et le réseau CS met en œuvre les entités BGCF (uniquement pour
les appels sortant) MGCF, SGW et MGW.

5.5.1 L’appel généré par le réseau IMS

Les différents échanges relatifs à l’appel généré par le réseau IMS sont décrits à la figure ci-dessous.

L’appel est généré par l’entité UA d’Aly, par l’intermédiaire d’une requête INVITE dont l’identité TEL
URI contient le numéro de téléphone de l’appelé.

L’entité S-CSCF effectue une résolution ENUM auprès du serveur DNS, afin de convertir l’identité TEL
URI en SIP URI. Comme le destinataire n’est pas un client du réseau DNS, la réponse du serveur DNS
est négative.

L’entité S-CSCF route alors la requête INVITE vers l’entité BGCF qui consulte une table pour trouver
l’identité MGCF qui assure l’interconnexion correspondant à l’adresse téléphonique de l’appelé.
 Figure 5.12: L’appel généré par le réseau IMS

Lorsque l’entité MGCF reçoit la requête INVITE, elle effectue les opérations suivantes :

• Elle transfère à l’entité MGW le message SDP associé à la requête INVITE ;

• Elle commande la constitution de points de terminaison au niveau de l’entité MGW ;

• Elle récupère, dans un message SDP, les caractéristiques du flux média de l’interface côté IP de
L’entité MGW ;

• Elle traduit la requête INVITE en un message ISUP IAM. Ce message est transmis à l’entité
SGW en utilisant un transport SIGTRAN, puis au réseau fonctionnant en mode CS ;

• Elle répond à l’entité UA d’Aly avec un message 183 Session Progress dans lequel le message
SDP récupèré est inséré.

Le réseau fonctionnant en mode CS réserve les ressources et répond avec un message ISUP ACM
indiquant que l’appel a été présenté au destinataire. L’entité MGCF traduit ce message ISUP en une
réponse 180 Ringing. La tonalité de retour d’appel est appliquée au terminal téléphonique d’Aly.
Lorsque le demandé décroche, l’entité MGCF reçoit le message ISUP ANM. Elle effectue la connexion
des points de terminaison au niveau de l’entité MGW et transmet la réponse définitive 200 OK à l’entité
UA d’Aly. La tonalité de retour d’appel est alors supprimée et la communication est établie.

5.5.2 L’appel généré par le réseau CS

Les différents échanges relatifs à l’appel généré par le réseau CS sont décrits à la figure ci-dessous

Figure 5.13: L’appel généré par le réseau CS

L’appel est généré par une entité CS et se traduit, au niveau de l’entité MGCF, par la réception du
message ISUP IAM. L’entité MGCF réalise alors les opérations suivantes :

• Elle crée les terminaisons auprès de l’entité MGW et récupère le message SDP décrivant les
caractéristiques de la terminaison de l’entité MGW, côté IP ;

• Elle génère une requête INVITE avec l’identité TEL URI contenant le numéro de téléphone
contenu dans le message ISUP IAM en associant le message SDP fourni par l’entité MGW.

A la réception du message 183 Session Progress, l’entité MGCF transfère le message SDP de l’entité
Latyr à l’entité MGW, complétant ainsi les caractéristiques du point de terminaison côté réseau IP.
Lorsque l’entité UA de Latyr a la configuration de la réservation de ressource dans le réseau EPS, le
terminal téléphonique sonne et l’entité MGCF reçoit le message 180 Ringing. L’entité MGCF génère le
message ISUP ACM vers le réseau CS.

Lorsque Latyr décroche, l’entité MGCF reçoit le message 200 OK. Elle effectue la connexion des points
de terminaison de l’entité MGW et transmet le message ISUP ANM au réseau en mode CS.

5.5.3 La libération de la communication

Les différents échanges relatifs à la libération de la communication sont décrits à la figure.

Si la libération de la communication est déclenchée par l’entité CS, l’entité MGCF reçoit le message
ISUP REL de la part du réseau CS. L’entité MGCF génère à son tour une requête BYE à destination de
l’entité UA de Latyr et supprime les terminaisons de l’entité MGW.

A la réception de la requête BYE, l’entité P-CSCF provoque la libération des ressources du réseau EPS
par l’intermédiaire de l’entité PCRF.

L’entité UA de Latyr répond avec le message 200 OK. A la réception de ce message, l’entité MGCF
génère le message ISUP RLC à destination du réseauCS.

L’entité UA de Latyr peut également terminer la communication en générant la requête BYE. A la

réception de la requête BYE, l’entité P-CSCF provoque la libération des ressources du réseau EPS par
l’intermédiaire de l’entité PCRF et l’entité MGCF effectue les opérations suivantes :

• Elle répond à l’entité UA de Latyr avec le message 200 OK ;

• Elle supprime les terminaisons de l’entité MGW ;

• Elle génère le message ISUP REL à destination du réseau CS.

Le réseau CS répond avec le message ISUP RLC comme le montre la figure suivante :
 Figure 5.14: La libération de la communication

6. Le profil de service

A la souscription, l’utilisateur se voit attribuer une adresse privée à laquelle sont associés un ou
plusieurs profils de services. Chaque profile de services inclut une ou plusieurs identités publiques (SIP
URI ou TEL URI) et une logique de déclenchement de services sous la forme de données iFC (initial
Filter Criteria) comme le montre la figure ci-après :
 Figure 5.15: La structure du profil de service

Le champ Core Network Service Authorization de la structure de données iFC contient un nombre entier
représentatif du type de média (audio, vidéo) que l’utilisateur a le droit de négocier dans le message
SDP (Session Description Protocol).

L’entité HSS (Home Subscriber Server) stocke les données relatifs au profil de service d’un utilisateur.
Les données iFC sont transmises à l’entité S-CSCF (Serving Call Session Control Function) lors d’une
modification du profil de service.

Le premier champ des données iFC est la priorité (Priority) qui détermine l’ordre dans lequel les critères
doivent être évalués. Le champ suivant est relatif au point de déclenchement (Trigger Point) qui est une
collection de filtres (Service Point Trigger).
 Figure 5.16: La structure des données iFC

La figure 5.17 montre comment créer dans l’interface HSS d’OpenIMSCore un AS

Figure 5.17: Création d’un AS

La figure 5.18 montre la création Trigger point où on définit le critère suivant tout message INVITE
dont l’en-tête contient sip:20*.

Figure 5.18 : Définition de critère Trigger Point

La figure 5.19 montre la création d’un iFC qui utilise Trigger Point asterisk_tp pour envoyer à l’AS
asterisk_as :

Figure 5.19 : Définition d’un iFC

La figure 5.20 montre la définition d’un profil de service contenant 3 iFC avec leur ordre de priorité :

• l’iFC ayant la plus petite priorité est examiné en premier

 Figure 5.20 : Définition d’un profil de service

Chaque filtre consiste en une opération logique effectuée sur les paramètres suivantes :

• La valeur de l’entité URI (Uniform Ressource Identifier) de la requête (Request-URI

• Le type de méthode de la requête (SIP Method) ;
• Le contenu des en-têtes (SIP Header) ;
• Le type d’appel, appel sortant ou appel entrant vers un mobile enregistré ou non (Session Case ;
• Le contenu des champs du message SDP ;

Les données iFC contiennent également l’identité publique du serveur d’application de téléphonie
TAS(Telephony Application Server) vers lequel l’entité S-CSCF transfère la requête si les conditions
sont réunies. Le champ Default Handing définit le traitement à effectuer sur la requête (poursuite ou
arrête) si l’entité S-CSCF ne peut pas contacter le serveur d’applications. Le champ Service Information
contient des données transparentes pour les entités HSS et S-CSCF ? Ces données sont traitées
uniquement par le serveur d’applications.
Identité d’un utilisateur IMS

Un utilisateur IMS possède 3 identités :

• L’IMPI qui est son identité privée dont la composition peut être observée dans la figure
suivante :

• L’IMPU qui l’identité publique dont la composition peut être observée dans la figure ci-
dessous :
• L’IMSU qui est l’identité de soubscription dont la composition peut être observée dans la figure
ci-après :
 5.2 Étude de quelques plateformes IMS libres (OpenIMSCore, Clearwater et kamailio)
5.3.1 OpenIMSCore
Le projet d’open source IMS core a été lancé en 2006, développé par l’université FOKUS (Fraunhofer
Institute for Open Communication System), basé à Berlin-Allemagne là ou plus de 80 organisations ont
été impliquées dans ce projet dont 57 sont des universités. Les objectifs fondamentaux du projet sont les
tests d’interopérabilité, l’analyse comparative et le prototypage d’extension de technologie des
applications multimédia innovantes pour le réseau de télécommunications émergentes. Cette solution a
été adoptée par plusieurs opérateurs et fournisseurs de télécommunications dans le monde comme une
banque d’essais pour tester les fonctionnalités de système IMS avec l’intégration des nouveaux services
sur IP comme la télévision sur IP (IPTV). Open source IMS Core est formé par l’ensemble des éléments
de base d’une architecture IMS définit dans les réseaux de nouvelle génération et telle qu’indiquée dans
3GPP, 3GPP2, ETSI TISPAN et l’initiative PacketCable. Les composants de base de l’architecture
d’open source IMS Core sont illustrés par la Fig.4.1 (FOKUS, 2006).
Toutes les entités de ce framework sont basées sur des logiciels libres. Ainsi, open source IMS CSCFs
est composé de trois éléments : le Proxy (P-CSCF), Interrogating (I-CSCF) et Serving (S-CSCF) Call
Session Control Functions. Ces trois éléments sont des extensions de SIP Express Router (SER) qui ont
été testés avec des produits commerciaux pour l’interopérabilité.

Figure 5.3.1 : Architecture d’Open Source IMS Core

La base de données d’open source IMS Core, FHoSS (FOKUS Home Subscriber Server) est basé sur
MySQL.
La logique du FHoSS d’application est entièrement écrite avec Java en utilisant le conteneur de servlet
du logiciel libre Tomcat. La composante principale de cette base de données est l’utilisateur maître
(Master) à base de MySQL, supportant des entités de réseaux qui gèrent les communications
sur IMS. Plus précisément, le FoHSS offre les fonctions suivantes :
 stocke et gère les informations relatives au profil d’abonnés ;
 génère des données pour l’authentification et l’autorisation des utilisateurs ;
 maintenir les tables de routage sous forme de répertoires de localisation de l’abonné ;
 fournir des informations sur les points de service de l’abonné ;
 gestion de déclencheur de service et de l’information de base de l’orchestration ;
 enregistre les informations de facturation.

5.3.2 Clearwater
Le projet de Clearwater IMS est sponsorisé par la compagnie Metaswitch Networks(Networks, 2014).
C’est une solution libre publiée en mai 2013. Clearwater IMS suit les principes d’architecture IMS et
supporte toutes les interfaces clés standardisées attendues d’un cœur de réseau
IMS. À la différence des implémentations traditionnelles d’IMS, Clearwater IMS a été conçu dès le
départ pour être optimisé pour le déploiement dans les environnements virtualisés et dans le nuage
informatique d’où la particularité de cette solution par rapport à open source IMS Core.
Le framework de Clearwater IMS s’appuie sur des patrons de conception et de composants logiciels
libres ce qui donne la possibilité à l’évolutivité et la rentabilité de cette solution. Tous les composants de
Clearwater permettent le passage à l’échelle horizontale en utilisant un équilibrage de charge simple.L’
état à long terme ne sont pas stockées sur les nœuds du cluster, en évitant la nécessité des systèmes de
réplication de données complexes. Au lieu de cela, l’état à long terme est stocké dans des nœuds de
service back-end en utilisant les technologies de stockage nuage optimisé tel que Cassandra.
L’interface entre les composants SIP frontaux et les services back-end utilisent «RESTFULL»
API de services Web. Ainsi, que l’interface entre les différents composants utilise le regroupement
de connexion avec recyclage statistique de connexions pour assurer que la charge est répartie
uniformément comme des nœuds sont ajoutés et supprimés dans chaque couche.
 Figure 5.3.2 : Architecture de Clearwater IMS
 Bono (Edge Proxy)
Le nœud Bono forme un proxy SIP horizontalement évolutive offrant à la fois une interface compatible
SIP IMS Gm (P-CSCF) et une interface de WebRTC aux clients. Les requêtes clientes sont partagées sur
les nœuds on utilisant un équilibrage de charge. Ce nœud constitue le premier point de contact du client
avec le système Clearwater, y compris le soutien pour les divers mécanismes de traduction d’adresse
réseau NAT (Network Address Translation) pour les différents nœuds traversée. Un client est donc ancré
à un nœud Bono particulier pour la durée de son enregistrement, mais peut se déplacer vers un autre
nœud Bono si la connexion ou le client échoue. Les clients peuvent se connecter à Bono en utilisant le
protocole SIP/UDP ou SIP/TCP. Bono prend en charge tout client WebRTC qui effectue la signalisation
d’établissement d’appel utilisant le les différents nœuds traversée. Un client est donc ancré à un nœud
Bono particulier pour la durée de son enregistrement, mais peut se déplacer vers un autre nœud Bono si
la connexion ou le client échoue. Les clients peuvent se connecter à Bono en utilisant le protocole
SIP/UDP ou SIP/TCP. Bono prend en charge tout client WebRTC qui effectue la signalisation
d’établissement d’appel utilisant le protocole SIP sur WebSocket. Les nœuds Bono ne sont pas
nécessaires si Clearwater est déployé avec un tiers P-CSCF ou SBC (Session Border Controller) mise en
œuvre de P-CSCF.
  Sprout (routeur SIP)
Les nœuds de Sprout agissent comme registraire SIP horizontalement évolutive qui gère
l’authentification des clients et l’interface ISC pour les serveurs d’applications ainsi que l’interfaçage
avec le reste des serveurs tel que Homestead et Homer. Les nœuds de Sprout contiennent également une
option pour construire un serveur d’application MMTel. Le cluster Sprout comprend un cluster
redondant Memcached pour stocker les données d’enregistrement des clients avec l’état à long terme.
Les Transactions SIP sont équilibrées sur le cluster Sprout et il n’y apas d’association à long terme entre
un client et un nœud de Sprout particulier. Sprout utilise des interfaces de services Web fournis par
Homestead et Homer pour récupérer les informations de configuration du HSS telles que les données
d’authentification et du profil utilisateur ainsi que les paramètres de service MMTel.
 Homestead (HSS Mirror)
Homestead fournit une interface de services Web à Sprout pour récupérer des informations relatives au
profil d’utilisateur comme les informations d’authentification. Cette composante gère directement les
données à travers l’interface web ou les extraire à partir d’un HSS à travers l’interface Cx conforme à
IMS. Les nœuds de Homestead fonctionnent comme un cluster à l’aide de Cassandra pour stocker les
données. Dans l’architecture d’IMS, la fonction de miroir HSS est considérée comme partie des
composants I-CSCF et S-CSCF, cependant dans Clearwater IMS les fonctions des deux composants I-
CSCF et S-CSCF sont implémentée avec une combinaison de cluser de Sprout et Homestead.
 Homer ( XDMS )
Homer est un serveur de management des documents XML standard, en anglais XML Document
Management Serve(XDMS) permet de stocker les paramètres du service MMtel dans des documents
XML pour chaque utilisateur du système. Les documents sont créés, lus, mis à jour et supprimés à l’aide
d’une interface XCAP (XML Configuration Access Protocol) standard. Comme Homestead, les nœuds
Homer sont implémentés comme un cluster à l’aide Cassandra.
 Ellis
Ellis est un portail simple d’approvisionnement qui fournit une auto-inscription des utilisateurs, gestion
de mot de passe et le contrôle des paramètres de service MMTel. Ellis n’est pas destiné pour être une
partie de la production des déploiements Clearwater .Et la mise à l’échelle horizontalement n’est pas
facile pour cette entité en raison de l’utilisation de MySQL.
5.3.3 Kamailio
Kamailio est un Server SIP open source. Ce fork du projet OpenSER (en 2005) est l'un des PBXles plus
complets. Il supporte des transactions asynchrones TCP, UDP et SCTP, l'encryptagedes communications
via TLS, la répartition de charge, un mécanisme natif de fail-over,l'authentification sur des backend
Radius, Mysql, LDAP ou via transport XMLRCP. Il est utiliséaussi bien par des opérateurs télécoms
comme plate-forme de service VoIP que pour lessolutions classiques de téléphonie d'entreprise. C'est
une alternative à Freeswitch et Asteriskles deux autres poids lourds du domaine.
Kamailio dispose d'un fichier de configuration nommé kamailio.cfg et situé dans le dossier
/etc/kamailio.
Le fichier kamailio.cfg contient les informations principales de configuration de Kamailio. Les sections
présentes sont les suivantes:

 Définitions globales (Global Parameters): Cette section du fichier liste les paramètres
d'exécution du programme. On y trouve principalement le niveau de débogage, le type de
couche de transport utilisé (UDP ou TCP), l'alias du serveur, les adresses IP et les ports d'écoute.
Il faut redémarer kamailio pour recharger ces paramètres.
 Paramètres locaux (Custom Parameters): Ces paramètres peuvent être modifiés en cours
d'exécution grâce au module 'cfg_rpc'.
 Modules utilisés (Modules Section): Cette section du fichier liste les modules chargés au
démarrage de Kamailio, ainsi que le chemin pour trouver les modules (mpath). Pour définir des
paramètres à ces modules, la commande modparam est utilisée. Les paramètres sont aussi listés
dans cette section.
 Routage et automate (Routing Logic): Cette section définit comment le serveur réagit à un
message SIP ou à un événement. C'est l'automate du serveur SIP. L'algorithme livré initialement
est censé être conforme aux normes SIP, mais il peut être modifié dans cette section justement.
La routine route permet de définir cela.

Chaque requête SIP reçue sera traitée dans la boucle commençant par:

route {

elle se termine avec:

}

Lorsqu'un mot clef Mot Clef est utilisé en paramètre, la fonction

Route[MotClef] {

---

} est exécuté
Pré-requis

Pour mettre en place kamailio et IMS, nous avons utilisé:

 Ubuntu 14.04, 64 bits
 2 Go de RAM
Les paquets à installer sont:
#apt-get install bind9 bind9utils apache2 mysql-server phpmyadmin ant subversion

I. Installation

Pour mettre en place le DNS, aller dans le site: http://repository.ng-voice.com et télécharger le fichier
install.sh, puis exécuter le,

#chmod a+x install.sh

#./install.sh

1. Mise en place du DNS

Pour mettre en place le DNS, nous avons crée un fichier dans /etc/bind comme suit.

#vim /etc/bind/db.ec2lt
$ORIGIN ec2lt.sn.
$TTL 1W
@ 1D IN SOA localhost. root.localhost. (
1 ; serial
3H ; refresh
15M ; retry
1W ; expiry
1D ) ; minimum

1D IN NS ns
ns 1D IN A 127.0.0.1
pcscf 1D IN A 127.0.0.1
_sip._udp.pcscf 1D SRV 0 0 5060 pcscf
_sip._tcp.pcscf 1D SRV 0 0 5060 pcscf

icscf 1D IN A 127.0.0.1
_sip._udp 1D SRV 0 0 4060 icscf
_sip._tcp 1D SRV 0 0 4060 icscf
_sip._udp.ims 1D SRV 0 0 4060 icscf
_sip._tcp.ims 1D SRV 0 0 4060 icscf

scscf 1D IN A 127.0.0.1
_sip._udp.scscf 1D SRV 0 0 6060 scscf
_sip._tcp.scscf 1D SRV 0 0 6060 scscf
hss 1D IN A 127.0.0.1
Changer l’adresse IP 127.0.0.1 par celui de votre serveur en utilisant tout simplement la commande sed.
Exemple: sed -i s/127.0.0.1/192.168.1.208/g /etc/bind/db.ec2lt
Editer le fichier suivant:
#vim /etc/bind/named.conf.default-zones
zone "ec2lt.sn" {
type master;
file "/etc/bind/db.ec2lt";
};

Il faut éditer le resolve et y met l’adresse de votre serveur comme suit:

Il reste alors à redémarrer le service avec la commande:

#service bind9 restart

 Testons le fonctionnement de notre DNS

2. Mise en place des entités

a) PCSCF

Pour installer l’entité pcscf, il faut utiliser la commande:

#apt-get install ims-pcscf
Il faut suivre les instructions suivantes pour une bonne installation:
Ceci met fin à l’installation du pcscf.

b) ICSCF
Pour installer l’entité icscf, il faut utiliser la commande:
#apt-get install ims-icscf
Il faut suivre les instructions suivantes pour une bonne installation:
Ceci met fin à l’installation du icscf.

c) SCSCF
Pour installer l’entité scscf, il faut utiliser la commande:
#apt-get install ims-scscf
Il faut suivre les instructions suivantes pour une bonne installation:
Ceci met fin à l’installation du scscf.

3. Mise en place du HSS de OpenIMSCore

Pour mettre en place le HSS, nous avons procédé de la manière suivante:

• Crée un dossier OpenIMSCore dans /opt
mkdir /opt/OpenIMSCore
cd /opt/OpenIMSCore
• Crée un dossier FhoSS dans /opt/OpenIMSCore
mkdir FhoSS
svn checkout https://svn.code.sf.net/p/openimscore/code/FHoSS/trunk FhoSS

Si cette commande est bien exécuté, nous devons avoir comme ceci:

• Crée un dossier ser_ims dans /opt/OpenIMSCore

mkdir ser_ims
 svn checkout https://svn.code.sf.net/p/openimscore/code/ser_ims/trunk ser_ims

Si cette commande est bien exécuté, nous devons avoir comme ceci:

Après on se déplace dans FhoSS pour effectuer la commande ant compile deploy.
cd FHoSS
ant compile deploy

Si cette commande est bien exécuté, nous devons avoir comme ceci:

Ensuite faire:
cd ..
On ce déplace dans le dossier ser_ims
cd ser_ims
make install-libs all
cd ..

• Nous allons maintenant crée les bases de données

Pour cela, nous allons effectué la commande sed au niveau des fichier de base de données pour
changer le domaine par le notre comme suit:

Ensuite on effectue ceci:

mysql -u root -p < FhoSS/scripts/hss_db.sql

mysql -u root -p < FhoSS/scripts/userdata.sql
mysql -u root -p < ser_ims/cfg/icscf.sql

• Configuration du Diameter et le HSS de openIMSCore

Pour cela il faut éditer le fichier
#vim /opt/OpenIMSCore/FhoSS/deploy/DiameterPeerHSS.xml

#vim /opt/OpenIMSCore/FhoSS/deploy/hss.properties

II. Configuration des entités IMS

1. PCSCF
a) kamailio.cfg
 b) pcscf.cfg

c) dispatcher.list

Pour le dispatcher.list, il faut copié le dispatcher.list.sample en dispatcher.list.

Ensuite l’éditer et commenter les lignes comme suit:
#vim /etc/kamailio_pcscf/dispatcher.list
2. ICSCF
a) kamailio.cfg

b) icscf.cfg

c) icscf.xml
3. SCSCF
a) kamailio.cfg
b) scscf.cfg

c) scscf.xml
 III. Arrêt de ferm et de fail2ban

Avant de démarrer les entités, il faut d’abord configurer le ferm en éditant le fichier /etc/ferm/ferm.conf
et remplacer tous les DROP par ACCEPT.

Après il faut effectuer les commandes suivantes:

#service ferm stop

#service fail2ban stop

Ensuite il ne reste qu’à redémarrer les entités.

IV. Démarrage des entités et du HSS

V. Test de connexion des users par défaut
 5.3 Plan des travaux pratiques
TP-1 : Implémentation de OpenIMSCore et gestion de profiles d'abonnés (maîtrise de HSS)

Dans ce TP, il est demandé à l'étudiant de

pouvoir mettre en place OpenIMSCore dans une
machine ubuntu 14 64bits, mais aussi de pouvoir
configurer un client sur l'interface de FoHSS de
OpenIMSCore, de maîtriser la gestion des profils
d'abonnés c-à-d maîtriser la base de données HSS
de OpenIMSCore.

Pré-requis

Accès réseaux
 Ubuntu 14v 64bits
 une adresse IP publique
 un serveur DNS exemple Bind avec les enregistrements de type SRV

Les paquets nécessaires

 GCC3/4, make, JDK1.5, ant ;

 mySQL server, bison, flex, libxml2, libmysql ;
 ipsec-tools, curl and libcurl4-gnutls-dev.

Téléchargement du code source

Créer un nouveau répertoire ser_.ims et télécharger le code de CSCFs :

 mkdir ser_.ims ;
 svn checkout https ://svn.code.sf.net/p/openimscore/code/ser_.ims/trunk ser_.ims

Créer un nouveau répertoire FHoSS et télécharger le code de HSS :

 mkdir FHoSS ;
 svn checkout https ://svn.code.sf.net/p/openimscore/code/FHoSS/trunk FhoSS

Compilation du Code

Pour compiler le code suivez les étapes suivantes :

 cd ser_.ims
 make install-libs all
 cd ..
 cd FHoSS
 ant compile
 ant deploy
 cd ..

Configuration de l’environnement

Configuration de DNS :
Par défaut open ims core est configuré pour être exécute localement, un simple zone DNS est dans
le fichier suivant ser_.ims/cfg/open-ims.dnszone Configuration de MySQL :
 mysql -u root -p -h localhost < ser_.ims/cfg/icscf.sql
 mysql -u root -p -h localhost < FHoSS/scripts/hss_.db.sql
 mysql -u root -p -h localhost < FhoSS/scripts/userdata.sql

Configuration d’openIMSCore

Copier les fichiers suivant dans /opt/OpenIMSCore

 cp ser_.ims/cfg/*.cfg /opt/OpenIMSCore
 cp ser_.ims/cfg/*.xml /opt/OpenIMSCore
 cp ser_.ims/cfg/*.sh /opt/OpenIMSCore

Démarrer les composants

Démarrer les composants CSCFs :

 Les trois composants doivent être exécutés en parallèle
 Start pcscf.sh, icscf.sh and scscf.sh

Démarrer le FHoSS :

 start FHoSS/deploy/startup.sh ;
 Vérifier que l’interface web de la base de données est en cours d’exécution :
http ://localhost :8080
TP-2: Implémentation d'un cœur de réseau avec Clearwater

Dans ce TP, l'étudiant doit implémenter un cœur de

réseau IMS avec Clearwater, de bien comprendre

les différents nœuds de Clearwater, le rôle de

chaque nœuds et savoir comment ils s'inter-

agissent entre eux.

Pré-requis

 avoir une machine avec Ubuntu 14, 64bit comme système d’exploitation ;
 la machine doit posséder deux adresses IP, une accessible au public et la deuxième
accessible au réseau privé ;
 avoir le nom de domaine complet de la machine, qui se résout en adresse IP publique de la
machine, sinon, utilisez l’adresse IP publique ;
 accès SSH aux machines à un utilisateur autorisé à utiliser sudo pour accéder a distance.

Il y a quelques étapes qui sont communes à tous le nœud Clearwater a savoir la configuration des

sources de logiciels APT, fournir les adresses IP ou noms d’hôte DNS à utiliser pour garantir la

communication entre les hôtes. La configuration du APT : Les machines doivent être configurés de

telle sorte que APT peut utiliser la dépendance du serveur Clearwater.

 Sous sudo, créer /etc/apt/sources.list.d/clearwater.list avec le contenu suivant : " deb http
://repo.cw-ngv.com/stable binary/ " ;
 reindexé les packages du ubuntu par un update : " sudo apt-get update "

Pour établir la commuication entre nœud nous devons créer un fichier de configurer le répertoire
Clearwater "/etc/clearwater/config" et saisir la configuration suivante :

# Deployment definitions

home_domain=<zone>
sprout_hostname=sprout.<zone>

chronos_hostname=<privateIP> :7253

hs_hostname=hs.<zone> :8888

hs_provisioning_hostname=hs.<zone> :8889

ralf_hostname=ralf.<zone> :10888

xdms_hostname=homer.<zone> :7888

# Local IP configuration

local_ip=<privateIP>

public_ip=<publicIP>

public_hostname=<hostname>

# Email server configuration smtp_smarthost=<smtp server>

smtp_username=<username>

smtp_password=<password>

email_recovery_sender=clearwater@example.org

# Keys

signup_key=<secret>

turn_workaround=<secret>

ellis_api_key=<secret>

ellis_cookie_key=<secret>

# activer la fonction option I-CSCF et/ou external HSS lookups, ajouter également les

éléments suivants :

I-CSCF/S-CSCF configuration

icscf=5052

upstream_hostname=<sprout_hostname>
upstream_port=5052

# HSS configuration

hss_hostname=<address du HSS>

hss_port=3868

# Si vous voulez héberger plusieurs domaines du même déploiement Clearwater, ajouter ce qui

suit (et configurer DNS pour acheminer tous les domaines aux mêmes serveurs) :

# Additional domains

additional_home_domains=<domain 1>,<domain 2>,<domain 3>...

# Si vous voulez que vos nœuds incluent les serveurs d’applications Gemini/Memento ajouter

ce qui suit :

# Application Servers

gemini_enabled=’Y’

memento_enabled=’Y’

Étape d’installation de nœud spécifique

 Ellis
Installer Ellis package :

sudo DEBIAN_FRONTEND=noninteractive apt-get install ellis –yes

sudo bash -c "export PATH=/usr/share/clearwater/ellis/env/bin :$PATH cd /usr/share/clearwa-

ter/ellis/src/metaswitch/ellis/tools/ python create_numbers.py –start 6505550000 –count 1000

Après l’exécution de cette commande vous devez avoir ce résultat :

Created 1000 numbers, 0 already present in database

 Bono

Installer bono package :

sudo DEBIAN_FRONTEND=noninteractive apt-get install bono restund –yes

 sprout

Installer sprout package :

sudo DEBIAN_FRONTEND=noninteractive apt-get install sprout –yes

si vous voulez activer Gemini server :

sudo DEBIAN_FRONTEND=noninteractive apt-get install clearwater-cassandra –yes

sudo DEBIAN_FRONTEND=noninteractive apt-get install memento memento-nginx –yes

 homer

Installer homer package :

sudo DEBIAN_FRONTEND=noninteractive apt-get install clearwater-cassandra –yes

sudo DEBIAN_FRONTEND=noninteractive apt-get install homer –yes

 homestead

Installer homestead package :

sudo DEBIAN_FRONTEND=noninteractive apt-get install clearwater-cassandra –yes

sudo DEBIAN_FRONTEND=noninteractive apt-get install homestead homestead-prov –yes

- on met à jour les paramétres de configuration partagés en lançant les deux scripts

/usr/share/clearwater/clearwater-config-manager/scripts/upload_shared_config

/usr/share/clearwater/clearwater-config-manager/scripts/upload_scscf_json

- on se connecte sur l'interface d'ellis avec l'url : http://localhost:8080

NB: Pour ce TP, les plateformes IMS sont déjà implémentées donc il suffit tout
simplement de faire les configurations nécessaires pour l'interconnecter avec les
AS que vous allez mettre en place.
L'autre étape est de faire la configuration pour pouvoir faire de la VoD.
TP-3 : La gestion des IFC: serveur d'application, VOD (C’est pour maitrise des régles de

routage)

Dans ce TP, l'étudiant doit être en mesure de

d'implémenter un cœur de réseau IMS avec
OpenIMSCore ou Clearwater, et bien
comprendre la gestion des iFC dans IMS, de
mettre en place un serveur d'applications (AS)
et l'interconnecter avec la plateforme IMS,
maîtriser comment faire la vidéo à la demande

TP-4 : Implémentation d'un coeur de réseau IMS avec Kamailio

Dans ce TP, après avoir implémenté le

cœur du réseau IMS avec toutes les
configurations nécessaires pour que les
utilisateurs parviennent à se connecter,l
'étudiant doit mettre en place un serveur
Kamailio qui fonctionne et l'interconnecter
avec un cœur du réseau IMS basé sur
clearwater.
TP-5 : Intégration IMS et WebRTC

Dans ce TP, après avoir implémenté le cœur du réseau

IMS avec toutes les configurations nécessaires pour que
les utilisateurs parviennent à ce connecter,l'étudiant doit
mettre en place un client WebRTC et l'interconnecter avec
le cœur du réseau IMS: ici clearwater