Avant-propos

Ce cours est destiné aux étudiants de licence en Télécommunications et Réseaux ainsi qu'aux
professionnels et tous ceux qui évoluent dans le domaine des TIC.

Le cours est organisé à partir d'un objectif général, qui définit les grands points qui seront
détaillés dans le cours, des objectifs spécifiques ainsi que des activités. Chaque activité permet
au lecteur de satisfaire les différents points définis dans l'objectif spécifique. A la fin de chaque
chapitre, le lecteur doit faire un bilan de synthèse pour s'auto-évaluer et évaluer également les
techniques de l'enseignement utilisées.

La téléphonie sur IP est devenue un moyen pour les PME/PMI de réduire leur coût de
communications téléphoniques par de simples techniques encore méconnues du grand public.
Objectif général du cours
A la fin de ce module, l'étudiant doit être capable 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. Il doit connaître les différentes solutions existantes lui permettant
d'effectuer le meilleur choix tout en tenant compte des dispositions financières de son client,
mais aussi de la performance du matériel et du logiciel.

L’étudiant devrait être capable de déployer un cœur de réseau IMS et y ajouter des services
téléphoniques intéressants.

Il devrait être capable d’analyser les messages Diameter qui sont utiles pour la gestion des
profils et la facturation des abonnés dans les réseaux convergents de télécommunication
d’aujourdhui

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

 Table des matières
Activité 1 : Concepts de base de la téléphonie sur IP _______________________ 1
Introduction _________________________________________________________ 2
1.1- Problématiques liées à la téléphonie sur IP __________________________ 2
1.2- Les contraintes de la ToIP ________________________________________ 2
1.2.1 Les contraintes physiques ______________________________________ 2
1.2.2 Les contraintes temporelles _____________________________________ 3
1.2.3 La synchronisation ____________________________________________ 3
1.3 La Signalisation et Protocoles ___________________________________ 3
1.4 Les CODECs _________________________________________________ 4
1.4 Les protocoles de transport _____________________________________ 5
1.4.1 Le protocole TCP _____________________________________________ 5
1.4.2 Le protocole UDP ____________________________________________ 5
1.2.4.3 Les protocoles RTP et RTCP ________________________________ 6
Activité 2:Etude du protocole SIP _______________________________________ 7
2.1 Historique ______________________________________________________ 9
2.2 Caractéristiques du protocole SIP ________________________________ 9
2.2.1 La Compatibilité _____________________________________________ 9
2.2.2 Modularité _________________________________________________ 10
2.2.3 Simplicité __________________________________________________ 10
2.3 Les composants de l’architecture sip _____________________________ 10
2.3.1 Terminal utilisateur __________________________________________ 11
2.3.2 Serveur d’enregistrement ______________________________________ 12
2.3.3 Le serveur de localisation _____________________________________ 12
2. 3.4 Le serveur de redirection ____________________________________ 12
2.3.5 Le serveur proxy ____________________________________________ 12
Activité 3 Etude détaillée des protocoles SIP, RTP et RTCP ________________ 14
3.1 Les messages et les requêtes SIP ________________________________ 16
3.2 L'adressage SIP ______________________________________________ 16
3.3 L'initialisation _______________________________________________ 16
3.5 Les Méthodes SIP ____________________________________________ 17
3.6 La signalisation ______________________________________________ 19
3.7 Mode de transmission _________________________________________ 19
3.8 Le transport et le contrôle du flux multimédia ______________________ 20
3.8.1 Les protocoles RTP et RTCP ___________________________________ 20
3.8.2 Rôle du protocole RTCP _______________________________________ 22
 ATELIER SIP ____________________________________________________ 26
