Mikiela

Projet de Diplôme
CAMAC-Call Machine. Simulateur de charge pour central VoIP
Auteur : Anne Léticia Mikiela

Professeur: Markus Jaton
Mandataire : Cédric Ducommun, Ingénieur télécommunication HES
Entreprise Flückiger SA à St. Blaise
Date : 17 décembre 2007
Projet de Diplôme 2007 Anne Léticia Mikiela
Simulateur de charge pour central VoIP HEIG-VD-IICT
1. Table des matières

1.Cahier des charges.........................................................................................................................................5
1.1 Résumé du problème ............................................................................................................................5
1.2 Cahier des charges.................................................................................................................................5
2. Résumé.........................................................................................................................................................6
3. Introduction..................................................................................................................................................7
Cadre de travail............................................................................................................................7
Structure du rapport ....................................................................................................................7
4. Analyse des besoins et choix des technologies.............................................................................................8
4.1 Analyse des besoins...............................................................................................................................8
4.1.1 Les applications externes à intégrer au projet...............................................................................8
4.1.2 La problématique de la simulation de charge................................................................................8
4.1.3 L'interface graphique.....................................................................................................................9
4.1.4 Le rendu des résultats...................................................................................................................9
4.2 Choix des technologies..........................................................................................................................9
4.2.1 Outil de test de performance SIPp de HP [1].................................................................................9
4.2.1.1 Caractéristiques.....................................................................................................................9
4.2.2 Analyseur de trafic Wireshark.....................................................................................................10
4.2.3 Base des données MySQL............................................................................................................10
5. Introduction aux technologies VoIP et ISDN...............................................................................................11
5.1 Concept VoIP.......................................................................................................................................11
5.1.1 Les principaux protocoles VoIP....................................................................................................11
5.1.1.1 Les protocoles RTP et RTCP.................................................................................................12
5.1.1.2 Concept SIP.........................................................................................................................12
Les messages SIP .......................................................................................................................12
Les Terminaux SIP.......................................................................................................................14
Transactions SIP.........................................................................................................................14
5.2 Solution PABX-IP pour la VoIP..............................................................................................................15
5.2.1 Le PABX Asterisk [4].....................................................................................................................15
Etablissement de session audio avec le PABX Asterisk...............................................................16
5.3 Caractéristiques de la technologies ISDN............................................................................................16
5.3.1 Canaux logiques...........................................................................................................................17
5.3.2 Interfaces standards ISDN...........................................................................................................17
6. Analyse du fonctionnement........................................................................................................................18
6.1 Architecture du projet.........................................................................................................................18
6.2 Ensemble des fonctionnalités.............................................................................................................19
6.2.1 Module de gestion du déroulement de la simulation..................................................................19
6.2.1.1 Diagramme de contexte du déroulement de la simulation.................................................19
6.2.1.2 Complexités de l'exécution de l'application........................................................................21
Le démarrage de l'application....................................................................................................21
La terminaison de l'application...................................................................................................21
6.2.2 Module de gestion de la génération du trafic..............................................................................22
6.2.2.1 L'établissement du trafic ....................................................................................................22
6.2.2.2 Le dimensionnement de la charge à générer.......................................................................22
6.2.2.3 Scénarios de simulation.......................................................................................................23
Tâches confiées aux agents SIPp...............................................................................................23
-2-
6.2.2.4 Diagramme d'activités du déroulement de la simulation....................................................23

