conception et réalisation d'une application de gestion des rapports téléphoniques et taxation

Projet de Fin d’Études
Présenté à :
La Faculté des Sciences de Gabès
Département Informatique
en vue de l’obtention du diplôme de
LICENCE APPLIQUEE AUX RESEAUX
INFORMATIQUES
CONCEPTION ET REALISATION D’UNE APPLICATION DE
GESTION DES RAPPORTS TELEPHONIQUES ET
TAXATION
Réalisé Par :
Ismail BOUALLAGUI
et
Moujahed HAJJI
Soutenu le 29/06/2016
Devant le jury composé de :
Mme. Raja AYED Président
Mlle. Ons MABROUK Examinateur
M. Nassreddine HAJLAOUI Encadrant
République Tunisienne A. U. : 2015-2016
Ministère de l’Enseignement Supérieur et
de la Recherche Scientifique
N° Ordre : LARI N°9 /2016
Université de Gabès
Faculté des Sciences de Gabès

CONCEPTION ET REALISATION D’UNE
APPLICATION DE GESTION DES RAPPORTS
TELEPHONIQUES ET TAXATION
Ismail BOUALLAGUI
Moujahed HAJJI
‫الخالصة‬:‫االجازة‬ ‫شهادة‬ ‫على‬ ‫الحصول‬ ‫اجل‬ ‫من‬ ‫الدراسات‬ ‫ختم‬ ‫مشروع‬ ‫اطار‬ ‫في‬ ‫العمل‬ ‫هذا‬ ‫يندرج‬
. ‫االعالمية‬ ‫الشبكات‬ ‫في‬ ‫التطبيقية‬
‫الهدف‬‫من‬‫هذا‬‫المشروع‬‫هو‬‫تصميم‬‫وانجاز‬‫اداة‬‫للفوترة‬‫في‬‫سياق‬‫خدمة‬‫نقل‬‫الصوت‬‫عبر‬‫بروتوكول‬
‫اإلنترنت‬‫وتطلب‬‫ذلك‬‫أوال‬‫دراسة‬‫عموميات‬‫هذا‬‫البوتوكول‬‫مع‬‫التأكيد‬‫على‬‫المبادئ‬‫و‬‫المعايير‬
‫والبروتوكوالت‬‫التي‬‫تدعم‬‫هذه‬‫الخدمة‬‫ثم‬‫قمنا‬‫بعد‬‫ذلك‬‫بتصميم‬‫شبكة‬‫افتراضية‬‫مبنية‬‫على‬‫اجهزة‬‫سيسكو‬
‫واخيرا‬‫استطعنا‬‫بعد‬‫مرحلة‬‫التحليل‬‫والتصميم‬‫من‬‫انجاز‬‫برمجية‬‫مع‬‫قاعدة‬‫.بيانات‬‫تمكن‬‫اساسا‬‫من‬‫تقديم‬
‫فاتورة‬‫لقائمة‬‫المكالمات‬‫لمستخدم‬‫معين‬‫ولمدة‬‫معينة‬
‫المفاتيح‬:‫الصوت‬‫عبر‬‫بروتوكول‬‫اإلنترنت‬,‫خادم‬‫الهيكلية‬ ‫االستعالم‬ ‫لغة‬
Résumé : Ce travail s’inscrit dans le cadre du projet de fin d’étude en vue de l’obtention du
diplôme de licence appliqué en réseau informatique.
Le but de ce projet est de concevoir et développer un outil pour la facturation dans un
contexte de service VOIP. Pour atteindre ce but, on a commencé par étudier les généralités sur
la Téléphonie sur IP, ceci tout en insistant sur les principes, normes et protocoles qui sous-
tendent ce service. Après nous avons conçu une architecture réseautique basé sur des
matériels CISCO. Enfin on a pu réaliser, après une étape d'analyse et de conception, une
plateforme WEB couplée à une base de données, permettant de façon basique de présenter
une facture et un listing des appels pour un utilisateur précis et pendant une période donnée.
Mots clés: VOIP,SQLSERVER
Abstract This work is part of my graduation project to obtain the bachelor's degree in
applied computer network.
The purpose of this project is to design and develop a tool for billing within a context of
VOIP service. To achieve this goal, we initially started to study general IP Telephony and
focusing mainly on the principles, standards and protocols that underpin this service. After
that we designed a networking architecture based on Cisco hardware. Our work went through
a step of analysis and design Finally, we were able to implement a Web platform combined
with a database that allows a basic submission of an invoice and a listing of calls for a specific
user within a given period.
Key-words: VOIP,SQLSERVER

Rapport de PFE Hajji Moujahed & bouallagui Ismail
41
Dédicace
A Dieu source de toute connaissance
A la mémoire de mes grands parents
Puisse Dieu les accueillir dans son infinie Miséricorde
A celui qui a toujours garni mes chemins force et lumière…mon trop cher père
A la plus belle perle au monde…ma tendre mère
A mon frère, A mes sœurs
En lui souhaitant tout le succès…tout le bonheur
A toute ma famille pour l’amour et le respect qu’ils m’ont toujours accordé
A mes binômes pour les sœurs agréables qu’elles étaient et qu’elles seraient pour moi
A tous mes amis
Pour une sincérité si merveilleuse…jamais oubliable
A toute personne
Qui m'a aidé à franchir un horizon dans ma vie…
Aimablement…
Je dédie ce modeste travail…

42
Remerciements
Le travail présenté dans ce rapport a été effectué dans le cadre de notre projet de
fin d’étude de la licence appliquée en réseaux informatique.
Ce projet a été réalisé en collaboration avec la société CollNet au terme de ce
travail.
On tient à exprimer nos remerciements à nos encadrant : Mr Nassredine hajlaoui,
Professeur à l'FSG, et Mr Mouhamed Ouazzaa, ingénieur à l’entreprise, pour leurs
idées, leurs directives et leurs pédagogies.
Veuillez trouvez ici l’expression de notre grand estime et de profonde
reconnaissance.