TP0 : Installation de deux terminaux SIP (Linphone 4, MicroSIP, zoiper,
CSIPsimple …) et appels directs entre deux terminaux et l’impact des codecs
audios et vidéos __________________________________________________ 26
TP1 : Appel point à point entre deux terminaux SIP et faire l’analyse des trames 26
TP2 : Analyse de requêtes et réponses de signalisation avec kamailio _______ 26
TP3 : L’intérêt des enregistrements DNS SRV et NAPTR _______________ 26
TP4 : Analyse des messages de type SDP +XML attachés à un message SIP __ 26
TP5 : Paquets RTP et RTCP ________________________________________ 26
TP6 : installation d’asterisk, création de compte SIP, définition du Dialplan
(Création des numéros) et l’impact et gestion des codecs __________________ 27
TP7 : Création de boîtes vocales _____________________________________ 27
TP8 : Mise en place de la conférence__________________________________ 27
Activité 4 Etude du protocole SCCP ____________________________________ 28
4.1 Signalisation dans SCCP ______________________________________ 30
ATELIERS SCCP _________________________________________________ 31
Atelier 1 : Utilisation des téléphones SIP sur un Call Manager Express _______ 31
Atelier 2 : Interconnexion SIP-CME __________________________________ 31
Atelier 3 : Asterisk en tant que serveur SCCP et interco asterisk -cme _______ 32
Activité 5 Réseau IMS _______________________________________________ 33
5.1 L'architecture IMS ___________________________________________ 34
5.1.1 Le contrôle des sessions _______________________________________ 35
5.1.1.1 L'entité P-CSCF __________________________________________ 35
5.1.1.2 L'entité I-CSCF ___________________________________________ 36
5.1.1.3 L'entité S-CSCF __________________________________________ 36
5.1.1.4 L'entité E-CSCF __________________________________________ 37
5.1.2 Les serveurs d'applications ____________________________________ 38
5.1.3 Les bases de données _________________________________________ 38
5.2 Etude de quelques plateformes IMS libres (OpenIMSCore, Clearwater et
kamailio) _________________________________________________________ 39
5.2.1 OpenIMSCore _______________________________________________ 39
5.2.2 Clearwater _________________________________________________ 40
5.2.3 Kamailio ___________________________________________________ 42
Atelier IMS _______________________________________________________ 44
TP-1 : Implémentation de OpenIMSCore et gestion de profils d'abonnés
(maitrise de HSS) _________________________________________________ 44
TP2 : Implémentations de quelques services téléphoniques ________________ 63
 Activité 1
Concepts de base de la téléphonie sur IP

1
Introduction
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 en train de s'imposer dans le secteur des
TIC en particulier dans les entreprises. La téléphonie est l'un des moyens de communication les
plus utilisés des êtres 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 était 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) enAnglais.

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
utilisé à 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 :

2
- l’écho : l’écho désigne le signal 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 56ms aller-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épasser 150ms.

L’idée est de dire que si nous voulons respecter cette contrainte temporelle il faudrait que le
canal établi entre les deux correspondants ne soit pas utilisé à 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’’.

1.2.3 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 doit pas dépasser 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 de
synchronisation :

▪ 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.3 La Signalisation et Protocoles

La signalisation est l'ensemble des processus (méthodes) liés à l'ouverture, l'établissement et la
fermeture de session entre deux utilisateurs.
3
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 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.

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

1.4 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: le nom de ces codecs commencent par G.XXX mais pas tous.

- G.711

- G.729

- G.723

- GSM

- ILBC

- Opus

4
Les codecs vidéo: leur nom commence généralement par H.XXX et pas tous.

- H.261

- H.263

- H.264

- MPEG4

- VP8

Google a mis au point le protocole VP8 placé sous Licence GPL pour supplanter le protocole
H.264

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

Nom du Débit voix Débit voix Caractéristiques Algorithmes

CODEC (min) max
Kbits/s Kbits/s

G.711 64 80 à 100 - Fréquence d’échantillonnage : 8khz -Loi U

- Débit fixe : 64kbits/s - Loi A

- 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

Tableau 1.1 : caractéristiques des codecs

1.4 Les protocoles de transport

1.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.4.2 Le protocole UDP

5
UDP (User Datagram 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é).

6
 Activité 2
Etude du protocole SIP

7
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

Contenu
- Historique du protocole SIP

- Architecture et fonctionnement du protocole SIP

- Composants d’une architecture SIP

8
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 fluxtemps

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

9
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 detransport.

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 6 entités:

- Terminal utilisateur
- Serveur d’enregistrement
- serveur de localisation
- serveur de redirection
- serveur proxy
- B2BUA (BACK to BACK User Agent)

10
 Figure 2.1 : Composants de l’architecture SIP

2.3.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,

- MicroSIP

- Linephone

- Zoiper

- CSipSimple

- X-Lite

- Jitsi

- PortGo

- Boghe IMS client

- Imsdroid

11
2.3.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 aenvoyé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.3.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. 3.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.3.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

12
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
- OpenSIPS
- Asterisk
- Freeswitch
- Clearwater
- OpenIMSCore

13
 Activité 3

Etude détaillée des protocoles SIP, RTP et RTCP

14
Objectifs spécifiques 3
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

- Être capable de dimensionner des liaisons pour tenir compte de nombre de

communications simultanés

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

- Le transport et le contrôle du flux media par RTP et RTCP

15
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 URI est de la forme :

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

▪ Identifiant spécifie le mot de passe ou le nomutilisateur
▪ Password est facultatif, mais on peut l'utiliser pour s'authentifier auserveur.
▪ serveur, désigne le serveur qui se charge du compte SIP
▪ paramètres, ce champ est optionnel.

