Université Paris XIII Institut Galilée Master Informatique 1 ère année

Transcription

1 Université Paris XIII Institut Galilée Master Informatique 1 ère année Année Universitaire : 2006/2007

2 SOMMAIRE I. Introduction... 2 II. Etude du projet Analyse des besoins Réponses aux besoins... 3 III. Organisation du projet... 4 IV. Architecture globale... 7 V. Conception Cas d utilisation et diagrammes des séquences Diagrammes flux Diagrammes des classes VI. Réalisation Tester les performances du réseau Récuperer les mesures du réseau Auto-configurer le réseau VII. Environnement de travail Installation du serveur VoIP Installation du serveur Bases de données Installation du réseau Inter-opérabilité des composants VIII. Documentation Guide utilistateur Guide de l administrateur IX. Conclusion X. Annexes

3 I. Introduction Actuellement les fournisseurs de services Internet (ISP) qui offrent un service de VoIP ne se préoccupent guère de la qualité de service. Par exemple, Free dans son offre ADSL prévoit un temps de latence d environ 5 secondes en téléphonie sur IP. Aujourd hui, nous constatons une multiplication des ISP offrant un service de téléphonie sur IP (Alice, neuftelecom, Wanadoo, Darty, ). Sachant que tous ces ISP offrent le même service de téléphonie sur IP, il est évident que la qualité de service (QoS) est un argument de vente non négligeable. De plus, avec l arrivée de la vidéo sur IP, le critère de qualité de service devient essentiel dans le domaine des télécommunications. Dans le cadre de la "Conduite et Gestion de Projet", Mr. Hassine MOUNGLA, enseignant chercheur au LIPN (Laboratoire d Informatique de Paris-Nord) a proposé le projet suivant : " La gestion autonome des services sur les réseaux Diffserv. Cas d'étude: La Voix sur IP ". Il s agit d un nouveau projet de recherche qui consiste à trouver une solution pour faire passer de la voix via un réseau IP-Diffserv tout en maintenant le même niveau de qualité de service. La première partie de ce rapport décrit la manière dont nous avons géré notre projet, l attribution des tâches à la réalisation en passant par la conception. La deuxième partie du rapport (annexes) peut servir pour la maintenance du logiciel. 2

4 II. Etude du projet 1. Analyse des besoins Les points explorés dans ce projet portent sur la construction de deux systèmes : (i) Système de monitorage qui collecte les informations sur le réseau. (ii) Système de gestion auto-configuration qui prend les décisions selon les informations collectées par le système de monitorage, et qui réalise des ajustements du réseau si nécessaire. 2. Réponses aux besoins Nous pouvons décomposer notre projet en plusieurs parties. La première partie sera la préparation de l environnement de travail, la deuxième la récolte des mesures des paramètres de QoS pertinents à la VoIP et la troisième l autoconfiguration ou la gestion autonome du réseau. 1 ère partie : Préparation de l environnement de travail En accord avec le client nous allons effectuer l ensemble du projet sous Unix, car cela nous permettra par la suite d utiliser des commandes Unix (ping f ) pour simuler une surcharge du réseau. De plus l unique solution IP-PBX libre (Asterisk) n est disponible que sur Linux. Nous allons donc installer un serveur IP-PBX sur lequel se connecteront les clients VoIP. Le protocole de VoIP utilisé sera SIP, l un des standards et le plus répandu chez les fournisseurs de services Internet (ISP). 2 ème partie : Récolter les mesures des paramètres de QoS pertinents à la VoIP Une communication téléphonique est une application réelle qui impose donc des contraintes de QoS au réseau que n'imposent pas les applications traditionnelles telles que FTP, Web et même telnet. La littérature sur le sujet converge vers les contraintes suivantes : 3

