Projet de Master 1

Mention informatique
Spécialité réseaux

MISE EN PLACE
D’UN SERVICE DE TELEPHONIE SUR IP

Adrien DORLAND
Loïc GAUTIER
Alexis KOVALENKO
Hervé NALLAMOUTOU

Responsables: Guy Pujolle

Laurent Ouakil

Rapporteur: Anne Fladenmuller

> Rapport
J’ai toujours rêvé d’un ordinateur qui soit aussi facile à utiliser qu’un téléphone.
Mon rêve s’est réalisé : je ne sais plus comment utiliser mon téléphone.
[Bjarne Stroustrup - inventeur du C++]
TABLE DES MATIÈRES

Introduction 01

1/ Plan de développement 02

2/ Dossier analyse et conception 04

2.1 Le matériel 04
2.2 Les protocoles 04
2.2.1 H.323 04
2.2.2 SIP 06
2.2.3 IAX 06
2.3 Développement 07
2.3.1 Php 07
2.3.2 Perl 07
2.3.3 AGI 07
2.3.4 Java 07
2.4 Les logiciels 08
2.4.1 Plateforme de travail 08
2.4.2 Asterisk 08
2.4.3 Gatekeeper 09
2.4.4 Clients VoIP 10
2.4.5 OpenLDAP 10
2.4.6 Autres… 11
2.5 Schéma de développement 12

3/ Réalisation du projet 13
3.1 Gatekeeper (Gnugk) 13
3.1.1 Présentation et problématique 13
3.1.2 Installation 14
3.1.3 Configuration 14
3.2 Asterisk 16
3.2.1 Installation 16
3.2.2 Configuration 17
3.3 Interactions 18
3.3.1 Asterisk – Gatekeeper 18
3.3.2. Asterisk – Asterisk 18
3.3.3 Asterisk/Gatekeeper – PBX Hardware 19
3.4 Développement et mise en place de services 20
3.4.1 Obelix 20
3.4.1.1 Présentation 20
3.4.1.2 Réalisation 20
3.4.2 Script d’ajouts d’utilisateurs 21
3.4.3 Programme de monitoring du gatekeeper 21
3.4.4 Annuaire 22
3.4.5 Messagerie vocal 24
3.4.6 Musique d'attente 24
3.4.7 Transfert d'appel 25
3.4.8 Annuaire vocal inversé 25
4/ Etat du projet 27
4.1 Travail accomplit 27
4.2 Avancées par rapport au cahier des charges 27

Conclusion 28

Notes et remerciements 29

Annexes 30

Bibliographie 46
 Depuis de nombreuses années, une partie vitale des locaux d’une entreprise est située
au niveau de son réseau téléphonique. Celui-ci permet la communication des employés
entre eux mais surtout l’ouverture vers le monde extérieur. L’avènement de
l’informatique moderne, des réseaux locaux et d’Internet a bouleversé les modes de
communications intra et extra entreprise. Ainsi on peut désormais trouver des solutions
de téléphonie plus rentable et plus avantageuses que l’ancien réseau téléphonique.

Ce compte rendu présente notre projet de mise en place d’un service de ToIP
(Téléphonie sur IP) dans un réseau d’entreprise. Nous nous proposons de mettre au point
une architecture stable et fonctionnelle de téléphonie utilisant le réseau informatique
d’une entreprise en utilisant la technologie de VoIP. Notre service repose sur plusieurs
composants que nous avons appris à utiliser et à relier entre eux pour avoir un système
fonctionnel utilisable dans n’importe quelle cadre d’entreprise disposant d’un réseau
informatique.

Dans une première partie nous détaillons la liste des taches à accomplir pour la
réalisation du projet. Puis nous poursuivons avec le dossier d’analyse et conception qui
reprend les concepts (matériels, protocoles…) que nous mettons en œuvre. La troisième
partie est consacrée aux détails de réalisation concrète du projet. Enfin nous faisons un
bilan de ce que nous avons accomplis et de ce qu’il nous reste à faire dans la dernière
partie.

1/47
1/
Plan de développement

Première approche
Etude du protocole H.323 (Recherche de Documentation) (1 semaine)
Etude comparative des Serveurs existants (1 semaine)
Choix du PBX software
Etudes des différents Clients (1 semaine)
Choix d’un client polyvalent et complet
Mise en place d’un wiki (Site Internet destiné à rassembler nos travaux)
Rédaction du cahier des charges (1 semaine)

Gatekeeper
Documentation sur le rôle du gatekeeper H.323 (1 semaine, 2 personnes)
Etude comparative des gatekeeper H.323 (1 semaine, 2 personnes)
Choix d’un gatekeeper
Installation, Configuration (3 semaines, 2 personnes)
Rédaction de tutoriaux (1 semaine, 1 personne)
Mise en place d’un environnement autour du gatekeeper
Développement d’une interface Web/PHP de configuration (3 semaine, 1 personne)
Rédaction d’un tutorial d’utilisation (1 semaine, 1 personne)
Mise en place d’un annuaire Web/Perl (3 semaines, 1 personne)
Mise en place d’un script d’ajout d’utilisateurs
et interaction avec une base LDAP (3 semaines, 1 personne)
Test de communications VoIP dans un réseau de plusieurs machines et utilisation des scripts
réalisés.

Asterisk
Recherche de Documentation (1 semaines, 2 personnes)
Installation et familiarisation (2 semaine, 2 personnes)
Contact avec la communauté Asterisk (forum et Channel IRC)
Prise en main de la Configuration (utilisation d’un GUI)
Test d’utilisations (1 semaine, 2 personnes)
Ecriture d’un tutorial d’installation (1 semaine, 1 personne)
Ecriture d’un tutorial de configuration (1 semaine, 1 personne)
Mise en place d’une architecture de configuration avec fichier unique
Création d’une interface de configuration Web PHP (2 semaines, 1 personnes)
Création d’un script de mise à jour des fichiers des configurations (2 semaines, 2 personnes)
Recherche de documentation pour interaction Asterisk / gatekeeper (2 semaine, 4 personnes)
Configuration d’Asterisk pour interagir avec un gatekeeper (2 semaines, 2 personnes)
Ecriture de documentation / Tutorial pour l’interaction (1 semaine, 2 personnes)
Recherche de Documentation sur interaction Asterisk/Asterisk
Configuration et Test d’une telle interaction (2 semaines, 2 personnes)
Recherche d’information sur interaction Asterisk/PBX hardware (1 semaine, 4 personnes)
Etude des services de téléphonies couramment fournis
Implémentation de certains services sur Asterisk (2 semaines, 4 personnes)
Utilisation des services dans un environnement stable

2/47
Calendrier de répartition des taches :
Semaine 1 :
Tous - Etude des protocoles de VoIP/ToIP et des différents serveurs et gatekeepers

Semaine 2, 3, 4 :
Tous - Installation de H323, du gatekeeper, et prise en main de la configuration

Semaine 5, 6 :
Adrien – développement de l’interface web et rédaction de tutoriaux
Hervé – développement d’un script d’ajouts d’utilisateur
Alexis – développement d'un script de génération d’un annuaire web
Loïc – Mise en place de fichier de configurations plus élaborées

Semaine 7 :
Loïc, Hervé – Documentation sur le serveur Asterisk

Semaine 8, 9 :
Adrien, Alexis – Installation et configuration

Semaine 10, 11 :
Adrien – Création d’une interface Web et rédaction de tutoriaux
Alexis – Réalisation d’un script perl de mise à jours des fichiers de configuration
Loïc, Hervé – Tests de communications SIP et maîtrise de la configuration.

Semaine 12,13 :
Tous – Recherche de documentation sur les interactions
Tous – Mise en places des interactions

Semaine 14,15 :
Hervé : développement programme de monitoring du gatekeeper
Loïc : documentation et mise en place sur le transfert d'appel
Alexis : développement du script d'annuaire vocal inversé
Adrien : documentation et mise en place du service de messagerie et de musique d'attente

3/47
2/
Dossier analyse et conception

2.1 Le matériel
Notre projet de mise en place d’un service de téléphonie sur IP dans un réseau informatique
d’entreprise, nous amène à travailler avec différents équipements informatiques et téléphoniques.
Notre travail s’effectue principalement sur des machines de type PC x86. Ce sont les machines
auxquels nous avons le plus facilement accès et elles sont donc privilégiées de fait dans
l’élaboration du projet. Elles nous servent pour l’utilisation des différents logiciels que nous
utilisons ainsi que pour tout notre travail de développement. Toutefois nous n’excluons pas la
portabilité et essayons au mieux de mettre au point un service pouvant être mis en place sur
d’autres plates-formes tels que PowerPC, SPARC ou autres.
Pour relier les différentes machines de notre réseau de test nous avons utilisé un routeur
mixte Ethernet/wifi. Nous avons ainsi mis en place un réseau de test avec le serveur relié par câble
Ethernet au routeur et les clients en wifi.
Enfin un dernier type de composant que nous serons peut être amenés à utiliser est l’interface
PC/ réseau RTC. Cette interface est disponible sous la forme de carte PCI de type Zaptel (ex :
Generic X100P) qui permet de relier un PBX software (Asterisk) au réseau RTC.
Toutefois notre service ne se limite pas à un réseau informatique et nous mettons en place une
interaction avec un composant essentiel de téléphonie : le PBX-IP hardware. Ces PBX de dernière
génération nous permettent d’ouvrir notre service de VoIP au réseau téléphonique local de
l’entreprise ainsi qu’au réseau RTC. De cette manière, l’intégration des lignes VoIP dans le réseau
téléphonique de l’entreprise est complète.

2.2 Les protocoles

2.2.1 H.323

Le protocole H.323, défini par l’ITU, est un protocole de signalisation. Il est aujourd’hui le plus
utilisé sur les réseaux de téléphonie IP.
Il définit les mécanismes nécessaires au transport des conversations téléphoniques sur un réseau
utilisant des paquets.
Le standard H.323 fournit une base pour la communication utilisant de l’audio, de la vidéo, et
des données à travers les réseaux IP. En se conformant au standard H.323, les produits et les
applications multimédias des multiples distributeurs peuvent inter-opérer, permettant aux
utilisateurs de communiquer sans se soucier de la comptabilité entre elles.
Les recommandations du standard H.323 recouvrent les besoins techniques pour les services
de communications audio et vidéo, dans les LANs qui ne fournissent pas de Qualité de Service.

4/47
H.323 définit 4 composants majeurs pour la mise en place d'un système de communication :

Figure 1 : Eléments constituants d’un réseau H.323

