REPUBLIQUE DU SENEGAL

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR

DIRECTION GENERALE DE L’ENSEIGNEMENT SUPERIEUR

DIRECTION DE L’ENSEIGNEMENT SUPERIEUR PRIVE

ECOLE SUPERIEURE DE TECHNOLOGIE ET DE

MANAGEMENT

(ESTM)

Mise en place d’un enregistrement SRV avec SIP, Le Trunking et Le

protocole ENUM dans Kamailio

Réalisés par :
Hadja Idiatou Diallo
Master 2 en Génie Logiciel Administration Réseau (GLAR)
Amadou Tidiane Diallo
Master 2 Reseaux Télécoms
 Tables des matières
I. Enregistrement SRV avec le protocole SIP

1. Définition
2. Format de l’Enregistrement
3. Objectif
4. Prérequis et Mise en œuvre

II. Le Trunking

1. Objectif

2. Mise en Œuvre

III. Mise en place du protocole ENUM dans Kamailio

1. Introduction et Définition

2. Principe de Création d’Enum

3. Mise en Œuvre
 I. Enregistrement SRV avec le protocole SIP

1. Définition:
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 protocoles récents (par
exemple SIP et XMPP) nécessitent souvent un support des enregistrements SRV par le
client. Par ailleurs, les implémentations côté client de protocoles plus anciens tels
que LDAP, SMTP peuvent également se voir ajouter un support pour les
enregistrements SRV.
2. Format de l’Enregistrement :
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). S'il y a plusieurs
enregistrements à différentes priorités pour le même service et un même protocole,
un seul enregistrement pour chacune des priorités sera retourné aux clients DNS
(les clients sont censés alors tenter de se connecter en priorité au serveur retourné
ayant la plus faible valeur de priorité parmi les enregistrements retournés, mais si
cela échoue, ils peuvent utiliser le serveur suivant de priorité plus élevée dans la
liste de serveurs qui lui sont retournés). Différentes priorités permettent de mettre
en place des services de secours (éventuellement distincts dans leur contenu et plus
limité dans les possibilités, par exemple un ou plusieurs serveurs alternatifs
fonctionnant en lecture seule sans support de certaines modifications par le
service).
• Poids : poids relatif pour les enregistrements de même priorité (valeur entière de 0
à 65535, permet au serveur DNS de retourner aléatoirement un des serveurs cibles
ayant la même priorité, avec une distribution correspondant au poids indiqué,
relativement au poids total des autres enregistrements de même priorité). Le poids
indiqué n'a pas d'effet s'il n'y a qu'un serveur cible de la même priorité pour le
même service et le même protocole (ce paramètre permet une distribution de
charge assez sommaire entre plusieurs serveurs pour les services très fréquentés
 par de nombreux clients effectuant des requêtes DNS séparées, mais il n'aura pas
d'effet si ces clients font leurs requêtes DNS via un même serveur DNS proxy
cache).
• 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é.

3. Objectif
L’objectif de SRV est d’avoir deux serveurs Kamailio avec des noms de domaines
différents mais qui utilisent le même serveur DNS et qu’un utilisateur s’enregistre
au niveau du premier serveur et un autre qui s’enregistre au niveau du deuxième,
ses utilisateurs s’enregistre avec les noms de domaines de leurs serveurs et pour
passer des appels on utilise nomUser@nomDomaine pour passer des appels.

4. Prérequis et Mise en œuvre

Tout d’abord nous devons installer un serveur qui implémente le protocole SIP
(Session Initiation Protocol) sur deux machines (poste1.etudiant.sn et
poste1.professeur.sn), ici nous allons utiliser le serveur Kamailio et le bind9 pour le
serveur de résolution de nom (DNS) (une seule machine).
Installation de Kamailio et bind9 à partir des commandes respective :
apt-get install Kamailio
apt-get install bind9 bind9utils

Configuration de DNS:
Dans poste1.etudiant.sn éditer le fichier /etc/bind/name.conf.default-zones pour la
déclaration des zones etudiant.zone et professeur.zone

Puis on les crée la première zone etudiant.zone en copiant le fichier db.local et on

l’édite
On crée et on édite aussi la zone professeur.sn pour le second domaine

On redémarre le serveur pour que les modifications soient prises en compte

Sur chaque machine on édite le fichier resolv.conf et on met l’adresse IP de la

machine où est installé le serveur DNS pour l’indiquer où se trouve le serveur

Pour tester le DNS, on essaye de faire un ping sur poste1.etudiant.sn

On voit que la résolution avec l’enregistrement de type A marche maintenant vérifions
la présence de l’enregistrement de type SRV sur le domaine

Donc on voit que l’enregistrement de type SRV a été pris en compte et quand un
utilisateur qui est enregistré dans le domaine etudiant.sn envoi une requête au serveur
DNS en utilisant le protocole udp il lui redirige directement sur la machine
poste1.etudiant.sn.
Configuration de Kamailio:
Dans poste1.etudiant.sn on installe le serveur Kamailio

Une fois l’installation terminée on édite le fichier /etc/Kamailio/kamltrc pour

renseigner le nom, les utilisateurs qui ont le droit de lecture et d’écriture sur la base de
données et le nom de domaine où s’enregistre les utilisateurs au niveau du serveur
On utilise la commande kamdbctl create pour créer la base de données avec toutes
ses tables qui viennent par défaut

On se connecte à MySQL pour voir la base de données

Kamailio est le nom de la base de données qui vient d’être créé.

On édite aussi le fichier /etc/kamailio/kamailio.cfg puis on dé commente alias et on
met le nom de domaine du serveur Kamailio