Le protocole SIP utilise aussi l’adressage TEL URI de la forme tel :numero

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 :

16
 Ligne de requête ou 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 Méthodes SIP

Les méthodes SIP 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

17
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

401 Unauthorized – refusé : seulement utilisé par les registrars. Les proxy doivent employer
l’autorisation par proxy407

402 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

18
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.6 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 connait 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.7 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. Il ne gère alors que l'établissement d'une connexion et la
signalisation. Le canal voix est utilisé 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 à 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

19
être renouvelée entre 60 à 3600s selon la configuration de l'architecture du réseau. Ce
mécanisme assure qu’une requête envoyée sur téléphone va aboutir. Mais si un UA ne
s'enregistrer pendant dans la période donnée il sera supprimé dans la base de données.

3.8 Le transport et le contrôle du flux multimédia

3.8.1 Les protocoles RTP et RTCP

RTP (Realtime Transport Protocol) et son compagnon RTCP (Realtime Transport Control
Protocol) permettent respectivement de transporter et de contrôler des flots de données qui ont
des propriétés temps-réel.

RTP et RTCP sont des protocoles qui se situent au niveau de l'application et utilisent les
protocoles sous-jacents de transport TCP ou UDP. Mais l'utilisation de RTP/RTCP se fait
généralement au-dessus de UDP.

RTP et RTCP peuvent utiliser aussi bien le mode Unicast (point à point) que le mode Multicast
(multipoint).

Chacun d'eux utilise un port séparé d'une paire de ports. RTP utilise le port pair et RTCP le port
impair immédiatement supérieur.

+-------------+ +-------------+
| |port pair port pair! |
| RTP |----------- -----------| RTP |
| appli A | | appli B |
+-------------+ +-------------+

+-------------+ +-------------+
| |port pair+1 port pair+1! |
| RTCP |----------- -----------| RTCP |
| appli A | | appli B |
+-------------+ +-------------+

Format du paquet

L'entête d'un paquet RTP est obligatoirement constituée de 12 octets, éventuellement suivis
d'une liste d'identificateurs de sources contributeurs CSRCs dans le cas d'un mixer. Cet entête
précède le "payload" qui représente les données utiles.

20
+-------------------------+--------------------------------------
| RTP header (12 octets) | Payload ...
+-------------------------+--------------------------------------

Format de l''entête RTP

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Version V : 2 bits, V=2

• padding P : 1 bit, si P=1 le paquet contient des octets additionnels de bourrage (padding)
pour finir le dernier paquet.

• extension X : 1 bit, si X=1 l'entête est suivie d'un paquet d'extension

• CSRC count CC : 4 bits, contient le nombre de CSRC qui suivent l'entête

• marker M : 1 bit, son interpretation est définie par un profil d'application (profile)

• payload type PT : 7 bits, ce champ identifie le type du payload (audio, video, image,
texte, html, etc.)

• sequence number : 16 bits, sa valeur initiale est aléatoire et il s'incrémente de 1 à chaque

paquet envoyé, il peut servir à détecter des paquets perdus

• timestamp : 32 bits, réflète l'instant d'échantillonage du premier octet du paquet

• SSRC: 32 bits, identifie de manière unique la source, sa valeur est choisie de manières
aléatoire par l'application

• CSRC : 32 bits, identifie les sources contribuantes.

21
 Figure 3.2 : exemple d’un paquet RTP

3.8.2 Rôle du protocole RTCP

Le protocole RTCP est basé sur des transmissions périodiques de paquets de contrôle par tous
les participants dans la session.

Format des paquets

Il existe 5 types de paquets RTCP pour transporter des informations de contrôle :

• SR : Sender Report, transmission de statistiques des participants actifs en émission

• RR : Receiver Report, transmission de statistiques des participants passifs

• SDES : Source Description items (CNAME, NAME, EMAIL, PHONE,...)

• BYE : Fin de participation

• APP : fonctions spécifiques à l'application

➢ SR (Sender Report)

La partie fixe minimum d'un paquet SR est de 4 octets. Un paquet paquet SR peut contenir des
informations de la partie émetteur (sender info) sur 6 mots de 32 bits (48 octets) et ou des
informations de la partie récepteur (report block) sur 6 mots de 32 bits (48 octets).

22
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=SR=200 | length | header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of sender | sender
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ info
| NTP timestamp, most significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp, least significant word |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's packet count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sender's octet count |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| fraction lost | cumulative number of pacquets lost | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extented highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Format des SDES items