Le Terminal : il représente le client final sur le LAN qui fournit des communications temps
réels à deux voies. Il existe deux possibilités pour l’utilisateur, soit l’achat d’un système matériel de
visioconférence H.323, ce sont des équipements relativement coûteux mais qui permettent une
utilisation de qualité professionnelle. Ce genre d’équipement est surtout utilisé dans des salles de
conférence. Soit, l’utilisateur peut transformer son poste de travail en terminal H.323 grâce à des
logiciels, que nous détaillerons par la suite. Lors d’une communication point à point entre deux
interlocuteurs, sans services particuliers, les utilisateurs peuvent communiquer entre eux
directement par l’intermédiaire de leurs adresses IP en utilisant les terminaux H.323. En revanche,
dans toutes les autres situations, il est nécessaire d’utiliser d’autres éléments (GateKeeper, MCU,
Gateway).

Le Gateway : il est un élément optionnel pour de la conférence H.323. Les passerelles

fournissent une multitude de services, que nous mettrons en place dans la suite du projet, le plus
habituel est de permettre une communication entre différents types de réseaux multimédias
autres que H.323 (comme illustré dans la figure 1)
Le gatekeeper : il représente le composant le plus important d’un réseau H.323. Il agit comme le
point central pour tous les appels dans sa zone et pourvoit au service de contrôle dans les
enregistrements des points finaux (endpoints). De beaucoup de manière, un gatekeeper H.323 agit
comme un commutateur virtuel.

Multipoint Control Unit : Il s’agit d’un service applicatif de ponts multipoints qui se charge de
rediffuser la vidéo et l’audio à tous les participants de la visioconférence. C’est un élément
indispensable dans le système H.323 pour une communication supérieur à deux interlocuteurs
interactifs. Le MCU étant un service, nous pouvons le trouver dans chacun des différents éléments
qui composent H.323 (Terminal, GateKeeper, Gateway)

5/47
 2.2.2 SIP

Session Initiation Protocol (SIP) est un protocole multimédia défini par l’IETF (Internet
Engeeneering Task Force) supportant la voix, la vidéo, les messageries instantanées, le partage de
fichiers et un nombre croissant d’autres applications. Il assure en particulier des connexions
nomades, en toute indépendance du lieu où l’on se trouve. Ce protocole de signalisation de
niveau applicatif vient du monde d'Internet, et non de celui de la téléphonie et de l'UIT, d’où est
issu H.323. Il établit, modifie et termine des sessions multimédias interactives sur IP entre des
terminaux.

La raison pour laquelle ce protocole intervient dans notre projet est que SIP représente un très
sérieux concurrent au protocole H.323. Comme notre but est la mise en place de la téléphonie IP,
Il était inconcevable de ne pas les comparer.
Le protocole SIP propose une architecture décentralisée permettant à deux téléphones IP de
dialoguer sans intermédiaire. Lorsqu'un téléphone SIP se connecte au réseau IP, il signale sa
présence à une passerelle spécifique (proxy SIP) installée dans l'entreprise ou chez un prestataire
externe. Cette passerelle n'a pas pour objet de régir les communications, elle se contente
seulement de recenser les équipements SIP disponibles. Le proxy dialogue avec un serveur DNS
pour assurer la correspondance entre le nom de domaine de l'équipement et une adresse IP. Le
téléphone appelant interroge son proxy pour localiser le téléphone destinataire (son adresse IP) et,
s'il est disponible, engage le dialogue. Les deux téléphones disposent alors de toutes les
informations nécessaires pour établir une communication directe, sans passer par un serveur
central qui régirait la connexion.
A l'origine, SIP est conçu pour gérer des conférences téléphoniques sur des réseaux IP.
Contrairement à H.323, qui fait partie des protocoles les plus utilisés, SIP ne prend pas en charge
le transport de la voix et souffre du manque de fonctions de téléphonie classique, qui ne sont pas
encore définies. D'une manière générale, SIP manque encore de nombreux éléments de services
actuellement utilisés dans les réseaux téléphoniques ainsi que dans les PBX d'entreprise pour
prétendre remplacer le protocole H.323, qui a les faveurs de l'industrie. C’est pour cette raison que
nous avons besoin d’un protocole capable de mettre en place de nouveaux services de téléphonie
et de réaliser une interaction avec un PBX-IP hardware, comme le protocole H.323.

En revanche, SIP est plus simple et garantit des implémentations réellement standard. Sans
aucun doute qu’il vise à devenir le standard des télécommunications multimédia (son, image,
etc…).

2.2.3 IAX

Inter-Asterisk EXchange protocol est un protocole utilisé par les serveurs PBX open source
Asterisk et les clients qui leurs sont associés.
Grâce à ce protocole, Asterisk permet de déployer des passerelles d’interconnexion vers la
téléphonie classique ainsi que vers d’autres protocoles de téléphonie sur IP.
IAX est un protocole robuste, riche de services qui permettent la connexion entre deux
serveurs Asterisk ou entre un client et serveur. IAX est compatible avec n’importe quel type de flux
de données dont la vidéo mais est particulièrement utile pour la voix sur IP.
L’intérêt porté à ce protocole est justifié par l’interaction du logiciel Asterisk avec un PBX-IP
hardware puisque nous avons décidé qu’il était préférable dans un premier temps de faire
interagir deux serveurs Asterisk avant de s’attaquer à cette tache beaucoup plus compliquée.

6/47
 2.3 Développement
2.3.1 PHP

PHP est un langage de scripts Open Source, spécialement conçu pour le développement
d'applications web. Il peut être intégré facilement au HTML. Le grand avantage de PHP est qu'il est
extrêmement simple, mais offre des fonctionnalités avancées notamment en ce qui concerne les
entrées sorties, mais aussi une grande facilité dans la manipulation des fichiers. Il est utilisable sur
la majorité des systèmes d'exploitation, comme Linux, Microsoft Windows, Mac OS X, RISC OS et
d'autres encore. PHP est également supporté par la plupart des serveurs web actuels notamment
Apache et Microsoft Internet Information Server.
PHP s’est très vite imposé à nous, du fait de sa simplicité et connaissant sa puissance et sa
simplicité à réaliser une interface graphique web.
La réalisation d’une interface par le biais d’un site web entièrement dynamique semble être
un bon choix. De plus php étant le langage de programmation web le mieux maîtrisé par
l’ensemble du groupe, il semblait inévitable de l'utiliser.

2.3.2 Perl

Dans le cadre de ce projet, plusieurs scripts sont nécessaires à la mise en place de notre
architecture. Comme de nombreux administrateurs, notre choix s’est porté sur le langage Perl
pour les développer. Ce langage nous a semblé très adapté pour plusieurs raisons. La première est
que Perl est un puissant outil de manipulation de fichiers, notamment par sa gestion des
entrées/sorties et des « expressions régulières ». C’est donc un outil indispensable pour travailler
sur les fichiers de configuration comme nous le faisons. D’autre part, c’est un langage très adapté
à l’écriture de script CGI, grâce à son module CGI, et utilisé conjointement avec le module
Net::LDAP pour la gestion de base LDAP, nous avons à notre disposition des outils simples et
performants pour réaliser notre annuaire. Et ce même module Net::LDAP va nous permettre de
réaliser le script d’importation des couples login/pass depuis une base de l’entreprise vers le
système d’authentification de notre gatekeeper. Le module AGI est aussi un élément important
dans la réalisation de notre projet. On peut ainsi développer facilement des scripts communiquant
avec Asterisk via l'interface AGI et ainsi proposer des services interactifs intéressant comme
l'annuaire inversé vocal interactif présenté plus loin.
Enfin pour terminer, il faut préciser que Perl est portable vers de nombreuses plates-formes et
nous permet donc d’envisager de mettre en place notre architecture sans restrictions au niveau
du matériel disponible dans l’entreprise.

2.3.3 AGI

AGI (Asterisk Gateway Interface) est une interface de programmation permettant à des
programmes d'interagir directement avec Asterisk. La communication se fait par l'envoi de
commandes sur les entrée/sortie standards du programme, qui vont être ensuite exécutées par
Asterisk. On pourra ainsi mettre en place un dialplan dynamique par exemple et toutes sortes
d'autres services.

2.3.4 Java

Java, langage orienté objet, nous permet de développer une applet, que l’on pourra intégrer à
un environnement HTML. En effet, les nombreuses classes mises à notre disposition nous
permettent de faire de faire une interface graphique (via Awt) et d’établir des communications
TCP (Socket,etc...) sur notre Gatekeeper.

7/47
 2.4 Les logiciels
2.4.1 Plateforme de travail

Nous utilisons une plate-forme Unix de type linux pour notre serveur de voix sur IP. Plusieurs
distributions se sont proposées à nous, néanmoins notre choix s’est finalement tourné vers la
Debian. C’est une distribution avec laquelle nous sommes très familier et qui dispose d’un
système de paquetage très riche.

D’un autre coté, les utilisateurs de notre réseau de voix sur IP ne seront pas forcément des
utilisateurs de linux c’est pourquoi les clients sont installés à la fois sur des stations de travail
Windows et des postes linux. Nous prévoyons aussi des tests avec des terminaux mobiles de type
Pocket PC.

2.4.2 Asterisk

Asterisk est ce que l’on peut appeler un PBX Software (private branch exchange), et sert donc
de central téléphonique mais implanté en tant que logiciel au sein d’un ordinateur.
Durant nos recherches préliminaires nous avons recueillis des informations sur différents
logiciels proposant les mêmes types de services, tel que Vocal et SIP-x. SIP-x étant orienté
uniquement pour fonctionner avec le protocole SIP il a été vite écarté.
Quand à Vocal il nous a paru réellement moins documenté et moins mis a jour qu’Asterisk,
qui en plus possède un très bon support et une communauté active de gens l’utilisant (Forum,
Channel IRC…). (Voir schéma comparatif)

Asterisk Vocal SIP-X

Support H.323 Oui Pas natif Non
Support SIP Oui Oui Oui
Derrière Maj. Fev 2005 Avril 2003 Fev 2005
Forum Oui Non Non
Chan IRC Oui Non Non
Documentation +++ ++ +
Mailing Liste Oui Oui Oui
Sécurité +++ ++ ++
Open Source Oui Oui Oui
Compatibilité
++++ ++ ++
avec le matériel

Figure 2 : Tableau Comparatif des PBX software.

Asterisk correspond très bien à nos besoins, il intègre les protocole H.323 et SIP. Après de
nombreuses recherches, il semble clairement afficher une compatibilité avec bon nombres de
matériels hardware de téléphonie (carte de téléphonies RTC…), mais aussi une compatibilité
certaine à s’interfacer avec d’autre PBX-IP Software et Hardware (utilisation protocole IAX vu
précédemment), qui est un point important de notre projet.
Toujours dans le cadre de notre projet, Asterisk peut intégrer un bon nombre de services
supplémentaires couramment utilisés dans le monde de la téléphonie et ainsi mettre en place un
réseau de communication stable et compétitif.

8/47
 Néanmoins contrairement à son utilisation dans le cadre du protocole SIP, Asterisk ne
s’occupe pas de la translation d’adresse des utilisateurs utilisant le protocole H.323, il est donc
nécessaire d’utiliser un gatekeeper H.323 qui jouera ce rôle.

2.4.3 Le gatekeeper