On enregistre le fichier puis on redémarre le serveur kamailio

NB: Pour la machine poste1.professeur.sn on fait les mêmes configurations au niveau

du serveur kamailio mais où on renseigne les noms de domaine on met professeur.sn
à la place de etudiant.sn
Pour tester on crée un utilisateur au niveau de chaque serveur avec la commande
kamctl add user@nomdeDomain password
Au niveau de poste1.etudiant.sn :

Et enfin sur poste1.professeur.sn

Pour les clients on va utiliser le logiciel Microsip, on crée le compte pour les
utilisateurs sur chaque machine.

Dans les paramètres du logiciel on renseigne l’adresse du serveur DNS et on coche la

case DNS SRV puis on sauvegarde

On lance wireshark pour voir ce qui se passe

On voit que quand l’utilisateur 7700 essaye de s’enregistrer avec un nom

domaine il envoie une requête au serveur DNS et lui aussi consulte son enregistrement
de type SRV et regarde quelle est la machine qui gère ce domaine et lui répond en lui
donnant le nom de la machine
Ensuite il essaye de s’authentifier au niveau du serveur Kamailio se trouvant sur cette
machine

Ainsi, voici l’utilisateur 7700 connecté sur le serveur qui gère le domaine etudiant.sn

L’utilisateur 7600 effectue les mêmes procédures pour se connecter au niveau de la

machine qui gère le domaine professeur.sn
NB: L’adresse IP de poste1.etudiant.sn est désormais 192.168.1.163 et celle de
poste1.professeur.sn est 192.168.1.113
 II. Le Trunking
1. Objectif
L’objectif est de faire communiquer des utilisateurs se trouvant sur des serveurs
de téléphonie différents en créant une ou plusieurs route(s) au niveau de chaque
serveur pour effectuer le routage.
2. Mise en œuvre :
Suite aux configurations faites ci-haut, nous allons créer une route dans chacun
de nos serveurs de téléphonie pour router les appels provenant de chaque
serveur.

Interprétation :
Si un utilisateur compose un numéro commençant par 77 On remplace le
Request_URI en ajoutant le domaine de l’utilisateur.
Dans notre cas quand l’utilisateur 7600 qui se trouve sur le serveur gérant le
domaine professeur.sn essaye de joindre l'utilisateur 7700 se trouvant au niveau
du serveur qui gère le domaine etudiant.sn en composant juste son nom
utilisateur(7700) le serveur du domaine professeur.sn associe le nom de
l’utilisateur avec le domaine pour former le Request_URI
 III. Mise en place du protocole ENUM dans Kamailio
1. Introduction et Définition:
Alors qu'une proportion de plus en plus importante des services de voix fixe et
mobile migre sur IP (VoIP, NGN, IMS pour VoLTE, IMS pour VoWiFi),
l'interconnexion avec les réseaux circuit existants fixes et mobiles aujourd'hui et
L’interconnexion avec les autres réseaux de voix sur IP est une préoccupation
essentielle.
Les hypothèses de départ sont :
➢ qu'il existe déjà une infrastructure pour allouer les numéros de téléphone
et que des milliards sont déjà attribués,
➢ que ces numéros sont des clés "naturelles" pour beaucoup de gens.
Dans ce contexte, ENUM, spécifié dans le RFC 6116 et RFC 6117, permet
d'utiliser un numéro de téléphone comme clé de recherche dans le DNS pour
connaître la méthode pour joindre la destination. En effet, ENUM retourne les
URI (Uniform Resource Identifiers) de service de la destination et notamment
l’URI SIP si la destination est un client Voix sur IP. L’URI contient le nom de
domaine VoIP de la destination. Il est alors possible d’obtenir via interrogation
DNS les adresses des nœuds qui représentent les points d’entrée du réseau VoIP
de la destination qui se chargeront de router l'appel à l’appelé. Sans ENUM, il
est toujours possible d’assurer l’interconnexion entre opérateurs Voix sur IP via
le réseau téléphonique commuté. Cependant les nouveaux services IP qui ne
sont pas relatifs à la voix ne pourront pas être acheminés si l’interconnexion IP
et ENUM ne sont pas mis en œuvre (Rich Communication Suite,
Videotéléphonie sur IP, Roaming VoLTE, etc.).
2. Principe de Création d’Enum:
ENUM s'appuie sur le système DDDS ('Dynamic Delegation Discovery
System', RFC 3401) et sur les enregistrements NAPTR du DNS.
Une recherche ENUM par un résolveur ENUM commence par un numéro de
téléphone à la norme UIT E.164, comme +221337000600
Ce numéro est transformé en nom de domaine en l'inversant (comme on fait
pour trouver un nom de domaine à partir d'une adresse IP, ici, cela donnerait
0.0.6.0.0.0.7.3.3.1.2.2.professeur.sn.

3. Mise en Œuvre:
A partir des configurations faites ci-haut nous allons effectuer:
- Un enregistrement de type NAPTR au niveau du serveur DNS sur la zone
etudiant.zone pour faire correspondre le numéro de téléphone à l’URI sip
correspondant

- Et définir la route ENUM au niveau du serveur Kamailio qui a pour

domaine professeur.sn

Interprétation:
Lorsqu’un utilisateur du domaine professeur.sn compose le numéro
+221337000600 le serveur Kamailio interroge le DNS et lui à son tour consulte
la zone etudiant.zone et recherche la résolution de type NAPTR correspondant
au numéro composé et le nom de domaine associé pour retourner l’URI sip de
l’utilisateur.