MISE EN PLACE D UN SERVICE DE TELEPHONIE SUR IP

Transcription

1 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

2

3 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++]

4 TABLE DES MATIÈRES Introduction 01 1/ Plan de développement 02 2/ Dossier analyse et conception Le matériel Les protocoles H SIP IAX Développement Php Perl AGI Java Les logiciels Plateforme de travail Asterisk Gatekeeper Clients VoIP OpenLDAP Autres Schéma de développement 12 3/ Réalisation du projet Gatekeeper (Gnugk) Présentation et problématique Installation Configuration Asterisk Installation Configuration Interactions Asterisk Gatekeeper Asterisk Asterisk Asterisk/Gatekeeper PBX Hardware Développement et mise en place de services Obelix Présentation Réalisation Script d ajouts d utilisateurs Programme de monitoring du gatekeeper Annuaire Messagerie vocal Musique d'attente Transfert d'appel Annuaire vocal inversé 25

5 4/ Etat du projet Travail accomplit Avancées par rapport au cahier des charges 27 Conclusion 28 Notes et remerciements 29 Annexes 30 Bibliographie 46

6 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

7 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

8 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

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

10 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

11 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 ) 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

12 2.3 Développement 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 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 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 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

13 2.4 Les logiciels 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 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

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

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

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

17 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

18 3/ Réalisation du projet 3.1 Gatekeeper (Gnugk) 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

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

20 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