REPUBLIQUE DU SENEGAL

***** * * ********

UNIVERSITE CHEIKH ANTA DIOP DE DAKAR

ECOLE SUPERIEURE POLYTECHNIQUE

DEPARTEMENT GENIE INFORMATIQUE

Rapport de fin de module

Téléphonie
Et
Services

Présenté:
Serigne Habib DIAGNE Professeur encadreur:
Mame Diarra DIONE
Mouhamed DIOUF Dr Samuel Ouya
Moussa DIOUF
Yaye Maty Traoré

Année universitaire: 2019– 2020

Table des matières
Chapitre I : Généralités sur la ToIP ............................................................................................. 5
1) Définition et principe de fonctionnement ............................................................................. 5
2) Critère de base ...................................................................................................................... 6
2.1) Les contraintes de la ToIP .............................................................................................. 6
a) Les contraintes temporelles............................................................................................... 6
b) L’écho ................................................................................................................................ 6
c) La synchronisation ............................................................................................................ 6
2.2) La conversion analogique numérique ............................................................................ 6
a) Acquisition de la parole ..................................................................................................... 6
b) Numérisation ..................................................................................................................... 6
c) Compression ...................................................................................................................... 7
2.3) Les codecs ....................................................................................................................... 8
a) Temps de latence et gigue .................................................................................................. 9
3) Les protocoles utilisés par la ToIP ...................................................................................... 10
3.1) Les protocoles TCP et UDP ...................................................................................... 11
3.2) Le protocole RTP (Real Time Transport Protocol)............................................... 11
3.3) Le protocole RTCP (Real Time Control Protocol) ................................................ 11
3.4) Le protocole SIP(Session Initiation Protocol) ....................................................... 12
a) Architecture SIP .............................................................................................................. 12
3.5) Protocole SDP ............................................................................................................... 16
4) Aperçu des logiciels Open Source ....................................................................................... 16
4.1) Solutions serveurs Open Source ................................................................................... 16
4.2) IP PABX ........................................................................................................................ 17
4.3) Proxys SIP .................................................................................................................... 17
4.4) Clients VoIP Open Source ............................................................................................ 19
5) Scénario SIP ......................................................................................................................... 20
5.1) Processus d’enregistrement ............................................................................................ 20
5.2) Appel entre deux UA .................................................................................................... 23
Chapitre II: Configuration de services ....................................................................................... 27
I) Le service DHCP ................................................................................................................. 27
1) Installation des paquets ................................................................................................... 27
2) Fichier de configuration .................................................................................................. 28
3) Configuration au niveau du client .................................................................................. 28
II) Le service DNS ................................................................................................................... 30
1) Installation du paquet ..................................................................................................... 31
2) Configuration de bind ..................................................................................................... 31
3) Test ................................................................................................................................... 32
 III) Le service TFTP................................................................................................................ 32
1) Installation des paquets ................................................................................................... 32
2) Configuration .................................................................................................................. 32
3) Test ................................................................................................................................... 33
Chapitre III: Mise en Pratique ................................................................................................... 34
I) Utilisation des codecs ........................................................................................................... 34
1_) Appel audio entre deux terminaux utilisant des codecs audios différents ................... 34
2) Appel vidéo avec des codecs vidéos différents(même codec audio) ............................... 35
3) Appel vidéos avec des codecs audio différents (même codec vidéo) .............................. 35
II) INTERCONNEXION DE CALL MANAGER EXPRESS (CME) AVEC ASTERISK ... 36
1) Installation et configuration du serveur TFTP .............................................................. 37
2) Configuration du CME ................................................................................................... 38
3) CONFIGURATION D’ASTERISK ................................................................................ 40
4) Configuration de cloud1.................................................................................................. 41
5) Démonstration ................................................................................................................. 42
III) Utilisation des enregistrements SRV et NAPTR .............................................................. 44
1) Définition SRV................................................................................................................. 44
2. Définition NAPTR ........................................................................................................... 44
3) Objectif ............................................................................................................................ 45
4) Installation de Kamailio et configuration de base .......................................................... 45
4.1) Installation des prérequis et de kamailio ..................................................................... 46
4.2) Configuration de Base de Kamailio ............................................................................. 46
5) Configuration de DNS, type SRV et NAPTR ................................................................. 48
5.1) Configuration type SRV ............................................................................................... 48
5.2) Algorithme de mise en place d’un enregistrement de type NAPTR ........................... 49
5.3) Déclaration ................................................................................................................... 49
5.4) Configuration ENUM................................................................................................... 54
a) Chargement du module enum.so .................................................................................... 54
b) Création de la route ........................................................................................................ 55
c) Appel de la route dans le plan de numérotation de Kamailio ........................................ 55
d) Test de connectivité ......................................................................................................... 56
Chapitre I : Généralités sur la ToIP
1) Définition et principe de fonctionnement
La téléphonie sur IP est un service de téléphonie offert sur un réseau de
télécommunications, public ou privé, utilisant principalement le protocole de réseau
IP. La téléphonie IP définit l’utilisation de liens Internet pour acheminer des appels
téléphoniques d’une personne à une autre. L’appel téléphonique de type IP diffère de
la téléphonie conventionnelle (RTC) dans l’encodage de la voix. Dans le système
traditionnel, la voix est encodée de façon analogique et numérique et transmise sur un
réseau de commutation de circuits alors que dans le système IP, la voix est encodée
en format numérique et mise en paquets sous format IP.
Un système qui est censé mettre des personnes et des systèmes en relation exige une
certaine standardisation. C'est pourquoi sont apparus des protocoles standards,
comme le H.323, le SIP (Session Initation Protocol) ou encore le MGCP (Media Ga-
teway Control Protocol) qu’utilisent la ToIP. Les techniques de transformation d'un
signal sonore obéissent à plusieurs nécessités. Le son, et notamment la voix, est un
signal analogique, variable de façon continue. Cependant, les ordinateurs ne peuvent
traiter, stocker et transmettre que des nombres binaires. Il faut donc prélever sur le si-
gnal le minimum nécessaire à une reproduction correcte (l'échantillonnage) et le
transformer en nombres (la numérisation). Le signal obtenu est appelé « signal numé-
rique ». Ce signal numérique sera compressé en fonction de codecs que l’on choisira
choisis, cette compression a comme but de réduire la quantité d’information qui est
transmise sur le réseau.
En résumé le principe de la téléphonie sur IP consiste en la numérisation de la voix,
c’est-à-dire le passage d’un signal analogique à un signal numérique. Celui-ci est
compressé en fonction des codecs choisis. Le signal obtenu est découpé en paquets, à
chaque paquet on ajoute les entêtes propres au réseau (IP, UDP, RTP,…) et pour finir
il est envoyé sur le réseau. A l’arrivée, les paquets transmis sont réassemblés en sup-
primant d’abord les entêtes. Le signal de données ainsi obtenu est décompressé puis
converti en signal analogique afin que l’utilisateur puisse écouter le message d’ori-
gine.
Ces différentes notions seront plus abordées en détails dans la suite du document.

2) Critère de base
2.1) Les contraintes de la ToIP
a) Les contraintes temporelles
La principale difficulté de la téléphonie par paquets réside dans la très forte contrainte
temporelle due à l’interaction entre individus. Si l’on souhaite une bonne qualité de la
conversation, le temps séparant la parole de l’entente ne doit pas dépasser 150 ms.
b) L’écho
Une autre contrainte a lieu lorsqu’il y a un écho, c’est-à-dire un signal qui revient
dans l’oreille de l’émetteur. La valeur normalisée de la latence de l’écho étant de 56
ms, pour que l’écho ne soit pas gênant à l’oreille, il faut que le temps de traversée
dans le réseau ne dépasse pas 28 ms.
c) La synchronisation
Avec la téléphonie IP, les paquets sont remis au récepteur à des instants quelconques
donc il est nécessaire de faire une resynchronisation de ces paquets avant de les trans-
mettre au codeur (codec). La norme exige que le temps de resynchronisation soit
100ms. C'est le temps d'entrée du paquet dans le réseau, ajouté du temps maximal de
traversée du réseau.
2.2) La conversion analogique numérique
a) Acquisition de la parole
Elle consiste naturellement à capter la voix, Il se fait à travers un microphone com-
posé d'une bobine, d'une membrane et d'un aimant.
b) Numérisation
 L'échantillonnage :