1
Introduction générale
es réseaux téléphoniques n'ont cessé d'évoluer et de se varier depuis longtemps . Pendant
plusieurs décennies, la transmission analogique de la voix fut la seule technologie
maîtrisée et utilisée. Mais, grâce à l’apparition des techniques d'échantillonnage, de
quantification et de codage, la transmission numérique de la voix est devenue possible. Aussi
bien la transmission de gros volumes de données requise par l'industrie informatique vocal
trouve son application à travers les réseaux numériques à intégration de services (RNIS) ,
l'INTERNET.
Pour tirer profit du développement d'Internet pour le grand public, des sociétés ont
développé des logiciels de téléphonie IP . Il est alors possible de transporter de la voix entre deux
ordinateurs et ainsi de communiquer. Bien que cette technique puisse paraître révolutionnaire,
elle est devenue insuffisante et peu professionnelle. En effet, pour pouvoir être applicable, un tel
réseau de téléphonie IP doit être interconnecté avec le réseau téléphonique commuté public
(RTCP).
Aujourd'hui, des standards sont en train d'émerger et des entreprises commencent à
satisfaire le marché en fournissant des passerelles faisant le lien entre les réseaux IP et les
réseaux RTCP. Mais interconnecter ces deux mondes n'est pas une chose facile, les
télécommunications et l'informatique ne s'étant jamais mis d'accord en matière de protocoles par
le passé. En effet, les télécoms ont toujours eu un souci de la qualité de service alors que les
informaticiens recherchaient un débit maximal. Le but de la téléphonie sur IP est de finaliser la
convergence voix/données autour d'un protocole unique, IP (et IPv6 dans le futur).
En effet, la téléphonie IP se base sur la même architecture que l'Internet et utilise les
mêmes infrastructures. La bande passante est une ressource rare et très déterminante pour la
qualité de la voix sur les réseaux IP ; cependant lorsqu'elle est disponible la fiabilité de la VOIP
dépend essentiellement de la configuration des infrastructures ; ce qui suppose une parfaite
L

2
maîtrise des protocoles mis en jeux. C'est dans cette perspective que s'inscrit la présente étude
intitulé : ‘ la taxation de la téléphonie VOIP’.
Au regard de ce qui précède, l'objectif de notre étude est de savoir comment faire une
facturation. Le suivi de la communication étant d'autant plus importante que la communication
elle-même un système de facturation fiable s'impose. C'est dans cette optique que CollNet, une
entreprise prestataire de services en télécommunication, réseau, électronique et sécurité incendie,
disposant d'une infrastructure adéquate pour la téléphonie IP nous a confié la mission de
configurer la VOIP sur des routeurs CISCO et surtout d'établir un système fiable de facturation.
Ce présent rapport est composé de trois chapitres. Le premier chapitre présente la structure
d’accueil est déroulement de notre stage (étude préalable).Nous présenterons dans le chapitre 2
une étude conceptuelle de la solution proposée. Les configurations des routeurs Cisco ainsi que
l’implémentation du système de facturation détaille dans le dernier chapitre.

3
CHAPITRE
1
Etude Préalable
Introduction
ans ce chapitre, nous présentons, tout d’abord, le cadre du projet et l’organisme
accueillant. Ensuite, nous définirons les notions de base sur lesquelles s’appuie notre
projet. Par ailleurs, nous exposerons une étude de l’existant qui permet de critiquer les
fonctionnalités des systèmes existants et leurs limites et qui nous amène à dégager la
spécification des besoins fonctionnels et non-fonctionnels de la société.
Cadre du projet
Ce projet s’englobe dans le cadre d’un projet de fin d’études au sein de la faculté du science de
Gabes pour l’obtention du diplôme licence appliqué en réseaux Informatique. Il a été réalisé au
sein de la société Collaboration Network IT.
1. Présentation de la Société
CollNet It est une société de services qui propose une multitude de services à valeur ajoutée et
des solutions intégrées dans le domaine de l’informatique et les télécommunications à base
d’infrastructures adaptées aux besoins et au profil exact de chaque entreprise.
a. Les services offerts par Collaborations Network IT
CollNet est une entreprise qui offre ses services dans la vente et la maintenance des onduleurs,
des groupes électrogènes, des infrastructures pour les réseaux informatiques et dans la sécurité
incendie. De ce fait elle assure alors l'étude, la vente, l'installation et la maintenance.
Elle assure plusieurs services tels que :
 La fourniture et la mise en place des solutions clef en main à base d’infrastructures des
réseaux, de la sécurité informatique, de serveurs et du stockage des données.
 La formation.
 L’assistance technique et l’expertise technologique.
 L’optimisation des infrastructures des réseaux et la sécurité.
D

4
 La conception et la validation d’architectures.
 Le transfert de compétences et la veille technologique.
 Concevoir et de déployer les systèmes de câblage pour ses clients.
b. Les différents domaines d’activité
Collaborations Network IT intervient principalement dans les domaines suivants:
 La sécurité informatique: protection des réseaux privés des attaques extérieures et
l'internes
 Les réseaux informatiques :
 Les communications unifiées: tout ce qui concerne les nouvelles technologies du système
téléphonique.
 La supervision des systèmes et des réseaux
 L’infrastructure des serveurs : les serveurs de messagerie, les annuaires LDAP et la
gestion de permission des utilisateurs.
 La sauvegarde et le stockage des données: backup des données et l'archivage des
historiques.
 Le câblage informatique.
2. Organigramme de CollNet IT
L'organisation structurelle de CollNet IT est perceptible à travers son organigramme
présenté dans la figure 1.1 qui présente schématiquement les liens hiérarchiques des
différents services et leurs relations. Notre stage a été accueilli au bureau d'études et de
conception qui est sous la responsabilité de la direction technique. La direction technique,
département de l'entreprise qui s'occupe de l'étude, du dimensionnement, de la planification
pour le déploiement et assure la maintenance des équipements ou des technologies fournis
par la société.

5
Figure 1.1: Organigramme de CollNet IT
3. Partenaires de CollNet
CollNET IT est officiellement partenaire avec ces différents constructeurs:
 Cisco : constructeur des équipements réseaux (switch, routeur, les solutions
téléphoniques sur IP, firewall).
 McAfee : fournisseur de solution antivirus et protection des emails.
 IBM: fournisseur de solutions de gestion des documents confidentiels d'entreprise ainsi