Comme nous venons de le voir, si Asterisk gère très bien l’authentification et la translation
d’adresse réseaux pour les utilisateurs SIP, il n’en est rien pour les utilisateurs H.323.
En effet Asterisk ne joue pas ce rôle là pour le protocole H.323. Il semble donc inévitable
d’utiliser un logiciel qui soit dans un premier temps capable de faire cette authentification et cette
translation d’adresse (Schéma ci dessous), mais aussi qui soit capable de s’interfacer avec Asterisk,
notre PBX qui reste quand même le pivot central de notre réseau de téléphonie IP.

Apres quelques recherches sur les différents gatekeepers existants, Gnugk a été très vite adopté
au profit d’autres gatekeepers beaucoup moins utilisés et documentés.

Gnugk est un projet open source implémentant le protocole H.323. Le gatekeeper offre un
contrôle des appels, et est une architecture indispensable dans un réseau de téléphonie H.323.
Gnugk offre différents services tels que : la translation d’adresse réseaux pour les
communications, mais aussi le contrôle d’accès des utilisateurs, le contrôle de bande passante, et
les différentes autorisations allouées tant aux utilisateur qu’aux appels passés, en d’autres termes,
tout ce qui nous manque dans Asterisk pour faire de la téléphonie sur IP en H.323.

Figure 3 : Schéma de translation d’adresse lors d’une procédure d’appel

9/47
 2.4.4 Les Clients VoIP

La finalité de notre projet est de faire communiquer des clients entre eux. Pour se faire, il
nous est indispensable de choisir un client adapté à notre travail et à nos besoins, c’est-à-dire un
client supportant l’utilisation de H.323 et donc la possibilité de se connecter à un gatekeeper.
Les recherches sur les clients soft phones nous ont amené à étudier plusieurs logiciels parmi
eux, SjPhone, X-Lite, Openphone, Gnome-meeting et Kphone.
Parmi ces clients, notre choix s’est tourné vers Sjphone, qui est pour nous le client le plus
adapté à notre utilisation, il est facile à utiliser et très bien documenté (cf figure 4). Sjphone est un
Client VoIP gratuit qui supporte les protocoles H.323 et SIP, il permet de se connecter à des
serveurs VoIP en utilisant au choix l’un de ces deux protocoles. Il intègre en plus beaucoup de
fonctionnalités comme la connexion à un annuaire, le paramétrage des informations
personnelles, ou encore la configuration de nombreuses options sonores.

Gnome
SJPhone X-Lite OpenPhone Kphone
Meeting
Support H.323 Oui Non Oui Non Oui
Support SIP Oui Oui Non Oui Non
Derrière Maj. Mars 2005 Mai 2004 Mars 2003 Dec 2004 Mar 2005
Forum Oui Oui Oui Non Oui
Chat IRC Non Non Non Non Oui
Documentation ++ ++ ++ + ++
Mailing Liste Oui Oui Oui Non Oui
O.S. Windows Windows Win/Linux Linux Linux
Open Source Non Non Oui Oui Oui
Options/config Complet Complet Moyen Moyen Complet

Figure 4 : Tableau comparatif des clients disponible sous Windows.

2.4.5 OpenLDAP

Le protocole LDAP (Lightweight Directory Access Protocol, protocole d'accès aux annuaires
allégé) est une norme ouverte proposée pour les services d'annuaires globaux ou locaux sur réseau
et/ou Internet. Dans ce sens, un annuaire a beaucoup en commun avec un annuaire
téléphonique. Si le protocole LDAP peut traiter d'autres informations, il est actuellement
essentiellement utilisé pour associer des noms à des numéros de téléphone et des adresses
électroniques. Les répertoires sont conçus pour prendre en charge un volume important de
requêtes, tandis que les données qu'ils contiennent ne sont pas sujettes à de fréquentes
modifications.
Une importante partie de notre architecture repose sur la présence d’un serveur de stockage
d’informations sur les utilisateurs de notre service. Les solutions qui s’offrent à nous sont LDAP,
NIS ou une base de données de type SQL. Notre projet se cadrant plus dans une optique
d’architecture d’entreprise, nous avons choisit d’utiliser LDAP comme service d’annuaire. En effet,
il n’est pas rare de trouver dans une quelconque entreprise, une base LDAP regroupant tous les
informations des différents utilisateurs du parc informatique. Nous avons écarté NIS car bien que
correspondant à ce même type de service, est une technologie propriétaire, et nous avons décidé
de privilégier l’open source. Nous nous servirons donc des informations récupérées de la base
LDAP afin de constituer notre annuaire de personne joignable.
Il existe différents serveurs implémentant un serveur de base LDAP. On peut citer par exemple
OpenLDAP, Sun ONE Directory Server, Active Directory de Microsoft ou encore l’Active Directory
d’Apple.

10/47
 Notre choix s’est tourné tout de suite vers OpenLDAP par la simple raison que c’est le seul qui
soit libre et distribué sous licence GPL. Il présente aussi un certains nombres de points forts par
rapport à ses concurrents commerciaux : il respecte parfaitement la norme LDAPv3 telle qu’elle
est écrite dans les RFC, il est disponible sur différentes plateformes.
LDAP est le protocole d'annuaire sur TCP/IP. Les annuaires permettent de partager des bases
d'informations sur le réseau interne ou externe. Ces bases peuvent contenir toute sorte
d'informations que ce soit des coordonnées de personnes ou des données systèmes.
Dans notre cas d’étude la base LDAP servira à récupérer les informations des personnes en
ligne sur notre réseau VoIP et à avoir une entrée dans la base LDAP.

2.4.6 Autres…

Lors de la réalisation de nos travaux, nous nous sommes servis de logiciels additionnels tel que
Apache, serveur web le plus répandu, accompagné de son module php pour tester notre interface
de configuration Web/PHP.

11/47
 2.5 Schéma de développement du projet
Après avoir analysé toutes les taches que ce projet nous amène à réaliser, nous avons établis
que l’architecture finale de notre projet serait celle présentée dans le schéma ci-dessous (cf fig. 5).

Figure 5 : Architecture finale du projet

12/47
3/
Réalisation du projet
3.1 Gatekeeper (Gnugk)
3.1.1 Présentation et problématique

Dans un premier temps, nous nous sommes penchés sur les services qu’Asterisk fournit, afin
d’essayer de gérer les communication H.323. Cependant au moment de la configuration, un
problème est survenu. En effet, Asterisk requiert que l’on saisisse dans les fichiers de configuration
l’adresse IP des clients. Or, il n’est pas rare d’avoir un réseau dont les adresses IP sont fournis par
un serveur DHCP, et donc un même client peut obtenir des adresses différentes. Comme vu
précédemment, le gatekeeper est le point essentiel de notre architecture dans ce projet, de plus il
permet de remédier au problème exposé précédemment. En effet, il agit comme un
commutateur virtuel et permet d’établir aisément une communication entre deux terminaux. Il
effectue aussi de nombreuses vérifications sont (enregistrement des clients, état du client, etc…).

Figure 6 : Echange lors d’une communication H.323 avec un gatekeeper

13/47
 Avec la figure ci-dessus, on considère donc le cas d’une communication H.323 avec un
gatekeeper, nous allons détailler les étapes lors d’une communication :

> À l'ouverture du logiciel, le client A s'enregistre auprès du gatekeeper en lui transmettant son ID
H.323 et son adresse IP (Contrôle d’accès).
> Le client B fait de même.
> Le client A entre l'ID de connexion du client B dans le champ du logiciel réservé à cet effet.
> Le logiciel du client A demande l'autorisation au gatekeeper pour se connecter au client B.
> Si le gatekeeper accepte, celui-ci demande au client B son état (déjà en conversation ou non).
> Si l’état est compatible, le gatekeeper transmet l'adresse IP du client B au client A.
> Le gatekeeper informe le client B qu'une communication va avoir lieu avec le client A.
> Le client A entre directement en négociation avec le client B avec les protocoles de contrôle de
communication.
> Le client A énumère ses possibilités de codecs audio et vidéo (si disponibles).
> L'appelé énumère les codecs compatibles à l'appelant pour accord.
> Si accord, d'autres ports TCP et UDP sont négociés pour l'audio (UDP), la vidéo (UDP) et les
données (TCP).
> Tous les flux sont ensuite transmis indépendamment les uns des autres sans passer par le
gatekeeper mais directement entre les clients.
> À la fermeture d'une session, le gatekeeper est informé de la fin de connexion, les ports sont
libérés et les transmissions de contrôle sont stoppées.

Le gatekeeper permet entre autre :

• la translation des Alias vers des adresses de transport.
• le contrôle d’accès, c’est-à-dire l’autorisation des accès aux LAN en utilisant des messages
requêtes
• la gestion de la zone H.323 : il fournit les fonctions décrites aux MCU et Gateway
• autorisation d’appel : il peut rejeter un appel provenant d’un terminal basé sur les
spécifications Q.931
• gestion d’une liste d’appel, etc…

Il fournit une interopérabilité de périphérique vers périphérique, d’application vers application,

de distributeur vers distributeur entre des LANs intégrant un autre protocole de signalisation.
Cependant, la présence d’un gatekeeper n’est pas obligatoire dans un système H.323. Par
contre, si un gatekeeper est présent, les terminaux sont obligés d’utiliser les services offerts par
celui-ci.

3.1.2 Installation

Nous avons donc choisit d’utiliser Gnugk, pour jouer le rôle de gatekeeper. L’installation est
assez facile, elle nécessite deux librairies afin de pouvoir utiliser le protocole h.323. Un guide
d’installation est disponible en annexe (Annexe 1). Après installation, la gatekeeper peut être
lancée sans aucune configuration et fonctionner avec des paramètres par défauts.

3.1.3 Configuration

La configuration du serveur fournissant le service de gatekeeper, est vraiment simple

comparée à d’autres services qui nécessitent plusieurs fichiers de configuration. En effet le
gatekeeper centralise toutes ces options dans un fichier unique de configuration.

14/47
 Un fichier standard de configuration est de la forme suivante :

[NomDeSection1]
Option_1 = Valeur_1
Option_2 = Valeur_2
[NomDeSection2]
Option_i = Valeur_i
Option_x = Valeur_x…

Le gatekeeper offre un grand panel de configurations possibles, nous allons détailler les
principales options qui nous serviront par la suite.
La première section à apparaître dans un fichier de configuration est [gatekeeper ::Main] dans
laquelle on peut configurer les options suivantes:
• Name = GKId ; Nom du gatekeeper
• Fourtytwo = 42 ; afin de vérifier la présence d’un fichier de configuration
• TimeToLive = N ; Durée en secondes max pendant lequel un client peut rester en
inactivité avant que le gatekeeper ne lui renvoie une demande de ré-enregistrement
• StatusPort = N°port ; pour le monitoring du gatekeeper
• StatusTraceLevel = 2 ; pour avoir un niveau 2 pour tracer l’arrivée de nouveaux clients

