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.

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

Récupération de la liste de tous les 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

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.htmlWiki H323, http://fr.wikipedia.org/wiki/H323Actos Asterisk GUI, http://www.ifrance.com/belikewater/code/actos.htmlGateGeeper, http://www.Gnugk.org/ Cours Cours de programmation réticulaire, de Christian Queinnec

47/47