que les solutions de gestion des logs et événements.
 FORTINET : fournisseur des équipements de sécurités.
CollNET IT est certifié sur les solutions montionnées ci-dessous:
 Cisco SMB Select.
 Cisco Unified Communications Express.
 Cisco Express Foundation.
 IBM Business Partner.

6
Concepts de base
1. Qu’appelle t’on voix sur IP ?
Le terme générique VOIP (Voice Over Internet Protocole) est souvent utilisé dans son sens le
plus général pour désigner toutes les solutions permettant le transport de la parole sur un réseau
IP.
2. La signalisation dans la TOIP :
La signalisation correspond à la gestion des sessions de communication (ouverture, fermeture,
etc.). Le protocole de signalisation permet de véhiculer un certain nombre d'informations
notamment
 Le type de demande (enregistrement d'un utilisateur, invitation à une session multimédia,
annulation d'un appel, réponse à une requête, etc.).
 Le destinataire d'un appel.
 L'émetteur.
 Le chemin suivi par le message.
Protocoles Descriptions
SIP ( session initation
protocol)
Il est un standard IETF (Internet Engineering Task Force) décrit dans le RFC
3261. Il se charge uniquement d'initier la communication entre les participants
d'une communication. Il n'est utilisé qu'entre les Agents et le Registrar. C'est le
protocole RTP (Real-time Transfert Protocol) qui se charge de transporter les
données entre les participants d'une communication, le protocole SIP peut jouer un
rôle mineur pendant la session pour contrôler la liaison et s'occupe également de
sa terminaison.
H323
Il est défini par l'UIT-T.Il est destiné au début à normaliser les systèmes de
visiophonie sur un réseau local. L'architecture d'un réseau H323 fait appels aux
éléments suivants : les terminaux, un Gatekeeper, une Gateway, le MCU
(Multipoint Control Unit)
SCCP
Il est un protocole propriétaire CISCO.(Skinny Client Il est utilisé dans tous les
téléphones IP Cisco et dans Control Protocol) l'autocommutateur Cisco Call
Manager.
Tableau 1 : Différents protocoles de signalisation dans la TOIP [N1]

7
3. Présentation de la solution CCM de CISCO :
a) Cisco Call Manager Express (CCME)
Cisco Call Manager Express est une solution intégrée à la plate-forme logicielle Cisco IOS
(Internetwork Operating System) et qui permet le traitement d’appel sur les téléphones IP de
Cisco.
Grâce à elle, chaque routeur d’accès multiservice de Cisco peut offrir des fonctionnalités
analogues à celles d’un combiné multi lignes ou d’un commutateur privé (PBX) pour permettre
le déploiement d’une solution économique de communication IP haute fiabilité dans les petites et
moyennes entreprises.
Cisco Call Manager Express réalise une solution peu coûteuse, fiable et aux multiple
fonctionnalités pour des déploiements allant jusqu'à 240 utilisateurs.[2]
4. La Tarification dans la Téléphonie sur IP
a) Les fichiers spéciaux
La tarification VOIP se sert de deux types de rapports qui donnent l'historique des appels et le
diagnostic des appels.
 Call Details Records (CDR) ou rapport détaillé des appels : les enregistrements de
données qui contiennent des informations sur chaque appel qui a été traitée par le serveur
VOIP
 Call Management Records (CMR) ou rapport détaillé du management : les
enregistrements de données qui contiennent les paramètres de QOS ou le diagnostic des
informations de contrôle.
b) Les techniques de récolte d'information de tarification
Il en existe plusieurs
 Via requêtes SQL:
Dans les versions 3 et 4 du Call Manager la récupération des tickets appelés (CDR) est réalisée à
partir d'une connexion à une base de donnés via ODBC et par l'intermédiaire de requêtes SQL
générées à des intervalles réguliers définis en nombre de minutes.
 Communication par le protocole FTP :
Dans les versions récentes du Call Manager (6 et 7) le principe de récupération des CDR est basé
sur le Protocol FTP ou le CCM doit être configuré en tant que client FTP communiquant avec un

8
serveur qui récupère périodiquement les tickets envoyés par le Call Manager à des intervalles
réguliers paramétrables en nombre de minutes.
L'un des inconvénients majeurs dans cette architecture de communication est l'absence du fil de
l'eau dans le sens rigoureux du terme, du fait que la transaction téléphonique (appel entrant,
sortant, perdu etc..) ne peut être reçue qu'après au moins une minute. Ceci peut être contraignant
surtout dans un environnement d'exploitation hôtelier ou centre d'appel.
 Communication en temps réel par le protocole Syslog :
En tant que protocole, Syslog se compose d'une partie cliente et d'une partie serveur. La partie
cliente émet les informations sur le réseau, via le port UDP 514. Les serveurs collectent
l'information et se chargent de créer les journaux. L'intérêt de Syslog est donc de centraliser les
journaux d'événements, permettant de repérer plus rapidement et efficacement les défaillances
d'ordinateurs présents sur un réseau. La communication via syslog génère un trafic temps réel de
l'activité du CME à travers le port de communication UDP standard.[1]
Présentation du projet
1. Etude de l’existant
Dans le but d’atteindre les objectifs de notre application et apporter de la valeur ajoutée au
domaine de développement, il est nécessaire de faire une étude des solutions déjà existantes sur
le marché. Cette étude nous permet, d’abord, d’analyser les fonctionnalités déjà développées.
Par la suite, nous pouvons dégager les solutions envisageables qui peuvent faire face aux
problèmes liés aux solutions existantes ou bien améliorer les services offerts. Dans ce qui suit,
on cite quelques exemples des applications existantes sur le marché.
a) Asterisk2Biling(A2Billing)
A2Billing, combiné avec Asterisk est une plate - forme Télécom physique et Soft-commutateur
fournissant une large gamme de services de télécommunications utilisant à la fois la technologie
du téléphone traditionnel ou VoIP. Cela donne maintenant toute entreprise Telecom une très
bonne raison de considérer la plate - forme A2Billing sur les offrandes traditionnelles pour
VoIP Soft-commutateurs ainsi que de gros la facturation. Solutions A2Billing peut être utilisé
dans un certain nombre de rôles différents. [N2]
b) Freeside
Freeside est le package d'administration open-source de facturation, de billetterie et de compte
pour les fournisseurs de services Internet qui inclut maintenant le support pour la VoIP CDR

