Projet de Diplôme. CAMAC-Call Machine. Simulateur de charge pour central VoIP

Transcription

1 Projet de Diplôme CAMAC-Call Machine. Auteur : Professeur: Markus Jaton Mandataire : Cédric Ducommun, Ingénieur télécommunication HES Entreprise Flückiger SA à St. Blaise Date : 17 décembre 2007

2 1. Table des matières 1.Cahier des charges Résumé du problème Cahier des charges Résumé Introduction...7 Cadre de travail...7 Structure du rapport Analyse des besoins et choix des technologies Analyse des besoins Les applications externes à intégrer au projet La problématique de la simulation de charge L'interface graphique Le rendu des résultats Choix des technologies Outil de test de performance SIPp de HP [1] Caractéristiques Analyseur de trafic Wireshark Base des données MySQL Introduction aux technologies VoIP et ISDN Concept VoIP Les principaux protocoles VoIP Les protocoles RTP et RTCP Concept SIP...12 Les messages SIP...12 Les Terminaux SIP...14 Transactions SIP Solution PABX-IP pour la VoIP Le PABX Asterisk [4]...15 Etablissement de session audio avec le PABX Asterisk Caractéristiques de la technologies ISDN Canaux logiques Interfaces standards ISDN Analyse du fonctionnement Architecture du projet Ensemble des fonctionnalités Module de gestion du déroulement de la simulation Diagramme de contexte du déroulement de la simulation Complexités de l'exécution de l'application...21 Le démarrage de l'application...21 La terminaison de l'application Module de gestion de la génération du trafic L'établissement du trafic Le dimensionnement de la charge à générer Scénarios de simulation...23 Tâches confiées aux agents SIPp

3 Diagramme d'activités du déroulement de la simulation Module de gestion de l'analyse du trafic Point d'analyse du trafic et de collecte des résultats Résultats de simulation Module de gestion d'accès à la base des données Schéma conceptuel de la base des données MySQL Représentation graphique des résultats Réalisation Module de gestion de la génération du trafic Choix des technologies Implémentation Module de gestion de l'analyse de trafic Choix des technologies Implémentation Diagramme d'activités du traitement des captures Wireshark...30 Création du pipe et déroulement de la tâche de stockage des résultats...33 Le parser XML Diagramme des classes Module de gestion de la base de données...34 Gestion de la base de données...34 Exploitation des résultats et méthode de représentation graphique Module de gestion du déroulement de la simulation Implémentation...35 Exécution des modules de lancement de l'application Connexion de contrôle à distance Contrôle de la synchronisation au démarrage et du déroulement de l'application...36 Contrôle de la terminaison de l'application Diagramme UML des classes implémentées Interface graphique...38 Gestion de l'évènement démarrer à partir de l'interface graphique Tests de fonctionnement Tests des fonctionnalités Tests unitaires Test de fonctionnement de l'application...41 Exemple d'exploitation des résultats de test Conclusion Améliorations...44 Résultats de simulations...44 Scénarios...44 Ajout d'un application de représentation et de contrôle des données de simulation Remerciements Annexes...46 L'outil SIPp [1]...46 Commandes d'exécution SIPp...46 Fichiers d'installation d' Asterisk et configurations...46 La librairie XERCES C Base de données MySQL Journal de travail Index des figures

4 15. Bibliographie

5 1.Cahier des charges CAMAC Call Machine. Proposé par : Flückiger SA à St. Blaise 1.1 Résumé du problème En cas de surcharge, le comportement d un central téléphonique (et d un PABX) devient erratique, parfois même imprévisible. Il en va ainsi de la majorité des systèmes d exploitation : lorsqu ils sont stressés au-delà du raisonnable, on voit apparaître des phénomènes imprévus, dûs à d obscures concurrences d activités dont personne n avait jamais eu l occasion de tester le fonctionnement parallèle. Ainsi, lors d une célèbre panne de réseau en 1992, il n était plus possible de téléphoner, ni même d effectuer une opération de maintenance qui eût permis de rétablir l ordre, parce que la surcharge se manifestait au niveau du réseau de signalisation, considéré comme prioritaire, et que le central refusait toute autre entrée, car il était à traiter des millions de messages de signalisation entrant. Toute la Suisse Romande et une partie de la Suisse Alémanique fut ainsi privée de service téléphonique suite à une défaillance dans un central particulier à Lausanne. Le fait qu on ait changé de technologie n a pas changé le mode de fonctionnement des utilisateurs du service de téléphonie, et une surcharge reste une surcharge. Comment réagit un PC équipé du logiciel Asterisk sous Linux dans une situation analogue? Et, plus intéressant, dans quelle mesure pourrait-on améliorer le comportement d Asterisk (par configuration, ou par modification du logiciel) de manière à ce que ses réactions aux surcharges s améliorent? Plus intéressant encore, quelles retombées économiques pour une PME ayant dans les mains un outil permettant de valider une installation Asterisk dans une configuration précise, et à même de certifier les installations qu elle livre avec une garantie écrite de bon fonctionnement? 1.2 Cahier des charges Le but de ce travail est de parvenir à générer des situations de charge et de surcharge sur un central téléphonique équipé du logiciel de commutation Open Source Asterisk. Le central cible (Device Under test, DUT) sera dimensionné et fourni par l'entreprise Flückiger SA à St. Blaise. Le simulateur permettra de simuler du trafic SIP/RTP aussi bien que du trafic ISDN. Les divers paramètres à fournir au simulateur de trafic, les résultats attendus de la simulation, ainsi que le schéma-bloc de fonctionnement sont décrits dans le document cité en annexe

6 2. Résumé Dans une entreprise ou une université, on distingue deux réseaux, le réseau de données purement IP sur Ethernet et un réseau téléphonique autour d'un centrale téléphonique privé ou PABX (Private Automatic Branch exchange - Autocommutateur téléphonique privé ). Actuellement, avec l'essor de la VoIP (Voice over IP-Voix sur IP), de plus en plus de constructeurs de centraux téléphoniques offrent des équipements qui combinent les fonctionnalités téléphoniques classiques et celles de la voix sur IP ( équipement appelé PABX-IP). Les appels VoIP sont ainsi commutés sur des lignes internes et les utilisateurs peuvent également partager un certain nombre de lignes externes. Il serait ainsi intéressant de voir dans quelle mesure ce type de centraux sont résistants à une montée en charge lorsqu'un grand nombre d'appels téléphoniques sont effectués simultanément. Dans ce cadre, ce projet se propose de se mettre dans une configuration d'une entreprise avec un PABX-IP, de créer un simulateur de charge qui permet de simuler un trafic d'appels VoIP avec les protocoles de VoIP SIP/RTP et un trafic externe avec le protocole ISDN