6.2.3 Module de gestion de l'analyse du trafic ....................................................................................25
6.2.3.1 Point d'analyse du trafic et de collecte des résultats...........................................................25
6.2.3.2 Résultats de simulation .......................................................................................................26
6.2.4 Module de gestion d'accès à la base des données ......................................................................27
6.2.4.1 Schéma conceptuel de la base des données MySQL...........................................................27
6.2.4.2 Représentation graphique des résultats .............................................................................27
7. Réalisation..................................................................................................................................................28
7.1 Module de gestion de la génération du trafic .....................................................................................28
7.1.1 Choix des technologies................................................................................................................28
7.1.2 Implémentation...........................................................................................................................29
7.2 Module de gestion de l'analyse de trafic.............................................................................................30
7.2.1 Choix des technologies................................................................................................................30
7.2.2 Implémentation...........................................................................................................................30
7.2.2.1 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.............................................................................................................................33
7.2.3 Diagramme des classes ...............................................................................................................33
7.3 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.........................................34
7.4 Module de gestion du déroulement de la simulation..........................................................................35
7.4.1 Implémentation...........................................................................................................................35
Exécution des modules de lancement de l'application...............................................................35
7.4.1.1 Connexion de contrôle à distance.......................................................................................35
7.4.1.2 Contrôle de la synchronisation au démarrage et du déroulement de l'application.............36
Contrôle de la terminaison de l'application................................................................................36
7.4.1.3 Diagramme UML des classes implémentées.......................................................................36
7.4.2 Interface graphique.....................................................................................................................38
Gestion de l'évènement démarrer à partir de l'interface graphique..........................................39
8. Tests de fonctionnement............................................................................................................................40
8.1 Tests des fonctionnalités.....................................................................................................................40
8.1.1 Tests unitaires..............................................................................................................................40
8.1.2 Test de fonctionnement de l'application.....................................................................................41
Exemple d'exploitation des résultats de test..............................................................................41
9. Conclusion..................................................................................................................................................43
10. 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...............44
11. Remerciements.........................................................................................................................................45
12. 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++ ..............................................................................................................47
Base de données MySQL............................................................................................................47
13. Journal de travail......................................................................................................................................48
14. Index des figures.......................................................................................................................................49
-3-
15. Bibliographie.............................................................................................................................................50
-4-
1.Cahier des charges
CAMAC Call Machine. Simulateur de charge pour central VoIP
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.
-5-
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-
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.
-7-
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
4.1.1 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.
4.1.2 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-
○ 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)
4.1.3 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.
4.1.4 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.
4.2.1 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.
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-
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.
4.2.2 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.
4.2.3 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...).
- 10 -
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.
5.1.1 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.
- 11 -
5.1.1.1 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.
5.1.1.2 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 5060. 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.
- 12 -
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 : Permet le demande d’une nouvelle session

ACK : Confirme l'établissement de l’INVITE
BYE : 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
- 13 -
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
- 14 -
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.
5.2.1 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
- 15 -
é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
INVITE
100 TRYING
100 TRYING
180 RINGING
180 RINGING
200 OK
200 OK
ACK
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
- 16 -
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.
5.3.1 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 5.3.2
5.3.2 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.
- 17 -
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 DUT Module de

gestion du gestion de
déroulement l'analyse de
de la trafic
simulation
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
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
- 18 -
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
6.2.1 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.
6.2.1.1 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.
- 19 -
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
- 20 -
é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é.
6.2.1.2 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 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 -
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.
6.2.2.1 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).
6.2.2.2 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é
- 22 -
○ 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.
6.2.2.3 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.
6.2.2.4 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.
- 23 -
Figure 8: Diagramme d'activité du scénario de simulation
- 24 -
6.2.3 Module de gestion de l'analyse du trafic
6.2.3.1 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.
- 25 -
○ 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.
6.2.3.2 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 5.1.1.2 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.
- 26 -
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.
6.2.4.1 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 .
6.2.4.2 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.
- 27 -
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
7.1.1 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.
- 28 -
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
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.
- 29 -
7.2 Module de gestion de l'analyse de trafic
7.2.1 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.
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.
7.2.2.1 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.
- 30 -
Figure 11: Tâche de lecture des sortie Wireshark
- 31 -
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 à
- 32 -
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.
7.2.3 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é.
- 33 -
Main utilise les