9
note et la facturation. Freeside soutient Asterisk et beaucoup d’autres formats de CDR. Services
Internet Freeside offre également des services d’installation, d’intégration, de configuration, de
migration, de formation, et de personnalisation.[N3]
2. Critique de l’existant
Différentes sont les raisons qui peuvent pousser les entreprises à s’orienter vers la VoIP
comme solution pour la téléphonie. Les avantages les plus marqués sont :
 Fiabilité et qualité sonore.
 Un réseau voix, vidéo et données (à la fois).
 Réduction des coûts.
 Flexibilité.
Après avoir émis certains doutes sur la qualité de service, les entreprises sont désormais
convaincues de la plus grande maturité technologique des solutions proposés sur le marché.
Cependant, plusieurs problématiques demeurent :
 la qualité sonore.
 la sécurité.
 les délais de transmission ou la perte de paquets.
 de facturation n’est pas en temps réel.
3. Problématique
L’objectif de notre projet est la mise en place d’une plate-forme de facturation. La solution
proposée doit permettre une taxation téléphonique consistante avec la génération des rapports de
journalisation.
Ce système de taxation sera intégré sur un routeur et se basera sur l'analyse des tickets CDR
(Call Detail Record).
Ce module de gestion de la taxation permettra de gérer, et de calculer les coûts téléphoniques
associés à tous les appels entrants et sortants. Il sera possible de trier les appels en fonction :
4. Fonctionnalité
L’étude de l’existant dans la section précédente nous a permis de mieux comprendre et cerner les
différentes fonctionnalités du système à réaliser.
 Fournir les tableaux de bord nécessaires à l'analyse de la consommation téléphonique.
 Refacturer les communications internes.

10
 Restreindre les utilisateurs ou services consommant trop.
 Fournir un système de pré payé aux utilisateurs ou services de téléphone pour des appels
vers national/international.
Conclusion
Apres avoir présenté les techniques diverses de déploiement de VOIP tout en insistant sur la
solution CCME qui nous a été proposée, aussi en présentant un état de l'art des technique de
tarification dans la téléphonie en générale et la téléphonie sur IP en particulier. Cette partie nous
présente les généralités et l'état de l'art de la technologie, c'est ainsi que la partie suivante sera
consacrée à une étude d'un cas particulier et à la configuration et la mise en place de notre
solution.

11
CHAPITRE
2
Analyse et conception
Introduction
a phase de spécification des besoins est indispensable pour tout système informatique. Au
cours de cette phase, on présente les exigences de notre projet, on définit les attentes ainsi
que les spécifications fonctionnelles et non fonctionnelles auxquelles notre application doit
répondre, les acteurs et l’étude conceptuelle tout en utilisant le langage de modélisation UML.
I. Modélisation de l’application
Notre projet diviser on deux parties, premièrement nous avons simulée avec le logiciel GNS3
une architecture VOIP, puis en mettre en place les configurations nécessaire pour les routeurs
et les softphones. deuxièment on a développé une application web pour la facturation des appels
téléphoniques dans lequel on a étudié la conception seulement pour cette partie.
II. Spécification des besoins
Pour spécifier les besoins, on débute l’analyse par l’identification des acteurs qui sont en
interaction avec le système. Ce dernier doit être capable de garantir des fonctionnalités pratiques
et utiles. Afin de définir les acteurs, nous nous sommes concentrés sur les rôles joués par les
entités extérieures de notre application.
1. Identification des acteurs
Un acteur est une entité externe (utilisateur humain, dispositif matériel ou autre système) qui
interagit directement avec le système. L’acteur qu’on a identifié est :
Admin: c’est toute personne interagissant avec l’application. Il a les droits d’accès libres et il
profite des différents services présents dans l’application.
2. Spécification des besoins fonctionnels
Les besoins fonctionnels représentent les exigences du futur système en termes de
fonctionnalités. Ils constituent une sorte de contrat ou promesse pour le comportement du
L

12
système généré. En effet, dans ce qui suit, on va énumérer les exigences fonctionnelles de
l’utilisateur.
S’identifier: l’admin s’identifie au début, saisit son login et mot de passe qui lui permettent
d’accéder aux différents services présents dans l’application.
Gérer compte: l’utilisateur peut ajouter, supprimer au modifier le compte.
Générer des factures : génération de rapports de facturation après la journalisation des CDR
qui contient ( date , heure , duré , appelant et appelée ) ou exporter pdf .
Filtrer les appels : l’admin filtrer les appels téléphoniques par date et par nom .
3. Spécification des besoins non fonctionnels
Les besoins non fonctionnels ont une influence directe sur la qualité de l’application. Notre
système doit répondre aux besoins non-fonctionnels suivants :
- Sécurité : L’application doit respecter la protection des informations personnelles de
l’utilisateur.
- Performance : Ces besoins sont liés au temps du chargement de l’application, l’ouverture
d’interface utilisateur et les délais de rafraîchissement des achats.
- Utilisabilité : Ces besoins sont liés aux aspects généraux de l’interface utilisateur. Cette
dernière doit être lisible, simple, intuitive et légère à utiliser.
- Ergonomies : l’application doit offrir une bonne ergonomie, une interaction avec l’utilisateur
intuitive et être facile à utiliser par tous les utilisateurs.
III. Diagramme du cas d’utilisation
1. Diagramme du cas d’utilisation général
L’admin de notre système peut effectuer les opérations suivantes :
- S’identifier.
- Gérer compte (ajouter, supprimer au modifier le compte).
- Générer des factures.
- filtrer les appels.
Ces opérations sont permises par le système après une tâche d’identification.
La figure 2.1 illustre le diagramme du cas d’utilisation général de notre système.