Une autre section importante est [GkStatus ::Auth], qui permet de définir avec ou non des
expressions régulières, les adresses IP autorisées à se connecter sur le port de monitoring
(StatusPort) :
• Default = allow ; si c’est la seule ligne de cette option alors n’importe quelle machine
peut se connecter au status port du gatekeeper
• Rule = explicit
• w.x.y.z = allow
• default = forbid ; on n’autorise que la machine dont l’adresse est w.x.y.z à se connecter
sur le port de monitoring de Gnugk

Grâce à la section [gatekeeper ::Auth], nous allons pouvoir filtrer les clients , leur permettre
certaines actions ou d’autres. Dans un premier temps, on définit le type d’authentification requis :
• SimplePasswordAuth, associe un client à un mot de passe et un UserId, qui ont
préalablement été encryptés dans le fichier de configuration à l’aide du module
addpasswd
• SLPasswordAuth, authentifie un client à l’aide d’un login et password enregistrés dans
la base SQL.
• Un bon nombre d’autres types d’authentification sont disponibles.

Donc dans la section [gatekeeper ::Auth], on spécifie les types d’authentification et pour quels
types d’action, ceux-ci sont effectués.
Par exemple, on configure le module SimplePassword comme règle optionnelle pour vérifier si
le client est autorisé à faire des requêtes d’enregistrement (RRQ), et les requêtes d’admissions
d’appel (ARQ). Si les requêtes d’enregistrement (RRQ), vérifiées par le module
SimplePasswordAuth, n’ont pas réussi. C’est le module AliasAuth qui s’en chargera, si cette
dernière vérification échoue, un message d’erreur sera envoyé au client.

[gatekeeper ::Auth]
SimplePasswordAuth=optional;RRQ,ARQ
AliasAuth=required;RRQ

15/47
 Après avoir choisit, les modules d’authentification, on crée des sections dédiées à ces modules
afin de définir les comptes autorisés à faire ou pas certaines actions. Prenons l’exemple de notre
gatekeeper, dans lequel nous avons choisit d’utiliser le module SimplePasswordAuth, pour vérifier
les requêtes d’enregistrement :

[gatekeeper ::Auth]
SimplePasswordAuth=required;RRQ,ARQ

[SimplePasswordAuth]
;UserIds et mots de passe cryptés grâce à la commande addpasswd
1010=03APuuRLg6Q=
2020=X0fCt921uiY=
3030=JxPjm/y+m5o=

La dernière section, que nous utiliserons, est [RoutedMode]. Cette section définit les options
du mode de routage du gatekeeper :
• GKRouted = 1 ; le gatekeeper route les données de contrôle H245 entre les clients
• H245Routed = 0 ; Gnugk ne route pas les données logique H245 (audio, vidéo) entre les
clients
• CallSignalPort = 0 ; par défaut le port de signalement d’appel est le 1721
• CallSignalHandlerNumber = 1 ; nombre de processus de traitement d’appels (à augmenter
en cas de zone H.323 chargée)
• AcceptUnregisteredCalls=1 ; accepter tous les appels

Toutes ces options de paramétrages peuvent paraître compliquées, c’est la raison pour
laquelle, nous avons développé une interface permettant de paramétrer le gatekeeper sans avoir à
éditer manuellement le fichier de configuration.

3.2 Asterisk
3.2.1 Installation

L’installation du logiciel Asterisk n’est pas très compliquée. On a besoin des sources d’Asterisk
et de deux bibliothèques, pwlib et OpenH323 (cf Annexe 2).
Il est important de signaler que le protocole H.323 n'est pas pris en charge par Asterisk juste
après l'installation. C’est à ce moment très précis qu’interviennent les librairies pwlib et
OpenH323.
Ceci était donc un premier problème que nous devions mettre en évidence.
La deuxième difficulté est intervenue lors de la compilation de pwlib et de OpenH323. Leurs
compilations doivent s’effectuer sans erreur sinon l’utilisation des channels, qui jouent un rôle
très important dans une communication entre deux clients, du protocole H.323 est impossible.
Une fois ces problèmes surmontés, une trentaine de fichiers de configuration doivent être
présent dans le répertoire /etc/Asterisk/, dont les fichiers suivants:

modem.conf agents.conf extensions.conf modules.conf

SIP.conf H.323.conf alsa.conf Asterisk.conf

Seulement quelques un de ces fichiers seront exploités au cours de notre projet.

16/47
 3.2.2 Configuration

La configuration du logiciel Asterisk pour pouvoir établir une communication passe par trois
étapes :
• Configurer les channels dans le fichier channels.conf avec une configuration
particulière pour chaque channels (par exemple h323.conf pour le chan_h323)
• Mettre en place le dialplan dans le fichier extensions.conf
• Configurer les modules dans le fichier modules.conf

Le rôle d’un channel est très simple. Son but est de raccorder les différents canaux de
transmission et de signalisation utilisés par Asterisk pour relier ou créer des appels. Ils peuvent être
physiques comme un port analogue FXO ou logiciel comme un channel AIX. Ces liaisons sont
définies dans le dialplan. Le logiciel met en valeur toute son importance à ce niveau puisqu’il
permet de traiter n’importe quel type de channel de la même manière. Il suffit juste de modifier
le fichier de configuration associé au channel.
Par exemple si on souhaite rajouter un client SIP, il faut le rajouter dans le fichier SIP.conf.
Pour rajouter un client H.323, on modifie le fichier h323.conf. Néanmoins, Asterisk ne joue pas le
rôle de gatekeeper pour le protocole H.323. Nous avons alors besoin de déterminer quels sont les
channels à utiliser avant de configurer le fichier du dialplan.

Le dialplan représente le cœur du système d’Asterisk car il définit comment le logiciel doit
traiter les appels. Il se compose d’une liste d’instructions ou d’étapes que le logiciel doit suivre et
déclenchés par des chiffres ou des caractères. Le dialplan se configure par la modification du
fichier extension.conf qui est partagé en quatre parties contexts, extensions, priorités, et
applications.
Dans le dialplan, le context joue un rôle d’organisation. Pour expliquer plus précisément, le
context permet de gérer différentes façon un appel pour un channel donné. Par exemple, ils
peuvent être utilisés pour créer un système simple de menu où si un client SIP choisi la touche «
1 » le logiciel Asterisk exécute une application différente par rapport à un client H.323 choisirait la
touche « 1 ». Il faut mettre en évidence aussi qu’il existe toujours un context par défaut.

Une extension est une chaîne de caractère qui permet de déclencher un événement à
l’intérieur d’un context. Ces événements peuvent être complétés par une priorité qui permet de
leurs donner un ordre préférentiel.
Les applications permettent des actions comme de jouer des sons quand un client est en
attente, etc… Par exemple l’application Answer () est utiliser pour répondre à une
communication entrante et l’application playback () permet de jouer un son enregistré.

Il ne reste plus qu’à définir les modules que le logiciel Asterisk doit charger au démarrage en
configurant le fichier modules.conf. Par exemple, si on souhaite charger le module OSS pour
avoir le son on ajoute dans ce fichier la ligne
load => chan_oss.so ou charger le module load => chan_modem.so car il permet d'utiliser la
console d'Asterisk comme un client SIP/H.323.

Puis on a besoin de configurer le fichier Asterisk.conf pour indiquer les chemins des différents
composants d'Asterisk (les sons, channels, les scripts, etc...).

Le serveur Asterisk nécessite donc un certains nombres de fichier de configurations pour

pouvoir fonctionner selon les besoins de l’administrateur. Nous avons donc décidé de réaliser une
interface pour modifier ces fichiers de manière centralisée.

17/47
 3.3 Interactions
3.3.1 Asterisk ---- Gatekeeper

Figure 7 : Schématisation d'une interaction Asterisk-Gnguk

Le but de l’interaction entre les deux entités est dans un premier temps de pouvoir faire
communiquer les utilisateurs SIP et H323 entre eux, mais aussi de pouvoir faire profiter aux
utilisateurs du gatekeeper, des services proposés par Asterisk.

Asterisk s’enregistre donc sur le gatekeeper comme une passerelle en spécifiant les préfixes
d’appel qui lui correspondent.
Dans le schéma précèdent, le préfixe 20 est fournit par Asterisk. Ce qui signifie que si un
utilisateur compose un numéro commençant par 20, il sera alors automatiquement routé sur
Asterisk.
De ce fait, pour mettre en place le système global de communication, on doit distinguer les
deux mondes au niveau des numéros de téléphone :
Asterisk utilisera une plage de numéros commençant par 20 tandis que le gatekeeper lui,
utilisera une plage de numéro commençant par 10.
Les paramètres de configuration pour le gatekeeper se trouvent dans le fichier h323.conf de
Asterisk.
On y spécifie l’adresse IP où se trouve le gatekeeper, et on paramètre les informations du
compte pour s’enregistrer au près du gatekeeper
De ce fait, lorsque un utilisateur d’Asterisk voudra joindre un utilisateur utilisant le protocole
H323, Asterisk étant enregistré sur le gatekeeper, l’appel sera routé vers le gatekeeper
En effet, sachant qu’il existe un gatekeeper, Asterisk routera automatiquement tous les appels
utilisant le protocole H323 vers le gatekeeper.

3.3.2 Asterisk ---- Asterisk

Faire interagir et coupler plusieurs Asterisk peut être très intéressant. En effet on peut penser
qu’il serait intéressant d’avoir un serveur par départements, ou par étages au sein d’une
entreprise, par exemple. Ceci pour optimiser pour la répartition de charge, mais aussi pour
simplifier l’administration du réseau de téléphonie.

18/47
 Figure 8 : Schématisation d'une interaction Asterisk - Asterisk

Le serveur n°1 s’enregistre sur le serveur n°2, et peut ainsi potentiellement contacter les
utilisateurs du serveur n°2.
Comme pour l’interaction précédente, il devient stratégique d’adresser correctement les
numéros de téléphone par serveur et ainsi alléger les dialplan.
En effet, on choisira ici que les utilisateurs du Server 1 utilisent des numéros préfixés par 20xxx
et ceux du serveur 2 seront préfixés par 30xxx.

Ainsi dans le dialplan du serveur 1 enregistré au près du serveur 2, on aura :

exten => _30XXX,1,Dial(IAX2/server2/${EXTEN:1},30,r)

Ce qui signifie que pour les numéros commençant par ’30’, on appelle le serveur n°2 en
utilisant le protocole IAX2.
C’est bien évidemment sur le serveur 2 que les utilisateurs sont enregistrés ayant les numéros
commençant par ‘30’.

Chaque serveur doit s’enregistrer au près du serveur distant en tant que client pour accéder
aux utilisateurs, si le serveur distant veut communiquer avec les utilisateurs du serveur 1 il doit
faire la même manipulation, dans l’autre sens…

3.3.3 Interaction Asterisk/GK ---- hardware