Il consiste à capturer des points (échantillon) du signal analogique à des intervalles de
temps régulier, dont la durée est fixée par la fréquence d'échantillonnage. Le théo-
rème d'échantillonnage, dit aussi théorème de Shannon ou théorème de Nyquist-
Shannon, établit les conditions qui permettent l'échantillonnage d'un signal de largeur
spectrale et d'amplitude limitées.
Théorème de Shannon : Pour que le signal puisse être entièrement reconstruit à partir
des échantillons, la fréquence d'échantillonnage doit être strictement supérieure à
deux fois la plus grande fréquence présente dans le spectre du signal continu
La quantification :
Elle consiste à représenter un échantillon par une valeur numérique à la moyenne
d'une loi correspondance. Il convient de trouver cette loi de correspondance de telle
sorte que la valeur des signaux ait le plus de signification possible.
NB : La quantification uniforme n'est pas adaptée pour la parole téléphonique car il
peut y avoir des amplitudes rares de très grandes valeurs
Le codage :
Son but est de transformer un signal vocal en général analogique, en un signal
numérique d'un débit et d'une qualité donné. Généralement, la voix est échantillonnée
à 8 kHz et chaque échantillon est codé sur 8 bits, ce qui donne un débit de 64 kbit/s.
c) Compression
Le signal une fois numérisé peut être compressé, c’est-à-dire réduire la quantité
d’informations nécessaire pour l’exprimer. L’avantage de la compression est de
réduire la bande passante nécessaire pour transmettre le signal. Des loi de
compression sont utilisées pour rapprocher les grandes amplitudes des petites à
savoir :
-Loi A :La loi A (en anglais A-Law) est un système de quantification
logarithmique d'un signal audio, utilisé principalement à des fins de compression
pour les applications traitant la voix humaine. Elle est standardisée sous la référence
ITU-T G.711. Elle est uilisée principalement en Europe. L'équation de sortie de la loi
A est :

où A est le paramètre de compression. En Europe A=87,7. La valeur A=87,6 est par-

fois utilisée.
La fonction inverse est la suivante:

-Loi Mu : L'algorithme Loi µ (ou Loi Mu, en anglais μ-law ou mu-law) est un
système de quantification logarithmique d'un signal audio standardisée sous la réfé-
rence ITU-T G.711. Il est principalement utilisé pour traiter la voix humaine dont il
exploite les caractéristiques. Il est principalement utilisé pour les communications té-
léphoniques. Ce système de codage est utilisé aux États-Unis et au Japon.
L'équation de cette loi est :

où μ = 255 (8 bits) dans les standards nord-américains et japonais. L'amplitude de

cette fonction va de -1 à 1.
2.3) Les codecs
Dans un système de téléphonie sur IP, après la numérisation de la voix,
celle-ci se retrouve compressée, on parle à ce moment de codec. Il s’agit d’un
circuit imprimé de compression du son et permet ainsi de réduire le volume de
données échangées entre deux correspondants, on parle souvent de : Compression
/ Décompression.
La voix numérisée est donc compressé selon l’un des formats de codec (compres-
sion / décompression) puis insérée dans paquets IP. Le codec joue un rôle impor-
tant dans la mise en place d’une téléphonie IP, car premièrement la qualité sonore
dépend du codec utilisé (Taux de compression). Deuxièmement, en téléphonie sur
IP, la bande passante peut varier selon les codecs utilisés.

Nous distinguons deux types de codecs :

-les codecs audio : G711, G722, G723, G729, opus etc...

-les codecs vidéo : H261, H263, H263+, H264, VP8, VP9
A chaque codec nous associons deux valeurs : le débit et le score MOS (Mean Opinion
Score).
MOS est une note donnée à un codec audio pour caractériser la qualité de la restitution
sonore.
Pour le score MOS, la note peut varier de 0 à 5: 5 = Excellent, 4 = bon, 3 = Moyen, 2
= Dégradé, 1 = Mauvais.
Voici un tableau avec différents codecs ainsi que leur débit et score MOS :

a) Temps de latence et gigue

Enfin, le temps de transmission de la voix entre correspondants ne doit pas dépasser un
certain délai sous peine de dégrader la qualité. Il correspond au temps nécessaire pour :

 coder la voix (la compression augmente toujours le délai de codage),

  transmettre la voix sur Internet.

En pratique, un délai de 100 à 150 ms pour transmettre la voix est un maximum.