Le premier octet définit le type de l'item. Le second octet donne la longueur en octets de la
chaine de caractères de taille variable qui suit, mais arrondie à une frontière de mot.

23
 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CNAME=1 | length | user and domain name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAME=2 | length | common name of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EMAIL=3 | length | email address of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHONE=4 | length | phone number of source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LOC=5 | length | geographic location of site ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOOL=6 | length | name/version of source appl ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NOTE=7 | length | note about the source ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

BYE

Ce paquet permet d'indiquer aux autres participants que le membre quitte la session.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=BYE=203 | length | header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| length | reason for leaving ... (optional)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

24
RR (Receiver Report)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=RR=201 | length | header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SSRC_1 (SSRC of first source) | report
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block
| fraction lost | cumulative number of pacquets lost | 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extented highest sequence number received |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| last SR (LSR) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| delay since last SR (DLSR) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

SDES (Source Description)

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=SDES=202 | length | header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC_1 | chunk 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SDES items |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... | chunk 2
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

APP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT=APP=204 | length | header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC/CSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| name (ASCII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| application-dependent data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

25
ATELIER SIP

TP0 : Installation de deux terminaux SIP (Linphone 4, 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 : Analyse de requêtes et réponses de signalisation avec kamailio

Pour cela, on installe les prérequis et le serveur SIP kamailio

On crée des comptes SIP et on teste les enregistrements et les appels tout en analysant
les trames.

On conclut sur les deux phases d’enregistrements SIP, les différents types d’entêtes
from, to etc…, l’échange des informations sur les codecs.

TP3 : L’intérêt des enregistrements DNS SRV et NAPTR

Pour cela, on installe bind9 et bind9utils

On configure deux domaines rtn.sn et ec2lt.sn sur le serveur DNS

On fait des enregistrements SRV indiquant les serveurs sip respectifs de rtn.sn et
ec2lt.sn

Installation d’un serveur SIP (Asterisk)

On fait des enregistrements NAPTR sur les domaines rtn.sn et ec2lt.sn et on utilise un
téléphone supportant enum tel que imsdroid pour faire les appels à partir des numéros
( tel uri)

On conclut sur la place du DNS-ENUM dans l’interconnexion des domaines SIP

On conclut sur les types d’entêtes via, route, record-route

TP4 : Analyse des messages de type SDP +XML attachés à un message SIP

Pour cela, on utilisera dans un premier temps deux téléphones linphone 4 et dans un
deuxième deux téléphones linphones passant par un serveur central kamailio pour les
appels

On analysera les messages SIPMLE et autres pour se rendre compte des types de
messages attachés à un message SIP

On conclut sur les types de messages pouvant être attachés à des messages SIP

TP5 : Paquets RTP et RTCP

26
 On pourra faire des analyses des paquets RTP et RTCP pour :

1- Comprendre l’encapsulation de la voix

2- Comprendre et calculer la taille des paquets de la VOIX
3- Déterminer selon les codecs utilisés l’occupation de la bande passante par un appel
4- Dimensionner des liaisons

TP6 : installation d’asterisk, création de compte SIP, définition du Dialplan (Création

des numéros) et l’impact et gestion des codecs

TP7 : Création de boîtes vocales

TP8 : Mise en place de la conférence

NB : Le rapport de l’atelier doit être rendu à la fin du modul

27
 Activité 4
Etude du protocole SCCP

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

- Être capable de configurer l’interface d’un routeur sous GNS3

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

- Être capable d’interconnecter deux Call Manager Express

- Être capable de mettre en place et paramétrer un serveur TFTP pour les fichiers de
configuration des téléphones IP cisco

- Paramétrer les tréphones physiques Cisco utilisant le protocole SCCP et ceux utilisant
le protocole SIP

Contenu
- Activation du Call Manager Express

- Interconnexion de deux Call Manager Express

- Prise en charge du protocole SCCP par asterisk

- Interconnexion CME-Asterisk pour la gestion des boites vocales par asterisk

29
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 de trames.

- KeepAliveMessage : Message envoyé par les téléphones au Call Manager pour lui
prevenir que le lien établit est toujoursactif.

- KeepAliveAckMessage : C’est la réponse auxmessages

- 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 à un problè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 sesboutons.

30
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'ils se connectent 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 server 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

31
Atelier 3 : Asterisk en tant que serveur SCCP et interco asterisk -cme

Objectif

L’objectif de cet atelier est de gerer les telephones SCCP par le serveur asterisk

Contenu

- Activer le module SCCP sur asterisk

- Utiliser un softphone logiciel sccp et faire des appels

- Installer un serveur TFTP et y créer des fichiers de configuration de telephone selon leur
adresse MAC

- Définir le plan de numérotation à envoyer au serveur SCCP

- Configurer les téléphones SCPP qu’ils utilisent le serveur TFTP

- Tester la connectivité et les appels

32
 Activité 5

Réseau IMS

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

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 cœur 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) ;

34
• 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 post payé 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 un UA (User Agent) 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 ;

35
• 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 ;

36
• 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écupere son

profil auprès de l'entité HSS. Elle répond avec un message 200 OKcontenant 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écupéré lors de l'enregistrement. Elle transfère la 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.

37
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éphoniques. 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é HSSlors 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.

38
5.2 Etude de quelques plateformes IMS libres (OpenIMSCore,
Clearwater et kamailio)

5.2.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éfinie 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.1 : Architecture d’Open Source IMS Core

39
La base de données d’open source IMS Core, FHoSS (FOKUS Home Subscriber Server) est
basée 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.2.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.

40
 Figure 5.2 : Architecture de Clearwater IMS

• Bono (Edge Proxy)

Le nœud Bono forme un proxy SIP de périphérie extensible horizontalement (scalabilité

horizontale) offrant à la fois une interface compatible SIP IMS (Gm) et une interface de
WebRTC aux clients. Les requêtes clientes sont réparties entre les nœuds en utilisant un
équilibrage de charge. Ce nœud constitue le premier point de contact du client avec le système
Clearwater, y compris la prise en charge de divers mécanismes de traversée de NAT (Network
Address Translation). 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 P-CSCF tiers ou un SBC (Session Border Controller) implémentant un P-
CSCF.

• Sprout (routeur SIP)

Les nœuds de Sprout agissent comme un serveur d’enregistrement SIP horizontalement évolutif
qui gère l’authentification des clients et l’interface ISC pour les serveurs d’applications ainsi

41
que l’interfaçage avec le reste des serveurs tel que Homestead et Homer Les nœuds Sprout
contiennent également le serveur d'application MMTEL intégré. 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 a pas
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.2.3 Kamailio

Kamailio est un Server SIP open source. Ce fork du projet OpenSER (en 2005) est l'un des PBX
les plus complets. Il supporte des transactions asynchrones TCP, UDP et SCTP, l'encryptage
des 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 les
solutions classiques de téléphonie d'entreprise. C'est une alternative à Freeswitch et Asterisk les
deux autres poids lourds du domaine.

42
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ée

43
Atelier IMS

TP-1 : Implémentation de OpenIMSCore et gestion de profils d'abonnés (maitrise de

HSS)