Comme écris dans le cahier des charges du projet, nous avions prévu de mettre en place une
communication entre un serveur Asterisk (PBX software) et un PBX-IP hardware. Toutefois nous
n'avons pas pu avoir accès au matériel nécessaire pour mener à bien cette partie du projet. Ce
sont en effet, des outils coûteux réservés à des usages d'entreprises et donc difficile d'accès pour
nous. Notre service de ToIP restera donc limité au champ d'application des softphones et à usage
local.

19/47
 3.4 Développement et mise en place des services
3.4.1 Interface de configuration (Obelix)

3.4.1.1 Présentation

Dans un souci final d’incorporer notre service de téléphonie au sein d’une entreprise, nous
avons développé une interface permettant pour configurer le gatekeeper Gnugk, mais aussi la
gateway Asterisk.
En effet, dépourvut de toute interface graphique à la base, nous avons décidé de réaliser en
php, une interface simple, facile à utiliser, qui permettra de régler les paramètres nécessaires à la
mise en oeuvre de notre service de VoIP
Nous avions dans un premier temps, une interface spécifique différente pour configurer
Asterisk et le gatekeeper (cf rapport intermédiaire).
Par souci de simplicité, nous avons décidé de tout réunir au sein d’Obelix qui désormais peut
servir de plateforme de configuration aussi bien pour le gatekeeper que pour la gateway. Il suffit
pour cela de choisir le mode ("gateway" ou "gatekeeper").

3.4.1.2 Réalisation

Plutôt que de développer une interface lourde et imposant de longues heures de travail, nous
avons simplement décidé de passer par une interface web/php et ainsi bénéficier de fonctions très
utiles pour la manipulation des fichiers et des chaînes de caractères.
Ainsi Obelix se compose principalement d’un fichier index.php de quelques modules,
notamment maj.php, pour la mise à jour du fichier de configuration.
La mise en œuvre n’a pas spécialement posé de problème, notamment après voir suivi un
module de programmation réticulaire. La principale difficulté était de bien gérer les écritures dans
le fichier de configuration au bon endroit lors d’une mise à jour. En plus d’éditer la configuration,
Obelix est doté d’options supplémentaires tel que le « reset » et la visualisation du ficher de
configuration.
Les sources du projet Obelix sont disponibles sur le site lui-même, c'est-à-dire que l’un des
onglets de navigation nous mène directement au listing des fichiers php, et il suffit de choisir le
fichier à visualiser.
Un tutorial d’utilisation (cf. Annexe 3) a été rédigé pour expliquer les différentes
fonctionnalités de l’interface.

En mode Gatekeeper, après lui avoir spécifié l’emplacement du fichier de configuration,

Obelix pourra, par le biais de formulaires Web, éditer les sections principales qui nous sont utiles.
Les quatre principales sections sont :
• La Section « Main » s’occupe des paramètres globaux relatifs au gatekeeper tels que
l’adresse du serveur, le port d’écoute, le degré de verbosité etc…
• La Section « GkAuth » édite les règles d’accès et d’utilisation du gatekeeper, contrôle des
utilisateurs tentant l’accès (login, mot de passe) au gatekeeper…
• La Section « StatutAuth » édite les règles d’accès et d’utilisation du port de monitoring du
Gatekeeper pour l’administrateur notamment
• La section « Routed » est, pour le moment, développée mais pas utilisée, elle nous servira
essentiellement lors de l’interaction du gatekeeper avec le gateway Asterisk.

Le mode Gateway étant basé sur une architecture avec un fichier de configuration unique
(server.conf), et Asterisk étant basé sur une architecture avec de multiples fichiers de configuration
(SIP.conf, H.323.conf, etc…), nous avons besoin en plus d’un script Perl qui à partir du fichier
central de configuration, met à jour les différents fichiers de configuration d’Asterisk.

20/47
 Après avoir spécifié l’emplacement du fichier central de configuration, on pourra ajouter,
modifier, supprimer des utilisateurs SIP, paramétrer la configuration du Chanel SIP, et mettre en
place les information relatives au Gatekeeper.
On pourra en plus afficher le fichier de configuration, le remettre a zéro, ou encore lancer la
mise à jour des fichiers d’Asterisk.

Figure 9 : Schéma Fonctionnel de L’interface web/php ‘Obelix (mode Gateway) ‘

3.4.2 Script d’ajouts d’utilisateurs

Ce script permet de récupérer tous les utilisateurs d’une base LDAP, dans notre fichier de
configuration, ceci afin de faciliter la tâche de l’administrateur du gatekeeper. En effet, lorsque la
base dénombre une grande quantité d’utilisateurs, il devient vite laborieux de récupérer chaque
entrée (utilisateur) de la base, et de passer en ligne de commande le UserId et le mot de passe.
Afin que les clients des utilisateurs puissent s’enregistrer sur le gatekeeper, nous avons donc écrit
un script.
Le script se connecte dans un premier temps à une base LDAP, puis effectue une recherche
sur cette base. On récupère ensuite le UserId et le password de chaque entrée. Une fois toutes ces
entrées récupérées, on passe chaque UserId et password en argument de la commande
addpasswd :

addpasswd Fichier_config SimplePasswordAuth UserId Password

Ainsi on aura ajouté tous les comptes autorisés à se connecter au gatekeeper. De cette façon,
nous pourrons constituer un annuaire des utilisateurs présents sur le réseau ou pas, à partir de la
liste des comptes qui aura été ajoutée.

3.4.3 Programme de monitoring du Gatekeeper

Le monitoring du gatekeeper a été développé en Java sous forme d’applet, afin de pouvoir
l’intégrer directement à notre plate-forme d’administration Obelix. Ce service a été développé
dans l'optique de permettre à l’administrateur de monitorer l’activité du gatekeeper. En fait, il est
intéressant pour l’administrateur de pouvoir contrôler l’activité sur le gatekeeper.
Si dans le fichier de configuration, on a autorisé les connexions à un port que l’on peut
choisir, on pourra monitorer l’activité du gatekeeper, dans le cas contraire, la connexion au
gatekeeper sera impossible.

21/47
 Après s’être connecter au gatekeeper, l’administrateur aura accès à plusieurs fonctions
différentes :
• Avoir la liste des utilisateurs (leur Id) connectés au gatekeeper
• Avoir la liste des appels en cours (avec Id de l’appelant et appelé)
• Déconnecter les utilisateurs du gatekeeper
• Arrêter le service Gatekeeper

Figure 10 : capture d'écran du programme de monitoring

Nous n’avons implémenté que ces fonctions, car elles nous paraissaient les plus importantes,
cependant, il nous serait possible d’en rajouter d’autres.

3.4.4 Annuaire

Une partie importante de notre projet est la mise en place d’un annuaire interactif (cf figure 7)
des utilisateurs du service de téléphonie. Nous le qualifions d’interactif car il permet de connaître
le statut (en ligne / hors ligne / occupé) des utilisateurs.

Figure 7 : schéma de l’annuaire

22/47
 Comme cela est suggéré sur la figure 7, l’annuaire est accessible par un simple browser car
c’est une page HTML. C’est la solution la plus commode à mettre en place et aussi la plus
accessible. Dans la mesure où nous avons décidé de rendre ce service interactif, il faut que la page
web soit générée dynamiquement et c’est pour quoi nous avons décidé de développer un script
CGI pour cette tâche. La classe CGI de Perl simplifie l’écriture du script grâce aux fonctions de
générations de code HTML. Elle permet aussi de récupérer dans une table de hash les paramètres
passés au script par les méthodes GET et POST. Nous utilisons donc un unique script pour réaliser
toutes les fonctions de notre annuaire, et ce sont les paramètres qui aiguillent le script pour savoir
quelle page générer.

L’interface de l’annuaire se décompose en 2 parties :

• la liste des utilisateurs du service avec leur statut (cf annexe8)
• une page d’informations pour chaque utilisateur (cf annexe8)

Le script génère la première page après avoir parser le fichier de configuration du gatekeeper
(Gnugk.ini). En effet grâce au script d’ajout d’utilisateurs, le fichier de configuration contient une
entrée pour chaque usager du service. Donc le plus rapide est d’accéder à ce fichier. On récupère
ainsi un tableau contenant une liste d’identifiants. Ce tableau est en réalité une table de hash où
la clé est l’identifiant de l’usager et la valeur associée, son statut. A l’issu de cette étape, tous les
statuts sont mis à « off line ».
On passe à la second étape du processus qui consiste à se connecter au gatekeeper pour lui
demander la liste des utilisateurs actuellement enregistrés (i.e. ceux dont le statut doit être à « on-
line » dans notre annuaire). Le script utilise le module IO::Socket de perl pour se connecter au port
de monitoring du gatekeeper et envoyer la requête « PrintAllRegistrations ». La réponse est ensuite
parsée en utilisant des regexp pour ensuite mettre à jour le statut des usagers en ligne. Enfin le
script génère la page web servi au client.
Lorsque l’on clique sur un nom dans la page principale de l’annuaire on accède à une seconde
page (généré par le même script) contenant les informations (nom, prénom…) de l’utilisateur en
question. Ces informations sont tirées d’une base LDAP. On utilise le module Net::LDAP pour se
connecter à la base LDAP et on filtre la recherche sur l’identifiant de l’utilisateur (qui est unique).
On récupère les informations dans une variable de type Net::LDAP::Search puis on affiche ces
différentes informations en HTML.
Toutefois cette interface montre ses limites pour un annuaire constitué d'une importante liste
de noms. En effet dans ce cas la page principale se réduirait à une interminable liste de noms dans
laquelle il serait difficile de trouver l'utilisateur recherché. Pour pallier à ce problème, nous avons
mis en place trois mécanismes. Le premier est un système de filtrage par lettre qui lorsque l'on
clique sur une des lettres de l'alphabet situé en haut de la page n'affiche que les utilisateurs dont
le nom commence par cette lettre. Et pour compléter nous avons développé deux fonctions de
recherche : une par nom et une par numéro. Ce sont ces deux fonctions qui au final
constitueront le meilleur moyen d'obtenir des résultats rapides dans le cas d'annuaires
importants.

23/47
Voici un schéma récapitulatif du processus de génération de l’annuaire :

Génération de l’annuaire Génération de la page d’info

Récupération de la liste de tous les Connexion à la base LDAP pour

usagers en parser le fichier de récupérer les informations.
configuration du gatekeeper

Mettre à jour les statuts des usagers en Générer le code HTML de la page à
ligne en utilisant la fonction de servir.
monitoring du gatekeeper

Générer le code HTML de la page à

servir.

3.4.5 Messagerie vocale