Dans la mesure où le délai introduit par le codage reste sensiblement constant, c’est le
temps de transmission sur Internet (latence) qui sera déterminant. De plus, lorsque la
latence est trop élevée, il est probable que certains paquets d’information arrivent de
manière trop désordonnée et que la qualité se dégrade nettement (voix métallique ou
hachée). On rencontre alors le phénomène de gigue (jitter en anglais).
La gigue est la variation de latence, ou différence de délai de transmission, entre des
paquets transmis entre deux systèmes d’un réseau informatique. Elle désigne la diffé-
rence de délai de transmission de bout en bout entre différents paquets d’un même flux
de paquets lors d’une transmission d’un système à l’autre.
C’est à dire qu’un paquet prend plus de temps qu’un autre à voyager entre les deux
systèmes. La gigue découle de plusieurs causes, elle peut apparaître en cas de
congestion du réseau, de dérive du timing ou de changement de routage. Cet effet est
particulièrement problématique dans le cas des communications en temps réel,
comme la téléphonie par voix sur IP ou la vidéo-conférence et autres services temps
réel.
Pour limiter ce phénomène, dans le cas des flux multimédias, on peut utiliser un
« jitter buffer » (tampon de gigue) sur un routeur du réseau ou sur un ordinateur au
niveau du récepteur. Il s’agit d’une zone au sein de laquelle l’on collecte, stock et
envoie les paquets vers le processeur de voix à des intervalles espacés de façon égale.

3) Les protocoles utilisés par la ToIP

Un protocole est un langage commun utilisé par l'ensemble des acteurs de la
communication pour échanger des données, autrement dit, c’est un ensemble de
procédures et de règles à l’émission et à la réception des données sur un réseau.
Nous avons essentiellement
Les protocoles de signalisation, qui gèrent la mise en relation avec une autre
personne, qui indiquent la ligne occupée, le statut du télép hone, les codecs.
En VoIP, on trouvera plusieurs protocoles de signalisation :
1. SIP
2. H.323
3. IAX
4. Skiny/SCCP
5. MGCP
6. MEGACO
7. BICC
SIP s'impose comme le protocole majeur dans les déploiements VoIP.
Les protocoles de transport de la voix qui s’occupent de transporter
l’information sonore sur le réseau.
3.1) Les protocoles TCP et UDP
TCP et UDP constituent les deux principaux protocoles de transport que nous
connaissons. Cependant, avec le délai de 150ms cité plus haut, et TCP étant un
protocole orienté connexion, il n’est pas adapté pour la voix téléphonie car
nécessitant un accusé de réception. Dès lors le protocole UDP appqraît bien
plus adapté que ce dernier.
3.2) Le protocole RTP (Real Time Transport Protocol)
RTP définit une méthode standardisée de transport réseau pour transmettre des
échantillons de voix et de vidéo sur le réseau Internet. RTP, protocole de
transport pour applications en temps-réel, est formalisé dans le RFC 3550.
Il est utilisé pour le transport de bout en bout de flux ayant des contraintes
temporelles fortes, typiquement pour les flux multimédias avec interactivité, tel
le service de téléphonie sur IP. RTP assure un contrôle spécifique des données
en temps réel. Il permet de reconstituer les propriétés temps réel des flux médias
en opérant sur deux niveaux, la synchronisation des flux et la reconstitution de
l’ordre des paquets émis et la détection des pertes de paquets de l’autre.
Plus généralement, RTP permet :
• d'identifier le type de l'information transportée,
• d'ajouter des marqueurs temporels et des numéros de séquence l'information
transporte
• de contrôler l'arrivée à destination des paquets.

3.3) Le protocole RTCP (Real Time Control Protocol)

RTCP est un protocole de contrôle et de supervision du réseau. Il opère comme
une sonde qui rend compte aux émetteurs des performances dont la
communication en cours bénéficie. Son objectif est d’offrir aux participants
d’une session une vision sur l’état du réseau et de s’y adapter de façon
dynamique. Dans sa spécification, RTCP n’est aucunement indispensable pour
le fonctionnement de RTP. La réciproque est vraie également. Néanmoins, leur
association apporte une cohérence globale dans le traitement des
communications multimédia.
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

3.4) Le protocole SIP(Session Initiation Protocol)

SIP a été normalisé par le groupe de travail WG MMUSIC (Work Group
Multiparty Multimedia Session Control) de l’IETF.
SIP prend en charge cinq facettes de l’établissement et de la terminaison de
communications multimédia :
-Localisation de l’utilisateur : détermination du système terminal à utiliser pour la
communication ;
-Disponibilité de l’utilisateur : détermination de la volonté de l’appelé à s’engager
dans une communication ;
-Capacités de l’utilisateur : détermination du support et des paramètres de support à
utiliser ;
-Etablissement de session : "sonnerie", établissement des paramètres de session à la
fois chez l’appelant et
L’appelé ;
-Gestion de session : y compris le transfert et la terminaison des sessions, la
modification des paramètres de session, et l’invocation des services.

a) Architecture SIP
AOR
Adresse d’enregistrement (AOR, Address-of-Record) : Une adresse d’enregistrement
est un URI SIP ou SIPS qui pointe sur un domaine avec un service de localisation qui
peut transposer l’URI en un autre URI où l’utilisateur pourrait être disponible.
Normalement, le service de localisation est rempli au moyen des enregistrements. Un
AOR est fréquemment vu comme l’"adresse publique" de l’utilisateur.
Proxy
Serveur Proxy (mandataire) : Entité intermédiaire qui agit à la fois comme un serveur
et comme un client pour les besoins de l’élaboration de demandes au nom des autres
clients.
Un serveur proxy joue principalement un rôle d’acheminement, de routage, ce qui
signifie que sa tâche est de s’assurer qu’une demande est envoyée à une autre entité
"plus proche" de l’utilisateur cible. En cela il est comparable au routeur IP qui
transfère le trafic en fonction de l'adresse IP de destination. Les proxys sont aussi
utiles pour mettre en application la politique de routage des appels (par exemple,
s’assurer qu’un utilisateur est autorisé à effectuer un appel). Un proxy interprète et, si
cela est nécessaire, réécrit des parties spécifiques d’un message de demande avant de
le retransmettre.
Les notions de Stateful Proxy et et de Stateless Proxy se distinguent par le maintien
d'un état des transactions. Alors que le proxy Stateless ne maintient aucun état, le
proxy stateful peut accomplir des tâches plus complexes telles que la duplication les
transactions, l'absorption des transactions ou d'autres telles que le transfert d'appel.
Serveur de redirection
C’est un serveur d’agent d’utilisateur (UAS) qui génère des réponses 3xx
(Redirection) aux demandes qu’il reçoit, amenant le client à contacter un ensemble
d’URI de remplacement.
B2BUA (Back-to-Back User Agent)
Un B2BUA est une entité logique qui reçoit une demande et la traite comme UAS.
Afin de déterminer comment il devrait être répondu à la demande, il agit comme un
UAC et génère des demandes. A la différence d’un serveur mandataire, il maintient
l’état du dialogue et doit participer à toutes les demandes envoyées dans les dialogues
qu’il a établi.
REGISTRAR Server et Location Server
Un REGISTRAR Server un serveur qui gère les requêtes REGISTER envoyées par
les Users Agents pour signaler leur emplacement courant. Ces requêtes contiennent
donc une adresse IP, associée à une URI, qui seront stockées dans une base de
données.
Un service de localisation est utilisé par un Redirect Server ou un serveur proxy pour
obtenir des informations sur la ou les localisations possibles d’un appelé. Il contient
une liste de liens de clés d’address-of-record pour aucune ou plusieurs adresses de
contact. Les liens peuvent être créés et retirés de nombreuses façons.
Les URI SIPs sont très similaires dans leur forme à des adresses email :
sip:utilisateur@domaine.com
Généralement, des mécanismes d'authentification permettent d'éviter que quiconque
puisse s'enregistrer avec n'importe quelle URI.

