Mikiela
Mikiela
Mikiela
-2-
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
-3-
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
15. Bibliographie.............................................................................................................................................50
-4-
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
-5-
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
-6-
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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
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.
-7-
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
● L'interface graphique
● Le rendu des résultats
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.
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-
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
○ trafic du réseau VoIP vers le réseau ISDN : de SIP/RTP vers ISDN (et inversement)
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.
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.
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.
4.2.1.1 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.
-9-
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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 :
● 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.
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.
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...).
- 10 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
- 11 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
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.
- 12 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
start-line
request-line status-line
message-header
message-headers
CRLF
message-body
message
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
- 13 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
- 14 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
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.
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
- 15 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
é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.
PABX Asterisk
Appelant
INVITE
INVITE
100 TRYING
100 TRYING
180 RINGING
180 RINGING
200 OK
200 OK
ACK
ACK
Flux RTP
BYE BYE
200 OK
200 OK
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.
- 16 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
transport numérique. Cette technologie est utilisée par la plupart des opérateurs téléphoniques.
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 5.3.2
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 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.
- 17 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
Unité de
test
Réseau IP * Interface de
Module de communication
* gestion de
l'accès à la
Module de base de
gestion de la données
génération du
trafic Base de
* données
Station 1 Station 2
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 :
- 18 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
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.
- 19 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
● 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.
- 20 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
é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.
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 6.2.2.3 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.
- 21 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
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.
○ La durée de la simulation
○ La période pour laquelle la charge généré est augmenté
- 22 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
● Une test d'endurance qui consiste à réaliser la simulation sur une longue durée.
Le serveur SIPp une fois démarré se met juste à l'écoute du client et repond à ses requêtes.
- 23 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
- 24 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
● 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.
- 25 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
○ 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.
● Protocole RTP : ce protocole étant au dessus du protocole UDP, il est en général transporté dans
le réseau IP
- 26 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
L'implémentation des traitements effectués sur la base de données sont définis dans ce module.
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 .
- 27 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
En plus de l'outil SIPp, deux autres technologies sont introduites dans cette partie :
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.
- 28 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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 6.2.2.3 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 6.2.2.4
○ 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.
● 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
- 29 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
7.2.2 Implémentation
- 30 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
- 31 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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 à
- 32 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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]
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.
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é.
- 33 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
1:1
Analyseur.cpp
Analyseur utilise
Parseur utilise
le parser Parseur.cpp Appel.cpp
les méthodes
de BDconnection
1:1 1: n
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]
- 34 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
● nous avons vu dans le chapitre 6.2.1.1 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.
7.4.1 Implémentation
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.
● 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().
- 35 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
Le problème de la gestion des bug de fonctionnement des programmes lancés en parallèles à aussi été
soulevé au chapitre 6.2.1.2. 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.
- 36 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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
- 37 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
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.
- 38 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
- 39 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
8. Tests de fonctionnement
La livraison du centrale téléphonique n'a pas pu être faite par l'entreprise mandataire du projet. Nous
avons utilisé le PABX Asterisk présenté au chapitre comment solution de test. Seule le package
permettant de faire de la VoIP à été utilisé. il La procédure d'installation du PABX Asterisk et les fichiers
de configuration du PABX Asterisk sont présentés dans le chapitre 12. Avant de tester l'application, nous
allons faire des tests unitaires pour chaque module qui peut s'exécuter independemment.
Respect des étapes Dans ce test il s'agit de vérifier que les Validé
d'exécution du scénario paramètres de simulations sont pris en
( arrêt suivant la condition compte par la simulation et que l'arrêt de la
du nombre maximal simulation est contrôlé par ces paramètres.
d'appels, arrêt suivant la
durée de la simulation,
période de monté en
charge).
Arrêt du serveur SIPp, du Il s'agit ici de vérifier l'exécution du script Validé
programme distant via ssh shell d'arrêt du serveur SIPp en local et du
en fin de simulation. script d'arrêt de Wireshark à distance. La
programmation de ces scripts a été présenté
au chapitre 7.1.2
Gestion des bug Il s'agit de simuler un échec au niveau du Le module d'analyse renvoie
- 40 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
d'exécution programmes lancement du module de gestion de l'analyse une exception avia le tunel ssh
de lancement de du trafic, la simulation est réalisé en mais renvoie également le
l'application. L'application supprimant le script perl de lancement de signal d'exécution du module.
doit s'arrêter en cas de bug Wireshark. Nous avons vu au chapitre 6.2.1.2 L'application ne s'arrête pas et
au lancement d'un que le thread d'exécution du scénario reste bloquée.
programme de démarrage. bouclait tant que le module d'analyse n'avait
pas été lancé Echec
Test de performance du La performance du parser se vérifie dans un Echec. Nous avons une
parser xml cas de simulation en charge, si le utilisation maximale de la
l'implémentation du parser est optimisé et mémoire. L
libère bien les différents emplacements
mémoire utilisé pour stocker les résultats lors
du parssage.
Avec le problème de saturation de la mémoire mentionné au chapitre 8.1 il est impossible de faire de test
selon un scénario de monté en charge. Seul un test avec un nombre d'appel fini est possible à condition
bien sûr que le nombre d'appel soit pas très élévé. L'optimisation du parser sera corrigé pour la
démonstration du fonctionnement lors de la défense de diplôme.
Nous présentons ci-dessous la courbe représentant les temps d'établissement des sessions SIP. Comme
mentionné dans le chapitre 7.3.
Une simulation avec un nombre maximal de 50 appels à été réalisé, chaque appel dure 1 seconde par
défaut. Ci-dessous la courbe montrant les temps d'établissement des sessions SIP. Nous rappelons que
les messages RTP passe dans le réseau IP et non par le central, ce point à été expliqué au chapitre 5.2.1
- 41 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
Sur l'axe des abscisses, nous avons les temps pour lesquels les requêtes INVITE de demande
d'établissement ont été envoyées. Et en ordonnée la différence de temps entre le temps d'envoi de
demande et le temps de réponse confirmant l'établissement de la session.; ce temps est en micro-
seconde.
L'allure de cette courbe est assez surprenante en effet avec ce nombre d'appel, nous nous attendions à
avoir une courbe assez plate avec des temps de réponses tres voisins. Cependant nous avons tenu à
ajouter cette coube dans notre rapport juste pour montrer un exemple de courbe.
- 42 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
9. Conclusion
Durant ce travail de diplôme, nous avons vu la complexité de la mise en place d'un simulateur de charge
VoIP. L'approche d'analyser un par un les messages SIP/RTP a été assez fastidieuse et la maîtrise d'un
système repartie sur une architecture distribuée difficile. Le simulateur développé n'est pas totalement
au point, en effet quelques aspects de dysfonctionnement doivent être améliorés. Par contre il reste
une bonne base pour l'élaboration d'une solution de test. Le développement du simulateur de charge
s'est plus concentré sur l'aspect d'évaluation de la performance, de la fiabilité du central téléphonique,
laissant ainsi l'aspect de qualité au second plan. Il pourrait être intéressant d'approfondir l'analyse de
cet aspect et d'intégrer des scénarios de simulation permettant d'effectuer des tests de qualité.
Personnellement, ce travail de diplôme m'a permis d'approfondir mes connaissances dans le langage de
programmation C++, la technologie VoIP et sur le PABX Asterisk .
- 43 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
10. Améliorations
Résultats de simulations
● Nous nous sommes limité aux résultats des protocoles SIP et RTP. Le protocole RTCP présenté au
chapitre 5.1.1.1 contient des informations sur la qualité de service voix. Ce protocole contient des
informations sur le nombre des paquets RTP perdus par la source depuis le début de la réception
et sur la gigue inter-arrivées qui est une évaluation de la variance statistique du temps inter-
arrivées des paquets RTP reçus.
● Si le central téléphonique possède une MIB (Management Information Base) il serait intéressant
d'analyser la possibilité d'ajouter un module implémentant le « monitoring » de la MIB . Des
données sur le CPU (Central Processing Unit – Unité Central de traitement), sur le trafic global
d'entrée et de sortie au niveau des interface du central téléphonique pourront être collecter.
Nous rappelons que les résultats de test dépendent des objectifs de test. En effet différents résultats
sont envisageables.
Scénarios
L'outil SIPp peut interpréter des scénarios définis dans le format xml. On pourrais offrir à l'utilisateur la
possibilité de diversifier les scénarios de test.
L'idée est de faire communiquer notre simulateur de charge avec une autre application responsable de
la représentation et du contrôle des données de simulation. Cette structure avait été présenté lors du
pré-travail de diplôme. Ia nouvelle application mettra en place les points suivants :
● Une structure de représentation et de stockage des profiles d'appels des personnes dans service
donné ( par exemple une service informatique). Ainsi la simulateur simulera une situation de
charge correspondant au trafic de ce service.
- 44 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
11. Remerciements
Je tiens à remercier les personnes suivantes pour leur contribution dans l'élaboration de ce projet de
diplôme :
Markus Jaton : pour la disponibilité et pour l'aide sur les schémas de conception
- 45 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
12. Annexes
Nous présentons les différentes installations faites dans ce projet. Ces installations ont été faites sur une
distribution Linux Fedora core 6 . Fedora met à disposition l'utilitaire yum qui permet d'installer les rmp.
Les rpm sont des paquetages pré-compilés.
Adresse IP
Option service Port sip rtp local
local
Exécutable Adresse IP
SIPp Scénario par local
défaut
Figure 17: Exemple de commande d'exécution du serveur SIPp
Exécutable Adresse IP
Port sip local rtp local
SIPp
Figure 18: Exemple de commande d'exécution du client SIPp
Remarque : les adresses des interfaces IP sont à remplacer par celles des stations utilisées
- 46 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
[sippuas]
type=friend
username=sippuas ; Username to use when calling this device
beforeregistration
host=10.192.52.45 ; we have a static but private IP address
;fromdomain=10.192.52.45
port=5061
context=simulation ; Where to start in the dialplan when this phone
calls
dtmfmode=rfc2833 ; Choices are inband, rfc2833, or info
insecure=very
canreinvite=yes ; allow RTP voice traffic to bypass Asterisk
nat=yes ; there is not NAT between phone and Asterisk
[sippac]
type=friend
username=sippuac ; Username to use when calling this device
beforeregistration
host=10.192.52.45 ; we have a static but private IP address
;fromdomain=10.192.52.45
port=5060
context=simulation ; Where to start in the dialplan when this phone
calls
dtmfmode=rfc2833 ; Choices are inband, rfc2833, or info
insecure=very
canreinvite=yes ; allow RTP voice traffic to bypass Asterisk
nat=yes ; there is not NAT between phone and Asterisk
[simulation]
exten=>s,1,Dial(SIP/sippuas,20)
- 47 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
- 48 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
- 49 -
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
15. Bibliographie
1: , , http://sipp.sourceforge.net/
2: , sdgfsdf,
3: Christian Bersier, Hans-Peter Bucher, Antoine Delley, Voix sur IP et Multimédia,
4: Jim Van Meggelen, Jared Smith, Leif Madsen, Asterisk La téléphonie Open Source,
5: , MySQL++ Documentation, http://tangentsoft.net/mysql++/doc/
6: Christophe Blaess, Programmation Système en C sous Linux,
7: David R.Butenhof, Programming with Posix Threads,
8: , Xerces c++ parser, http://xerces.apache.org/xerces-c/
9: , boost C++ labraries, http://www.boost.org/doc/html/date_time/posix_time.html
10: , , http://ydisanto.developpez.com/tutoriels/j2se/runtime/
- 50 -