L’un des services les plus intéressant à développer est le service de messagerie vocal. En effet,
il est désormais rare de trouver une entreprise ou un fournisseur de téléphonie ne possédant pas
un serveur de messagerie pour ses utilisateurs. Asterisk permet l’implémentation de ce service et
peut ainsi en faire bénéficier ses utilisateurs.
Pour ce faire, Asterisk crée dans un répertoire spécifique les différentes boites vocales
utilisateurs qui existent sur le serveur (fichier audio…), et l’administrateur peut alors configurer à
sa guise l’utilisation de ces dernières. En effet il existe deux moyens d’être envoyé sur la
messagerie, en cas de non réponse après un temps de sonnerie définit, ou alors car l’utilisateur est
déjà en communication. L’appelant se verra donc envoyé sur la messagerie en ayant un message
‘Absent’ ou ‘Occupé’.
L’administrateur peut aussi configurer les différentes options relatives aux boites vocales, telles
que le format audio employé, la notification de réception de messages vocaux, le temps
maximum de durée d’un message, de validité d’un message dans la boite vocale, etc…
L’utilisation avec notre gatekeeper est tout à fait opérationnelle, en effet, il suffit de créer les
boites vocales des utilisateurs du gatekeeper et ainsi, quand Asterisk recevra des appels à router
vers Gatekeeper, si l’utilisateur H323 ne répond pas, on pourra lui laisser un message. L’utilisateur
H323 pourra consulter sa boite vocale en se connectant à un numéro spécialement routé vers le
serveur Asterisk et qui lui délivrera ses messages.
Il en est de même pour l’interaction Asterisk - Asterisk via le protocole IAX à la différence que
chaque utilisateur aura sa boite mail sur son propre serveur.

>Tutorial d’utilisation en annexe

3.4.6 Musique d’attente

On a tous eu l’occasion d’entendre une douce musique pour nous faire patienter au
téléphone. C’est aussi un service utilisable avec Asterisk. En effet la musique d’attente peut être
utilisée dans deux cas de figure, soit pour mettre en attente quelqu’un parce qu’on est occupé à
faire autre chose, ou lors d’un transfert d’appel vers un autre utilisateur, où le temps de réaction
peut être plus ou moins long…
Après avoir installé un module de lecture de fichiers MP3, on peut configurer le serveur pour
accepter ce type de service.

24/47
 Il faut créer des classes de musique d’attente matérialisées par des répertoires contenant des
MP3 à jouer.
Après on peut assigner par le biais des fichiers de configuration des classes de musique aux
utilisateurs. Des musiques différentes par départements au sein d’une entreprise, par exemple.
Il est néanmoins possible de mettre en place un service supplémentaire de choix de musique
d’attente qu’on souhaite s’assigner et utiliser.
Comme précédemment ce service est disponible pour les entités interagissant avec notre
serveur Asterisk (Gatekeeper, autres serveurs Asterisk …).

>Tutorial d’utilisation en annexe

3.4.7 Transfert d'appel

Parmi les services que nous avons décidé d’intégrer à notre architecture il semblait inévitable
d'ajouter le service, courant des opérateurs téléphoniques, de transfert d’appel. Le but de se
service est, comme son nom l’indique, de transférer un appel vers un autre poste. En résumé il
sert à changer la destination d’un appel.
Il existe deux types de transfert d’appel au sein d’Asterisk, le transfert "aveugle" et le transfert
"supervisé". Le transfert "aveugle" est un transfert d’appel qui se fait sans intervention. Par
exemple le téléphone sonne et si personne ne décroche au bout d’un certain temps alors l’appel
est transféré. Tandis que pour un transfert d’appel supervisé l'appel change de destinataire par
l’intermédiaire d’une personne qui met en relation deux clients, comme par exemple pour les
standards téléphoniques.
Pour pouvoir intégrer l’un de ces deux types de transfert, ou les deux, nous avons besoin de
configurer le fichier features.conf .Ce fichier représente la base du transfert d’appel car il contient
des variables permettant de configurer les deux types de transfert cités précédemment, comme
par exemple pour définir les touches pressées du téléphone pour initier le transfert. Mais la
configuration de ce fichier ne suffit pas pour réaliser le transfert d’appel. Nous avons besoin
d'utiliser les commandes dial () et transfert () dans le fichier extension.conf, deux commandes du
dialplan, pour exécuter les deux types de transfert d’appel. (Pour plus de détails sur la réalisation de
ces deux transferts d’appel, se référer au tutorial du transfert d’appel)
La mise en place de ce service est assez simple. La principale difficulté a été rencontrée au
niveau des tests du transfert d’appel. En effet, pour tester la fiabilité de ce système, on a eu besoin
de plusieurs clients (au minimum trois ) sachant qu’on ne peut installer qu'un client par
machines, et que l'on a aussi besoin d’une machine où est installée Asterisk, le gatekeeper et
toutes les librairies. Donc cela fait un total de quatre machines minimum à réunir pour tester
correctement ce service.

>Tutorial d’utilisation en annexe

3.4.8 Annuaire vocal inversé

L'annuaire inversé est un service classique des opérateurs de téléphonie. Nous avons décidé
d'en implanter une version totalement automatisée pour notre service de VoIP. Le concept est
assez simple : l'utilisateur appelle un numéro, une annonce automatique l'invite à entrer un
numéro puis décline l'identité du propriétaire du numéro si celui-ci est valide. Pour réaliser ce
service nous avons mis en oeuvre plusieurs procédés. Tout d'abord le script a été écrit en perl
pour pouvoir bénéficier du module AGI et pouvoir ainsi communiquer avec Asterisk. Il a ensuite
fallu installer et configurer Festival qui est un synthétiseur vocal open source très performant. Ce
synthétiseur est une partie importante du service car elle évite d'avoir à enregistrer un fichier
audio pour chaque nom d'utilisateur, processus pénible pour une base d'une dizaine de noms et
rédhibitoire pour une centaine. Malheureusement ce synthétiseur n'étant pas disponible en
français, il faut noter que les noms sont prononcés avec un léger accent américain.
Enfin ce script utilise aussi une base LDAP où sont stockées les informations et le principe
s'apparente à ce qui est utilisé pour l'annuaire web présenté plus tôt dans ce rapport.

25/47
Concrètement ce service se déroule en plusieurs étapes :

• L'utilisateur compose le 12 (numéro assigné au service dans le dialplan d'Asterisk)

• Asterisk décroche la ligne et lance le script
• Le script fait lire par Asterisk une annonce d'accueil (par interface AGI)
• Le script fait lire par Asterisk une annonce invitant l'utilisateur à entrer un numéro
• utilisateur entre numéro en le composant
• script cherche dans la base LDAP à qui appartient le numéro
• si une réponse : festival synthétise un fichier audio où est lu le nom puis le script fais
lire à Asterisk ce fichier
• si pas de réponse ou si pas de numéro entré dans un délai imparti : script fais lire à
Asterisk une annonce d'erreur
• Le script fait lire par Asterisk une annonce d'au revoir
• Asterisk raccroche la ligne

26/47
4/
Etat du projet
4.1 Travail accomplit
Apres un semestre passé sur ce projet, nous pouvons dresser un bilan satisfaisant des resultats
de nos travaux. Nous avons mis en place un service de téléphonie sur IP totalement fonctionnel et
mixte H.323/SIP. Cette mixité apporte une grande souplesse d'utilisation et d'importante
possibilité d'extension. Pour aller plus loin dans le confort d'utilisation, nous avons agrémenté
notre réseau de nombreux services. Certains sont des classiques des opérateurs de téléphonie tel
que le transfert d'appel, la messagerie ou la musique d'attente. D'autres comme l'annuaire vocal
sont nos idées propres.
Un point important sur lequel, il faut revenir est l'administration d'un réseau aussi développé
que nous avons mis en place. En effet s'il est simple et riche pour l'utilisateur, il pourrait n'en être
pas moins complexe à gérer pour un administrateur. C'est pour cette raison que nous avons
développé des outils devant aider celui-ci dans l'installation et la gestion de notre service. Ces
outils comprennent une interface web d'administration, opérationnel pour Gnugk et Asterisk, et
un programme de monitoring d'activité pour Gnugk. Ceci est complété par un ensemble de script
dont certains sont évoqués dans ce rapport et qui sont principalement destiné à la gestion de la
base LDAP sur laquelle repose une grande partie des services. Vous trouverez tous ces outils sur le
CD fournis avec la version papier du présent rapport. Dans la même optique nous avons rédigé
une série de tutoriaux pour faciliter le déploiement des outils nécessaires car nous avons pu nous
rendre compte que c'était assez délicat avec des logiciels comme Asterik ou Gnugk.

4.2 Avancées par rapport au cahier des charges

Par manque de ressources matérielles, nous avons décidé conjointement avec notre
encadrant, de passer l’étape interconnexion PBX Hardware – Asterisk. En effet, il était difficile de
pouvoir avoir accès librement à un PBX afin de pouvoir s’adonner à de nombreux tests. Ce fait
établit, notre encadrant a décidé de nous commander une carte RTC capable de convertir les flux
IP afin de les rendre compatible à des flux RTC, afin de pouvoir depuis un poste situé sur notre
réseau un téléphone analogique situé n’importe où.. Malheureusement suite à un problème de
stock du fournisseur, nous n’avons pas pu réaliser ce point de substitution.
Mis à part ces points indépendants de notre volonté, nous nous sommes tenus à la ligne
directrice de réalisation de ce projet. Nous avons installé les logiciels choisis, développés des
applications pour enrichir notre service, et mis en place les services proposés.

27/47
 Pour conclure nous partirons sur un constat simple : beaucoup de personne à l’heure
actuelle n'ont encore jamais entendu parler de la téléphonie sur IP. C'est pourtant un
service qui se développe de plus en plus, dont l'exemple le plus frappant est la popularité
d’un logiciel comme Skype, ou encore la conversion des constructeurs de centraux
téléphonique traditionnels dans la téléphonie IP.
La téléphonie sur IP est un service de téléphonie fourni sur un réseau de
télécommunications ouvert au public ou privé utilisant principalement le protocole de
réseau IP. Cette technologie permet d'utiliser une infrastructure existante de réseau IP
pour raccorder des terminaux IP ainsi que des logiciels sur PC raccordés sur le même
réseau IP.
Ce projet nous a permis de nous familiariser avec des concepts, technologies qu’il est
difficile de manipuler durant un cursus scolaire. En effet, nous avons pu nous imprégner
des différents éléments constitutifs d’une architecture de téléphonie sur IP, mais
également des difficultés que l’on peut rencontrer lors du déploiement de cette
architecture.
Nous en avons dégagé un nombre de points en faveur de la téléphonie sur IP :

• Economies sur les factures télécoms classiques

• Simplification des infrastructures
• Homogénéiser les services téléphoniques sur un ensemble de site
• Faciliter l’intégration avec le système d’information déjà en place
• Evolution plus facile
• Se passer plus facilement des services d’un prestataire