Requêtes (Méthodes) SIP

Le client envoie des requêtes au serveur, qui lui renvoie une réponse. Les méthodes
de base (RFC 3261) comprises dans ces requêtes sont :
 INVITE : permet à un client de demander une nouvelle session
 ACK : confirme l'établissement de la session
 CANCEL : annule un INVITE en suspens
 BYE : termine une session en cours
 OPTIONS : permet de récupérer les capacités de gestion des usagers, sans
ouvrir de session
 REGISTER : permet de s'enregistrer auprès d'un serveur d'enregistrement.

Réponses SIP
Selon les contextes une réponse est attendue, les réponses possibles sont similaires
aux réponses HTTP. Dans le meilleur des cas on obtient un 200 OK.
Une transaction SIP survient entre un client et un serveur et comprend tous les
messages depuis la première demande envoyée du client au serveur jusqu’à la
réponse finale (non-1xx) envoyée du serveur au client. Si la demande est INVITE et
la réponse finale est un non-2xx, la transaction comporte aussi un ACK à la réponse.
Le ACK pour une réponse 2xx à une demande INVITE est une transaction distincte.
Un dialogue est une relation SIP d’homologue à homologue qui persiste pendant un
certain temps entre deux agents d’utilisateur. Un serveur SIP répond à une requête
SIP au moyen d’une ou de plusieurs réponses. Les réponses, dont les codes sont de la
forme 2xx, 3xx, 4xx, 5xx et 6xx, sont des réponses finales et terminent la transaction
courante :
  Provisional (1xx): La demande est reçue et est en cours de traitement.
 Success (2xx): L'action a été reçue, comprise et acceptée avec succès.
 Redirection (3xx): Une action supplémentaire doit être prise (par l'appelant)
pour compléter la demande.
 Client Error (4xx): La demande comporte une mauvaise syntaxe et ne peut
être prise en charge par le serveur.
 Server Error (5xx): Le serveur a échoué remplir une demande apparement
valide.
 Global Failure (6xx): La demande ne peut être prise en charge par aucun
serveur.

Messages SIP
Un message SIP est composé des éléments suivants :
1. Une ligne de départ (start-line) : Message URI SIP/2.0
2. Un ou plusieurs champs d'en-tête (header fields)
3. Une ligne vide indiquant la fin des champs d'en-tête.
4. Un corps de message optionnel (message body)
Un message SIP est notamment composé de champs d'en-têtes définis dans le RFC
3261 pour la signalisation et le routage des informations entre des entités SIP. Chaque
en-tête consiste en un nom de champs suivant d'un deux-points (:) et d'une valeur.
Les champs d'en-tête (header fields) peuvent être, entre autres :
1. From : Il indique l'identité de celui qui initié la requête SIP. Cette valeur est
souvent valorisée par l'AOR de l'envoyeur. Il comprend un URI SIP ou SIPS voire un
"display name" optionnel.
2. To : Cet en-tête indique le destinataire souhaité pour la requête SIP. Il utilise
habituellement l'AOR du destinataire.
3. Call-ID : Il identifie un dialogue SIP de manière unique. Il est donc identique pour
toutes les requêtes et les réponses SIP d'un même dialogue.
4. Cseq : Cet en-tête est composé d'une valeur de nombre entier et un nom de
méthode. Il identifie, ordonne et séquence les requêtes SIP au sein d'un dialogue. Il
permet de différencier les nouveaux messages et les retransmissions.
5. Via : Le champ Via indique le chemin pris par la requête et identifie où la réponse
doit être envoyée. Il indique aussi le transport utilisé. Cet en-tête doit contenir un
paramètre "branch" qui est utilisé pour identifier la transaction créée par la requête.
Ce paramètre est utilisé aussi bien par le client que par le serveur. Il doit toujours
commencer par un "magic cookie" d'une valeur de "z9hG4bK".

3.5) Protocole SDP

Le Session Description Protocol (SDP) est un protocole de communication de
description de paramètres d'initialisation d'une session de diffusion en flux
(streaming). L'Internet Engineering Task Force (IETF) a publié une première
spécification comme une proposition de standard Internet en avril 1998 et a publié
une spécification révisée comme le standard Internet RFC 4566 en juillet 2006.
Le SDP a été créé pour décrire des sessions de communication multimédia, par
exemple pour l'annonce de la session, l'invitation à une session et la négociation de
paramètres. Le protocole SDP ne livre pas le média lui-même, mais est utilisé par
l'émetteur et le destinataire pour la négociation du type et du format du média, et les
propriétés associées. L'ensemble des paramètres d'une session est souvent appelé un
profil de session. Le SDP a été conçu pour être extensible et soutenir les nouveaux
types et formats de médias. Le SDP a commencé comme une composante du Session
Announcement Protocol (SAP), mais a trouvé d'autres utilisations en conjonction
avec le Real-time Transport Protocol (RTP), le Real-Time Streaming Protocol
(RTSP), le Session Initiation Protocol (SIP) et même comme un format autonome
pour décrire des sessions de multidiffusion.
SDP avec SIP fonctionne selon un modèle Offre/Réponse où chacun des
protagonistes d'un dialogue indique ses capacités en terme de codage du media utilisé
(voix, vidéo, ...) et choisissent les paramètres qui leur correspondent pour le
placement du trafic RTP.
SDP est composé d'une série de lignes sensible à la casse <caractère>=<valeur>
, où <caractère> est un caractère alphabétique et <valeur> est un texte structuré.
Il se compose de trois sections principales:
La session, le timing et les descriptions des médias.
Chaque message peut comporter plusieurs descriptions de synchronisation et de
média, mais seulement une description de session.

4) Aperçu des logiciels Open Source

4.1) Solutions serveurs Open Source
 IP PABX
  Asterisk et dérivatifs
 Freeswitch
 Proxys SIP (Fed VoIP)
 Kamailio
 OpenSips
 Repro
 Flexisip