Dans ce TP, il est demandé à l'étudiant de pouvoir mettre en place OpenIMSCore dans une
machine ubuntu 14 64 bits, mais aussi de pouvoir configurer un client sur l'interface de FoHSS
de OpenIMSCore, de maitriser la gestion des profils d'abonnés c’est à dire maitriser la base de
données HSS de OpenIMSCore.

Prérequis

• Accès réseaux
• Ubuntu 14v 64bits
• une adresse IP
• un serveur DNS exemple Bind avec les enregistrements de type SRV
Installer les paquets nécessaires
apt-get install build-essential debhelper cdbs lintian fakeroot
devscripts pbuilder dh-make dpatch subversion ipsec-tools bison curl
libcurl4-gnutls-dev ssh pure-ftpd openjdk-7-jdk linux-headers-`uname -
r` flex mysql-server libxml2 libxml2-* libmysqlclient-dev libmysql++-
dev ant docbook-to-man
apt-get install phpmyadmin

Télécharger le code source et le compiler

root@m2ims-pc:/opt# mkdir OpenIMSCore

root@m2ims-pc:/opt# cd OpenIMSCore
root@m2ims-pc:/opt/OpenIMSCore# mkdir ser_ims
root@m2ims-pc:/opt/OpenIMSCore# svn checkout
https://svn.code.sf.net/p/openimscore/code/ser_ims/trunk ser_ims
root@m2ims-pc:/opt/OpenIMSCore# mkdir FhoSS
root@m2ims-pc:/opt/OpenIMSCore# svn checkout
https://svn.code.sf.net/p/openimscore/code/FHoSS/trunk FHoSS
root@m2ims-pc:/opt/OpenIMSCore# cd ser_ims
root@m2ims-pc:/opt/OpenIMSCore/ser_ims# make install-libs all
root@m2ims-pc:/opt/OpenIMSCore/ser_ims# cd ..
root@m2ims-pc:/opt/OpenIMSCore# export JAVA_HOME="/usr/lib/jvm/java-7-
openjdk-amd64"
root@m2ims-pc:/opt/OpenIMSCore# cd FHoSS