13
Figure 1.1 : diagramme du cas d’utilisation générale
IV. Diagrammes de séquences
1. Principe
Pour décrire les interactions entre les acteurs et le système selon un ordre chronologique, nous
faisons appel aux diagrammes de séquence. Ces interactions sont ainsi montrées dans le cadre
d’un scénario d’un diagramme du cas d’utilisation et elles ont pour but de décrire comment se
déroule les actions entre les acteurs et les objets.
2. Objectifs :
Les diagrammes de séquences sont utilisés pour illustrer les cas d’utilisations. En effet, ils
permettent de représenter des collaborations entre objets selon un point de vue temporel.
3. Présentation:
Dans un diagramme de séquences, les classes et les acteurs sont énumérés en colonnes, toutefois
avec leurs lignes de vie verticales indiquant la durée de vie de l'objet.

14
- Objet : Les objets sont des instances des classes, ils sont rangés horizontalement. En fait, la
représentation graphique pour un objet est similaire à une classe (un rectangle) précédée du nom
d'objet (facultatif) et de deux points (:).
- Acteur : Les acteurs peuvent également communiquer avec des objets, ainsi ils peuvent eux aussi
être énumérés en colonne.
- Ligne de vie : Les lignes de vie (Life Line) identifient l'existence de l'objet par rapport au temps.
La notation utilisée pour une ligne de vie est une ligne pointillée verticale partant de l'objet.
A ce stade, on présentera les différents diagrammes de séquences correspondants aux différents
cas d’utilisations déjà étudiés.
Description textuelle du cas d’utilisation « S’authentifier »
Acteur : admin.
Objectif : l’utilisateur s’identifie afin de pouvoir accéder à l’application.
Pré-Condition : la base de données est joignable.
Post-Condition : ouverture de l’application.
- Scénario : *L’utilisateur introduit ses coordonnées pour s’identifier.
*Le système valide les données saisies
*L’application est ouverte.
Exception : Si le login et le mot de passe sont erronés
La figure 2.2 illustre le diagramme de séquences pour le cas d’utilisation « s’authentifier ».

15
Figure 2.2 : diagramme de séquences pour le cas d’utilisation « S’authentifier »

16
Description textuelle du cas d’utilisation « Gérer comptes »
Acteur : admin.
Objectif : L’admin peut modifier, ajouter et supprimer un compte.
Pré-Condition : identification.
Post-Condition : le compte est géré.
- Scénario : *L’utilisateur saisit les informations du comptes à gérer.
*Le système valide ces informations.
*L’utilisateur choisit l’action de gestion du compte.
*Le compte est géré.
Exception : le compte n’existe pas.
La figure
2.3 illustre le diagramme de séquences pour le cas d’utilisation « ajouter abonné».
Figure 2.3 : diagramme de séquences pour le cas d’utilisation « ajouter abonné »
La figure 2.4 illustre le diagramme de séquences pour le cas d’utilisation « supprimer abonné».

17
Figure 2.4 : diagramme de séquences pour le cas d’utilisation « supprimer abonné».
Description textuelle du cas d’utilisation « filtrer les appel »
Acteur : admin.
Objectif : filtrer les appels téléphoniques .
Pré-Condition : l’admin peut choisir des critères de recherche sur les appels par date et par nom.
Post-Condition : liste des appels, correspondant aux critères de l’admin affichée.
- Scénario : *l’admin accède à la page de recherche.
*L’utilisateur choisit le nom ou la date recherché.
*système affiche la liste correspondante aux critères choisis .
Exception : s’il n’ya pas d’appel le système n’affiche rien.
La figure 2.5 illustre le diagramme de séquences pour les cas d’utilisation « filtrer des appels».

18
Figure 2.5 : diagramme de séquences pour le cas d’utilisation « filtrer les appels »
Description textuelle diagramme de séquence « générer facture»
Importer les fichiers logs enregistrées dans le serveur.
Parser ce fichier et insérer dans la base de donnée.
Exporter en pdf.
La figure 2.6 illustre le diagramme de séquences pour les cas d’utilisation « Générer factures».

19
Figure 2.6 : diagramme de séquences pour le cas d’utilisation « Générer factures »
V. Diagrammes de classes :
1. Principe
Le diagramme de classes identifie la structure des classes d’un système, y compris les propriétés
et les méthodes de chaque classe. Les diverses relations, telles que la relation d’héritage, peuvent
exister entre les classes y sont également représentées. En effet, le diagramme des classes
montre la structure interne d’un système à mettre en place. Il permet de fournir une
représentation abstraite des objets du système qui vont interagir ensemble pour réaliser les cas
d’utilisation. Il s’agit d’une vue statique car on ne tient pas compte du facteur temporel dans le
comportement du système.

20
2. Représentation graphique
La figure 2.7 illustre notre diagramme des classes.
La figure 2.7 : diagramme des classes générale
Conclusion
Au cours de ce chapitre, nous avons entamé la modélisation conceptuelle, la présentation des
langages de modélisation ainsi que les diagrammes nécessaires pour la réalisation de notre
application. Dans le chapitre suivant, nous allons montrer comment traduire cette étude
conceptuelle tout en présentant les outils nécessaires pour notre travail ainsi que les outils de
développement qu’on les a utilisés.

21
CHAPITRE
3
Réalisation
Introduction
près avoir entamé la phase de conception, nous passons à la partie réalisation qui consiste
au développement de notre application. Au cours de ce chapitre, nous décrivons la phase
de réalisation de l’application tout en spécifiant l’environnement du développement matériel et
logiciel, nous aborderons également les fonctionnalités les plus importantes de notre application
développée.
I. Outils logiciels
Les outils nécessaires à la réalisation de notre application sont présentés comme suit :
 Microsoft Visual Studio : est une suite de logiciels de développement
pour Windows conçue par Microsoft Visual Studio est un ensemble complet d'outils de
développement permettant de générer des applications web ASP.NET, des services
web XML, des applications bureautiques et des applications mobiles.
 ASP.NET : est une technique pour générer des pages web dynamiques. Une page ASP.NET
est composée de deux parties: d'un coté du HTML, et de l'autre des instructions de
programme.
Ces instructions sont utilisées pour générer le résultat d'une demande de page qui
sera envoyée au navigateur web. Le résultat que reçoit le navigateur est du HTML ordinaire.
Une page ASP.NET comporte des Web control : des portions de HTML qui peuvent être
modifiées par programmation.
 3CDaemon : est un logiciel de Freeware dans la catégorie Web Développent développé par