5 - Bande passante : sans compression, la voix nécessite 64 Kbps de bande passante, avec compression on peut descendre jusqu'à 5 Kbps. Dans ce dernier cas, la qualité du son est moins bonne et le temps de traitement pour la compression et la décompression au départ et à l'arrivée augmente ainsi le temps de latence. - La perte de paquets : la voix supporte bien les pertes de paquets par rapport à d'autres applications. On considère que le taux de pertes doit être inférieur à 20 %. A noter que la retransmission des paquets erronés ou perdus est inutile car elle induirait un temps de latence trop important. - La gigue : c'est une variation du délai de transmission de l'information. Elle provient de la variation de la charge du réseau (si la taille des files d'attente dans les routeurs augmente, le temps de latence augmente et inversement), éventuellement des routes différentes utilisées (IP est un mode sans connexion où un flot de datagrammes peut emprunter des chemins différents lors d'un même appel téléphonique). Cette gigue ne doit pas être trop importante. On peut diminuer celle-ci en ajoutant des mémoires tampons dans le chemin, mais cela peut engendrer une augmentation du temps de latence. Notre objectif est d'identifier les paramètres clés qui ont un impact fort sur les paramètres de QoS (bande passante, perte de paquets et gigue). Ensuite, nous utiliserons l'architecture DiffServ afin de garantir la QoS de bout en bout. Cela nécessite de mettre en œuvre un système de monitorage. Pour cela, nous allons utiliser l outil iperf qui se base sur le modèle client/serveur. Le serveur reçoit les mesures relevées sur les clients. Iperf a l avantage de pouvoir enregistrer les informations relevées dans un fichier. Pour exécuter le client à intervalle de temps régulier, nous allons utiliser crontab. Les mesures relevées seront affichées en temps réel dans la console principale qui sera mise à jour toutes les trente secondes. 3 ème partie : Auto-configuration du réseau Pour cette partie, nous considérons une machine dédiée sur laquelle est lancé en permanence un programme Java (7 heures par jour). Ce programme contiendra les paramètres minimaux du réseau (les mesures à ne pas dépasser). Lorsque les paramètres sont dépassés, ces derniers sont enregistrés dans la base de données. Le programme java identifiera ensuite le routeur qui possède le plus fort taux de congestion et lui indique qu il faudra privilégier les paquets qui concernent la VoIP. 4

6 4 ème partie : Documentation Au terme de notre projet, nous prévoyons de fournir une documentation qui contiendra les différentes étapes du projet. Cette documentation nous servira également pour notre rapport. Une personne du groupe sera chargée en partie de constituer cette documentation. III. Organisation du projet Pour réaliser ce projet nous nous sommes réparti les tâches en fonction des compétences techniques de chacun. Néanmoins tous les membres peuvent être sollicités pour travailler sur l ensemble du projet. Pour gagner du temps certaines tâches pourront être effectuées en parallèle. Comme par exemple la documentation qui sera effectuée tout au long du projet. La répartition dans notre groupe est la suivante : Ahmed BENSI sera le responsable de la gestion du projet. - Responsable du planning - Organisation des réunions de travail - Correspondance avec le client - Installation de l environnement de travail : Pei YU et Ahmed BENSI - IHM : Fatah HASSANI et Piotr BENSALEM. - Programmation Java : Romain BALARA Une fois les moyens identifiés, il convient de les organiser : définir les phases du projet et leurs échéances, préciser le rôle des intervenants des différentes parties pour le suivi de l avancement, organiser les réunions du comité de pilotage. Planning prévisionnel : Mardi 16/01 Jeudi 25/01 Présentation des projets par les clients Réponse à l appel d offre Mardi 06/03 Initialisation Mardi 03/04 Elaboration 1 Lundi 04/06 Documentation Vendredi 08/06 Construction, livraison finale 5

7 Organisation du projet : Un comité de direction et de pilotage a été constitué. Tous les mercredis après-midi aura lieu une réunion de comité de pilotage A chaque fin de phase, une réunion de comité directeur aura lieu (Exemple : 1 er et 2 nd avancement) Evaluation des charges : Phase Partie 1 : Préparation de l environnement de travail Partie 2 : Récolte des informations Partie 3 : Gestion autonome du réseau (programme java) Partie 4 : Documentation Tests unitaires Total Temps réalisation des fiches (en jour/personne) 5 j 25 j 10 j 5 j 5 j 50 j 6

8 IV. Architecture globale Après analyse du projet et validation du client, nous avons conçu l architecture globale ci-dessus : UC 3 UC 1 UC 4 UC 2 Pour mieux comprendre la suite du rapport, notamment les cas d utilisation, nous avons représenté ces derniers sur le schéma de l architecture globale. UC 1 : Récupérer les mesures UC 2 : Vérifier les paramètres UC 3 : Afficher les données UC 4 : Configurer le réseau Ces cas d utilisation sont décrits plus en détails dans le chapitre suivant. 7

9 V. Conception 1. Cas d utilisation et diagrammes des séquences Dans cette partie, nous allons décrire les cas d utilisation. Depuis la dernière réunion certaines modifications ont été apportées. Attention, le premier cas d utilisation est de niveau stratégique (haut niveau), c'est pour cela qu il regroupe l ensemble des cas d utilisation de niveaux inférieurs. SYSTEM : La station de surveillance et les routeurs PRIMARY ACTOR : Le serveur VoIP Astérisk USE CASE GENERAL: Auto-configuration d'un réseau VoIP SCOPE : Système de maintient de qualité de service d'un réseau informatique LEVEL : Stratégique INTENTION IN CONTEXT : Le cas étudié est la voix sur IP PRIMARY ACTOR : Le serveur VoIP Astérisk MAIN SUCCESS SCENARIO : 1. Récupérer les mesures 2 : Vérifier les paramètres 3 : Afficher les données 4. Configurer le réseau EXTENSIONS : 1.a Les données ne parviennent pas. Essayer à nouveau et au bout de X tentatives, échec de l UC Informer l administrateur du réseau par mail 3.a Les paramètres sont dépassés, le UC poursuit en 5 3.b Les paramètres ne sont pas dépassés, le UC reprend en 1 8

10 USE CASE 1 : Récupérer les mesures SCOPE : Système de maintient de qualité de service d'un réseau informatique LEVEL : Objectif-utilisateur INTENTION IN CONTEXT : Le client iperf envoie des mesures spécifiques au système. PRIMARY ACTOR : Le serveur VoIP Asterisk MAIN SUCCESS SCENARIO : 1. Exécuter les commandes prédéfinies sur les différents clients 2. Traiter le résultat des données obtenues EXTENSIONS: 2.a Les données ne parviennent pas. Essayer à nouveau, au bout de X tentatives, échec de l'uc. Envoyer un mail à l'administrateur. Les scripts qui permettent de relever les mesures seront exécutés toutes les trente secondes sur chaque client à l aide de la table crontab. Le diagramme suivant illustre les cas d utilisation 1 et 2. Le réseau et les bases de données sont les acteurs secondaires. Les données relevées sont en réalité les réponses des commandes exécutées sur les clients. Le traitement des données permet de les purger afin de ne retenir que l information (valeur) dont on a besoin. Il faut également les formater pour pouvoir les insérer dans la base de données. 9

11 Base de données Système Réseau Le système attend de nouvelles mesures Exécuter la commande pour relever les mesures Envoie des mesures relevées Insertion des données Traiter les données obtenues Confirmation (OK, Echec) Le système attend de nouvelles mesures Envoie des mesures relevées Exécuter la commande pour relever les mesures Traiter les données obtenues USE CASE 2 : Vérifier les paramètres SCOPE : Système de maintient de qualité de service d'un réseau informatique LEVEL : Objectif-utilsateur INTENTION IN CONTEXT : Le système vérifie que les mesures récupérées ne dépassent pas certains seuils. PRIMARY ACTOR : Le serveur VoIP Asterisk MAIN SUCCESS SCENARIO : 1. Le système attend l enregistrement de nouvelles mesures dans le fichier 2. Le système compare les nouvelles mesures aux seuils définis par l utilisateur. EXTENSIONS : 1.a. Aucune nouvelle donnée n a été enregistrée, le UC reprend à l'étape 1 2.a. Les seuils sont dépassés. On poursuit à l'uc n 5 2.b. Les seuils ne sont pas dépassés, on reprend à l'uc n 1 10

12 USE CASE 3 : Afficher les données SCOPE : Système de maintient de qualité de service d'un réseau informatique LEVEL : Objectif-utilisateur INTENTION IN CONTEXT : Le système affiche les données récoltées à partir des clients. PRIMARY ACTOR : Le serveur VoIP Asterisk MAIN SUCCESS SCENARIO : 1. Sélectionner les données à afficher (dernière ligne du fichier) 2. Afficher les données dans l interface principale java EXTENSIONS: 1.a Le système n arrive pas à lire le fichier. Au bout de X tentatives, informer l administrateur par mail. Le UC se termine en échec 2.b Aucune donnée n est sélectionnée. Ne rien faire, on reprend à l UC 1 On suppose que la fenêtre d affichage est l ihm principale, la demande d affichage dépend de ce que l administrateur souhaite voir (historique, ) On suppose que le système (programme java) est toujours connecté à la base de données. Administrateur Système Base de données Demande d affichage Sélection des données Réponse sélection Afficher les données 11

13 USE CASE 4 : Autoconfigurer le réseau SCOPE : Système de maintient de qualité de service d'un réseau informatique LEVEL : Objectif-utilsateur INTENTION IN CONTEXT : Quand les paramètres minimaux du réseau sont dépassés, le système exécute des scripts sur les routeurs afin de rétablir le service. PRIMARY ACTOR : Le serveur VoIP Asterisk MAIN SUCCESS SCENARIO : 1. Identifier les scripts à exécuter 2. Identifier les routeurs sur lesquels il faut exécuter ces derniers 3. Se connecter au(x) routeur(s) 4. Exécuter les scripts 5. Sauvegarder les résultats d'opération dans le log du Système. EXTENSIONS : 1.a les scripts correspondants n'existent pas, envoyer un mail à l administrateur. L UC se termine en échec. 3.a La connexion au(x) routeur(s) a échoué, envoyer un mail à l administrateur. L UC se termine en échec. 4.a Les scripts ne se sont pas correctement exécutés. Le UC reprend à l étape 1. Au bout de X tentatives, envoyer un mail à l administrateur. Les cas d utilisation 4 et 5 sont illustrés par le diagramme ci-dessous. 12

14 Base de données Système Réseau Mesures relevées Vérification des paramètres Récupérer les scripts Identifier les scripts à exécuter Envoie des scripts Identifier les routeurs sur lesquels exécuter les scripts Se connecter aux routeurs (Telnet) Connexion OK Envoie des scripts Confirmation (OK, Echec) Sauvegarder l opération dans le fichier log Exécuter les scripts 13

15 2. Diagramme de flux 14

16 3. Diagramme de classes 15

17 VI. Réalisation 1. Tester les performances du réseau Durant nos tests, nous avons rencontré des difficultés pour perturber la qualité de la voix. En effet le problème est que le routeur bénéficie d une file d attente importante et que les paquets de la voix sur IP arrivaient tout de même à passer (avec certes un léger retard). Pour remédier à ce problème nous avons annulé la file d attente grâce à la commande suivante : no fair-queue Ensuite nous avons diminué la bande passante jusqu à trouver la bande passante minimum qui nous permette d avoir une qualité correcte de la voix. La commande suivante nous permet de diminuer la bande passante (à exécuter évidement sur les routeurs) : clock rate Le tableau ci-dessous montre les résultats que nous avons obtenus : Bande passante (kbits/s) Niveau de qualité de la voix 32 Très mauvaise Mauvaise Moyenne Bonne Bonne 0 Retard (seconde) La bande passante qui nous permet donc d obtenir un niveau de qualité correcte (bonne qualité de la voix et sans retard) est de 115 kbits/s. Comme iperf (défini dans la suite) envoie massivement des paquets sur le réseau. Nous choisissons finalement une bande passante minimum de 128 kbits/s. Cela nous permet d avoir une qualité correcte de la voix avec le trafic généré par plusieurs clients iperf. 16

18 Comment dégrader la voix? L outil ping nous permet de surcharger le réseau afin de dégrader la voix. En effet la commande ping f permet l envoie massif de paquets ICMP vers la machine Deux fichiers au format mp3 sont disponibles sur le site du projet aux adresses : - Avant de flooder le réseau : - Après avoir foodé le réseau : 2. Récupérer les mesures du réseau L outil que nous utilisons pour relever les performances de notre réseau est IPERF. Cet outil disponible sur de nombreuses plateformes (Linux, BSD, Mac, Windows), se présente sous la forme d une ligne de commande à exécuter sur deux machines disposées aux extrémités du réseau à tester. Il est basé sur le modèle client / serveur selon le diagramme suivant : Cet outil nous permet de relever l ensemble des paramètres critiques à la VoIP (gigue, bande passante, perte de paquet). Cependant cet outil présente un inconvénient qui est qu on doit le lancer manuellement à chaque nouvelle mesure. La solution que nous avons trouvé pour remédier à ce problème est de créer un script iperf et de le rajouter dans crontab. Le script iperf (sans extension) se trouve en annexe (II.1). 17

19 La structure de crontab est la suivante : Minute Heure Jours Semaine Mois script * * * /home/tp/iperf Cela signifie que le script sera lancé : - Toutes les minutes - De 9 H 00 à 18 H 00 - Du lundi au vendredi (0 indique le dimanche) - Toutes les semaines - Tous les mois Par ailleurs, pour recevoir les données des clients iperf, il faut démarrer le serveur iperf grâce à la commande suivante : iperf s u f m > iperf.txt -s : signifie qu il s agit du serveur -f m : indique que les données relevées vont être converties en Mégabits (kilobits par défaut) > iperf.txt : signifie que les données relevées vont être enregistrées dans un fichier iperf.txt. Cette commande peut être écrite dans un fichier script, ainsi de la même manière que pour le client iperf on peut utiliser crontab pour que le script soit lancé 7 heures par jour. Le fichier iperf.txt est écrasé à chaque nouvelle insertion. 18

20 3. Auto-configurer le réseau Lorsque le système détecte un dépassement de l un des seuils. Celui-ci se connecte sur chacun des routeurs et relève le taux de congestion du routeur en question (correspond à l étape Identification du routeur). Ensuite on exécute un script sur le routeur qui permet de marquer les paquets en fonction de leur protocole. Puis on exécute un troisième script qui permet de traiter les paquets propres à la voix sur IP en priorité. C est le principe de DiffServ que nous mettons ici en place. Pour établir une qualité de service il faut tout d'abord sélectionner les flux qu'on veut différencier. Pour cela on utilise une certaine technique de filtrage disponible dans l'ios du routeur CISCO qui est l'utilisation d'acls (Access Control List). L ensemble des scripts d auto-configuration commentés se trouve en annexe. SETDSCP.script : Permet de marquer le flux, marquer le type de paquet en fonction du protocole utilisé. class-map : Permet de classifier le flux en suivant une politique de priorité des paquets propres à la voix sur IP. VOIP.script : Permet de relever le taux de congestion sur le routeur, la bande passante et la perte de paquet. 19

21 VII. Environnement de travail Comme prévu dans la réponse au cahier des charges, nous nous sommes réparti les tâches selon les compétences. Nous avons donc décider de créer deux groupes, un groupe plutôt orienté système et réseau et un groupe orienté développement. Le premier groupe est chargé de l installation de l environnement de travail (installation du serveur VoIP, routeurs, PostgreSQL). Le second groupe s est penché sur la conception de l interface graphique. 1. Installation du serveur VoIP Asterisk Nous avons installé avec succès le serveur VoIP sur Linux Debian. Ci-dessous la démarche que nous avons suivie : 1. Pré-requis : Les packages suivants doivent être installés avant de procéder à l'installation d'asterisk - Linux 2.4 kernel sources ( - bison et bison-devel ( - ncurses et ncurses-devel - zlib et zlib-devel - openssl et openssl-devel 2. Télécharger les sources à cette adresse : 3. décompresser les sources : # tar zxvf asterisk tar.gz 4. Compilation des sources : # cd asterisk #./configure # make # make install # make samples # make progdocs 5. Pour lancer Asterisk en mode console : # /usr/sbin/asterisk -c 20

22 Pour la configuration, étant donné que nous n allons pas utiliser de carte voix (pour la connexion de ligne analogique France télécoms). Nous allons utiliser que deux fichiers de configuration parmi la dizaine qu utilise Asterisk. Ces fichiers sont sip.conf pour l ajout de clients VoIP et le fichier et extensions.conf pour le plan de routage. Nous avons choisi le protocole sécurisé de VoIP SIP. C est pour cela que nous modifions le fichier sip.conf. Par la suite nous n utilisons que les commandes commençant par sip (help pour les lister). Création d un utilisateur (ClientA, n d appel 101, mdp password) dans le fichier sip.conf : [general] context=default srvlookup=no [ClientA] type=friend username= ClientA secret=password Callerid : "" <101> quality=yes nat=no canreinvite=no auth=md5 host=dynamic dtfmode=rfc2833 allow=ulaw context=internal Création d un utilisateur (ClienB, n d appel 102, mdp password) [general] context=default srvlookup=no [ClientB] type=friend username= ClientB secret=password Callerid : "" <102> quality=yes nat=no canreinvite=no auth=md5 host=dynamic dtfmode=rfc

23 allow=ulaw context=internal La commande sip show users nous confirme la création des utilisateurs : Username Secret Accountcode Def.Context ACL NAT ClientA password internal No RFC3581 ClientB password internal No RFC3581 Ci-dessous notre plan de routage qui se trouve dans le fichier extensions.conf. ; ClientA exten => 101,1,wait(1) exten => 101,2,Dial,SIP/ ClientA exten => 101,3,Hangup ; ClientB exten => 102,1,wait(1) exten => 102,2,Dial,SIP/ ClientB exten => 102,3,Hangup 2. Installation du serveur base de données Nous avons choisi PostgreSQL comme serveur de base de données car ce dernier est facile à installer et ne demande pas énormément de ressources (contrairement à Oracle). De plus il est très bien documenté sur Internet (contrairement à MySQL). Ci-dessous la démarche que nous avons suivie : 1- Téléchargement des sources : apt-get install postgresql 2- Démarrer le serveur : /sbin/service postgresql start 3- Dans le fichier /var/lib/pgsql/data/postgresql.conf, décommeneter la ligne : tcpip_socket = true 4- L utilisateur postgres est créé par défaut (mdp posgres). C est le seul utilisateur autorisé à se connecter à la base. 5-Créer une base de données voip_db : psql createdb voip_db 22

24 6- Démarrer la base de données : psql -d voip_db 7- Créer la table monitor dans laquelle seront sauvegardées les informations relevées lorsque les seuils sont dépassés. On sauvegarde dès que le seuil d un paramètre est dépassé. Le script de création de la table se trouve en annexe (I.1). Ci-dessous la structure de la table Attribut ID Bande passante Gigue Perte de paquets Date Type serial Varchar Varchar Varchar Varchar L attribut ID est la clé primaire. Il est de type serial, ce qui signifie que c est une séquence. ID sera incrémenté à chaque nouvelle insertion dans la table. 3. Installation du réseau Nous avons essayé de construire un réseau complexe pour reproduire les conditions et les contraintes d un vrai réseau d entreprise voir du réseau Internet. Le schéma ci-dessous montre le «câblage» que nous avons effectué : 23

25 Configuration des routeurs Pour réaliser notre projet nous disposons de deux switchs ainsi que de quatre routeurs fournis par le client. Il s agit de routeurs CISCO 1841 qui possèdent trois interfaces en état de fonctionnement : - 2 interfaces Ethernet - 1 interface série Tout d abord nous avons besoin d affecter une adresse IP à l une des interfaces réseau pour qu on puisse y accéder en Telnet à partir du réseau. Pour cela on se connecte directement sur le port console du routeur à partir du port série de notre PC portable. La vitesse d Hyperterminal est de 9800 bauds. Interface série Port console Voici les commandes à saisir pour chaque routeur : Attribuer un nom au routeur : hostname voip_r1 Indiquer l interface concernée eth0 : line vty 0 Attribuer un login au routeur : voip_r1(config-line)#login Attribuer un mot de passe : voip_r1(config-line)#password cisco Sortir du mode config-line : voip_r1 (config-line)#exit Pour sauvegarder la configuration : copy running-config startup-config Il faudra effectuer la même opération sur les autres routeurs voip_r2, voip_r3 et voip_r4. La configuration de l ensemble des routeurs est détaillée en annexe (I.2). 24

26 4. Inter-opérabilité des composants Pour que nos différents composants (serveur, base de données, routeurs) puissent communiquer entre eux, il faut télécharger les modules suivants : JDBC : La technologie JDBC (Java DataBase Connectivity) est une API fournie avec Java (depuis sa version 1.1) permettant de se connecter à des bases de données. L'API JDBC a été développée de telle façon à permettre à un programme de se connecter à n'importe quelle base de données en utilisant la même syntaxe, c'est-à-dire que l'api JDBC est indépendante du SGBD. De plus, JDBC bénéficie des avantages de Java, dont la portabilité du code, ce qui lui vaut en plus d'être indépendant de la base de données et de la plate-forme sur laquelle elle s'exécute. On pourrait croire que ce module est téléchargeable sur le site de SUN puisqu il s agit de java mais au contraire, c est sur le site de PostgresSQL que nous avons trouvé ce dernier. Dans notre programme java, nous indiquons ensuite le chemin où se trouve ce module. Apache : Ce module va nous permettre de nous connecter sur le routeur via une session Telnet. Ensuite on pourra relever le taux de congestion et exécuter les scripts d auto-configuration sur les routeurs. De même que pour le module JDBC il faudra indiquer le chemin où se trouve ce module dans notre programme java. Ce module est évidement téléchargeable sur le site du développeur Apache. 25

27 VIII. Documentation 1. Guide de l utilisateur Le terme utilisateur désigne ici la personne qui va utiliser le service VoIP et qui souhaite bénéficier d un niveau de qualité de service correct. Dans cette partie nous allons donc décrire comment se connecter tout d abord au serveur VoIP puis la procédure à suivre pour bénéficier d un bon niveau de QoS. Cette partie peut sembler inutile mais avec la topologie réseau et la configuration du serveur qui semblent assez complexes, il est important que les clients soient bien configurés pour identifier le problème. a) Se connecter au serveur Pour se connecter à notre serveur VoIP il faut un logiciel (client) supportant le protcole SIP. Nous avons choisi Xlite, disponible sous différentes plateformes à l adresse suivante : Puis nous avons suivi la démarche suivante : 1 - Décompresser le fichier X-Lite_Install.tar.gz 2 - Dans le répertoire X-Lite_Install exécuter xtensoftphone 3 Configurer le ClientA créé précédemment dans le serveur en cliquant sur «Menu» / «System Settings». Ensuite saisir les informations nécessaires comme le montre la figure ci-dessous : Fenêtre principale X-lite 26

28 Fenêtre de configuration Rappel : L adresse IP de notre serveur VoIP est b) Bénéficier d un bon niveau de QoS Pour bénéficier du service, il faut que le client dispose de l outil iperf qui est téléchargeable à cette adresse : On suppose que le client est sous plateforme Linux. Cela nous permettra de lancer le client toutes les 30 secondes à l aide de crontab. Le client iperf enverra les caractéristiques réseau au serveur iperf qui se trouve sur la machine de surveillance. Les scripts pour cette partie se trouvent en annexes. 27

29 2. Guide de l administrateur Le terme administrateur désigne la personne qui sera responsable de la qualité de la VoIP sur le réseau. Il s agit en général de l administrateur réseau. L administrateur peut télécharger le logiciel à l adresse suivante : Au cours de notre projet, nous avons abandonné l idée d une interface graphique sous la forme d un simple fichier XML au profit d une interface java plus conviviale. Nous proposons l interface graphique ci-dessous que nous avons élaborée avec le client : Fenêtre principale Nous avons choisi d afficher les trois critères de qualité de service liés à la VoIP dans la console principale, ce qui permet à l administrateur d y accéder très facilement. Ainsi, avec un seul coup d œil l administrateur du réseau peut superviser le réseau. 28

30 Par ailleurs, dans la partie supérieure de l interface, nous avons représenté par des boutons les fonctionnalités les plus importantes pour l administrateur. Il suffira donc pour l administrateur de cliquer sur le bouton souhaité pour accéder facilement à sa fonctionnalité. Comme par exemple la fonctionnalité «Historique» qui permet de consulter la base de données et d afficher l historique des dépassements de seuils. Fenêtre pour l historique Par défaut les seuils sont initialisés à : - bande passante : 1.10 Mbits/s - gigue : 2 ms - perte de paquets : 2% Néanmoins un simple click sur le bouton «configurer» permet de saisir de nouveaux seuils. Fenêtre de configuration 29

31 Fenêtre de saisie des seuils En cliquant sur le bouton «exporter», on pourra exporter les données affichées dans l historique sous un format exploitable (au format txt). Fenêtre exporter Le bouton «actualiser» permet d actualiser l affichage de la fenêtre principale. En effet les paramètres (gigue, bande passante, perte de paquet) sont affichés sur la console principale toutes les 30 secondes. Cliquer sur le bouton «actualiser» permet d outrepasser ce délai. Le bouton «Manuel» est un simple lien vers la documentation. Cette documentation n est autre que ce rapport au format PDF. Le bouton «imprimer» n est pas pour le moment fonctionnel. Ce dernier aura pour objectif d imprimer l historique de dépassement des seuils. (on pense qu il sera fonctionnel pour le jour de la présentation). 30