MISE EN PLACE D UN SERVICE DE TELEPHONIE SUR IP

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

SJPhone X-Lite OpenPhone Kphone Gnome 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 la page d’info

usagers en parser le fichier de configuration du gatekeeper

Génération de l’annuaire

Mettre à jour les statuts des usagers en ligne en utilisant la fonction de

monitoring du gatekeeper

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

Connexion à la base LDAP pour récupérer les informations.

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