3Com qui contient des serveurs TFTP, FTP et syslog
 C# : est un langage de programmation orienté objet, commercialisé par Microsoft depuis
2002 et destiné à développer sur la plateforme Microsoft .NET .
Il est dérivé du C++ et très proche du Java dont il reprend la syntaxe générale ainsi que les
concepts, y ajoutant des notions telles que la surcharge des opérateurs, les indexeurs et les
A

22
délégués. Il est utilisé notamment pour développer des applications web sur la
plateforme ASP.NET .
 Microsoft SQL Server est un système de gestion de base de données (abrégé en SGBD)
incorporant entre autres un SGBDR (SGBD relationnel ») développé et commercialisé par la
société Microsoft. Il ne fonctionne que sous les OS Windows.[N4]
II. Simulation GNS3
1. Qu’est-ce que GNS3 ?
GNS3 est un simulateur de réseau graphique qui permet de simuler des réseaux complexes.
Pour permettre une simulation complète GNS3, le programme doit être lié avec :
 Dynamips, Coeur du programme qui permet une émulation des IOS Cisco.
 Dynagen, programme faisant la passerelle GNS3 et Dynamips.
 Qemu, émulateur de PC virtualisé générique et open source.
GNS3 est un excellent outil complémentaire pour faire de vrais labos, utiles pour les ingénieurs
réseaux, administrateur réseaux et tous les gens souhaitant passer les certifications CISCO
comme par exemple le CCNA, CCNP, CCIP, CCIE, etc...
Il peut également être utilisé pour expérimenter les fonctionnalités d'IOS ou pour vérifier des
configurations destinées à être déployées sur de vrais routeurs. GNS3 est un logiciel libre qui
fonctionne sur de multiples plateformes, incluant Windows, Linux, et MacOS X
Le gros avantage de GNS3 est qu’il évite de dépenser beaucoup d’argent dans des équipements
CISCO qui coûtent très chers, et de pouvoir manipuler et tester, comme dans un environnement
réel.
Fonctionnalités :
* Conceptions de topologies réseau complexes et de grande qualité graphique.
* Émulation de routeurs Cisco et de pare-feu PIX
* Simulation de commutateurs Ethernet, ATM et Frame Relay.
* Export de la topologie sous forme d'image (JPEG, PNG, BMP and XPM).
* Fichier de configuration compatible avec le format .NET de Dynagen.

23
Pour commencer nous avons utilisé GNS3 sur une distribution Windows pour notre rapport,
mais nous pouvons aussi le faire sur une autre distribution ou système d’exploitation (Linux,
MacOS X) .[N6]
2. Représentation de l’architecture
a) Téléphonie sur IP
Avant de nous plonger dans CME initialisation et configuration, nous avons besoin d'introduire
quelques concepts et de se familiariser avec eux.
Comprendre comment les fonctions de base de CallManager Express fonctionnent est cruciale
pour la bonne configuration et le fonctionnement du système. Comme mentionné, le CME
fonctionne sur le routeur Cisco et fournit ses services au réseau. Téléphones IP connectés au
réseau via un commutateur sont utilisés pour gérer les appels entrants et sortants et aussi un
serveur syslog pour enregistrer les traces des appels et les stocker dans un fichier log
La figure 11 illustre architecture technique.
Figure 3.1 : Architecture technique de notre application

24
La présente démonstration va nous permettre d’utiliser un environnement réseautique basé sur
du matériel CISCO simulé à l’aide de l’outil GNS3. Nous allons configurer trois hôtes deux
virtuel (par exemple Virtuel box : Windows 7 et xp) et l’autre sur mon machine se trouvant
chacun sur un réseau distinct et ayant une passerelle (routeur) distincte pour qu’ils
communiquent entre eux. Bref la topologie à réaliser se présente comme suit :
Figure 3.2 : simulation gns3 de notre application
b) Spécifications du laboratoire
Routeur : deux Routeur Cisco c3745, ayant une interface : parallèle (voir figure)
Machine virtuel windows7 : ayant une interface Ethernet qui va être relié au port du Switch.
Machine virtuel Windows xp : ayan une interface Ethernet qui va être relié au port du Switch.
Switch : sw1 ayant trois ports, port 1 qui va être relié à la carte FastEthernet du routeur CCME
et l’autre relie la machine virtuel Windows 7 (ethernet0) et la 3eme
relié a la carte réseau virtuel
VLAN1
VLAN2

25
loopback et sw2 ayant deux ports , port 1 qui va être relié à la carte FastEthernet du routeur
CCME et l’autre relie la machine virtuel Windows xp
CIPC : trois Cisco IP communicateur (softphone), un relie au Windows 7, la deuxieme relie au
switch avec un carte réseau virtuel (loopback) et l’autre relie au windows xp
c) Dialogue entre 3 Cisco IP Communicator
Objectif : Réaliser l'architecture réseau ci-dessous et établir une communication vocale IP entre
trois Cisco IP Communicator.
Le plan de numérotation à mettre en œuvre :
Cisco IP Cisco IP Cisco IP
Communicator 1 Communicator 2 Communicator 3
Nom : Ismail Moujahed Naserddine
Numéro : 1000 1001 2000
Tableau 2 : Cisco IP communicators
3. Configuration du routeur Cisco (IOS Cisco Call Manager Express)
La configuration du routeur Cisco est l'étape la plus importante. En effet c'est cet équipement
réseau qui est à l'origine de la gestion des appels téléphoniques de type IP.
a) Configuration de l'interface Fa0/0 du routeur
L'interface Fa0/0 du routeur cisco est utilisée pour la communication entre les différents agents
téléphoniques et l'IOS Cisco Call Manager. C’est l'IOS qui s'occupe de la gestion de la
téléphonie, de l'intégration d'un équipement et de sa suppression au sein du réseau.
b) Configuration de l’interface S1/0 du routeur :
L’interface serial1/0