Main les threads de méthodes BDconnection.cpp
Main.cpp
gestion de l'analyse de BDconnection1:1
de trafic
1:1
Analyseur.cpp
Analyseur utilise
Parseur utilise
le parser Parseur.cpp Appel.cpp
les méthodes
de BDconnection
1:1 1: n
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 5.1.1.2. Ceci revient à faire des opérations de types soustractions
sur leur résultats de simulation «time», résultat présenté au chapitre 6.2.3.1. 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]
- 34 -
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 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.
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.
7.4.1.1 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().
- 35 -
7.4.1.2 Contrôle de la synchronisation au démarrage et du déroulement de l'application

Dans le chapitre 6.2.1.2 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 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.
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
7.2.2 .
7.4.1.3 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.
- 36 -
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
- 37 -
à 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().
7.4.2 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.
- 38 -
Gestion de l'évènement démarrer à partir de l'interface graphique

La bibliothèque des classes java Swing permet de créer une interface graphique et de la gérer. Les
gestionnaires d'évènements permettent d'intercepter les actions des utilisateurs et d'assigner au
programme un comportement en réponse. La gestion d'évènements se fait de différentes manières.
Dans notre cas, un «écouteur» d'action a été attaché au bouton «Démarrer» qui attend que l'utilisateur
clique sur le bouton pour démarrer le scénario de simulation.
- 39 -
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.
8.1 Tests des fonctionnalités
8.1.1 Tests unitaires
Tests Schéma de test Résultats

Test de configuration du Nous lançons le client SIPp avec comme Validé
routage du trafic entre les adresse IP du destinatire celle de l'interface
agents SIPp par Asterisk. d' Asterisk. Et le serveur SIPp avec l'adresse
IP de sa station hôte. Asterisk se charge de
route le trafic.
Synchronisation du Après avoir lancer le simulateur, à l'aide de la Validé

démarrage des différents commande shell «ps» nous vérifions que les
programmes (agents SIPp, PID des programmes existent dans la liste des
programme distant via ssh, processus actifs. Lors de l'implémentation
outil Wireshark ) à partir expliqué au chapitre 7.4.1.2, nous avons fait
de l'interface graphique. afficher à la tâche de démarrage du client
SIPp un message indiquant que le thread
d'exécution etait en attente du signal du
démarrage du module de l'analyse du trafic.
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 -
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 d'extraction des Le test consiste à afficher les résultats Validé

résultats de simulation par extraits avec le parser xml et verifier s'ils
le parser xml corespondent bien aux résultats définis.
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.
Test de connexion et de Il s'agit de vérifier si on arrive à se connecter Validé

mise à jour de données à la base des données et si l'exécution des
dans la base de données requêtes SQL s'effectue sans lever
d'exception sur la syntaxe des requêtes.
8.1.2 Test de fonctionnement de l'application
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.
Exemple d'exploitation des résultats de test
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 -
Figure 16: Courbe des temps d'établissement des sessions SIP
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 -
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 .
Yverdon-les-Bains, le 17 décembre 2007
Anne Léticia Mikiela
- 43 -
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.
Ajout d'un application de représentation et de contrôle des données de simulation
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.
● Une interface graphique de définition des profils utilisateurs.

● Un module d'affichage dynamique des résultats.
- 44 -
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
Christian Roubaty : pour la disponibilité également et les différentes explications.

Alexandre Delez : pour l'aide par rapport au système de développement Linux et les explications
Stephen Badan : pour le soutien et les coups de pouce.

Cédric Ducommun : pour le projet proposé
- 45 -
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.
L'outil SIPp [1]

Vesion utilisé dans le projet : 2.0
rpm d'installation : libpcap, libnet et libpcap-devel
Commandes d'exécution SIPp
Adresse IP
Option service Port sip rtp local
local
./sipp -s s -sn uac_pcap -p 5060 -i 10.192.52.45 -mi 10.192.52.45
Exécutable Adresse IP
SIPp Scénario par local
défaut
Figure 17: Exemple de commande d'exécution du serveur SIPp
Scénario par Adresse IP local Port média