44
root@m2ims-pc:/opt/OpenIMSCore/FHoSS#
root@m2ims-pc:/opt/OpenIMSCore/FHoSS# ant compile
root@m2ims-pc:/opt/OpenIMSCore/FHoSS# ant deploy
root@m2ims-pc:/opt/OpenIMSCore/FHoSS# cd ..

Installer et configurer le serveur DNS

root@m2ims-pc:/opt/OpenIMSCore# apt-get install bind9 bind9utils

Copier le contenu du fichier de zone DNS se trouvant dans le répertoire cfg et le mettre
dans le dossier de configuration du serveur.
root@m2ims-pc:/opt/OpenIMSCore# cp ser_ims/cfg/open-ims.dnszone
/etc/bind/bessan.zone

Remplacer open-ims.test et 127.0.0.1 dans le fichier respectivement par votre nom de

domaine et par votre adresse IP.
root@m2ims-pc:/etc/bind# sed -i s/open-ims.test/bessan.sn/g bessan.zone
root@m2ims-pc:/etc/bind# sed -i s/127.0.0.1/10.0.0.8/g bessan.zone

Editer le fichier named.conf.default-zones comme ci-dessous :

root@m2ims-pc:/etc/bind# nano named.conf.default-zones

zone "bessan.sn" {
type master;
file "/etc/bind/bessan.zone";
};

Renseigner dans le fichier resolv.conf l'adresse IP du serveur DNS comme ci-dessous :

root@m2ims-pc:/etc/bind# nano /etc/resolv.conf

nameserver 10.0.0.8

Redémarrer le serveur DNS et vérifier que la résolution fonctionne :

Le nom de domaine par défaut dans les fichiers de configuration de OpenIMSCore est
open-ims.test. Utiliser le script de configuration (configurator.sh) dans le dossier
/opt/OpenIMSCore/ser_ims/cfg pour adapter le nom de domaine et les adresses IP selon
votre configuration.
root@m2ims-pc:/opt/OpenIMSCore# ser_ims/cfg/configurator.sh
ser_ims/cfg/icscf.sql ser_ims/cfg/icscf.xml ser_ims/cfg/icscf.cfg
ser_ims/cfg/pcscf.cfg ser_ims/cfg/pcscf.xml ser_ims/cfg/scscf.xml
ser_ims/cfg/scscf.cfg FHoSS/scripts/hss_db.sql
FHoSS/scripts/userdata.sql FHoSS/deploy/hss.properties
FHoSS/deploy/DiameterPeerHSS.xml FhoSS/deploy/hibernate.properties

45
NB : Avant d’utiliser le script de configuration, il est impératif de s’assurer que l’adresse IP et
le nom de domaines ne changeront plus. Toute modification ultérieure devra se faire
manuellement sans l’aide du script.

Importer les bases de données à l'aide des fichiers dump.

root@m2ims-pc:/opt/OpenIMSCore# mysql -u root -p -h localhost <

ser_ims/cfg/icscf.sql
root@m2ims-pc:/opt/OpenIMSCore# mysql -u root -p -h localhost <
FHoSS/scripts/hss_db.sql
root@m2ims-pc:/opt/OpenIMSCore# mysql -u root -p -h localhost <
FHoSS/scripts/userdata.sql

En ligne de commandes où à l’aide de phpmyadmin, vérifier que les bases de données

ont été bien importées et modifier les droits d'accès à la base de données des utilisateurs
hss et icscf comme ci-dessous.

Sélectionner l’utilisateur icscf et cliquer sur changer les privilèges

Figure 5.3 : modification des privilèges

Dans la liste déroulante au niveau de client, choisir tout client (voir figure 5.4)

46
 Figure 5.4 : modification des privilèges étape 2

Faire la même opération pour l’utilisateur hss et obtenir le résultat ci-dessous :

Figure 5.5 : modification des privilèges étape 3

Copier tous les fichiers de configuration originaux et les scripts dans un dossier de votre
choix depuis lequel vous allez démarrer votre plateforme.
root@m2ims-pc:/opt/OpenIMSCore# cp ser_ims/cfg/*.cfg .

root@m2ims-pc:/opt/OpenIMSCore# cp ser_ims/cfg/*.xml .

root@m2ims-pc:/opt/OpenIMSCore# cp ser_ims/cfg/*.sh .

47
Démarrer les composants CSCFs et la base de données comme ci-dessous :

Figure 5.6 : lancement des services

Lorsque tous les services sont lancés, vous obtenez le résultat ci-dessous :

Figure 5.7 : Services démarrés

48
Configuration des clients et tests

Renseigner comme serveur DNS du terminal utilisateur (smarphone, laptop), l'adresse