26
c) Configuration du protocole de routage OSPF :
Le protocole OSPF utilisé, étant un protocole de routage à état de lien, choisit automatiquement
le meilleur chemin.[N5]
d) Configuration des connexions H.323 et SIP :
SIP et H.323 peuvent être configurés sur le même routeur, mais l'acheminement des appels
entre les deux numéros est par défaut désactivé. Pour activer ce routage, entrer dans le mode de
configuration de service vocal et exécutez la commande allow-connections from-type to to-
type.
Bind control et Bind media pour définit une adresse de source pour la signalisation et des
paquets de médias [3]
e) Configuration de la téléphonie sur le routeur CME
Dans un premier temps, nous configurons la téléphonie automatiquement à l'aide de la
commande telephony-service .
Maintenant que le service téléphonique est activé et configuré, nous devons créer 2 ephones qui
accueilleront les 2 softphones, ainsi que 2 extensions qui seront par la suite associées aux
ephones.

27
Comme dit précédemment les extensions possèdent un numéro et des options. L'option name de
l'ephone-dn permet d'indiquer le nom d'affichage de l'appelant sur le terminal appelé
(respectivement le nom de l'appelé sur le terminal de l'appelant).
Il y a aussi les options telles que :
Label : pour afficher le nom sur l’écran du téléphone (IP communicator)
Description : la description telle que le Bureau la fonction ou autre toujours sur l’écran du
telephone.
A cette étape de configuration nous pouvons dès à présent communiquer avec nos deux Cisco IP
Phone. [N6]
f) Configuration de Cisco IP Communicator
Cisco IP Communicator fonctionne de façon très similaire à un téléphone classique ; il permet de
passer et de prendre des appels téléphoniques, de mettre des appels en attente, d'utiliser la
numérotation abrégée, de transférer des appels, etc. Cisco IP Communicator prend également en
charge des fonctions téléphoniques spéciales (telles que le parcage d'appels et les conférences
Meet-Me) qui offrent des capacités de traitement d'appels supplémentaires et personnalisées.

28
Figure 3.3 : configuration Cisco IP communicateur
Connexion établie avec le numéro 1000 attribué automatiquement comme
spécifier.
Figure 3.4 : Cisco IP Communicator en mode par défaut
Renseigner
la carte
réseau
Renseigner
l’adresse IP
de call
manager

29
Entrez un numéro de téléphone (la fonction de numérotation automatique peut vous proposer
des numéros de téléphone de votre journal appels composés correspondant aux chiffres saisis).
Figure 3.5 : Test d’appel entre 1000 et 1001
Figure 3.6: Communication entre les deux softphone

30
g) Exemple de sortie call detail records (CDRs)
Ceci est une partie de sortie de la console à partir du routeur après chaque appel. Lorsque
la configuration est activée, les CDR sont dirigés vers la console du routeur ainsi que le serveur
syslog. Cela empêche les CDR et les autres messages du système d'apparaître sur la console,
mais ils sont toujours connectés au serveur syslog.
Les clients exigent parfois de journaliser les enregistrements détaillés des appels (CDR) des
systèmes de voix sur IP (VoIP) à des fins de comptabilité ou de facturation. Pour ce faire, il est
recommandé d’utiliser un serveur syslog fournissent souvent des fonctionnalités de
journalisation des CDR, de traitement des enregistrements d’après appel et de génération de
rapports de facturation.
On a utilisé le serveur syslog 3CDeamon
Avec les commandes gw-accounting et logging le CDR sera stocké dans le serveur syslog
(3CDaemon).
La journalisation des appels avec le syslog server :
Figure 3.7 : L’interface du logiciel 3CDaemon

31
Contenue du fichier enregistré dans le serveur syslog :
Figure 3.8: le fichier syslog.log
Les enregistrements de détails d'appels (CDR), de données de facturation et de données
d'événements sont des catégories d'événements archivés par les opérateurs de
télécommunications et de commutateurs réseaux. Les CDR contiennent des informations utiles
sur l'appel ou le service passé par le commutateur : numéro d'émission de l'appel, numéro du
destinataire, date et heure de l'appel, durée, type, etc.
III. Interface de l’application
Dans cette partie, nous nous intéressons à la manipulation de cette application en se basant sur
quelques exemples d'aperçus d'écran de notre application.
La ﬁgure 3.9 illustre la page de connexion. Comme montre la ﬁgure, l’admin doit saisir un login
et un mot de passe valides pour accéder aux interfaces qui suivent.
Figure 3.9 : Page d'authentification

32
Après connexion, une interface s’affichera permettant à l’admin d’avoir une idée globale sur le
nombre des utilisateurs, des operateurs et une statistique sur les différents appels ( locale et
extérieur )
comme montre la figure suivante .
Figure 3.10 : interface d’acceuil
Dans cette interface l’admin voir la liste des utilisateurs ,il peut changer l’état , modifer ,
supprimer ou ajouter un nouveau utilisateur
Figure 3.11: interface des utilisateurs

33
La figure si dessous illustre le formulaire d’ajout d’un utilisateur .
Figure 3.12: formulaire d’ajout d’un utilisateur
Une fois que le fichier logs est stocké dans le serveur syslog l’admin peut l’importer dans la base
de données.
La figure suivante indique la liste de facture générer
Figure 3.13: interface des factures

34
Après l’importation on peut exporter la facture en format pdf.
Figure 3.14 : exportation en pdf

35
Chronogramme
Ce travail a été réalisé durant une période de 4 mois. Sa structuration et répartition temporelle
sont décrites par le chronogramme suivant.
Figure 3.15 : chronogramme
Conclusion
Au cours de cette partie, nous avons évoqué tous les aspects qui sont en relation avec la
réalisation de l’application. Nous avons présenté, entre autre, des captures d’écrans présentant les
différentes interfaces de l’application. Nous passons à la fin de ce rapport à la conclusion
générale.