4.2) IP PABX
Ces logiciels font office de B2BUA, de serveurs multimédia, de transcodeur de
medias, d'IVR, etc.
Asterisk
Asterisk Core (http://www.asterisk.org/), sous Linux, en installation par paquet ou en
installation native par compilation sur des plateformes Intel ou embarquées, voire en
VM ou en Container ou encore en VPS.
Il existe aussi des dérivatifs à partir d'Asterisk et de FreePBX (GUI Web) fournis en
distribution Linux :
Notons aussi l'endurance du projet Xivo (http://www.xivo.io/), basé Asterisk avec une
interface spécifique.
Freeswitch
FreeSWITCH est un serveur d'applications gratuit et open-source pour la
communication en temps réel , WebRTC , les télécommunications , la vidéo et le
protocole Voice over Internet ( VoIP ). Multiplateforme, il fonctionne sous Linux,
Windows, macOS et FreeBSD. Il est utilisé pour créer des systèmes PBX, des
services IVR, la vidéoconférence avec chat et partage d'écran, le routage en gros à
moindre coût, le Session Border Controller (SBC) et appareils de communication
intégrés. Il a un support complet pour le cryptage, ZRTP, DTLS, SIPS. Il peut servir
de passerelle entre PSTN, SIP, WebRTC et de nombreux autres protocoles de
communication. Sa bibliothèque principale, libfreeswitch, peut être intégrée à d'autres
projets. Il est sous licence Mozilla Public License (MPL), une licence de logiciel
libre.
4.3) Proxys SIP
Ces logiciels visent à exploiter la Federated VoIP. La "Federated VoIP" est une forme
de la téléphonie qui utilise la VoIP entre des domaines autonomes dans l'Internet
Public sans aucun déploiement d'un point central d'échange ou de commutateurs pour
le routage du trafic.
La "Federated VoIP" peut utiliser notamment ENUM comme système d'adressage, de
localisation et d'identification des participants. Elle exploite des entrées DNS SRV à
la manière des entrées MX pour le service SMTP. Elle implémente des
communications sécurisées grâce à TLS et aux certificats X.509. Elle utilise les
protocoles SIP et XMPP/Jabber pour établir les communications.
Kamailio
Kamailio est un serveur SIP Open Source publié sous GPL, capable de gérer des
milliers de configurations d'appels par seconde. Kamailio peut être utilisé pour créer
de grandes plates-formes pour les communications VoIP et en temps réel - présence,
WebRTC, messagerie instantanée et autres applications. De plus, il peut être
facilement utilisé pour mettre à l'échelle des passerelles SIP vers PSTN, des systèmes
PBX ou des serveurs multimédias comme Asterisk ™, FreeSWITCH ™ ou SEMS.
Parmi les fonctionnalités puissantes: TCP asynchrone, UDP et SCTP, communication
sécurisée via TLS pour VoIP (voix, vidéo, texte); Prise en charge WebSocket pour
WebRTC; IPv4 et IPv6; Messagerie instantanée SIMPLE et présence avec serveur
XCAP intégré et relais MSRP; opérations asynchrones; Extensions IMS pour VoLTE;
ENUM; DID et routage à moindre coût; l'équilibrage de charge; basculement de
routage; comptabilité, authentification et autorisation; prise en charge de nombreux
systèmes backend tels que MySQL, Postgres, Oracle, Radius, LDAP, Redis,
Cassandra, MongoDB, Memcached; Interface de contrôle Json et XMLRPC,
surveillance SNMP.
OpenSips
OpenSIPS est un proxy / serveur Open Source SIP pour la voix, la vidéo, la
messagerie instantanée, la présence et toute autre extension SIP.
C’est un serveur SIP de signalisation multifonctionnel et polyvalent utilisé par les
opérateurs, les télécoms ou les ITSP pour des solutions telles que les plates-formes
résidentielles de classe 4/5, la jonction / la vente en gros, les solutions PBX
d'entreprise / virtuelles, les contrôleurs de frontière de session, les serveurs
d'applications, la charge frontale. Équilibreurs, plates-formes IMS, centres d'appels et
bien d'autres - voir l'ensemble complet des fonctionnalités.
OpenSIPS est recommandé pour tout type de scénario / service SIP:
  Le haut débit - des dizaines de milliers de CPS, des millions d'appels
simultanés
 La flexibilité du routage et de l'intégration - script de routage pour
l'implémentation de logiques de routage personnalisées, plusieurs API
d'interfaçage
 La construction efficace des applications - plus de 120 modules pour fournir
des fonctionnalités, pour la gestion SIP, pour les opérations backend, pour
l'intégration, pour les logiques de routage

4.4) Clients VoIP Open Source

Les clients SIP peuvent être encore appelés softphones. Les softphones sont des
logiciels qui assurent toutes les fonctions téléphoniques et qui utilisent la carte son et
le micro du PC de l'utilisateur.
Parmi les clients SIP, on peut citer entre autre :
- Ekiga
- Polycom
- X-Lite
- IppiMessenger
- Zoiper
- Phone Gaim
- Wengo
-QuteCom
5) Scénario SIP
5.1) Processus d’enregistrement

F1 : Demande d'inscription initiale de l'UA SIP avec ses informations auprès de l’AOR
F2 : Réponse du registrar avec les informations nécessaire à la connexion
F3 : Nouvelle demande d'inscription avec login
F4 : Confirmation de réussite d’enregistrement par le SIP Registrar
Observation avec Wireshark
Wireshark est un analyseur de paquets open source (GNU) populaire. Ses "dissectors"
ou décodeurs de protocoles permettent d'interpréter le trafic du réseau.
Conçu en 1997-1998 par Gerald Combs sous le nom historique de "Ethereal", il est
repris en 2006 sous le nom moderne de "Wireshark". En 2008, Wireshark sort en ver-
sion 1.0 et en 2015 en version 2.0 avec une nouvelle interface graphique.
  F1 :

 F2 :
Ce message indique que la demande exige que l'utilisateur réalise une authentification.
La réponse contient champ d'en-tête WWW-Authenticate qui demande des informa-
tions d'identification correcte de l'agent utilisateur (UA).
  F3
Une nouvelle requête fournit les paramètres adéquat : Authorization: Digest user-
name="justine",realm="asterisk",nonce="17ed85fe",uri="sip:172.20.10.6;trans-
port=UDP",response="2e80df3428ad9b1a6fa673ad9648fd1d",algorithm=MD5
Les nonces sont utilisés dans l'authentification d'accès par digest HTTP pour calculer
une empreinte MD5 du mot de passe. Ils sont différents à chaque demande d'authenti-
fication.

 F4 :
200 OK signifie que la demande a été acceptée.
5.2) Appel entre deux UA
L’illustration peut être faite en utilisant deux softphones et un serveur astérisk
Fichier sip.conf :

Fichier extensions.conf :

On va faire un appel entre les utilisateurs «moussa » et « justine » et visualiser à l’aide