7 3. Introduction Cadre de travail Le projet de simulateur de charge à réaliser à été proposé par l'entreprise Flückiger SA à St. Blaise dans le but de tester leur central voix sur IP (VoIP). Une simulation en charge apporte des informations sur le comportement du central. Ces informations peuvent être utilisées pour anticiper les situations de surcharges et prendre des mesures de corrections. Une simulation en charge peut également servir à comparer deux équipements et faire un choix. Une telle simulation sera effectuée en générant de nombreux appels téléphoniques simulés à l'aide d'un générateur d'appels à destination du central téléphonique à tester, puis en observant la capacité du central à gérer tous les appels. Bien que le principe en lui-même soit simple, les technologies à appliquer dans une telle simulation sont peu répandues et très souvent propriétaires, donc coûteuses. Ce travail de diplôme a pour but d'étudier quelles sont les technologies ouvertes et gratuites qu'il est possible d'utiliser pour effectuer une telle simulation, puis de mettre en place un simulateur fonctionnel en fonction des technologies trouvées. Structure du rapport Ce travail de diplôme comprend une partie théorique et une partie de développement. Dans le chapitre 4 nous faisons une analyse des besoins et des choix de technologies par rapport au cahier des charges. Le chapitre 5 introduit les technologies VoIP et ISDN. Cette introduction est nécessaire afin de comprendre les concepts théoriques de ces technologies, les principes du trafic SIP/RTP et ISDN à mettre en place et de situer le PABX dans cette architecture réseau. L'étude du fonctionnement du simulateur, des contraintes imposées par les fonctionnalités et la recherche des moyens d'élaboration est faite dans le chapitre 6 Le chapitre 7 est consacré à réalisation d'une solution, on y présente la logique d'implémentation, les choix des technologies et les réponses aux contraintes imposées par les fonctionnalités. Seule le trafic SIP/RTP sera simuler. En effet le centrale téléphonique de test n'a pas pu être livré et il est impossible de mettre en place un trafic ISDN sans le centrale téléphonique. Pour finir dans le chapitre 8 des tests de fonctionnement du simulateur développé seront présentés

8 4. Analyse des besoins et choix des technologies 4.1 Analyse des besoins Les besoins attendus par rapport au cahier des charges concernent les parties suivantes: Les applications externes à intégrer au projet La problématique de la simulation de charge L'interface graphique Le rendu des résultats Les applications externes à intégrer au projet L'une des contraintes du simulateur à développer est l'utilisation d'outils Open Source existants. Ainsi l'architecture de l'application devra intégrer autant que possible des solutions open source La problématique de la simulation de charge Commençons par donner une définition du trafic en télécommunication : le trafic est un phénomène directionnel, en ce sens qu'il met en jeu une source (ayant généré la sollicitation) et un destinataire, qui est un utilisateur auquel s'adresse la sollicitation (événement ponctuel, sans durée associée, qui peut ou non conduire à une occupation). Le fait que l'occupation (état ayant une durée associée) résultante de la sollicitation donne lieu à un échange bidirectionnel d'informations n'a pas d'incidence sur le sens du trafic, ce dernier étant défini par rapport à la seule sollicitation. Par rapport au trafic à générer, afin d'offrir à l'utilisateur la possibilité de simuler différentes situations de charge, nous énumérons les besoins attendus suivants : le simulateur de trafic doit pouvoir générer un trafic dynamique, c'est à dire offrir une flexibilité au niveau de la charge à générer et pouvoir intégrer des scénarios de simulation. D'où les contraintes suivantes : pouvoir générer un trafic de masse c'est à dire un nombre élévé d'appels dans une espace de temps cours. pouvoir varier les paramètres de simulations par rapport aux appels à générer, des paramètres tels que le taux d'appels (nombre d'appels par seconde), le nombre d'appels, la durée de simulation, etc. l'inter-connection par le central téléphonique des réseaux VoIP et ISDN implique définir le sens du trafic à simuler : - 8 -