IP de votre serveur DNS (10.0.0.8 dans notre cas). Faites les configurations comme ci-
dessus avec les utilisateurs par défaut Bob et Alice et essayez votre premier appel.

Figure 5.8 : configuration des clients

Figure 5.9 : Abonné Alice connecté avec le client Boghe

49
Sur un smartphone Android, installer le client IMSDROID et le configurer comme ci-
dessous :

Etape 1 Etape 2

Etape 3 Etape 4
Figure 5.10 : Configuration du client Imsdroid

Effectuer un appel entre Alice et Bob

Figure 5.12 : appel entre Alice et Bob

50
Administration du HSS : ajout d’un nouveau compte d’utilisateur

Pour se connecter à la console d'administration du hSS, il faut saisir dans un navigateur l'URL
suivante : http://ip:8080. Les informations de connexion par défaut sont :

Login : hssAdmin

Mot de passe : hss

Figure 5.13 : connexion au hss

Une fois connecté, cliquer sur User Identity pour créer l’IMPU, l’IMPI et l’IMSU.

Création IMPU : cliquer sur USER IDENTITIES et sur Create

Figure 5.14 : étape 1 création IMPU

51
Créer l’utilisateur bouki et lui affecter un profil de service comme ci-dessous :

Figure 5.14 : étape 2 création IMPU

Après avoir cliqué sur save, associer un réseau visité à l’IMPU :

52
 Figure 5.16 : étape 3 création IMPU

Création IMPI : cliquer à nouveau sur User Identities et cliquer sur create comme ci-
dessous :

Figure 5.17 : étape 1 création IMPI

53
Cliquer sur save et sur la page qui apparait associer l’identité publique à l’identité
privée qui vient d’être créée :

Figure 5.18 : étape 2 création IMPI

54
Création IMSU : cliquer à nouveau sur User Identities, puis sur Create sous IMS
Subscription :

Figure 5.19 : étape 1 création IMSU

Création IMSU : associer l’IMPI à l’IMSU

Figure 5.20 : étape 2 création IMSU

55
A cette étape l’utilisateur bouki est créé et peut être utilisé pour effectuer des appels. Les
figures 5.21 et 5.22 montrent respectivement la procédure d’enregistrement de
l’utilisateur Bouki et la procédure d’appel entre bouki et bob.

Figure 5.21 : processus d’enregistrement

56
 Figure 5.22 : processus d’appel

Interconnexion de deux serveurs IMS

Un nouveau serveur IMS a été mis en place. Voici le résumé des configurations des deux
serveurs IMS.

Réseau IMS 1 : BESSAN.SN

Adresse IP du serveur : 10.0.0.8

Nom de domaine : bessan.sn

Serveur DNS : 10.0.0.50

Réseau IMS 2 : INTERCO.SN

Adresse IP du serveur : 10.0.0.50

Nom de domaine : interco.sn

Serveur DNS : 10.0.0.50

57
Configuration particulière au niveau du serveur IMS 1 :

- Le serveur IMS 1 n’a pas besoin d’être configuré en tant que serveur DNS. Il n’est
donc pas nécessaire de faire les déclarations de zone dans le dossier /etc/bind/

- Le serveur IMS 1 doit utiliser comme serveur DNS, la machine où le serveur IMS 2
est installé. Mettre donc dans le fichier /etc/resolv.conf du serveur IMS 1, l’adresse IP
du serveur DNS qu’il doit utiliser : 10.0.0.50

Configuration particulière au niveau du serveur IMS 2 :

Dans le dossier /etc/bind/, déclarer à la fois la zone bessan.sn et interco.sn avec leurs adresses
IP respectives. (voir figure 5.23, 5.24 et 5.25)

Figure 5.23 : configuration du DNS

58
Figure 5.24 : extrait fichier bessan.zone

59
 Figure 5.25 : extrait fichier interco.zone

Modifier le fichier /etc/bind/named.conf.default-zones comme ci-

dessous :

60
 Figure 5.26 : configuration du DNS étape 2

A cette étape, un appel peut être fait entre un utilisateur du réseau IMS 1 et un autre du réseau
IMS 2. La figure 5.27 montre les détails des messages de signalisation et d’échange de flux
lors de l’appel entre bouki du réseau IMS 1 et bob du réseau IMS 2.

Appelant

IMPI : [email protected]

Client SIP : IMSDROID

Adresse IP : 10.0.0.9

Appelé

IMPI : [email protected]

Client SIP : Boghe IMS Client

Adresse IP : 10.0.0.6

Serveur IMS 1 : 10.0.0.8 (bessan.sn)