de wireshark les paquets
  Requête INVITE SDP
Le premier message est une requête INVITE

 Réponse provisionnelle 100 Trying

 Réponse provisionnelle 180 Ringing

 Réponse 200 OK SDP

 ACK
  Requête BYE

 Réponse OK

Le transfert de la voix est assuré par RTP codé en G.711 PCMU. Le format a été négo-
cié par SDP dans la requête INVITE et la réponse 200 OK.
Chapitre II: Configuration de services
I) Le service DHCP
Tout ordinateur d'un réseau TCP/IP a besoin des éléments TCP/IP pour pouvoir com-
muniquer avec les autres ordinateurs du réseau.
Ces adresses IP sont attribuées :
 statiquement, en configurant le réseau directement sur l'ordinateur
 dynamiquement, avec un serveur DHCP qui attribue les adresses
Le protocole DHCP (Dynamic Host Configuration Protocol : « Protocole de configu-
ration dynamique des hôtes ») est un service réseau TCP/IP. Il permet aux ordinateurs
clients l'obtention automatique d'une configuration réseau. Il évite la configuration de
chaque ordinateur manuellement. Les ordinateurs configurés pour utiliser DHCP n'ont
pas le contrôle de leur configuration réseau qu'ils reçoivent du serveur DHCP.

1) Installation des paquets

On installe le paquet isc-dhcp-server
2) Fichier de configuration
Les configurations vont se faire au niveau du fichier /etc/dhcp/dhcpd.conf

Le serveur assignera au client une adresse IP comprise entre 10.10.10.100 et

10.10.10.250 pour une durée de 600 secondes. Le client peut spécifier une période de
temps spécifique, dans ce cas, le temps d'allocation maximum est de 7200 secondes.
Le serveur va également informer le client qu'il doit utiliser :
 un masque de sous réseau à 255.255.255.0
 une adresse de routeur/passerelle à 10.10.10.254 : option routers

 un serveur DNS à 10.10.10.254 : option domain-name-servers

 l’adresse du prochain serveur à contacter 10.10.10.254: next-server

Des adresses IP fixes peuvent être créés, pour cela il suffit d'ajouter une directive
«host» dans la définition du subnet. Pour chaque client, il faut donner son adresse
fixe en fonction de son adresse MAC.

3) Configuration au niveau du client

On édite le fichier /etc/network/interface, les machines sont connectées au réseau par
l'interface réseau eth0
On rajoute l’interface au niveau du fichier /etc/default/isc-dhcp-server

On peut à présent redémarrer les services networking et isc-dhcp-server

Dans le fichier /var/lib/dhcp/dhcpd.leases on peut trouver des informations sur les

connexions
II) Le service DNS
Le service DNS (Domain Name System) est un service TCP/IP permettant la corres-
pondance entre un nom de domaine et une adresse IP.
En effet un site est toujours localisé sur Internet par l’adresse IP de la machine sur la-
quelle il se trouve. Mais on indique généralement au navigateur le nom de domaine
du site que l’on souhaite visiter, et non pas son adresse IP.
Un navigateur web, pour se rendre sur un site, doit donc connaître l'adresse IP du
nom de domaine correspondant. Il faut donc faire la correspondance entre un nom de
domaine et son adresse IP. Si les services de correspondance sont hors service, aucun
navigateur ne pourra connaître l'adresse IP du site correspondant, et donc consulter ce
site.
En téléphonie, si on dispose d’un serveur DNS, on peut configurer des enregistre-
ments NAPTR par exemple pour le mappage de serveurs et d'adresses d'utilisateur
dans le protocole SIP ( Session Initiation Protocol ). La combinaison d'enregistre-
ments NAPTR avec des enregistrements de service (SRV) permet l'enchaînement de
plusieurs enregistrements pour former des règles de réécriture complexes qui produi-
sent de nouvelles étiquettes de domaine ou des identificateurs de ressources uni-
formes (URI).
Il est aussi possible de donner les moyens de joindre un utilisateur à partir de son nu-
méro téléphone avec les enregistrements de type ENUM.
Les informations stockées sur un serveur DNS sont appelés des enregistrements.
Type d'enregistrements possibles :
 SOA: permet de préciser le nom du domaine sur lequel le serveur DNS a auto-
rité, le nom complet du serveur DNS ainsi que l’email de l’administrateur du
domaine
 A : Hôte local. Utilisé pour lier un nom de domaine DNS avec une adresse IP.
 PTR : Pointeur(PTR). Utilisé pour lier une adresse IP à un nom domaine.
 NS : Serveur de nom : Utilisé pour lier un nom de domaine DNS avec le nom
d'un ordinateur qui fait office d’un serveur DNS.
  CNAME : Nom canonique. Utilisé pour lier un nom de domaine DNS cano-
nique avec un autre nom principal ou canonique.
 MX: Serveur de Messagerie. Utilisé pour lier un nom de domaine DNS avec le
nom d'un ordinateur qui échange ou transmet du courrier pour un domaine.
 SRV: Utilisé pour déclarer les services
 NAPTR : Utilisé pour déclarer des serveurs de téléphonie

1) Installation du paquet
On aura besoin du paquet bind9

2) Configuration de bind
On crée le fichier de zone dans le fichier /etc/bind/named.conf.default-zones

Recherche directe : /etc/bind/esp.com

Ce fichier contient les noms de machines dans le domaine, mappés avec leur @ IP.

Il faut changer le contenu du fichier /etc/resolv.conf en lui indiquant le domaine auquel

vous appartenez et l'adresse IP du serveur DNS à tester (127.0.0.1 pour votre machine).
3) Test
La commande nslookup permet aussi de tester le DNS. Tapez nslookup :
>set type=any
>esp.com pour tester sur le domaine esp.com

III) Le service TFTP

TFTP (pour Trivial File Transfert Protocol) est un protocole simplifié de transfert de
fichiers. Il fonctionne en UDP sur le port 69, au contraire du FTP qui utilise lui TCP
et le port 21. L'utilisation d'UDP implique que le client et le serveur doivent gérer
eux-mêmes une éventuelle perte de paquets.
Les principales simplifications visibles du TFTP par rapport au FTP est qu'il ne gère
pas le listage de fichiers, et ne dispose pas de mécanismes d'authentification, ni de
chiffrement. Il faut connaître à l'avance le nom du fichier que l'on veut récupérer. De
même, aucune notion de droits de lecture/écriture n'est disponible en standard.
On utilise le protocole TFTP notamment pour la mise à jour des firmwares sur les
équipements réseaux, la sauvegarde de la configuration de ces équipements réseau,
mais aussi pour amorcer des stations de travail sans disque dur.
En téléphonie, le couplage DHCP/TFTP permet par exemple aux téléphones de télé-
charger les fichiers de configuration comme dans le cas de l’interconnexion entre
CME et Asterisk. Il permet aussi la configuration de clients légers et facilite l’instal-
lation des machines.
1) Installation des paquets
On installe les paquets tftp-hpa et tftpd-hpa