36
Conclusion générale
ous sommes intéressés dans ce projet à la conception et développement d’une application
web de taxation téléphonique consistant en la génération de rapports journaliers des appels
pour pouvoir superviser les appels et serrer au maximum la facture téléphonique, ce système de
taxation sera intégré avec le service de la VOIP et se basera sur l'analyse des tickets CDR (call
Detail Record)
La présente recherche nous a permis de nous familiariser avec les équipements CISCO. Nous
avons au passage maîtrisé la configuration des routeurs CISCO aussi bien pour la VoIP que pour
le routage, la configuration des Switchs CISCO aussi bien des softphones que du VLAN
Les objectifs que nous nous étions fixés au départ sont atteints. Il est vrai que notre système
actuel permet de suivre la consommation téléphonique mais il est moins pratique pour les
utilisateurs parce qu'il n'offre pas une interface où les utilisateurs pourront suivre en temps réel
l'évolution de la durée de leurs communications. Nous pensons aussi poursuivre nos recherches
en ce sens, de plus une évolution possible de notre projet consiste à affecter un budget, pour
l'entreprise en générale et alerter l’utilisateur par mail ou SMS en cas de dépassement d’une
durée donnée de consommation.
La téléphonie sur IP constitue un marché qui est sans cesse en progression. De plus en plus
d’entreprises ont recours à cette solution. Notre projet touche donc un aspect d’actualité ce qui le
rend très intéressant.
N

37
Nethographie
[N1]https://wapiti.telecom/lille.fr/commun/ens/peda/options/st/rio/pub/exposes/exposesser
2010-ttnfa2011/barisaux-gourong/H323vsSIP.html
[N2]www.asterisk2billing.org/
[N3] http://freeside.biz/freeside/
[N4] www.wikipedia.org/
[N5]http://www.cisco.com/cisco/web/support/CA/fr/109/1096/1096158_tdcmecue.htmlhttp
://www.frameip.com/voip/
[N6]http://www.firewall.cx/cisco-technical-knowledgebase/cisco-voice/922-cisco-voice-
cucm-cme-h323.html

38
Bibliographie
[1] [Cisco CallManager Express SNMP MIB Support, First Published: Dec 2005, Last
Updated: Jan 2006
[2] VoIP et ToIPAsterisk: La téléphonie sur IP (conception, installation ) p164
[3] Configuring Cisco Voice Over IP 2E p47

39
SOMMAIRE
INTRODUCTION GÉNÉRALE................................................................................................. 1
ETUDE PRÉALABLE ................................................................................................................. 3
INTRODUCTION............................................................................................................................. 3
I. Cadre du projet ................................................................................................................ 3
1. Présentation de la Société............................................................................................. 3
2. Organigramme de CollNet IT...................................................................................... 4
3. Partenaires de CollNet.................................................................................................. 5
II. Concepts de base.............................................................................................................. 6
1. Qu’appelle t’on voix sur IP ?........................................................................................ 6
2. La signalisation dans la TOIP :..................................................................................... 6
3. Présentation de la solution CCM de CISCO : .............................................................. 7
a) Cisco Call Manager Express (CCME)...................................................................... 7
4. La Tarification dans la Téléphonie sur IP .................................................................... 7
a) Les fichiers spéciaux................................................................................................. 7
b) Les techniques de récolte d'information de tarification............................................ 7
III. Présentation du projet...................................................................................................... 8
1. Etude de l’existant ........................................................................................................ 8
a) Asterisk2Biling(A2Billing)....................................................................................... 8
b) Freeside..................................................................................................................... 8
2. Critique de l’existant .................................................................................................... 9
3. Problématique............................................................................................................... 9
4. Expression des besoins...................................................... Erreur ! Signet non défini.
CONCLUSION.............................................................................................................................. 10
ANALYSE ET CONCEPTION................................................................................................. 11
INTRODUCTION........................................................................................................................... 11
I. Modélisation de l’application ........................................................................................ 11
II. Spécification des besoins fonctionnels........................................................................... 11
1. Identification des acteurs............................................................................................ 11
2. Spécification des besoins fonctionnels par acteurs : .................................................. 11
3. Spécification des besoins non fonctionnels................................................................ 12
III. Diagramme du cas d’utilisation..................................................................................... 12

40
1. Diagramme du cas d’utilisation général ..................................................................... 12
2. Description textuel du cas d’utilisation ............................. Erreur ! Signet non défini.
VI. Diagrammes de séquences ............................................................................................. 13
1. Principe....................................................................................................................... 13
2. Objectifs : ................................................................................................................... 13
3. Présentation: ............................................................................................................... 13
V. Diagrammes de classes :................................................................................................ 19
1. Principe....................................................................................................................... 19
2. Représentation graphique ........................................................................................... 20
CONCLUSION.............................................................................................................................. 20
RÉALISATION .......................................................................................................................... 21
INTRODUCTION........................................................................................................................... 21
I. Outils logiciels................................................................................................................ 21
II. Simulation GNS3............................................................................................................ 22
1. Qu’est-ce que GNS3 ? ................................................................................................ 22
2. Représentation de l’architecture ................................................................................. 23
a) Téléphonie sur IP .................................................................................................... 23
b) Spécifications du laboratoire................................................................................... 24
c) Dialogue entre 3 Cisco IP Communicator .............................................................. 25
3. Configuration du routeur Cisco (IOS Cisco Call Manager Express) ......................... 25
a) Configuration de l'interface Fa0/0 du routeur......................................................... 25
b) Configuration de l’interface S1/0 du routeur :........................................................ 25
c) Configuration du protocole de routage OSPF :....................................................... 26
d) Configuration des connexions H.323 et SIP :......................................................... 26
e) Configuration de la téléphonie sur le routeur CME................................................ 26
f) Configuration de Cisco IP Communicator.............................................................. 27
g) Exemple de sortie call detail records (CDRs)......................................................... 30
III. Interface de l’application............................................................................................... 31
CONCLUSION.............................................................................................................................. 35
CONCLUSION GÉNÉRALE.................................................................................................... 36
NETHOGRAPHIE ..................................................................................................................... 37
BIBLIOGRAPHIE...................................................................................................................... 38

conception et réalisation d'une application de gestion des rapports téléphoniques et taxation

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à conception et réalisation d'une application de gestion des rapports téléphoniques et taxation

Similaire à conception et réalisation d'une application de gestion des rapports téléphoniques et taxation (20)

Dernier

Dernier (6)

conception et réalisation d'une application de gestion des rapports téléphoniques et taxation