Cependant les entreprises semblent encore réticentes vis-à-vis de la téléphonie IP, car
il reste des point sensibles. Ces points nécessitent des améliorations avant que la
téléphonie IP puisse entrer sans crainte dans les mœurs des entreprises. Pour l’instant, la
fiabilité et la qualité sonore des communications de ce service restent à améliorer. On
note également une absence de réel support administratif, selon les solutions on peut
trouver des plateformes d’administration plus ou moins développées. Mais le principal
problème réside dans le protocole H.323 qui possède de nombreuses failles de sécurité
qui peuvent permettre d’exécuter des commandes arbitraire ou pire de provoquer un
déni de service sur le système vulnérable.
La téléphonie IP est un service trop peu utilisé à l’heure actuelle, cependant les
nombreuses offres proposées par les constructeurs traditionnels de serveur téléphonique
sont un gage de l’investissement des industriels dans ce domaine.

28/47
Notes et remerciements

Nous souhaitons remercier notre encadrant, Laurent Ouakil, pour ses conseils judicieux et
sa grande disponibilité tout au long de l'élaboration de ce projet.

Nous remercions aussi Benjamin qui nous a beaucoup aidé pour la conception graphique
de ce compte rendu.

Avec la version papier de ce rapport doit se trouver un cd-rom contenant les sources et les
versions électroniques de tous nos travaux sur ce projet.

Ces fichiers sont aussi accessibles en ligne à l'adresse suivante:

> http://darkar.free.fr/pres/cd/

Nous avons entretenu un wiki durant la plus grande partie du projet qui est accessible là :
> http://darkar.free.fr/pres/wiki/

29/47
Annexes

Annexe 1 : Tutorial d’installation du gatekeeper Gnugk

Annexe 2 : Tutorial d’installation de la gateway Asterisk

Annexe 3 : Tutorial d’utilisation d’Obelix (interface de configuration du gatekeeper)

Annexe 4 : Tutorial de mise en place du service de messagerie

Annexe 5 : Tutorial de mise en place du service de musique d'attente

Annexe 6 : Tutorial de mise en place du service de transfert d'appel

Annexe 7 : Tutorial d'installation du synthétiseur vocal Festival

Annexe 8 : Captures écran annuaire web

Annexe 9 : Captures écran programme de monitoring

Annexe 10 : Contenu du CD contenu dans la version papier du rapport

30/47
Annexe 1
Tutorial d’installation de Gnugk à partir des sources sous Red Hat 9