Serveur IMS 2 : 10.0.0.50 (interco.sn)

Serveur DNS : 10.0.0.50

Ports d’écoute pour les deux serveurs :

P-cscf : 4060

I-cscf : 5060

S-cscf : 6060

61
 Figure 5.27 : procédure d’appel interconnexion IMS

Travail à faire par l’étudiant : Après avoir installé votre réseau IMS, faire toutes les
étapes ci-dessous à mettre dans votre rapport.

1- On vous demande de parametrer imsdroid et le softphone Bohge pour qu’ils utilisent

respectivement les comptes par defaut alice et bob

2- Faire les appels audio, video et la messagerie instantanée

3- Ajouter un compte bouki en definissant son identité privée, son identité d’abonné et son
identité publique et faire les liens necessaires entre ses trois identités

4- Lancer wireshark sur le serveur IMS et enregistrer l’user bouki et analyser la procedure
d’enregistrement en mettant l’accent sur les messages diameter

5- Lancer wireshark et faites un appel entre bouki et alice et analyser la procedure d’appel
en mettant l’accent sur le role de HSS et les messages diameter echangés

6- On vous demande de mettre en place un deuxieme serveur IMS gerant le domaine rtn.sn

62
7- Faites le necessaire au niveau du serveur DNS gerant en meme temps les domaines
rtn.sn et ec2lt.sn pour permettre aux utiliseurs enregistrés dans le domaine rtn.sn d’appeler ceux
enregistrés dns le domaine ec2lt.sn

TP2 : Implémentations de quelques services téléphoniques

L’Objectif est de mettre en place de serveurs d’application IMS implémentant des services
téléphoniques tels que ;

La boite vocale

La conférence

Le parking

Le rappel automatique

Etc.

Pour cela, on vous demande d’installer asterisk et d’implémenter tous ces services

Ensuite on vous demande de bien configurer les profils de services pour que certains abonnés
IMS puissent utiliser ces services.

Administration du HSS : configuration d’asterisk comme serveur d’application de IMS

Pré-requis : Un serveur asterisk fonctionnel avec des utilisateurs déjà créés. Rajouter ces
configurations particulières au niveau des fichiers extensions.conf et sip.conf afin de définir
asterisk comme serveur d’application du réseau IMS.

63
Figure 5.28 : création d’un compte au serveur IMS dans le fichier sip.conf

64
Afin de ne pas créer des conflits de ports, le port d’écoute par défaut d’asterisk a été modifié
dans le fichier /etc/asterisk/sip.conf :

Figure 5.28 : configuration sip.conf étape 2

Figure 5.29 : plan de numérotation

65
Se connecter à l’interface d’administration du hss. http://ip:8080. Cliquer sur services, puis
« create » au niveau de Applications Servers.

Figure 5.30 : serveur d’application étape 1

66
Créer ensuite le Trigger Point

Figure 5.31 : création de trigger point

Créer un IFC et y associer le Trigger Point et le serveur d’application précédemment créés :

67
 Figure 5.32 : création de l’IFC

Modifier le Trigger Point créé pour ajouter les règles :

Figure 5.33 : modification du trigger point étape 1

Ajouter une règle afin d’indiquer que tous les appels allant vers 7001, 7002…soient pris en
charge par le serveur d’application Asterisk. Pour cela, ajouter d’abord SIP Method et choisir
INVITE. Ensuite, ajouter un Sip Header et remplir ça comme ci-dessous sachant qu’on a dans
notre fichier sip.conf les utilisateurs 7001 et 7002.

68
 Figure 5.34 : ajout des SPT

Associer l’IFC créé au profil de service par défaut des utilisateurs. Pour cela, cliquer à nouveau
sur Services et sur search au niveau de « Service Profiles ».

Figure 5.34 : profil de service

69
A cette étape, asterisk est configuré comme serveur d’application du serveur IMS. Les
utilisateurs du réseau IMS peuvent appeler ceux d’asterisk et vice-versa.

La figure 5.35 montre les messages échangés pendant un appel entre un utilisateur de IMS et
un autre de asterisk.

Appelant

IMPI : [email protected]

Client SIP : IMSDROID

Adresse IP : 10.0.0.11

Appelé

SIP URI : [email protected]

Client SIP : Linphone

Adresse IP : 10.0.0.13

Serveur IMS 1 : 10.0.0.8 (bessan.sn)

Ports d’écoute pour les deux serveurs :

P-cscf : 4060

I-cscf : 5060

S-cscf : 6060

Asterisk : 5090

Figure 5.35 : appel avec asterisk comme serveur d’application

70
Figure 5.36 : appel entre abonné IMS et abonné Asterisk

71