9 trafic interne dans le réseau VoIP : de SIP/RTP vers SIP/RTP trafic du réseau VoIP vers le réseau ISDN : de SIP/RTP vers ISDN (et inversement) L'interface graphique L'interface graphique est le point d'entrée de l'application. Elle doit permettre à l'utilisateur de saisir les paramètres de simulations. Le lancement de l'application se fera également à partir de cette interface Le rendu des résultats L'intérêt majeur des tests en charge du central téléphonique est de pouvoirs déterminer le comportement du central lorsqu'il s'approche de son seuil critique de fonctionnement. Ainsi tout au long de la simulation, nous allons suivre de bout en bout tous les différents évènements (début, échec, fin...) qui peuvent intervenir lors des appels générés, et constituer une banque de données. Cette banque de données sera exploitée en fin de simulation suivant les objectifs de tests, et à partir de l'exploitation des données de simulation, le résultat de test sera représenté sous forme de graphiques. 4.2 Choix des technologies Les technologies décrites ont été introduites lors du pré-projet de diplôme. Dans le chapitre 7, nous expliquerons comment ces technologies ont été intégrées à l'application. D'autres technologies seront présentées également dans ce même chapitre Outil de test de performance SIPp de HP [1] Cet outil, par ses caractéristiques de fonctionnement, répond aux besoins liés à la simulation de trafic énoncés dans le chapitre 4. Nous présentons ici ces caractéristiques Caractéristiques SIPp est une plate-forme logicielle Open Source, plate-forme fonctionnant sur un système Linux et dédiée au test de performance basé sur le protocole SIP. SIPp permet d'établir et de terminer des multiples sessions SIP sur le protocole UDP. Il supporte également le protocole RTP, plus précisément il reproduit le flux RTP enregistré dans un fichier défini selon le format de flux audio pcap. Nous notons différentes options pour paramétrer le trafic généré. Il est également possible d'interagir avec le processus de l'application via un port UDP et d'agir (augmenter, diminuer, diviser le nombre d'appels) sur la charge du trafic en cours de simulation. SIPp implémente un «user agent client» (UAC) et un «user agent serveur» (UAS) qui sont les deux terminaux qui s'échangent les messages SIP. Ils seront appelés dans la suite client SiPp et serveur SIPp. La description des scénarios de test est faite en language XML. SIPp inclut des scénarios de test par défaut. SIPp peut également interpréter des scénarios externes définis dans le language XML ou via un script Shell

10 La sortie des statistiques (taux d'appels et statistiques sur les messages des protocoles échangés) du trafic généré est listée dynamiquement sur la console. Ces statistiques peuvent également être stockées dans des fichiers au format CVS. Ces statistiques étant assez globales, celles ci ne sont pas suffisamment significatives pour être collectées. Pour mon projet, j'ai noté principalement deux faiblesses par rapport à cet outil : L'absence d'api (Application Programming Interface) qui permettrait de l'inclure facilement dans notre application. Une alternative sera présentée dans le chapitre 7. La non-gestion de la durée globale d'une simulation, SIPp ne pouvant en effet que gérer le nombre maximal d'appels et la durée de chaque appel Analyseur de trafic Wireshark Wireshark est un outil d'analyse réseau qui va nous permettre d'analyser de bout en bout, c'est à dire de suivre de l'émission à la réception le trafic VoIP établi lors des tests en charge. Wireshark est un analyseur de trafic Open Source sous licence GPL, il supporte de nombreux protocoles dont ceux de la VoIP et dispose des fonctionnalités avancés pour l'analyse de ces protocoles. Cet analyseur peut être lancé en mode graphique avec une interface graphique ou encore en ligne de commande sans interface. Wireshark offre différentes options de filtrage à définir soit avant ou après la capture du trafic. Il permet également de formater la sortie des trames capturées Base des données MySQL Dans la mesure où l'application génère des résultats de simulation, il est utile de disposer d'une structure de stockage des résultats qui permette de manipuler facilement ces résultats. Mon choix s'est porté sur le système de gestion de base de données MySQL. MySQL est un serveur de base de données Open Source multi-plate-forme supportant le language relationnel SQL. Avec MySQL, nous disposons d'une structure flexible et ses fonctionnalités permettent de manipuler facilement les données ( insertion, recherche...)

11 5. Introduction aux technologies VoIP et ISDN 5.1 Concept VoIP Couramment utilisé sur internet et dans les réseaux privés, le protocole IP est devenu plus qu'un moyen de routage des données sur les réseaux. Il est désormais utilisé pour le transport de la voix. La technologie VoIP (Voice over IP - Voix sur IP) permet ainsi à la voix de devenir rien de plus qu'une nouvelle application dans le réseau des données IP. Différentes solutions de VoIP sont présentes sur le marché ; parmi ces solutions nous avons entre autres les solutions personnelles telles que Skype, les équipements PABX purement IP ou Hybride Les principaux protocoles VoIP La voix et les informations de signalisation utiles à l'établissement de la transmission sont ainsi transportées sur le réseau IP. Plus précisément le signal numérique obtenu par numérisation de la voix est découpé en paquets qui sont transmis sur un réseau IP vers une application qui se chargera de la transformation inverse (des paquets vers la voix).[2] Nous abordons brièvement les protocoles de la VoIP utilisés dans le projet. Figure 1: Principaux protocoles de la VoIP Le protocole UDP (User Datagram Protocol) est un protocole de couche réseau utilisé dans la couche IP, il minimise la surcharge associée au transfert de chaque donnée en acheminant les paquets en mode datagramme, sans contrôle d'erreurs ni contrôle de flux. Le protocole UDP met à profit cette simplicité du service réseau pour offrir aux applications un service de transport de données simple et sans connexion, particulièrement adapté aux applications nécessitant un traitement rapide de la part des équipements du réseau, mais autorisant un taux de perte de paquets modéré. C'est le cas de la plupart des applications de transport de la voix sur IP

12 Les protocoles RTP et RTCP Dans les réseaux VoIP, la synchronisation de bout en bout doit être garantie. Cette tâche est confiée aux protocoles RTP et RTCP. Le RTP (Real-time Transport Protocol) permet d'assurer un service de remise bout en bout pour les données ayant des caractéristiques de temps réel, telles que les données audio et vidéo interactives. Ce service inclut l'indication du type de codage de l'information transportée, la numérotation des séquences, l'ajout des marqueurs de temps et le contrôle de la remise. Par contre, il ne garantit pas le bon acheminement des paquets, ni une quelconque qualité de service. [3] Le RTCP (Real-Time Transport Control Protocol) est le protocole de contrôle des flux RTP. Il transmet périodiquement des informations de contrôles entre les participants à une session comme les statistiques de réception et d'émission, informations indicatives de la qualité de service Concept SIP Le protocole SIP (Session Initiation Protocol ), décrit par la RFC 3261, est un protocole de signalisation appartenant à la couche application du modèle OSI et qui utilise le port SIP peut être transporté par UDP ou TCP. Ce protocole (basé sur le protocole HTTP : hypertext transfert protocol) est utilisé pour créer, modifier et terminer des sessions. Une session est l'ensemble d'émetteurs et récepteurs qui communiquent entre eux, ainsi que l'état à conserver pendant la communication. Une session peut inclure des appels téléphoniques Internet, une distribution multimédia, une conférence multimédia contenant un participant ou plus. SIP ne transporte pas que la voix entre les terminaux. Une fois la session établie, les participants s'échangent directement leur trafic audio grâce à d'autres protocoles, notamment le RTP et le SDP qui décrit les détails d'établissement de connexion. Le protocole SDP (Session Description Protocol ) négocie les codecs de compression des données de voix (par ex. G.711, G.729), les ports RTP, les protocoles de transport, etc. Par rapport aux protocoles VoIP (H.323, MGCP... ), SIP semble avoir la plus grande préférence auprès des fabricants de matériel. Sa souplesse architecturale en est un de ses avantages; nous citons par en exemple son implémentation facile ou la mobilité de l'usager atteignable avec une adresse indépendante du lieu. L'utilisation du protocole SIP ne se limite pas seulement à la VoIP, il est également utilisé dans d'autres applications telles que la messagerie instantanée ou la réalité virtuelle. Les messages SIP Il existe deux types de messages SIP, des requêtes pour les actions liées à la session et des réponses servant à acquitter les requêtes et à tracer le statut de la session. Le format des messages SIP se compose d'une partie d'en-tête (header et status-line) et d'une partie de corps du message (message-body) optionnelle. L'en-tête peut comporter un ou plusieurs «message header» délimité par une fin de ligne

13 start-line request-line status-line message-header message-headers CRLF message-body message Figure 2: Structure des message SIP Il existe six types de requêtes SIP de base : Invite ACK BYE : Permet le demande d une nouvelle session : Confirme l'établissement de l INVITE : Met fin à la session CANCEL : Annule l'établissement de la session REGISTER : Communique la location de l utilisateur (nom d hôte, IP) OPTIONS : Communique les informations sur les possibilités de recevoir et de passer des appels SIP Il existe six classes de réponses SIP de base : Classe 1xx : Information, la requête a été reçue et est en cours de traitement Classe 2xx : Succès, la requête a été reçue, comprise et acceptée Classe 3xx : Redirection, l appel requiert d autres traitements avant de pouvoir déterminer s il peut être réalisé Classe 4xx : Erreur requête client, la requête ne peut pas être interprétée ou servie par le serveur. La requête doit être modifiée avant d être renvoyée Classe 5xx : Erreur serveur, le serveur échoue dans le traitement d une requête apparemment valide Classe 6xx : Echec global, la requête ne peut être traitée par aucun serveur

14 Les Terminaux SIP Les terminaux sont des appareils pouvant émettre et recevoir de la signalisation SIP. On trouve essentiellement deux sortes de terminaux, les téléphones SIP ou les PC équipés d un logiciel adéquat, d une carte son et d un micro. SIP est un protocole point à point, les liaisons sont donc établies d un terminal à un autre. Il est aussi client serveur, cela vient du fait qu un terminal, nommé aussi «agent» devient client lorsqu il émet des requêtes et reçoit des réponses ( UAC User Agent Client) et donc son partenaire devient serveur (UAS User Agent Serveur) puisqu il répond à ses requêtes. Transactions SIP Une transaction SIP consiste en un ensemble de requêtes et de réponses échangées entre les différentes parties présentes dans la session. Le schéma ci-dessous montre les différents messages SIP échangés. Nous rappelons que lorsqu'on parle de massages SIP, il ne s'agit que de texte, la voix étant transmise ici via le flux RTP. Voici quelques explications du schéma : la partie appelante fait la demande d'établissement de la session SIP avec l'envoie de la requête INVITE. L'appelé repond avec une message de type 100 qui signifie que la requête à bien été reçu et est en cours de traitement. L'appelé après avoir traité et accepté la requête envoie une réponse de type 200 à l'appelant. La session SIP est établie et la conversation peut alors commencer. Le flux RTP représente l'échange de paquet de type voix. Pour terminer la session établie, l'appelant envoie une requête BYE qui est acquitté par l'appelé avec la réponse de type 200. Deux transactions sont notées sur le schéma : une commence avec le message INVITE et qui se termine avec le message 200 et l'autre commence avec le message BYE et se termine avec le message 200. L'ensemble de ces deux transactions forment un dialogue SIP. Figure 3: Transactions SIP

15 5.2 Solution PABX-IP pour la VoIP L'équipement PABX est tout simplement un central téléphonique privé situé dans les locaux de l'organisme utilisateur. Il dispose d'une ou plusieurs interfaces de type analogiques (fax) ou opérateurs RTC (Réseau Téléphonique commuté) ainsi que des interfaces numériques (ISDN). Il permet ainsi de connecter différents réseaux de communication entre eux. Le schéma simplifié ci-dessous montre les différents réseaux avec lesquelles le PABX-IP peut s' inter-connecter. Nous rappelons que les fonctionnalités des PABX sont spécifiques à chaque constructeurs. Figure 4: Interfaces de connection d'un PABX-IP aux différents réseaux L'établissement d'une communication entre le réseau RNIS et un usager SIP requiert la mise en ouvre d'une passerelle entre ces deux réseaux. La passerelle (gateway en anglais) est un élément de routage équipé de cartes d'interfaces analogiques et/ou numériques. Son rôle est d'assurer l'interconnexion entre applications de même type mis en oeuvre sur des réseaux différents Le PABX Asterisk [4] Logiciel Open Source flexible dont le développement est mené par Mark Spencer (à l'origine de l'entreprise Digium), Asterisk est une solution VoIP montante. Actuellement, des fournisseurs de centraux téléphoniques utilisent de plus en plus la plate-forme Asterisk. Nous voyons également de une augmentation du nombre d'entreprises qui font fonctionner une version d' Asterisk sur leur réseau. Asterisk s'installe sur n'importe quelle plate-forme Linux. Il supporte une vingtaine de protocoles, en plus des fonctionnalités d'un PABX. Asterisk supporte aussi les fonctionnalités de la VoIP et offre des fonctionnalités inovantes telle que la messagerie vocale interactive. Il peut se connecter à différentes interfaces analogiques et numériques, une gamme de carte d'interfaçage d' Asterisk avec les

16 équipements téléphoniques analogiques et numériques sont disponibles sur le marché. L'un des avantages d' Asterisk est qu'il laisse à l'utilisateur la liberté de développer son propre système téléphonique. Etablissement de session audio avec le PABX Asterisk Le PABX Asterisk est un proxy SIP; un proxy remplit la même fonction qu un serveur de redirection, il se charge de retransmettre les messages vers le destinataire. L'établissement de session audio est décrite dans le schéma suivant : PABX Asterisk Appelant INVITE 100 TRYING 180 RINGING 200 OK ACK INVITE 100 TRYING 180 RINGING 200 OK ACK Flux RTP BYE BYE 200 OK 200 OK Figure 5: Etablissement de session audio avec Asterisk Remarque : une fois la session SIP établie, pour ne pas accaparer les ressources du proxy, les échanges des paquets RTP se font directement entre les deux terminaux en passant par le réseau IP. 5.3 Caractéristiques de la technologies ISDN D'après la définition de l'union internationale des télécommunications (UIT), la technologie RNIS (Réseau Numérique à Intégration de Services) ou de l'anglais ISDN (Integrated Services Digital Network) est une architecture fournissant une connectivité numérique de bout en bout avec une grande variété de services. Le ISDN transporte la voix, les données, le texte et l'image en utilisant le même réseau de

17 transport numérique. Cette technologie est utilisée par la plupart des opérateurs téléphoniques. On classe les réseaux RNIS suivants deux types : Le réseaux ISDN à bande étroite avec un débit inférieur ou égal à 2 Mbit/s. Le réseau ISDN à bande large avec un débit supérieur ou égal 2 Mbit/s Canaux logiques ISDN définit deux types de canaux logiques distinguables par leurs fonctions et leurs débits : Les canaux B transmettent à un débit de 64Kbps (kilo bits par seconde) en commutation de circuit ou de paquet les informations. Les canaux D utilisés pour la signalisation, transmettent à un débit de 16Kbps en accès de base et à un débit de 64Kbps en accès primaire les informations de signalisations : appels, établissement des connexions, demandes de services, routage des données sur les canaux, routage des données sur les canaux B et enfin libération des connexions. Les notion d'accès de base et primaire sont expliquées dans le chapitre Interfaces standards ISDN Une interface d'accès à un réseau ISDN est une association de canaux B et D. On définit deux catégories d'interfaces : L'interface résidentielle : consiste en l'utilisation simultanée des services téléphoniques et d'une connexion Internet. L'interface professionnelle : consiste en l'utilisation d'un commutateur téléphonique (PABX) et/ou d'un routeur d'agence. Dans les deux cas, le nombre de canaux utilisés peut varier suivant les besoins. Le débit maximum étant fixé par le type d'interface. Il existe deux types de lignes ISDN: Les lignes d'accès primaires (PRA) qui fournissent 30 canaux simultanés. Ces lignes sont généralement réservées aux entreprises. Les lignes d'accès de base (BA) qui fournissent 2 canaux simultanés. Pour les individus ou les PME. Il est donc possible d'avoir simultanément deux appels téléphoniques ou un appel téléphonique et une connexion au réseau Internet

18 6. Analyse du fonctionnement Ce chapitre décrit l'ensemble des fonctionnalités de l'application à développer et analyse la façon dont l'application va être réalisée. 6.1 Architecture du projet Unité de test Module de gestion du déroulement de la simulation DUT Module de gestion de l'analyse de trafic * Module de gestion de la génération du trafic Réseau IP Module de gestion de l'accès à la base de données * Base de données * Interface de communication Station 1 Station 2 Figure 6: Schéma bloc de l'architecture du simulateur Remarque : l'interface entre le module de gestion du déroulement de la simulation et le module de l'analyse de trafic n'a pas été représenté dans un souci de pas surcharger le schéma L'architecture du projet est une architecture distribuée ; l'application à développer est répartie sur deux stations. J'ai regroupé les fonctionnalités selon des «modules de gestion» qui ont des interfaces de communications entre eux. L'architecture comprend : Le PABX-IP : plate-forme de test connecté au réseau IP. Le module de gestion du déroulement de la simulation : ce bloc comprend l'interface utilisateur, il a une interface avec le module de gestion de la génération de simulation et le module de gestion de l'analyse de trafic. Le module de gestion de la génération du trafic qui a une interface de communication avec le module de gestion de l'accès à la base de données. Le module de gestion de analyse du trafic : partie du système à développer chargée d'analyser le trafic, de filtrer le trafic afin de prélever les résultats de simulation. Le gestionnaire d'analyse du

19 trafic est une application observatrice du trafic et se doit d'être installé sur une station externe ceci dans un souci de percevoir tous les messages. Le Module de gestion d'accès à la base de données : les méthodes d'accès à la base de données et les méthodes de traitement des résultats y sont définies. 6.2 Ensemble des fonctionnalités Module de gestion du déroulement de la simulation Le gestionnaire du déroulement de la simulation, comme son nom l'indique, est responsable du bon fonctionnement de l'application. Ainsi lors du lancement de la simulation de charge à partir de l'interface graphique, le gestionnaire du déroulement est responsable de la coordination de l'exécution; il gère alors la procedure d'exécution et d'arrêt des modules de gestion du trafic et de gestion de l'analyse. L'ordre d'exécution de ces trois processus (pas défini dans le schéma) est important; pour pouvoir analyser toutes les trames dès le début et pour que le client ait des réponses à ses requêtes, le processus de gestion de l'analyse et le processus de l'agent serveur SIPp doivent être lancés avant le processus du client SIPp source de trafic Diagramme de contexte du déroulement de la simulation Le Use Case (diagramme de contexte des cas d'utilisations) ci-dessous résume le déroulement de la simulation et les principales fonctionnalités exécutées par le module de gestion du déroulement de la simulation. Le système à réaliser comprend deux acteurs : Un acteur physique : l'utilisateur qui utilise l'application Un acteur système : cet acteur fait partie de la logique d'implémentation du projet

20 Figure 7: Diagramme de contexte des cas d'utilisations des fonctionnalités du simulateur Description des fonctionnalités relatives à l'utilisateur: Saisir les paramètres de simulation : comme son nom l'indique, cette fonctionnalité consiste à entrer les paramètres de dimensionnement du trafic SIP et RTP à générer et la durée de la simulation. Exécuter la simulation : il s'agit de lancer la simulation de test en charge en intégrant les paramètres de simulations. Elle inclut les fonctionnalités suivantes : Exécuter l'agent client SIPp : l'agent client SIPp source de trafic, il doit générer le trafic conformément aux paramètres de simulation. Exécuter le scénario de simulation : le scénario de simulation décrit les étapes de la simulation, le lancement du scénario inclus : Exécuter l'agent client SIPp : source du trafic Exécuter l'agent serveur SIPp : consiste à démarrer l'agent serveur SIPp destinataire du trafic. Exécuter le module de l'analyse du trafic : cette fonctionnalité consiste à suivre les

21 échanges des trames entre les deux agents et à les traiter. Elle inclut la sous fonctionnalité suivante: Extraire et stocker les résultats de simulation: il s'agit d'analyser les trames échangés par les deux agents, d'y prélever des résultats de simulationet pour finir stocker ces informations dans la structure de stockage : la base de données. Description des fonctionnalités relatives à l'acteur système Terminer la simulation : cette fonctionnalité correspond à la fin de la simulation avec l'arrêt des différents programmes lancés en début de simulation qui termine l'exécution de la simulation. Exploiter les résultats de simulation : le but de la simulation de test en charge est de faire ressortir les caractéristiques du central téléphonique, caractéristiques dependant des objectifs de test (nombre maximal d'appels supportés, temps de réponse...). Ainsi, à la fin de la simulation un cas d'exploitation des résultats sera présenté Complexités de l'exécution de l'application Le démarrage de l'application Le lancement de l'application est une tâche assez complexe, en effet nous devons gérer le lancement en parallèle de quatre programmes qui une fois démarrés fonctionnent independemment. Le langage C++ met à disposition les threads pour gérer la synchronisation de différente tâche et l'exécution en parallèle de ces tâches. La gestion des bug de fonctionnement de ces programmes s'avère également complexe. En effet la logique d'exécution aimerait que la suspension de l'exécution de l'un de ces programmes pour une quelconque raison entraîne une suspension de l'ensemble de l'application. L'une des solution serrait de mettre en place deux flux de récupération des erreurs d'exécution et de récupération de la sortie standard après avoir exécuté chaque programme. Ainsi le flux de sortie d'exécution de ces programmes sera redirigé vers une console Shell. Le fonctionnement de chaque programme parallèle pourra être suivi via la console Shell. Une animation pourra même être implémentée. La solution trouvée ne resoud pas le problème mais permet de suivre au moins le déroulement de la simulation. L'implémentation de cette solution sera présentée dans le chapitre 7 La terminaison de l'application Parmi les programmes exécutés lors du lancement de l'application, seul le script Shell du scénario d'exécution de l'application présenté au chapitre se termine seul. Ainsi la fin de ce script est la condition d'arrêt des autres programmes : le serveur et le programme du module d'analyse du trafic

22 6.2.2 Module de gestion de la génération du trafic Ce module regroupe toute les fonctionnalités en rapport avec le trafic à générer, à savoir : la création de scénarios de simulation, le dimensionnement du trafic à générer, l'intégration des deux agents SIPp dans nos scénarios et l'établissement du trafic L'établissement du trafic L'établissement du trafic se fait entre les deux agents SIPp, le client SIPp représente notre source de trafic et le serveur SIPp l'agent de communication à qui le trafic est destiné. L'outil SIPp possède des scénarios de base d'exécution des deux agents de communication. J'ai choisi de prendre comme base pour la génération du trafic SIP/RTP ces scénarios présentés dans le chapitre 4. Les deux agents SIPp seront exécutés en tâche de fond car, par défaut SIPp liste sur la sortie standard les statistiques des messages échangés. Les deux agents SIPp seront installés sur la même station et pour que le trafic transite par le central téléphonique, il est important de définir aux niveaux des agents SIPp les adresses des interfaces et les ports qui serviront pour le routage du trafic. La ligne d'exécution des agents SIPp doit contenir : L'adresse IP de la station hôte, cette adresse sera utilisée dans l'entête des messages SIP pour définir l'identité de l'agent. L'adresse IP de la station hôte utilisée pour l'échange de messages RTP. Les ports utilisés pour le trafic SIP :nous utilisons par défaut les ports 5061 pour le serveur et 5060 pour le client. Le port pour le media RTP (juste du côté serveur). L'adresse IP de destination du trafic généré : l'adresse IP du centrale téléphonique (juste côté client SIPp émetteur de trafic) Le dimensionnement de la charge à générer Commençant par définir les paramètres de simulation. Ces paramètres sont classés selon deux groupes : Les paramètres de dimensionnement du trafic à générer Le nombre d'appel par seconde : qui correspond au taux d'appel La durée d'établissement des appels Le nombre maximum d'appel à générer Le nombre d'appel à ajouter pour augmenter la charge Les paramètres de contrôle de la simulation La durée de la simulation La période pour laquelle la charge généré est augmenté

23 Le nombre maximum d'appel à générer L'utilisateur dispose ainsi d'un ensemble de paramètres qui lui permettent de reproduire des configurations de charge de trafic de différent service d'un organisme avec un nombre d'usager Scénarios de simulation J'ai choisi en fonction des fonctionnalités offertes par le client SIPp, de définir deux scénarios de simulation : Simulation avec un nombre fini d'appel : dans ce cas de simulation, le paramètre définissant le nombre maximum d'appel permet de contrôler l'arrêt de la simulation. Simulation avec monté en charge : tout au long du déroulement de la simulation un nombre de nouvel appels seront injectés dans le trafic établie, la période d'injection et le nombre d'appel à injecter seront définis par l'utilisateur. La durée de la simulation et la période de la monté de charge sont les paramètres de contrôle de la simulation. Ces deux scénarios de simulation répondent parfaitement au besoin de flexibilité, en effet différents objectifs de test peuvent y être simulés : Une validation de la capacité d'accueil du central téléphonique à supporter un nombre de communication fixé injecté selon un taux d'appel. Un simualtion de stress afin de déterminer la sollicitation maximal tolérée par le central. Une test d'endurance qui consiste à réaliser la simulation sur une longue durée. Tâches confiées aux agents SIPp Toutes les actions sur le trafic (dimenssionnement du trafic, lancement des appels, arrêt, ajout de nouvel appel) sont commandées au client SIPp qui est la source du trafic. L'outil SIPp met à disposition un ensemble d'options de dimensionnement de la charge. Ainsi les paramètres de dimensionnement de la charge du trafic seront spécifiés sur la ligne de commande du client SIPp. Le serveur SIPp une fois démarré se met juste à l'écoute du client et repond à ses requêtes Diagramme d'activités du déroulement de la simulation Dans le diagramme d'activité ci-dessous nous définissant les étapes de déroulement de la simulation dans les deux scénarios de simulations définis précédemment

24 Figure 8: Diagramme d'activité du scénario de simulation

25 6.2.3 Module de gestion de l'analyse du trafic Point d'analyse du trafic et de collecte des résultats L'outil d'analyse de réseau Wireshark est le puit de données de ce module. Pour capturer les trames échangées par les deux agents de communications, il est important de bien se placer dans notre architecture distribuée par rapport à notre unité de test. Le but est de capturer directement les trames au niveau du DUT; l'outil d'analyse réseau Wireshark va être placé en déviation entre le DUT et la station hébergeant l'outil SIPp (le client et serveur SIPp). Seul le trafic échangé par le DUT et la station nous intéresse, il est donc nécessaire de spécifier un filtre de capture avec Wireshark; dans ce filtre les adresses source et destination des trames capturées correspondent à celles des interfaces du central téléphonique et de la station hôte de la source de trafic ( l'agent client SIPp). L'analyse des trames se fait en temps réel c'est à dire tout au long de la simulation, dès qu'une trame est capturée, elle est ensuite transférée vers le programme responsable de la récupération des résultats de simulation. Dans le schéma de câblage pour l'analyse du trafic le Hub utilisé sert à inter-connecter les stations hôtes de l'outil SIPp, de Wireshark et l'unité de test. Figure 9: Schéma de câblage pour l'analyse du trafic Ensemble des fonctionnalités : lancer Wireshark en tâche arrière sans sans interface graphique et rédiriger les trames capturées vers l'application de traitement des captures. L'intégration de Wireshark dans le projet impose deux contraintes : La redirection des captures nécessite de mettre en place un tuyau de canalisation entre Wireshark et notre programme, ce tuyau est aussi appelé tube ou pipe en anglais

26 La sortie des capture doit être formatée selon un format qui permette de les manipuler facilement. Wireshark supporte le format XML, ce format sera donc utilisé pour formater la sortie des captures. définir une structure afin d'uniformiser dans notre programme la représentation (sous forme de classes) des trames SIP et RTP capturées. La sortie des captures formatée selon le language XML impose l'implémentation d'un parser mxl qui va extraire les résultats de simulation. Le choix du parser XML devra tenir compte du nombre parfois très élévé surtout dans le cas d'une simulation avec monté de charge, des message RTP et SIP échangés lors de la simulation. Le parser XML se doit donc d'être performant. Pour pouvoir se connecter à la base des données ce module à une interface de communication avec le module de gestion d'accès à la base de données. Il utilise alors les méthodes de mises à jour des tables de la base de données, méthodes définies dans le module de gestion de la base de données Résultats de simulation Les résultats de simulation à collecter dépendent des objectifs de test, j'ai choisi de collecter un éventail assez large de résultat dans le but de ne pas se limiter à un test donné. Laissant ainsi à l'utilisateur la liberté dans l'exploitation de ces résultats. Les données vont être extraites des messages de protocoles de VoIP SIP et RTP et en fonction du rôle joué par chaque protocole dans la communication téléphonique. Nous prendrons soin d'associer les paquets de chaque flux RTP à chaque session SIP établie pour permettre l'émission du flux RTP. Cette association est faite à l'aide des ports source et destination RTP, ports définis lors de l'établissement de la session SIP. Protocole SIP Le temps temps de capture d'un message donnée depuis le lancement de la simulation. Le start-status des messages SIP défini au chapitre va nous renseigner sur l'état des sessions SIP Protocole SDP (protocole contenant les détails d'établissement des sessions SIP) Les ports RTP source et destination Le codec utilisé pour la compression du flux média. Protocole RTP : ce protocole étant au dessus du protocole UDP, il est en général transporté dans le réseau IP Le temps de capture d'un message donnée depuis le lancement de la simulation. Numéro de séquence : choisi aléatoirement au début, s'incrémente pour chaque paquet émis appartenant au même flux RTP et permet ainsi de déterminer de perte possible de paquet

27 6.2.4 Module de gestion d'accès à la base des données L'implémentation des traitements effectués sur la base de données sont définis dans ce module Schéma conceptuel de la base des données MySQL Après avoir défini les résultats de simulation, le schéma conceptuel de la base des données peut être réalisé ave l'outil graphique SQL Designer. Figure 10: Schéma conceptuel de la base de données Le schéma conceptuel comprend deux tables «PaquetRtp» et «PaquetSip» sans association entre elles, et représentant les protocoles RTP et SIP. Ces tables ont deux attributs identiques : «rtpsrcport» et «rtpdestport» qui sont les ports source et destination du média RTP. Ainsi pour pouvoir rattacher les paquets RTP à la session SIP établie pour leurs émissions, il suffit de réaliser une jointure des deux stables avec comme condition l'égalité des attributs des ports média. Ce modèle est simple et permet d'ajouter sans redimenssionner la base des données une nouvelle table. Les différents accès de mise à jour à la base de données et de récupération des données stockées se feront via des requêtes SQL. L'API MySQL++[5] possède un ensemble de classes et de fonctions qui permettent de déclarer les structures de connection/déconnexion à la base des données et d'exécution des requêtes SQL Représentation graphique des résultats L'exploitation des résultats dépend bien évidemment des objectifs de tests. Dans ce projet l'accent à plus été mis sur la possibilité de réaliser différentes situations de test de performance du central téléphonique. En fin de simulation, nous présenterons un cas d'exploitation des résultats du protocole SIP démontrant la courbe de temps d'établissement des différentes sessions SIP

28 7. Réalisation Nous expliquons dans ce chapitre la logique d'implémentation des fonctionnalités du projet et les choix des technologies utilisées en plus de celles définis dans le chapitre 4. L'environnement de développement utilisé est Linux et le language de programmation C++. C++ est un langage complexe, puissant, très repandu et avec une grande vitesse d'exécution. Toutefois en plus du langage C++, l'utilisation d'autre language est nécessaire comme expliqué plus loin. Comme représenté dans l'architecture de l'application au chapitre 6.1, les modules de gestion de la génération du trafic et de gestion du déroulement de la simulation sont sur une même station. Et ceux de gestion de l'analyse du trafic et de l'accès à la base de données sont également sur une même station. 7.1 Module de gestion de la génération du trafic Choix des technologies En plus de l'outil SIPp, deux autres technologies sont introduites dans cette partie : Le Langage Shell : le langage Shell est un langage de programmation (interprété) permettant d'exécuter une série de commandes systèmes. Le Bash est le shell de référence utilisé par les différentes distributions Linux. Le programme écrit en Shell s'appelle un script shell et c'est un fichier texte. Un script shell peut être exécuté en ligne de commande ou dans un autre script. Dans le chapitre 4, nous avons vu que l'un des points faibles de SIPp est l'absence d'api permettant de l'intégrer à notre projet; un programme Shell va nous permettre d'intégrer facilement cet outil. Ainsi le lancement du serveur, du client SIPp et les actions commandées au client SIPp seront définis dans un script Shell. L'utilitaire Netcat : Netcat à été développé à l'origine pour Unix puis Windows ; Netcat est un utilitaire qui permet d'ouvrir des connexions réseaux, aussi bien UDP que TCP, sans avoir besoin de programmer quoi que ce soit. En raison de sa polyvalence, Netcat est aussi appelé le «couteau suisse du réseau». Avec l'utilitaire Netcat nous allons créer une socket UDP de contrôle du processus client SIPp afin de réaliser la simulation de montée en charge. (Nous rappelons que SIPp supporte seulement un contrôle via une socket UDP). Dans notre application, le contrôle du process SIPp client est effectué en local sur une même station, donc nous n'avons pas de soucis à se faire par rapport à l'utilisation d'une socket UDP. En effet le protocole UDP ne garantit pas l'acheminement des données de bout en bout, en cas d'encombrement du réseau des pertes sont ainsi possibles

29 7.1.2 Implémentation Nous utilisons des scripts Shell pour l'exécution des lignes de commandes des deux agents SIPp et pour l'exécution des deux scénarios de simulation. Les deux scénarios de simulation définis au chapitre sont regroupés en un seul script Shell dont les étapes d'exécution sont celles du diagramme d'activités défini au chapitre Soient les scripts suivants : uac_pcap : script de base de l'outil SIPp pour générer le trafic SIP/RTP, ajouté à la ligne d'exécution du client SIPp uas : script de base de l'outil SIPp ajouter à la ligne d'exécution du serveur SIPp scenario.sh : script d'exécution et d'arrêt du simulateur à développer. Les arguments de simulation sont passés en paramètres à ce script et ajoutés à la ligne de commande du client SIPp avant de l'exécuter. Deux situations d'arrêt du scénario sont implémentées, plus précisément l'arrêt du client SIPp source de trafic : pour une simulation avec un nombre d'appels fixé : l'arrêt est assuré par le client SIPp lui même, qui génère le trafic jusqu'à ce que le nombre d'appels fixé soit atteint. Pour une simulation on charge, avec Netcat, une socket udp est crée sur le port SIPp (récupéré avec les mêmes routines systèmes utilisées pour stopper le serveur SIPp) et à travers cette socket, le caractère «q» est envoyé au processus client SIPp. Ce caractère permet de demander au processus client SIPp de terminer proprement sont exécution. start_server.sh : démarre le serveur SIPp : exécute la ligne de commande du serveur SIPp La ligne d'exécution du serveur est juste exécutée via ce script. stop_server.sh : arrête le serveur SIPp. L'arrêt du serveur SIPp est réalisé à l'aide de la series des routines système suivantes: [6] ps -aux : liste l'ensemble des processus actifs grep : recherche le processus du serveur SIPp awk : récupère le PID du processus serveur SIPp Kill -Term : demande au processus serveur SIPp de terminer proprement son exécution

30 7.2 Module de gestion de l'analyse de trafic Choix des technologies En plus de Wireshark présenté dans le chapitre 4 les technologies suivantes ont été utilisées : Le language XML : XML est un language de définition à balises (tags) définissable et extensible par l'utilisateur. L'utilisation d'un parser xml va nous permettre d'analyser les captures Wireshark au format xml. Le language Perl : Perl est un langage de programmation interprété qui dérive des scripts shell. L'un des avantages de ce language est qu'il est très adapté à la manipulation de chaînes de caractères. Dans le fichier perl scriptperl.pl nous définissant la commande d'exécution de Wireshark avec les options permettant de formater la sortie des captures en format XML. Les captures Wireshark qui sont des chaînes de caractères seront manipuler dans ce script perl. Ainsi les captures Wireshark seront stockées dans une variable dont le contenu sera envoyé sur la sortie standard du système Implémentation Ce module gère également la synchronisation de différentes tâches qui s'exécutent en parallèles. La connection à la base des données est effectuée au lancement de ce module Diagramme d'activités du traitement des captures Wireshark Le diagramme d'activités ci-dessous décrit les étapes de traitement effectués dans ce module

31 Figure 11: Tâche de lecture des sortie Wireshark

32 Figure 12: Tâche de traitement des captures Wireshark Le diagramme d'activité ci-dessus montre les deux tâches implémentées pour le traitement des captures, qui s'exécutent en parallèle partagent entre elles le fichier xml dans lequel les captures sont écrites. L'implémentation de ces deux tâches suit le modèle «Lecteur-Ecrivain»; ces deux tâches utilise en concurrence la liste de stockage des résultats de simulations, la tâche de lecture des captures écrit dans la liste et la tâche de traitement des captures lit dans la liste. Ainsi un mécanisme de synchronisation d'accès à la liste doit être mis en place. L'utilisation des threads permet de mettre un mécanisme de gestion de concurrence appelé mutex. Un mutex est un mécanisme de gestion de partage d'une unique ressource : la liste dans notre situation. Le mécanisme du mutex consiste à

33 verrouiller l'accès à la ressource partagée. La première tâche qui accède à la ressource, bloque l'accès à cette dernière et en débloque l'accès à la fin du traitement de la ressource. La deuxième tâche attend alors que la ressource soit libère. Ce mécanisme de mise en attente est réalisé en faisant dormir le thread (on suspend son exécution momentanément ). Quand le thread occupant la ressource la libère, il envoie un signal de reveil au thread endormi. La programmation des threads en C++ à été réalisé avec la librairie Posix avec l'utilisation des Pthread. Cette librairie définie un API en C de programmation de thread. [7] Création du pipe et déroulement de la tâche de stockage des résultats La mise en place du pipe par le thread de lecture des captures consiste à exécuter le script perl d'exécution de Wireshark et à récupérer la sortie du script perl dans une structure d'échange de données entre deux programme appelé flux (streams). La lecture dans le pipe est bloquante; le thread reste bloqué au niveau du pipe si Wireshark ne retourne pas de capture. Le blocage du thread de lecture au niveau du pipe entraîne également le blocage du thread de stockage des résultats. Ceci peut causer un blocage au niveau de l'exécution de l'application. Cette situation de blocage peut se produire que si Wireshark ignore la demande d'arrêt implémenté au niveau du module de gestion du déroulement de la simulation. En effet l'arrêt de Wireshark doit être faite par le module responsable du déroulement de la simulation. Le script shell stop_analyse.sh est défini pour arrêter Wireshark (ce script utilise les mêmes routines systèmes utilisées pour arrêter le serveur SIPp). Le parser XML Un parser xml est un analyseur syntaxique qui permet de parcourir un document xml et d'en extraire des informations. Xerces C++ [8] est un parser portable C++, il dispose d'un API permettant de générer, manipuler et valider un document xml. Nous utiliserons un parser Xerces C++ de type SAX pour implémenter l'analyseur des capture. SAX est une API basée sur un modèle événementiel, cela signifie que SAX permet de déclencher des événements au cours de l'analyse du document XML. Ainsi en parcourant la lecture du document xml contenant les captures, des opérations seront déclenchés en fonctions du types des noeuds du documents xml Diagramme des classes Le langage C++ permet d'utiliser la programmation orienté objet, ainsi ce modèle de programmation à été utilisé pour structurer notre code C++. Ci-dessous un diagramme des classes très simplifié est présenté

34 Main les threads de gestion de l'analyse de trafic Main.cpp Main utilise les méthodes de BDconnection 1:1 BDconnection.cpp 1:1 Analyseur.cpp Analyseur utilise le parser Parseur.cpp Parseur utilise les méthodes de BDconnection 1:1 1: n Appel.cpp Figure 13: Diagramme des classes du module de gestion de l'analyse de trafic 7.3 Module de gestion de la base de données Gestion de la base de données La gestion de la base de données consiste juste à définir l'objet de connection permettant de se connecter et de se déconnecter à la base de données, des requêtes SQL d'accès aux résultats et les différentes méthodes permettant d'exécuter ces méthodes. Nous prendrons soin de déclarer qu'une seule instance de l'objet connection. Certaines des requêtes SQL utilisés sont dynamiques ces requêtes qui sont des requêtes pré-compilées permettent d'optimiser le traitement dans la base des données. Exploitation des résultats et méthode de représentation graphique L'exploitation des résultats consiste à analyser les résultats stockés par rapport à un objectif de test et en faire ressortir une caractéristique du central. Nous avons choisi de représenter les temps d'établissement d'une session SIP. Calculer le temps d'établissement des sessions SIP, revient à calculer la différence de temps entre le temps d'envoi de la requête «INVITE» et le temps d'arrivée de la réponse «200» comme représenté au chapitre Ceci revient à faire des opérations de types soustractions sur leur résultats de simulation «time», résultat présenté au chapitre Les résultats des calculs seront stockés dans un fichier au format cvs. Puis un graphique sera généré avec l'application Excel. Par défaut le language C++ ne gère pas les opérations sur les heures, nous avons donc utiliser la la librarie portable C++ boost. [9]

35 7.4 Module de gestion du déroulement de la simulation Toute l'implémentation de ce module a été réalisé avec le language de programmation Java. Ce choix a été motivé par l'implémentation de l'interface graphique utilisateur à partir de laquelle l'application est lancée. En effet le développement de l'interface graphique utilisateur avec le language Java est plus aisé qu'avec le language C++. La logique d'implémentation de ce module doit respecter les contraintes suivantes: nous avons vu dans le chapitre les modules externes au module de gestion du déroulement de la simulation qui sont exécutés lors du lancement de l'application; cette gestion implique la synchronisation de leurs exécutions et la division de ce module en sections indépendantes. Le module de gestion de l'analyse de trafic est situé sur une machine distante à cause de l'architecture distribuée de l'application. Une connexion de contrôle à distante est donc nécessaire entre la station hôte du module de gestion du déroulement et le module de gestion de l'analyse du trafic Implémentation Exécution des modules de lancement de l'application Le language Java permet de réaliser des unités d'exécution indépendantes avec de thread. Un thread est une portion de code qui s'exécute en parallèle à d'autres traitements dans un programme. Ainsi chaque module externe sera exécuté par un thread. java permet d'exécuter une application externe avec la méthode exec() de la classe Runtime. La classe java Runtime définit un ensemble de méthodes exec() qui diffèrent l'une de l'autre en fonction de leurs arguments. La méthode exec() permet d'exécuter une ou une série de commande Connexion de contrôle à distance Il existe différent protocoles qui permettent de se connecter à distance sur une machine, nous avons retenu les protocoles RSH et SSH. Linux met à disposition les commandes rsh et ssh correspondantes. RSH (Remote Shell) est un protocole qui permet d'exécuter une commande sur une machine distante. L'utilisateur doit avoir un compte utilisateur sur la machine distante, l'authentification de l'utilisateur est silencieuse( pas de demande de mot de passe). SSH (Secure Shell) est un protocole de communication sécurisé qui impose une authentification de l'utilisateur (par mot de passe ou clé de chiffrement).la procedure de connection ssh sans authentification sera expliqué dans le chapitre 12. Dans un premier temps l'utilisation de la commande rsh à été choisi mais par défaut elle n'est pas activée sur notre environnement Linux et nous avons rencontré des difficultés pour l'installer. Finalement nous nous sommes tourné vers la commande rsh. Ainsi le module de gestion de l'analyse sera exécuter à travers le tunnel ssh à partir de la méthode exec()

36 Contrôle de la synchronisation au démarrage et du déroulement de l'application Dans le chapitre nous avons abordé la complexité du lancement en parallèle des différents programmes. Nous présentons ici un cas d'exécution de la simulation qui ne respecte pas l'ordre de démarrage des différents programmes : Lors du démarrage de la simulation le thread d'exécution du script de démarrage du serveur SIPp démarre et rend la main au programme principal; puis le thread de démarrage du module de gestion de l'analyse du trafic se lance à son tour et rend également la main au programme principale ce qui entraîne le démarrage du thread exécutant le scénario de simulation. Mais le module de gestion de l'analyse doit démarrer avant le scénario de simulation cette contrainte nécessite un contrôle pour empêcher au thread d'exécution du module de l'analyse du trafic de rendre la main au programme principal tant que ce module n'a pas démarré. Cette solution n'a pas pu être implémentée pour deux raisons : chaque exécution des programmes est assuré par un thread qui s'exécute indépendamment. Il est donc impossible de contrôler les threads une fois qu'ils sont lancés. L'exécution du module distant se fait via le tunnel ssh qui nécessite d'entrée un mot de passe. Il est possible de faire une connexion ssh sans mot de passe mais nous avons gardé la connexion avec mot de passe. Donc l'exécution du module distant ne se fait pas aussitôt que le thread d'exécution démarre et rend la main au programme principale. L'alternative à ce problème de synchronisation au démarrage est d'utiliser une variable de contrôle de l'exécution du scénario. Ainsi le thread de démarrage du scénario tournera en boucle tant que le module distant n'aura pas été exécuté. L'exécution du module distant retourne une valeur qui permet de changer l'état de notre variable de contrôle donc d'exécuter le scénario. En cas d'échec de lancement l'application doit suspendre son exécution. Le problème de la gestion des bug de fonctionnement des programmes lancés en parallèles à aussi été soulevé au chapitre Nous avons choisi de suivre l'exécution de ces programmes dans une console shell. Ainsi la la commande Shell xterm d'ouverture de terminal sera ajouté dans la serie de commande d'exécution des programmes de lancement de l'application. Cette solution n'a pas pu être réalisée mais elle le sera pour la défense de diplôme. Contrôle de la terminaison de l'application La condition de la fin d'exécution de l'application est donnée par l'arrêt du script du scénario. Ainsi l'arrêt du serveur se fera juste en exécutant le script stop_server.sh. Une nouvelle connexion ssh sera faite pour demander au module de gestion de l'analyse de se terminer. La demande de terminaison du module de gestion de l'analyse se fait par l'arrêt de Wireshark. Ce point a été expliqué au chapitre Diagramme UML des classes implémentées Le schéma ci-dessous présente le diagramme des classes du module de gestion du déroulement de l'application

37 Figure 14: Diagramme des classes du module de gestion du déroulement de la simulation Classes implémentées : MainFrame.java : cette classe représente l'interface graphique, elle implémente les écouteurs d'évènements au niveau des boutons définis sur l'interface graphique Main.java : classe principale de demarrage de l'application. L'application démarre en présentant

38 à l'utilisateur l'interface graphique, cette classe du lacement de l'interface graphique en exécutant la méthode start() de la classe MainFrame.java ProcessLauncher.java : cette classe définit les lignes de code des threads qui exécutent les différents programmes de lancement de l'application. Cette classe, sous licence GPL [10], a été modifiée selon nos besoins d'implémentation. La façon dont la méthode java exec() sera utilisée est définie dans cette classe. GestionApplication.java : cette classe utilise les méthodes d'exécution des threads définis dans ProcessLauncher.java. Elle déclare les threads qui exécuterons les différents programmes de lancement de l'application. Et défini les lignes d'exécutions qui seront passées à la méthode java exec() Interface graphique L'implémentation de l'interface graphique a été réalisée avec l'ide Netbeans. Figure 15: Interface graphique du simulateur de charge Au démarrage du simulateur de charge, cette interface est présentée à l'utilisateur. Par défaut des paramètres de simulation ont été définis. L'utilisateur peut choisir d'abandonner la simulation avec le bouton Quitter ou de lancer une simulation avec le bouton Démarrer