1.Télécharger :
pwlib_1.5.2.tar.gz (http://www.OpenH323.org/bin/pwlib_1.5.2.tar.gz)
OpenH323_1.12.2.tar.gz (http://www.OpenH323.org/bin/OpenH323_1.12.2.tar.gz)
Gnugk-2.2.1-2.tgz (http://prdownloads.sourceforge.net/OpenH323gk/Gnugk-2.2.1-2.tgz?download)

2.Compilation de pwlib :

• tar xvzf pwlib_1.5.2.tar.gz

• cd pwlib
• pwd (pour récupérer le chemin absolu du répertoire courant PWLIBDIR)
• export LD_LIBRARY_PATH=PWLIBDIR/lib
• ./configure
• make

3.Compilation de OpenH323 :

• tar xvzf OpenH323_1.12.2.tar.gz

• cd OpenH323
• pwd (pour récupérer le chemin absolu du répertoire courant OPENH323LIBDIR)
• export LD_LIBRARY_PATH=$LD_LIBRARY_PATH":OPENH323LIBDIR/lib"
• ./configure
• make

4.Compilation et installation de Gnugk

• tar xvzf Gnugk-2.2.1-2.tgz

• cd Gnugk-2.2.1
• ./configure
• make opt
• make addpasswd (nous servira à ajouter des comptes pour l'enregistrement des clients)
• cp obj_linux_x86_r/Gnugk /usr/sbin (facultatif mais fait pour un confort d'utilisation)
• cp obj_linux_x86_r/addpasswd /usr/sbin (facultatif mais fait pour un confort d'utilisation)
• touch /etc/Gnugk.ini (on créée le fichier qui servira de fichier configuration de Gnugk)

4.Lancement de Gnugk

• ./Gnugk -c /etc/Gnugk.ini -ttt (on appelle le fichier de configuration et on a un niveau de

monitoring de 3; on peut monter jusqu'à 5)

31/47
Annexe 2
Tutorial d’installation de la gateway Asterisk

1.Télécharger :
Asterisk-1.0.5-tar-gz http://www.Asterisk.org/html/downloads/Asterisk-1.0.5.tar.gz

2.Dépendances de bibliothèque:

Asterisk nécessite les bibliothèque pwlib et opnH.323, que nous avons installées précédemment
(cf tutorial d’installation de Gnugk)

3.Compilation et installation de Asterisk :

• tar xvzf Asterisk-1.0.5.tar.gz

• cd Asterisk-1.0.5
• make
• make install (vérifier si on peut s'en passer car on va le refaire après)
• cd channels/H.323 (on va installer le module H.323 d'Asterisk)
• make
• make samples
• cd ../.. (retour à la racine d'Asterisk-1.0.5)
• make install
• make samples

4.Lancement de Asterisk :

Se mettre dans le répertoire Asterisk-1.0.5 et faire ./Asterisk -vvvc pour voir si il y a des erreurs au
lancement et pour bénéficier de la ligne de commande

Si Asterisk est déjà lancé on peut se connecter à la console avec l'option -r (ex : Asterisk -vvvrc)

32/47
Annexe 3
Tutorial d’utilisation d’Obelix
Note : Obelix est le nom de l’interface de configuration pour gnugk et Asterisk.

1. Page d’accueil :

Choix du Mode de configuration

Gateway - Gatekeeper

2. Choix du mode :

En fonction du mode choisi on obtient deux menus différents, un pour le gatekeeper, et un pour
le gateway.
On peut a tout moment changer de mode en utilisant les deux boutons du haut.

33/47
On peut ainsi avoir accès a toutes les sections de configuration du gatekeeper et du Gateway.

3. Le fichier de configuration (Gatekeeper)

Spécifier l’emplacement du fichier de configuration (/etc/Gnugk.ini par exemple)

34/47
Simplement saisir l’emplacement du fichier de configuration dans la case : « New Path to config
file »
Et cliquer sur "Mettre a jour".
La page se recharge, on voit le « Curent Path » modifié.

4. Configuration Principale (gatekeeper)

Les paramètres les plus importants sont le Nom, le Home, Statut Port et le StatusTraceLevel.

On peut mettre le Nom que l’on désire pour le gatekeeper.

L’adresse IP du Home est l’adresse du gatekeeper sur le réseau.

Le status port est un port où l’on peut se connecter pour faire du monitoring des appels, des
utilisateurs connectés etc… (Voir script Annuaire)

Le StatusTraceLevel permet de définir le degré de verbosité du gatekeeper au lancement. Les

autres paramètres sont ici inutilisés.

5. Configuration d’authentification (Accès Administrateur)

35/47
Dans cet onglet on définit la règle d’accès au port de monitoring du gatekeeper.
Ici, la rule est en "allow" ce qui signifie que n’importe qui peut accéder au gatekeeper et initialiser
des communications.
On peut y définir des les règles d’accès par des expressions régulières pouvant filtrer les adresses
IP.
Par souci de simplicité le script ne permet de définir l’accès qu'en "Allow" ou en "forbid"

6. Configuration d’authentification (Accès utilisateurs)

Dans cet onglet on définit la règle d’accès au gatekeeper en lui-même

On peut alors définir dans la section ‘SimplePasswordAuth ‘ les règles d’accès
Le Requiered ;ARQ signifie que la requête de registration est requise pour avoir l’accès au
Gatekeeper.

7. Mode de routage

36/47
Les deux Options principales sont - GKRouted et H245Routed qui permettent de router le flux
audio et le flux de contrôle entre les Utilisateur.
Dans notre Configuration réseau, il était nécessaire de les mettre a 1.

Les autres options configurent les différentes configurations réseaux possibles (tunneling, nat…)

8. Fonction additionnelles :

Le reset.

Simplement cliquer sur supprimer pour effacer le fichier de configuration. Et ainsi refaire un
fichier de configuration.

9. Les sources

Cliquez sur le lien correspondant pour voir les sources php d’Obelix.

10. Le Monitoring

L’onglet du monitoring permet de voir qui est connecté sur le gatekeeper, avec la
possibilité de déconnecter les utilisateurs.

11. Ajout d’utilisateur

Grâce à cet onglet on peut rajouter un utilisateur ponctuel sur le Gatekeeper, il suffit pour
cela de rentrer son login et son pass, et il sera automatiquement ajouté au fichier de
configuration.

12. Mettre a jour le gatekeeper

Fonction pour que les nouveaux paramètres du gatekeeper soient pris en compte
immédiatement.

37/47
En Mode Gateway

Les onglets de configuration se ressemblent globalement.

On peut de la même façon ajouter et gérer les utilisateurs SIP :

Du coté H323 il suffit de paramétrer le gatekeeper en spécifiant l’adresse IP.

Le mode Gateway possède aussi des fonctions telles que le reset, la mise à jour des fichiers de
configuration…

38/47
Annexe 4
Tutorial ---- Messagerie vocale

Pour créer et rendre fonctionnelle une boite vocale il faut : la créer, la configurer, la rendre
utilisable.

La création de la boite vocale est simplifiée par l’utilisation d’un script fournit avec Asterisk :
> Addmailbox

lorsque l'on lance le script, on nous demande alors le context : Default

Puis on nous demande le login et le password : 1001 , 1001 pour notre exemple

Le script créé alors dans /var/spool/astersi/mailbox/default/ le repertoire 1001 contenant les fichiers
audio de messagerie de l’utilisateur (annonces d’absence etc…)

Pour chaque boite vocal ajoutée, il faut le spécifier dans le fichier de configuration dédié au
‘Voicemail’ : Voicemail.conf
On y paramètre la boite vocale :

[default]
1001 => 1001,BoiteVocal de Toto ,toto@lip6.fr

Avec le format : BoiteVocal => Password, Description, Email

Asterisk sait ainsi que la boite vocale existe et peut être utilisée.

- Dans le Dialplan désormais, il faut que la boite vocale puisse être utilisable
Si l’on souhaite joindre 1001 on aura dans le dialplan :

Exten => 1001,1,Dial(SIP/1001,10,tr)

Exten => 1001,2,Voicemail(u1001)
Exten => 1001,102,Voicemail(b1001)

Le, 10, en gras signifie que l’on va faire sonner pendant 10 secondes, si le destinataire n’a pas
répondu, alors on passera à la priorité suivante qui nous dit de lancer le voicemail de 1001 (avec
un message ‘non disponible’)
La troisième ligne correspond au cas ou l’utilisateur 1001 est déjà en ligne, on envoie son
correspondant sur la messagerie avec un message ‘ Occupé ‘.

Pour accéder à sa boite vocale, il suffit de composer *123*, qui est un numéro spécialement créé
pour envoyer un utilisateur sur sa propre boite vocale :

exten => *123*,1,VoicemailMain(s${CALLERIDNUM})

On peut alors consulter ses messages et utiliser les options du voicemail :

Enregistrer son propre message d’absence, archiver, gérer ses messages…

39/47
Annexe 5
Tutorial ---- MusicOnHold

1. Installation de Mpg123, lecteur de fichiers MP3 pour Asterisk

http://www.mpg123.de/cgi-bin/sitexplorer.cgi?/mpg123/
tar -zxvf mpg123-<version>.tgz
cd mpg123
make linux
make install
ln -s /usr/local/bin/mpg123 /usr/bin/mpg123

2. Configuration

On édite MusicOnHold.conf et on créé des classes de musique

[Classes]
Default => mp3:/var/mp3/default
Rock => mp3:/var/mp3/rock
Classic => mp3:/var/mp3/classic

Mettre des mp3 dans les dossiers correspondant.

3. Utilisation

On peut désormais utiliser les musiques d’attente dans le dialpan en utilisant la fonction
SetMusicOnHold(Classe)

Exemple :
Exten =>1001,1,SetMusicOnHold(Rock) ;on définie la classe utilisée
Exten => 1001,2,Dial(SIP/1001 ,10,tr)
Exten => …

Si l’utilisateur 1001 est mis en attente, il aura une musique rock pour patienter.

40/47
Annexe 6
Tutorial ---- transfert d'appel
Ce tutorial se décompose en deux parties. La première explique la fonction des différentes
variables présentes dans le fichier features.conf, fichier qui permet de configurer le transfert
d’appel. Puis s’enchaîne le paragraphe sur le rôle des commande dial () et transfert () avec deux
scénarios mettant en évidence le transfert d’appel « aveugle » et supervisé.

1. Configurer le fichier features.conf

Ce fichier permet de configurer le transfert d’appel. Il contient donc toutes les variables
nécessaires à sa création. Dans un premier temps il faut savoir que cette nouvelle partie de ce
fichier est une mise à jour, c'est-à-dire elle n’existait pas avant. Elle se trouve donc seulement, à ce
jour, dans la dernière version d’Asterisk.
Par la suite on décrit donc toutes les possibilités qu’apportent ces nouvelles variables.
Ainsi on peut définir le nombre de secondes à attendre entre les chiffres afin de transférer l’appel
par la variable transferdigittimeout suivi d’un chiffre. La variable xfersound permet d’indiquer
par un son la réussite du transfert supervisé d’appel. Réciproquement il existe une variable qui
permet d’indiquer l’échec d’un transfert. Cette variable est xferfailsound. A la base ces deux sons
sont représentés par un bip.
On trouve aussi dans ce fichier un context featuremap contenant deux variables utiles :
- blindxfer qui permet de définir les touches pressées pour initialiser un transfert
« aveugle » sachant qu’ Asterisk supporte les transferts aveugles avec les
protocoles H323 et SIP.
- atxfer qui permet de définir les touches pressées pour initialiser un transfert
supervisé

En fait, ces deux variables permettent de définir la clé initiant le transfert.

Une information importante est de ne pas oublier de relancer Asterisk pour qu’il prenne bien en
compte les modifications du fichier features.conf.
Cependant le faite de configurer ce fichier ne suffit pas à mettre en oeuvre le système de transfert
d’appel. En effet, la plus grande partie de cette fonctionnalité est réalisée par la commande dial ()
et la commande transfert ().

2. fonctionnement de la commande dial ()

Pou réaliser le transfert d’appel, on a besoin d’introduire cette commande dans les scripts des
différents contexts du fichier extension.conf qui utilisent cette fonction et aussi de la paramétrer
par exemple en donnant l’autorisation soit à l’appelant ou soit à l’appelé ou bien les deux à
réaliser le transfert d’appel. Le rôle de cette commande est simple mais très importante
puisqu’elle permet établir une communication sur un channel précis entre deux clients.
La commande dial () peut se composer de deux manières :
- Dial (type/identifier,timeout,options), pour se connecter à seulement un channel
- Dial (type1/identifier1&type2/identifier2&type3/identifier3...,timeout,options) pour donner
la possibilité de se connecter à plusieurs channels différents

Type spécifie le type de channel utilisé comme SIP, H323.

Identifier spécifie le numéro de téléphone que l’on veut joindre.
Le paramètre timeout est optionnel. Quand il est utilisé, il définit le temps maximum, en
secondes, d’attente pour que l’appelé décroche.
Le paramètre options est aussi optionnel mais dans le cas du transfert d’appel, il est essentiel
puisque l’ajout de l’option t autorise l’appelé à transférer l’appel et T autorise l’appelant à
transférer l’appel. Pour que les deux soient autorisés, il suffit de mettre les deux lettres.

41/47
Pour rentrer dans les détails en ce qui concerne l’utilisation de channels multiples, l’utilisation de
plusieurs channels au sein de la commande dial () permet d’atteindre simultanément plusieurs
appelés. La communication sera mise en place lorsque l’un de ses réceptionneurs décrochera.

En ce qui concerne la commande transfert (exten), elle intervient seulement pour le transfert
d’appel « aveugle ». Elle permet de transférer un appel à une extension distante préalablement
enregistrée dans la base d’Asterisk. Son utilité est mise en évidence par un exemple plus loin dans
cette partie.

Une fois toutes ces opérations prisent en compte, il ne manque plus que de les introduire dans le
script d’un context du fichier extensions.conf.
Pour faciliter la tâche, on présente deux exemples de scripts, un script qui réalise un transfert
d’appel « aveugle » et un deuxième, un transfert d’appel supervisé.
Il ne faut surtout pas oublier de rajouter dans le context [global], la ligne
include => featuremap pour pouvoir utiliser le context du fichier features.conf où se trouve la
configuration des transferts d’appels pour les deux cas.

2.1 Transfert d’appel supervisé :

Dans cet exemple, on utilise des utilisateurs SIP : 1001,1002 et 1003. Ce qui signifie que dans un
premier temps, ils ont été définis dans le fichier SIP.conf que l’on ne va pas détailler ici.
Le scénario est le suivant 1001 veut contacté 1003. Mais il est obligé de passé par l’intermédiaire
1002 pour savoir si 1003 veut répondre à cet appel.

[SIP]
exten => 1002,1,Dial(SIP/1002, 10, tT) ;

1001 appelle 1002, qui sont des utilisateurs SIP, alors la commande Dial () établit la
communication entre 1001 et 1002. Comme 1001 souhaite joindre 1003, 1002 peut initier le
transfert en composant le clé de transfert (atxfer) puis compose le numéro 1003.Si le client 1003
existe une tonalité de réussite est entendu sinon une tonalité d’échec. A cet instant 1001 patiente
en écoutant une musique d’attente, et 1002 et 1003 sont en communication. Dés que 1003
décide de prendre la communication, 1002 raccroche alors 1001 et 1003 rentre en
communication.
Cet exemple est très simpliste. Mais ceci montre que le transfert d’appel supervisé peut se faire à
tout moment.

2.2 Transfert d’appel « aveugle »

Dans cet exemple on utilise les mêmes utilisateurs que dans l’exemple précédent.
Dans ce scénario, 1001 contacte 1003 directement mais il ne veut pas recevoir l’appel et le
transfert à 1002.

[SIP]
exten => 1003,1,Dial(SIP/1003, 10, tT) ;
exten =>1003,2, transfert(1002) ;
exten => 1003,3,Voicemail(u1003);
exten => 1002,1,Dial(SIP/1002, 10, tT) ;

1001 contacte 1003. Le téléphone de 1003 sonne mais il ne veut pas prendre la communication.
Donc, soit il envoie l’appelant sur sa messagerie en attendant la fin du timeout, fixé à 10 ici, soit il
initie le transfert de l’appel en composant le clé de transfert (blindxfer) avant la fin du timeout.
Alors l’appel est transféré à l’extension indiquée par la commande transfert(), ici 1002, à la fin du
timeout. La commande dial() s’occupe alors d’établir la communication avec 1002.
Ces deux exemples concluent sur l’élaboration du transfert d’appel dans Asterisk.

42/47
Annexe 7
Installer Festival sous Debian

1. Installation

Étape 1:
apt-get install festival

Étape 2:
Éditez /usr/share/festival/festival.scm et ajouter :

;;;debut de la definition
(define (tts_textAsterisk string mode)
"(tts_textAsterisk STRING MODE)
Apply tts to STRING. This function is specifically designed for
use in server mode so a single function call may synthesize the string.
This function name may be added to the server safe functions."
(utt.send.wave.client (utt.wave.resample (utt.wave.rescale (utt.synth
(eval (list 'Utterance 'Text string))) 5) 8000)))
;;; fin de la definition

Étape 3:
Éditer /etc/Asterisk/festival.conf

[general]
host=localhost
port=1314
usecache=yes
cachedir=/var/cache/Asterisk/festival/
festivalcommand=(tts_textAsterisk "%s" 'file)(quit)\n

Étape 4:
Lancer festival avec : festival_server

2. Exemples d'utilisation :

Dans un dialplan :

exten => 555,1,Answer

exten => 555,2,Festival(La VoIP c'est cool !) ;
exten => 555,3,Hangup

Ou dans script AGI perl :

$AGI->exec('Festival', '"La VoIP c\' est toujours aussi cool ;)"');

43/47
Annexe 8
Captures d'écran de l'annuaire web

44/47
Annexe 9
Capture d'écran du programme de monitoring

45/47
Annexe 10
Contenu du CD fourni avec la version papier du rapport
Voici l'arborescence de ce que l'on peut trouver sur le cd

/
Asterisk/ *Sources Asterisk
Divers/ *Logiciels Utiles
Docs/ *Rapports
Gatekeeper/ *Sources Gnugk
H323/ *Stack H323
Images/ *Images Screen
Sources/
Ajout_base_LDAP/ *Script ajout d’utilisateur LDAP
Annuaire/ *Annuaire On-line
Annuaire_inversé/ *Script annuaire inversé
LDAP_To_Gnugk/ *Ajout d’utilisateur sur le Gk
Monitoring/ *Interface de monitoring
Obelix/ *Interface web
Tutorials/ *Tutoriaux du projet

README

46/47
Bibliographie

Livres

Les Réseaux, édition 2005, de Guy Pujolle

LDAP : Administration système, de Gerald Carter, Sébastien Pujadas - O'Reilly
Perl, de Larry Wall
VoIP Implementation and Management, John Q. Walker and Jeffrey T. Hicks
Java In A Nutshell, David Flanagan

Sites web

Asterisk, http://www.Asterisk.org/
The VOIP Wiki - a reference guide to all things VOIP, http://www.voip-info.org/
Asterisk Documentation Project, http://www.Asteriskdocs.org/
OpenH323 Project, http://www.openh323.org/standards.html
Wiki H323, http://fr.wikipedia.org/wiki/H323
Actos Asterisk GUI, http://www.ifrance.com/belikewater/code/actos.html
GateGeeper, http://www.Gnugk.org/

Cours

Cours de programmation réticulaire, de Christian Queinnec

47/47