2) Configuration
On édite le fichier /etc/default/tftpd-hpa

Le répertoire par défaut est /var/lib/tftpboot/, qui possède l'utilisateur root, on ne peut
donc télécharger que des fichiers depuis le serveur TFTP.
# sudo chown tftp:tftp /var/lib/tftpboot
On redémarre le serveur TFTP pour appliquer les modifications:
#sudo /etc/init.d/tftpd-hpa restart
3) Test
tftp - v <@IP_serveur>
tftp> put <nom_distant> (pour envoyer un fichier)
tftp> get <nom> (pour déposer un fichier)
Chapitre III: Mise en Pratique
I) Utilisation des codecs
Dans cette partie, nous allons illustrer l’importance des codecs dans le processus de
communication en se mettant dans des situations que nous allons énoncer ci-dessous.
On dispose d’un serveur kamailio avec les utilisateurs «6000» et « 6001» ainsi que le
softphone « linphone ».

1_) Appel audio entre deux terminaux utilisant des codecs audios différents
Nos deux utilisateurs sont connectés, on active seulement «G711» au niveau de 6000
on l’a désactivé au niveau de 6001.

Résultat : L’appel ne passe pas du fait que les codecs utilisés sont différents.
2) Appel vidéo avec des codecs vidéos différents(même codec audio)

Résultat : L'appel audio passe mais la vidéo ne marche pas du fait des codecs vidéo
différents.

3) Appel vidéos avec des codecs audio différents (même codec vidéo)
Résultat : L'appel vidéo marche mais l'appel audio ne passe pas

II) INTERCONNEXION DE CALL MANAGER EXPRESS (CME) AVEC AS-

TERISK
L’architecture que allons utiliser pour mettre en œuvre le projet est constituée d’un
serveur Asterisk sip qui gère les téléphones analogiques par l’intermédiaire du PAP2
qui a pour rôle de convertir un signal analogique en numérique et vice versa. Puis, nous
avons un CME qui est propriétaire de cisco permettant de gérer un système de télé-
phone avec des téléphones IP. Le serveur TFTP contient le fichier de configuration des
téléphones IP. Ce serveur facilite les tâches administratives au cas d’une mise à jour.
1) Installation et configuration du serveur TFTP

On se rend au niveau du répertoire /var/lib/tftpboot/ pour ajouter le fichier de configu-

ration XMLDefault.cnf.xml que les téléphones vont charger.
Le processNodeName correspond à l’adresse du CME

2) Configuration du CME
Nous allons utiliser gns3 pour la réalisation de l’interconnexion
 Configuration de l’interface
interface FastEthernet0/0
ip address 192.168.10.254 255.255.255.0
 Configuration du serveur DHCP
ip dhcp pool dic
network 192.168.10.0 255.255.255.0
default-router 192.168.10.254
option 150 ip 192.168.10.151
class dic
address range 192.168.10.100 192.168.10.150
NB: option 150 ip 192.168.10.151 : précise l’adresse ip du serveur TFTP

 Configuration du système de téléphonie

telephony-service
max-ephones 20
max-dn 20
ip source-address 192.168.10.254 port 2000

NB: ip source-address 192.168.1.254 port 2000 : Activation du protocole SKINNY

Le Skinny Call Control Protocol (SCCP) est un protocole de communication, créé par
Cisco et utilisant le port 2000. L’avantage de Skinny est qu’il utilise des messages pre-
nant très peu de bande passante c’est pourquoi il est utilisé pour les communications
entre les téléphones IP et le CallManager ainsi que pour contrôler une conférence.

 Plan de numérotation
ephone-dn 1
number 2000
label adama

ephone-dn 2
number 2020
label badou

 Interconnexion du CME au serveur SIP

dial-peer voice 1 voip
destination-pattern 1...
session protocol sipv2
session target sip-server
codec g711ulaw
NB:destination-pattern 1... : Indique le numéro à composer pour joindre l’autre serveur
sip-ua
authentication username Server-CME password 044B0A151C245E
sip-server ipv4:192.168.10.151
NB : sip-ua : active l’authentification
authentication username Server-CME password passer : Précise le login et le mot de
passe que le CME va utiliser pour se connecter sur le serveur SIP.
sip-server ipv4 : 192.168.10.151 : Precise l’adresse IP du serveur SIP

3) CONFIGURATION D’ASTERISK

 Création de comptes SIP

 Création d’un compte SIP pour le CME

  Plan de numérotation

NB : Inclure le context dic dans le context public.

4) Configuration de cloud1
Nous allons créer une interface TAP que nous allons relier à cloud1. Une interface TAP
est une connexion point à point dédiée entre votre système Linux et une application
(dans notre cas GNS3).

On configure le pare-feu pour accepter les entrées/sorties

5) Démonstration
Nous utilisons Cisco IP Communicator pour se connecter aux utilisateurs CME et Mi-
croSIP pour ceux d’Asterisk

 Appel CME vers Asterisk

 Appel Asterisk vers CME
III) Utilisation des enregistrements SRV et NAPTR
1) Définition SRV
Un enregistrement SRV ou enregistrement de service est une catégorie de données du
DNS d'Internet qui vise à indiquer quels sont les services disponibles.