défaut
./sipp -sn uas -p 5061 -i 10.192.52.45 -mi 10.192.52.45 -mp 6001
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
Fichiers d'installation d' Asterisk et configurations

Pour faire juste de la VoIP, seul le paquet asterisk ( version 1.5) est nécessaire.
Extraction du code source : tar zxvf asterisk-*.tar.gz

Compilation : make clean, make, make install , make sample.
Configuration du serveur SIPp
- 46 -
[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
Configuration du client SIPp
[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
Configuration du context de la dimulation
[simulation]
exten=>s,1,Dial(SIP/sippuas,20)
La librairie XERCES C++

Commande : yum install xerces-c*
Base de données MySQL

Commande d'installation du serveur MySQL : yum install mysql-server
Commande d'installation du client Mysql : yum install mysql, yum install mysql-max
Commande d'installation du rpm mysql c++ : yum install mysql++-devel

Commande de lancement/arrêt du serveur MySQL : service mysqld start /stop
- 47 -
13. Journal de travail

Semaine du 18.09.07 au 27.09.07
● Correction du rapport du pré-projet de diplome
● Etude d'une solution de monitoring du central téléphonique avec SNMP (Simple Network
Management Protocol)
● Etude du stack java SNMP de Westhawk
● Recherche d'information sur la MIB 2 d' Asterisk
● Etude sur la possibilité de tracer les appels et d'intégrer Wireshark
● Implémentation de la structure d'uniformisation des évènements à tracer
Remarque : l'approche SNMP a été abandonnée
Semaine du 28.09.07 au 9.10.07

● Etude des protocoles RTP/SIP
● Définition des évènements à tracer
● Recherche pour l'établissement du trafic RTP avec SIPp
● Analyse des possibilité d'intégration de SIPp au projet
Semaine du 10.10.07 au 17.10.07

● Recherche pour l'installation des rpm fedora Xerces C++ et des libraries de compilation
● Etude de Xerces C++ et implémentation du parser xml
● Test du parser XML avec les messages SIP
Semaine du 18.10.07 au 30.10.07

● Recherche sur les commandes linux pour implémenter les scripts d'arrêt du serveur SIPp
● Définition des scénarios de test
● Etude sur les threads Posix C++ , recherche des libraires de compilation
● Implémentation du module de l'analyseur de trafic
Semaine du 1.11.07 au 14.11.07

● Recherche des rpm fedora MySQL C++ et étude de la librairie MySQL C++
● mise en place de la base de données
● Recherche sur la façon d'exploiter les résultats
● Recherche comment générer les graphiques ; svg, gnuplot, solution java
● Implémentation de l'interface graphique
● Recherche d'installation de la commande rsh et d'utilisation de ssh sans mot de passe
● Implémentation des tâches d'exécution de l'application
● Rédaction du Rapport
Semaine du 15.11.07 au 29.11.07

● Installation d' Asterisk et séparation des modules
● Recherche des configurations pour permettre le routage de SIP/RTP
● Test de fonctionnement avec Asterisk et redimensionnement de la base de données
● Implémentation pour résoudre le problème de saturation de la mémoire par le parser xml
● Rédaction du rapport
Semaine du 30.11.07 au 14.12.07
● Rédaction du rapport
- 48 -
14. Index des figures

Figure 1: Principaux protocoles de la VoIP......................................................................................................11
Figure 2: Structure de message SIP.................................................................................................................13
Figure 3: Transactions SIP...............................................................................................................................14
Figure 4: Interfaces de connection d'un PABX-IP aux différents réseaux ......................................................15
Figure 5: Etablissement de session audio avec Asterisk.................................................................................16
Figure 6: Schéma bloc de l'architecture du simulateur...................................................................................18
Figure 7: Diagramme de contexte des cas d'utilisations des fonctionnalités du simulateur...........................20
Figure 8: Diagramme d'activité du scénario de simulation.............................................................................26
Figure 9: Schéma de câblage pour l'analyse du trafic.....................................................................................27
Figure 10: Schéma conceptuel de la base de données..................................................................................29
Figure 11: Tâche de lecture des sortie Wireshark...........................................................................................33
Figure 12: Tâche de traitement des captures Wireshark................................................................................35
Figure 13: Diagramme des classes du module de gestion de l'analyse de trafic.............................................37
Figure 14: Diagramme des classes du module de gestion du déroulement de la simulation.........................42
Figure 15: Interface graphique du simulateur de charge................................................................................43
Figure 16: Courbe des temps d'établissement des sessions SIP.....................................................................47
Figure 17: Exemple de commande d'exécution du serveur SIPp....................................................................51
Figure 18: Exemple de commande d'exécution du client SIPp.......................................................................51
- 49 -
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 -

Mikiela

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Mikiela

Hochgeladen von

Copyright:

Verfügbare Formate

Projet de Diplôme

CAMAC-Call Machine. Simulateur de charge pour central VoIP

Auteur : Anne Léticia Mikiela

1. Table des matières

6.2.2.4 Diagramme d'activités du déroulement de la simulation....................................................23

1.Cahier des charges

CAMAC Call Machine. Simulateur de charge pour central VoIP

Proposé par : Flückiger SA à St. Blaise

1.1 Résumé du problème

1.2 Cahier des charges

Ce travail de diplôme comprend une partie théorique et une partie de développement.

L'étude du fonctionnement du simulateur, des contraintes imposées par les fonctionnalités et la

4. Analyse des besoins et choix des technologies

4.1 Analyse des besoins

● Les applications externes à intégrer au projet

4.1.1 Les applications externes à intégrer au projet

4.1.2 La problématique de la simulation de charge

○ trafic interne dans le réseau VoIP : de SIP/RTP vers SIP/RTP

4.1.3 L'interface graphique

4.1.4 Le rendu des résultats

4.2 Choix des technologies

4.2.1 Outil de test de performance SIPp de HP [1]

● L'absence d'API (Application Programming Interface) qui permettrait de l'inclure facilement

4.2.2 Analyseur de trafic Wireshark

4.2.3 Base des données MySQL

5. Introduction aux technologies VoIP et ISDN

5.1 Concept VoIP

5.1.1 Les principaux protocoles VoIP

La voix et les informations de signalisation utiles à l'établissement de la transmission sont ainsi

Nous abordons brièvement les protocoles de la VoIP utilisés dans le projet.

Figure 1: Principaux protocoles de la VoIP

5.1.1.1 Les protocoles RTP et RTCP

5.1.1.2 Concept SIP

Les messages SIP

Figure 2: Structure des message SIP

Il existe six types de requêtes SIP de base :

Invite : Permet le demande d’une nouvelle session

BYE : Met fin à la session

REGISTER : Communique la location de l’utilisateur (nom d’hôte, IP)

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

Les Terminaux SIP

Figure 3: Transactions SIP

5.2 Solution PABX-IP pour la VoIP

Figure 4: Interfaces de connection d'un PABX-IP aux différents réseaux

5.2.1 Le PABX Asterisk [4]

Etablissement de session audio avec le PABX Asterisk

Figure 5: Etablissement de session audio avec Asterisk

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

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.

5.3.1 Canaux logiques

5.3.2 Interfaces standards ISDN

L'interface résidentielle : consiste en l'utilisation simultanée des services téléphoniques et d'une

Il existe deux types de lignes ISDN:

6.1 Architecture du projet

Module de DUT Module de

Figure 6: Schéma bloc de l'architecture du simulateur

● Le PABX-IP : plate-forme de test connecté au réseau IP.

● Le module de gestion de la génération du trafic qui a une interface de communication avec le

● Le module de gestion de analyse du trafic : partie du système à développer chargée d'analyser le

6.2 Ensemble des fonctionnalités

6.2.1 Module de gestion du déroulement de la simulation