Ce type d'enregistrement est défini dans la RFC 2782.Les enregistrements SRV sont
souvent utilisés par les clients Microsoft Windows afin de trouver le contrôleur de do-
maine pour un service donné. Par ailleurs, les enregistrements SRV sont communément
utilisés en association avec les protocoles standards ci- dessous :
• XMPP (Jabber)
• SIP
• LDAP
2. Définition NAPTR
Un pointeur d'autorité de nom (NAPTR) est un type d'enregistrement de ressource dans
le système de noms de domaine d'Internet.
Les enregistrements NAPTR sont le plus souvent utilisés pour des applications de té-
léphonie Internet, par exemple, dans le mappage de serveurs et d'adresses d'utilisateur
dans le protocole SIP ( Session Initiation Protocol ). La combinaison d'enregistrements
NAPTR avec des enregistrements de service (SRV) permet l'enchaînement de plusieurs
enregistrements pour former des règles de réécriture complexes qui produisent de nou-
velles étiquettes de domaine ou des identificateurs de ressources uniformes (URI).
Les noms de ressources uniformes (URN) sont un sous-ensemble d'identificateurs de
ressources uniformes (URI) utilisés pour les identificateurs abstraits, tels que le nom
d'une personne ou son numéro de téléphone. Pour que les URN aient un sens, elles
doivent être mappées sur une ressource concrète quelconque. Les URL (Uniform Re-
source Locator) sont souvent utilisées pour décrire de telles ressources, telles qu'un
nom d'hôte d'ordinateur ou un fichier local. L’enregistrement NAPTR facilite la nor-
malisation des URN. Les enregistrements NAPTR mappent entre des ensembles
d'URN, d'URL et de noms de domaine simples et suggèrent aux clients les protocoles
disponibles pour la communication avec la ressource mappée.
3) Objectif
Notre objectif est d’utiliser les enregistrements de type SRV et NAPTR en téléphonie
sur IP pour :
• Faciliter le paramétrage des terminaux SIP;
• Permettre aux terminaux, connaissant simplement le nom de domaine, de faire des
requêtes
SRV pour avoir l’adresse IP du Serveur et pouvoir se connecter ;
• Permet d’interconnecter deux serveurs de téléphonie ;
• Permet de faciliter la saisie des numéros d’appel au niveau des terminaux.
4) Installation de Kamailio et configuration de base
Kamailio (successeur des anciens OpenSER et SER) est un serveur SIP Open Source
publié sous GPL, capable de gérer des milliers de configurations d'appels par seconde.
Kamailio peut être utilisé pour créer de grandes plates-formes pour les communications
VoIP et en temps réel - présence, WebRTC, messagerie instantanée et autres applica-
tions. De plus, il peut être facilement utilisé pour faire évoluer des passerelles SIP vers
PSTN, des systèmes PBX ou des serveurs de médias comme Asterisk, FreeSWITCH
ou SEMS. 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.
Le fichier kamailio.cfg contient les informations principales de configuration de Ka-
mailio. 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émarrer 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 para-
mè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.
4.1) Installation des prérequis et de kamailio

4.2) Configuration de Base de Kamailio

On se rend dans le repertoire /etc/kamailio
 Au niveau du fichier kamctlrc, on décommente les paramètres suivants :
 On installe la base de données kamailio grâce à la commande :

 On peut vérifier que la base données kamailio est créée en faisant :

  Ensuite nous allons créer des utilisateurs kamailio pour effectuer des appels. La
création des utilisateurs se fait par la commande :
# kamctl add XXX password

5) Configuration de DNS, type SRV et NAPTR

Au niveau de notre DNS nous allons configurer deux domaines :
 telecom.sn avec les numéros 1XXX
 inf.sn avec les numéros 2XXX
5.1) Configuration type SRV
Un enregistrement SRV contient les informations suivantes :
 Service: le nom symbolique (commençant généralement par un symbole de
soulignement) du service concerné (par exemple _sip).
  Protocole : généralement, c'est soit _tcp pour TCP, soit _udp pour UDP.
 Nom.de.domaine : le domaine de validité de l'enregistrement (pleinement
qualifié au format FQDN ou local à la zone DNS en cours de définition pour
la même autorité d'origine).
 TTL : champ standard DNS indiquant la durée de validité (Time-To-Live,
durée de vie) de la réponse (en secondes).
 Classe : champ standard DNS indiquant la classe d'adressage (c'est toujours
IN pour Internet).
 Type : l'identifiant du type d'enregistrement DNS (toujours SRV ici pour un
enregistrement de service) ;
 Priorité : la priorité du serveur cible (valeur entière non négative, plus elle est
faible, plus ce serveur sera utilisé s'il est disponible) ;
 Poids : poids relatif pour les enregistrements de même priorité ;
 Port : le numéro de port (TCP ou UDP selon le protocole ci-dessus) où le
service est disponible ;
 Cible : le nom du serveur qui fournit le service concerné (doit être résolu en
adresse IPv4 ou IPv6 par d'autres requêtes DNS sur les enregistrements A ou
AAAA du nom de service cible) avec le protocole et sur le port indiqué.

5.2) Algorithme de mise en place d’un enregistrement de type NAPTR

L’algorithme de mise en place d’un enregistrement de type NAPTR défini les étapes
depuis sa mise en place jusqu’aux tests finaux.

5.3) Déclaration
 Test de fonctionnalité des domaines telecom.sn et inf.sn :
 Test de fonctionnement des configurations SRV avec la commande dig

 telecom.sn
 inf.sn
 Test de fonctionnement des configurations NAPTR avec la commande dig
 telecom.sn
  Test de fonctionnement des configurations NAPTR avec la commande dig
 inf.sn

5.4) Configuration ENUM

a) Chargement du module enum.so
ENUM, est un mécanisme permettant d'utiliser un numéro de téléphone comme clé de
recherche dans le DNS pour trouver la manière de joindre une personne ou une autre
entité.
L'objectif d'ENUM est d'utiliser un numéro unique pour accéder à plusieurs identifiants
de service caractérisant un individu : Grâce au numéro ENUM, on pourra atteindre un
e-mail, une URL, un numéro de téléphone (fax, mobile, SIP), etc. Les priorités d'accès
à ces différents services seront définies par l'utilisateur.
La création d’un numéro ENUM passe par les étapes suivantes :
• numéro initial : 1000
• numéro séparé par des points : 1.0.0.0
• numéro inverse : 0.0.0.1
• on y ajoute enfin le domaine : 0.0.0.1.telecom.sn
Elle se fait au niveau du serveur kamailio, dans le fichier de configuration kamailio.cfg

b) Création de la route
On crée une route qui va faire une requête au niveau de ENUM afin de trouver le
SIP/URI associe à un TEL/URI et transfert d’appel du serveur Kamailio.
Elle se fait au niveau du serveur kamailio, dans le fichier de configuration kamailio.cfg

c) Appel de la route dans le plan de numérotation de Kamailio

Il s’agit de l’appel de la route par un script. Lorsque le numéro de l’appelant se trouvant
pas dans le même domaine que celui de l’appelé, l’appel est redirigé vers les numéros
du domaine de l’appelé.

Ici lorsque les terminaux de telecom ( avec des numéros 1XXX) appelle ceux de inf
(avec des numéros 2XXX), le script redirige l’appel vers le domaine inf.
NB : Au niveau de chaque serveur kamailio il faut préciser dans le paramètre alias le
domaine qu’il gère.
d) Test de connectivité
On va utiliser le logiciel MicroSIP pour effectuer les tests.
On commence par la configuration des paramètres en cochant l’option « DNS SRV »
et en indiquant le «nameserver » qui sera l’adresse du serveur DNS

On peut après procéder à l’ajout du compte

Ainsi l’utilisateur 1000 du domaine telecom.sn est connecté
De même l’utilisateur 2000 du domaine inf.sn va se connecter
Ceci fait on peut observer que la communication passe entre les deux domaines