Conception d'une plateforme de ventes de crédits par des opérateurs de transferts d'argent.

REPUBLIQUE DU SENEGAL

***** * * ********

Ecole Centrale des Logiciels Libres et de Télécommunications

MEMOIRE DE FIN DE CYCLE

Pour l'obtention du : Diplôme de Licence en Télécommunications et Réseaux

SUJET :

CONCEPTION D'UNE PLATEFORME DE VENTE DE CREDITS PAR DES OPERATEURS DE TRANSFERTS D'ARGENT

Lieu de stage : RTN/ELT Période stage : 04/2016 - 08/2016

Professeur encadreur :

Dr Samuel OUYA

Présenté et soutenu par

· Abagana Mahamat KACHALLAH

· Akhibou Demba SOKHONA

DEDICACES

Nous dédions ce mémoire:

KACHALLAH Abagana Mahamat:

Ma maman Fatimé Nambe Khamis

Mon père Abagana Mahamat

Omar NDOYE & NDOYE Fatou

Mon Oncle Djibrine Nambe Khamis

Ma tante Zenaba Khamis Nambe

Ma soeur Hadje Rakhie Abagana

Mon Cousin Bichara Nambe Khamis

Akhibou Demba SOKHONA:

Ma maman Dieneba Moussa SOKHONA

Mon père Demba SOKHONA

Mon Oncle Oumar SOKHONA

Mes soeurs Tiguidé Demba SOKHONA,

Dieneba Demba SOKHONA,

Hademou Demba SOKHONA

Mes freres Bechir Demba SOKHONA,

Ousmane Demba SOKHONA

REMERCIEMENTS

Nous remercions ALLAH le tout puissant, le miséricordieux de nous avoir donné la force et le courage à l'élaboration de ce travail. Nos remerciements vont également à notre Professeur et encadreur Dr Samuel OUYA ainsi qu'à M. DIALLO Abdoulaye et M. Latyr NDIAYE pour leur soutiens au long de ce parcours. Nous remercions aussi M. Jean DIOKH pour ses conseils. Nos remerciements vont aussi à l'ensemble du corps professoral et administratif du groupe RTN/ELT, M. Allier QUENTINY particulièrement ainsi qu'à nos camarades de classe. Nous remercions M. Moussa DIAKHITE, M. James GAGLO et M. Ibrahima SANOGO pour leur aide.

Akhibou Demba SOKHONA: mes remerciements vont directement à mes parents Dieneba Moussa SOKHONA et Demba SOKHONA de leur confiance à mon égard et de l'éducation qu'ils m'ont inculqué. Mes remerciement vont tout droit vers tous les membres de ma famille et amis.

KACHALLAH Abagana Mahamat: mes remerciements vont directement à mes parents Fatime Nambe Khamis et Abagana Mahamat de leur confiance à mon égard et de l'éducation qu'ils m'ont inculqué. Mes remerciement vont tout droit vers tous les membres de ma famille et amis.

.

RESUME

Ce document est un mémoire de fin de cycle en vue de l'obtention du Diplôme de Licence en Télécommunications et Réseaux.

Le Groupe RTN/ELT est spécialisé dans le domaine des logiciels libres et de télécommunications.

Le contexte de notre sujet s'insère dans l'évolution des réseaux de télécommunications vers le tout IP qui constitue aujourd'hui un véritable défi pour les formations en télécommunication de se familiariser avec le protocole de signalisation comme SIP afin de pouvoir développer des services basés sur celui-ci. Etant conscient de ce phénomène, le Groupe RTN/ELT a initié un projet phare de mise en oeuvre :

· d'un système de facturation fiable basé sur le protocole SIP intégrable dans les plateformes web ;

· d'un système de vente de crédit intégrable chez les opérateurs de transfert d'argent.

Ainsi il sera question dans ce présent mémoire d'étudier Freeswitch, améliorer ses composants afin de faciliter la mise en oeuvre des systèmes en y ajoutant des fonctionnalités nouvelles mais aussi y intégrer un SMSC-IP pour le traitement des messages et des services à valeur ajoutés mais aussi de bien maîtriser l'outils de facturation a2billing.

SIGLES ET ABREVIATIONS

ToIP	Telephony over IP
RNIS	Réseau Numérique à Intégration de Services
AUC	Authentification Center
UCA	Unified Communications Agent
BSC	Base Station Controller
BTS	Base Transceiver Station
CN	Controller Network
FXS	Foreign eXchange Subscriber
FXO	Foreign eXchange Office
GGSN	Gateway GPRS Support Node
GMSC	Gateway Mobile Switching Center
GPRS	General Packet Radio Service
GSM	Global System for Mobile
HLR	Home Location Register
HSS	Home Subscriber Server
HTTP	Hyper Text Transport Protocol
QoS	Quality of Service
IAX	Inter-Asterisk eXchange
DNS	Domain Name System
IETF	Internet Engineering Task Force
AAC	Advenced Audio Coding
LTE	Long Term Evolution
DDDS	Dynamics Delegation Discovery System
TDM	Time Division Multiplexe
VoIP	Voice over IP
MSC	Mobile Swicthing Center
NMC	Network and Management Centre
NSS	Network and Switching Sub-system
GPL	General Public License
OMC	Operations and Maintenance Center
OSI	Open System Interconnection
OSS	Operations Sub-System
RTCP	Real-time Transport Control Protocol
RTP	Real-time Transport Protocol
SCP	Service Control Point
IP	Internet Protocol
REST	REpresetation State Transfer
SGSN	Serving GPRS Support Node
SIP	Session Initiation Protocol

TABLE DES FIGURES

Figure I.1: Organigramme de l'entreprise RTN.............................................................................7

Figure II-1: Les classes par niveau du modèle OSI........................................................................13

Figure II-2: L'établissement de session entre les agents.............................................................15

Figure II-3: l'enregistrement de l'utilisateur sur le serveur registrar...........................................16

Figure II-4: mécanisme de redirection de données.......................................................................17

Figure II.5 ports FXS et FXO .................................................................................................18

Figure II.6 passerelle FXS/FXO ............................................................................................18

Figure III.1 Architecture d'une passerelle..................................................................................27

Figure V.1 Architecture SOAP..............................................................................................34

Figure V.2 Architecture REST..............................................................................................35

Figure V.3 Image Python ....................................................................................................35

Figure V.4 Image Flask ......................................................................................................36

Figure V.5 Image Flask-restplus ........................................................................................36

Figure V.6 Architecture HTTPS..........................................................................................37

Figure V.6 Architecture VPN..............................................................................................38

Figure VI.1 Image Asterisk..................................................................................................39

Table des matières............................................................................................................................1

^DEDICACES 2

REMERCIEMENTS 3

RESUME 4

TABLE DES FIGURES 7

INTRODUCTION GENERALE 12

Chapitre I. PRESENTATION GENERALE 13

I.1. Présentation de L'entreprise RTN/ELT 13

I.1.2. Domaines d'activité de RTN 14

I.1.3. Organigramme de RTN/ELT 14

I.2 : Présentation du projet 15

I.2.1 : Le Contexte 15

I.2.2 : La Problématique 15

I.2.3 : Objectifs attendus 16

Conclusion 16

Chapitre II. CONCEPTS DE BASE DE LA VOIP ET LES PRINCIPALES IMPLEMENTATIONS 16

Introduction 16

II.1. Définition et Caractéristiques de la ToIP 16

II.1.1. Définition de la ToIP 16

II.1.2. Caractéristiques de la ToIP 16

II.1.3. Avantages de la ToIP 17

II.1.4. Contraintes de la ToIP 18

II.2. Etudes détaillées des protocoles de signalisation 20

II.2.1. Le protocole H323 20

II.2.2. Le protocole SIP 21

II.2.3. Le protocole SCCP 24

II.2.4. Le protocole ENUM 25

II.3. Les codecs 25

II.4. Etudes des passerelles VOIP 25

II.4.1. Concepts de ports FXS et FXO 25

II.4.2. Présentations de quelques cartes RNIS 27

II.4.3. Présentations de quelques passerelles dans la téléphonie 27

II.4.4. Présentations de quelques fournisseurs Voip en Europe et USA 28

II.4.5. Présentation de quelques solutions SIP 29

II.4.6. Présentation de quelques plateformes VOIP 31

Conclusion 31

Chapitre III. PRESENTATION DETAILLEE DE FREESWITCH 32

Introduction 32

III.1. Historique et philosophie de Freeswitch 32

III.1.1. Historique de Freeswitch 32

III.1.2. Philosophie de Freeswitch 33

III.2. Les notions de modules et présentation des modules relatifs à notre projet. 33

III.2.1. Les notions de modules 33

III.2.2. Présentation des modules relatifs à notre projet 34

III.3. Définitions de quelques concepts liés à Freeswitch 34

III.3.1. La notion de contexte 34

III.3.2. La notion de sip_profiles 35

III.3.3. La notion de dialplan 35

III.4. Présentations des modules lua et python 35

III.4.1. Présentations du module lua 35

III.4.2. Présentation du module python 35

III.5. Notions de Gateway 35

III.6. Dialplan avancé et applications externes 36

Conclusion 36

Chapitre IV. PRESENTATION DE LA FACTURATION 37

Introduction 37

IV.1. Quelques concepts liés à la facturation 37

IV.1.1. Facturation en ligne et hors ligne 38

IV.1.2. Types de comptes 39

IV.1.3. Modèles d'affaires 39

IV.1.4. Différents types de frais 40

IV.2. Modèles de facturations 40

IV.2.1. La facturation sur l'abonnement 40

IV.2.2. La facturation en fonction du volume 40

IV.2.3. La facturation sur l'évènement 40

IV.2.4. La facturation en fonction du temps 41

IV.2.5. La facturation Basée sur la récompense 41

IV.3. Stratégies de prix 41

IV.3.1. Prix forfaitaire 41

IV.3.2. Prix réactif 41

IV.3.3. Prix de capacité prévue 41

IV.3.4. Prix prioritaire 42

Conclusion 42

Chapitre V. CONCEPTS D'API ET NOTION DE SECURITE RESEAU 42

Introduction 42

V.1. Concept d'API 42

V.1.1. Définition 42

V.1.2. Architecture d'API 43

V.1.3. Présentation de Flask-Restplus 44

V.2 Notion de sécurité réseau 45

V.2.1. Présentation de la sécurité réseau 45

V.2.2 Les protocoles sécurisés 45

Conclusion 47

Chapitre VI : CONCEPTION ET IMPLEMENTATION DE LA SOLUTION 47

Introduction 47

VI.1. Conception de la solution 48

VI.1.1 Conception du système de facturation 48

VI.1.2. Conception du système de vente de crédit 56

VI.1.2. Implémentation de la solution 65

Conclusion 75

Conclusion générale et perspective 76

BIBLIOGRAPHIE 77

WEBOGRAPHIE 78

ANNEXE 79

INTRODUCTION GENERALE

Aujourd'hui nous assistons à un essor fulgurant des technologies de l'information et de la communication, l'utilisation des logiciels libres ne peut être en reste, elle est devenue incontournable dans le domaine des télécommunications.

C'est pourquoi, le groupe RTN qui s'active dans le domaine des logiciels libres et qui vise à accroître la compétitivité de ses clients par la valorisation des composantes informatiques, logicielles et réseaux constituants le système d'information de ces derniers, s'est fixée comme objectif de mettre en place un système de facturation et un système de vente de crédit en ligne pouvant être intégré chez les opérateurs de transfert d'argent. Ce dans ce même contexte que s'inscrit notre sujet de mémoire. Dans ce mémoire, nous présenterons les différentes étapes qui ont mené à la conception et à la réalisation de ces systèmes et de la plateforme. Ce document est structuré en six chapitres:

· Le chapitre 1 décrit la présentation générale et fait une présentation détaillée du projet.

· Le chapitre 2 décrit les concepts de la ToIP

· Le chapitre 3 décrit la présentation détaillée de Freeswitch

· Le chapitre 4 décrit les concepts liés à la facturation

· Le chapitre 5 décrit les concepts liés à l'API et la notion des sécurités réseaux

· Le chapitre 6 décrit la conception et la réalisation du système de facturation et du système de vente.

Chapitre I. PRESENTATION GENERALE

I.1. Présentation de L'entreprise RTN/ELT

Crée en 2003, RTN (Réseaux et Techniques Numériques) était à l'origine un G.I.E dirigé par une équipe de professionnels qualifiés, d'Ingénieurs, de Techniciens et de diplômés de 3eme cycle en réseaux informatiques. Son premier siège se trouvait alors aux HLM HANN MARISTES à l'immeuble A appartement 22.

En 2005, RTN se dote de ses propres locaux et transfère son siège qui actuellement se trouve à Front de Terre, Zone de captage immeuble N° 36 Dakar-Sénégal.

En 2006, RTN est transformé en une SARL au capital de 1.000.000 FCFA. La société est immatriculée au Registre du Commerce sous le numéro RC: SN DKR 2006 B 16356, NINEA 2652776 2R2.

En 2008, RTN crée une école supérieure de formation en télécommunications et réseaux informatiques: ELT (Ecole Centrale des Logiciels Libres et des Télécommunications) et devient ainsi le groupe RTN/ELT avec comme profile école- entreprise.

Le corps administratif du groupe RTN/ELT s'occupe aussi bien des services liés à l'activité principale de RTN, des questions pédagogiques liées à l'activité scolaire et pédagogique de l'ELT.

I.1.1. Missions de RTN

La mission du groupe RTN vise à accroître la compétitivité de ses clients par la valorisation des composantes informatiques, logicielles et réseaux constituants le système d'information de ces derniers. Cela leur confère des gains importants en produisant plus et mieux à budget réduit, grâce à l'exploitation de la puissance des logiciels libres existants et ceci, sans rupture des cycles d'exploitation de service de ces entreprises et sans remise en cause organisationnelle. Leur principal objectif est de conseiller et de former le personnel de entreprises qui veulent disposer des logiciels libres et adaptée à leurs besoins minimisant ainsi les coûts d'investissements en réseaux informatiques tout en leur apportant une sécurité avancée.

I.1.2. Domaines d'activité de RTN

RTN intervient dans la formation des ressources humaines aux technologies de l'information et de la communication. RTN intervient également à la mise en oeuvre des solutions d'entreprise. RTN a su diversifier ses domaines de compétences afin de proposer aux entreprises et aux administrateurs des offres de services dans plusieurs secteurs informatiques. Les services d'experts:

Ø Une expertise unique en développement d'applications : Web, Téléphonie etc. ;

Ø Une expertise unique en formation et certification ;

Ø Une expertise approfondie en logiciels libres ;

Ø Une expertise unique en ingénierie des réseaux ;

Ø Les services à valeur ajoutée autour des terminaux mobile;

RTN propose ses compétences en qualité d'expert en ingénierie des télécommunications et informatique pour accompagner toutes les sociétés et administrations publiques souhaitant former leurs personnels dans le domaine des systèmes libres (bureautique, systèmes d'exploitation, réseaux Internet et Intranet, développement etc.) du Management et de la gestion des projets d'entreprise. Avec l'avènement de la Télévision Numérique Terrestre (TNT), RTN s'est doté d'une équipe qui prend en charge de bout en bout les questions autour des méthodes de diffusion audiovisuel (DVB : Digital Vidéo BroadCast), de gestion de contenue pour les télévisions (HbbTV : Hybrid BroadCast Broadband TV) et des services à valeur ajoutée autour de la TNT.

I.1.3. Organigramme de RTN/ELT

Figure I.1: Organigramme de l'entreprise RTN

I.2 : Présentation du projet

I.2.1 : Le Contexte

Aujourd'hui l'IP prend de plus en plus d'importance dans les télécommunications. Certains opérateurs de télécommunications commencent à utiliser la téléphonie sur IP comme solution de service à leur client. Si nous prenons l'exemple du Sénégal avec le groupe Orange qui vient d'acheter la licence 4G, il faut attendre d'ici peu à une meilleure qualité des services offertes et il faut noter qu'en 4G tout est IP. La téléphonie sur IP est basée sur le protocole de signalisation SIP. Donc il devient intéressant aujourd'hui de développer des systèmes basés sur IP. C'est dans ce contexte que notre sujet de mémoire s'appui.

I.2.2 : La Problématique

La convergence vers du tout IP comme nous assistons actuellement au Sénégal, nécessite une meilleure qualité des services offertes, or le protocole de signalisation utilisé par l'IP présente un certain nombre de problème. C'est cette problématique du protocole SIP qui suscite une bonne réflexion sur les questions à savoir :

Peut-on avoir un système de vente de crédit et facturation fiable basé sur le protocole de signalisation SIP ?

Comment peut-on mettre en place un tel système dans un réseau convergent ?

Nous apporterons des éléments de réponses à ces interrogations durant tout le reste du mémoire.

I.2.3 : Objectifs attendus

Les objectifs attendus à l'issu de ce travail consiste à mettre en place un système de facturation utilisant le protocole SIP et de pouvoir l'intégré dans les plateformes web et la mise en place d'un système de vente de crédit afin de pouvoir l'intégré chez les opérateurs de transfert d'argent.

Conclusion

Nous avons présenté la structure d'accueil RTN qui est spécialisé dans les logiciels libres avec ses secteurs d'activités ensuite nous avons présenté le projet en dégageant les problématiques et les objectifs attendus. Pour mener à bien ce projet, nous allons d'abord faire une étude théorique du projet avant de passer à la pratique.

Chapitre II. CONCEPTS DE BASE DE LA VOIP ET LES PRINCIPALES IMPLEMENTATIONS

Introduction

Dans ce chapitre nous allons d'abord faire une étude de l'architecture fonctionnelle de la téléphonie sur IP, étudier le protocole de signalisation SIP

II.1. Définition et Caractéristiques de la ToIP

II.1.1. Définition de la ToIP

ToIP est un moyen de communication via IP, la numérisation de la voix a permis le transport de la voix et des données sur une même infrastructure de transport (multiplexage temporel ou TDM).

La voix sur IP consiste à transporter la voix sous forme de paquets sur un réseau IP, alors que la téléphonie sur IP (ToIP) est un service téléphonique complet appuyé sur des équipements IP.

II.1.2. Caractéristiques de la ToIP

TOIP est une technologie de pointe qui a dépassé les compagnies de téléphone et les sociétés de téléphonie mobile. Sa popularité augmente considérablement avec l'augmentation de sa couverture réseau. Elle s'est révélée être une invention étonnante qui a créé un nouveau monde de télécommunications en utilisant Internet.

Ø Avec l'introduction de la technologie ToIP, les appels sont devenus moins chers. Vous pouvez facilement faire des appels locaux et internationaux en utilisant une connexion réseau haut débit qui est une connexion haute vitesse à Internet.

Ø L'un des avantages importants est la capacité de diriger les appels entrants vers le service de ToIP et l'on peut facilement obtenir les détails des appels entrants provenant de n'importe quel terminal possédant Internet en utilisant le système TOIP.

Ø C'est un réseau qui vous suit partout où vous allez donc vous ne manquerez plus jamais aucun de vos appels importants, même si vous êtes hors de la ville.

Ø Elle a beaucoup aidé en matière de réduction de coût en raison des tarifs de communications , les factures téléphoniques mensuelles sont coupés. Par conséquent, la mise en place de la ToIP est très avantageuse économiquement.

Ø Il existe de nombreux services à valeurs ajoutées offerts par les différents fournisseurs de services ToIP. Par exemple, il est un centre international de messagerie vocale, conférence à 3, renvoi d'appel, la sonnerie simultanée, appel en attente, afficheur, de retour d'appel, identification de l'appelant , rejet des appels anonymes, une caractéristique intéressante de ne pas déranger, et le dernier numéro de composition. Tous ces services sont pour la plupart gratuitement dans leur plan de service de base.

Ø Il existe une installation de gestion de votre compte en ligne Voix sur IP depuis n'importe quel coin du monde s'il ya une disponibilité d'une connexion Internet haut débit.

II.1.3. Avantages de la ToIP

II.1.3.1. Gestion facile

Un réseau ToIP dispose d'une interface web qui vous permet de régler et configurer facilement votre parc de téléphones, contrairement aux réseaux propriétaires qui ont, la plupart du temps, des interfaces compliquées que seuls des professionnels peuvent utiliser. De même, il est simple d'organiser des conférences, ou toutes autres fonctionnalités à partir de l'interface graphique.

II.1.3.2. Simplicité d'installation

Aucun branchement téléphonique séparé n'est nécessaire puisque la ToIP utilise votre réseau informatique. Cette spécificité permet une grande flexibilité pour ajouter des utilisateurs ou des extensions au réseau. Si vous emménagez dans de nouveaux locaux et n'avez pas encore installé les prises téléphoniques, vous pourrez faire des économies substantielles en installant uniquement un réseau informatique.

II.1.3.3. Évolutif

La ToIP est un système qui permet d'agrandir votre parc téléphonique selon vos besoins, l'évolution de vos équipes et de votre structure.

II.1.3.4. Utilisation facile

Dans la ToIP, l'utilisation et l'interfaçage des téléphones informatiques se fait à partir d'une interface graphique.

II.1.3.5. Mobilité

La ToIP vous permet également d'appeler tous les collaborateurs, d'être appelé ou d'appeler gratuitement l'entreprise via Windows Phone, Android et iPhone.

II.1.3.6. Meilleur service et productivité

Les logiciels de la ToIP apportent de nombreux avantages et peuvent augmenter fortement la productivité d'une entreprise. Par exemple, un des outils de la ToIP permet d'afficher automatiquement à l'écran les trafics d'appels , les informations du client qui est en train de vous appeler directement depuis votre logiciel de gestion.

II.1.4. Contraintes de la ToIP

II.1.4.1. Perte de paquets

Lorsqu'il y a saturation, les mémoires tampons ont besoin de libérer une partie de la bande passante, négligeant ainsi certains paquets. Néanmoins, le trafic VoIP est transmis au-dessus de la couche UDP, ce qui implique qu'aucun mécanisme de contrôle de flux ou de retransmission des paquets perdus n'est offert par la couche transport. Cela implique qu'il faut accorder une forte importance aux protocoles RTP et RTPC (Real-Time Transport (Control) Protocol) qui vont permettre de calculer le taux de perte de paquets, et de réagir en conséquence au niveau de la couche applicative.

II.1.4.2. Latence

La latence est le décalage entre le temps écoulé d'envoi d'un paquet et de sa réception par le destinataire. Plus la latence est important, plus le transfert est long et sera donc décalée. Pour garantir une communication optimale, la maîtrise du délai de transmission est un point important afin de réduire l'effet d'écho ou la sensation de voix métallique. Le temps de transmission de paquets dans un réseau de type IP dépend de nombreux éléments tels que:

v Le nombre d'équipements actifs traversés dans le réseau

v Le débit de transit disponible

v Le délai de propagation de l'information

II.1.4.3. Variation du délai (gigue)

La gigue est la variation de délai de transmission de bout en bout entre des paquets appartenant à un même flux de données. Elle est due à la variation du temps de transmission des paquets (en l'occurrence: les échantillons de voix) dans le réseau de télécommunications et peut entrainer, si elle est trop élevée, une détérioration de la qualité vocale. La cause de ce problème peut être due à la différence des chemins empruntés par les paquets dans le réseau, à une congestion ponctuelle du réseau ou encore à un souci d'encapsulation des paquets IP.

II.1.4.4. Bande passante

C'est le terme utilisé pour évoquer le flux de connexion. C'est une unité souvent prise pour une unité de débit, mais elle ne définit en réalité que la plage de fréquence et le débit en dépend, d'où la confusion.

II.1.4.5. Sécurité de la ToIP

La sécurité de la téléphonie est souvent restée un sujet à part dans l'entreprise. Désormais, les risques associés aux systèmes téléphoniques peuvent avoir des conséquences graves sur le système d'information et sur l'entreprise. Par ailleurs, la liste des failles historiques de la téléphonie est toujours d'actualité maintenant qu'elle intègre les standards IP. VoIP shield Laboratories, une entreprise spécialisée dans la sécurité des systèmes VoIP, a découvert en novembre 2008 une faille de sécurité au sein du protocole RTP1. La faille en question n'a pas été présentée en détail mais le laboratoire a annoncé qu'elle permettrait de mener des attaques par déni de services sur les utilisateurs de logiciel utilisant le protocole RTP, soit près de 250 millions d'ordinateurs dans le monde. RTP (Real time Transport Protocol) est un protocole qui a été développé par l'IETF afin de faciliter le transport temps réel de bout en bout des flots données audio et vidéo sur les réseaux IP, c'est à dire sur les réseaux de paquets [B7]. RTP est un protocole qui se situe au niveau de l'application et qui utilise les protocoles sous-jacents de transport TCP ou UDP.

II.2. Etudes détaillées des protocoles de signalisation

De nos jours, la création de protocoles capables d'adapter les nouvelles technologies multimédias sur les réseaux, telles que la voix sur IP, l'envoi de données et la visioconférence en tenant compte des données en temps réels est devenue très important.

II.2.1. Le protocole H323

Le protocole H323 fait partie de ces protocoles indispensable dans la mesure où il permet l'envoie de son et de la vidéo (visioconférence) sur les réseaux IP. Il englobe une multitude de protocoles qui sont dans la famille de la signalisation (vidéo, voix, contrôle).

Figure II-1 donne les classes par niveau du modèle OSI

Malgré la standardisation mis par l'UIT qui permet une interopérabilité entre différents constructeurs, H323 présente des limites parmi lesquelles :

Ø interopérabilité avec les autres normes visioconférence:

Les terminaux utilisant les protocoles H320 et H323 posent des problèmes et nécessitent des passerelles pour faire de la visioconférence. H323 pose également d'énorme problème quant aux passerelles, car c'est un protocole qui demande l'ouverture d'un panel de ports TCP et UDP de façon dynamique et peu aléatoire, incompatible avec la logique des règles imposées par la sécurité de site ou intranet exposés à internet .

Ø Interopérabilité entre terminaux:

Comme le codec G.711 est le seul codec indispensable et que pour les autres codecs sont largement plus efficaces, l'interopérabilité entre différents constructeurs ne garantit pas qu'ils feront un usage optimal de la bande passante. En effet, dans le cas où il y a une différence entre les codecs à bas débit, l'envoi de la voix se fera sur 64kbps, ce qui ne présente pas, d'atout par rapport au système de téléphonie classique en termes de bande passante.

Ø Protocole complexe:

Le protocole H323 est une des normes mise en oeuvre pour la ToIP grâce à son développement inspiré de la téléphonie. Cependant, il est utilisé pour l'instant par des programmes propriétaires. La recherche sur sa documentation reste difficile à accéder, car l'UIT fait payer des droits d'accès au dernier développement de cette technologie.

II.2.2. Le protocole SIP

Le protocole SIP n'est pas en reste parmi les protocoles indispensables pour les nouvelles technologies. Il a été standardisé par l'IETF, conçu pour établir, modifier et terminer des sessions multimédias. Le protocole SIP est conçu pour être un protocole de pure signalisation. Les principales fonctions d'un protocole de signalisation sont :

· Localiser un terminal

· Contacter un terminal pour déterminer sa volonté d'établir une session

· Echanger des informations sur les media pour permettre l'établissement d'une session

· Clore une session media existant

En pratique, l'architecture SIP repose sur deux éléments : « User Agent » et les « Serveurs »

II.2.2.1. User Agent

Les User Agents désignent l'ensemble des agents que l'on retrouve dans les téléphones SIP (des soft phones, des ordinateurs, etc.) Quand le client envoi des requêtes au serveur, ce dernier lui répond par des méthodes de bases

comme suit :

§ INVITE : permet aux « User client » de demander une nouvelle session

§ ACK : c'est la méthode qui confirme l'établissement de session

§ CANCEL : pour annuler un INVITE

§ BYE : termine une session

L'objectif principal du protocole est l'établissement de session entre les agents.

La figure [Figure II-2] ci-dessous montre le fonctionnement du système:

II.2.2.2. Registrar

Le registrar est une entité dans le réseau qui gère la correspondance entre les adresses IP et SIP des utilisateurs (User Agent) qui seront enregistrés dans une base de données. Il joue le rôle de serveur dans le réseau.

La figure [Figure II-3] montre l'enregistrement de l'utilisateur sur le serveur registrar. A l'arrivée de la requête sur le serveur, ce dernier a accès sur l'adresse IP source de l'utilisateur. Il enregistre une correspondance de l'adresse IP et l'adresse SIP dans un champ contact dans la base de données.

II.2.2.3. Serveur Proxy

Un serveur proxy sert d'intermédiaire entre deux utilisateurs (User Agent). Il a un rôle dans la signalisation et ne gère pas les medias. En effet, la correspondance adresse SIP et adresse IP est stockée dans une base de données par un registrar. Le serveur va interroger la base de données pour avoir les informations du destinataire, ensuite va rediriger les données.

Figure II-4 : mécanisme de redirection de données.

Aujourd'hui, le protocole SIP est le plus répandu entre eux. Il est largement déployé et utilisé au sein des serveurs de ToIP.

II.2.3. Le protocole SCCP

SCCP est un protocole de communication, faisant partie de la couche Application du modèle OSI. Le H323 étant trop rigoureux pour certaines utilités de la téléphonie IP (comme le renvoi d'appel, le transfert, la mise en attente), Cisco a donc créé SCCP, qui utilise le port 2000. L'avantage de SCCP est qu'il utilise des messages prenant très peu de bande passante c'est pourquoi il est utilisé pour les communications entre les téléphones IP et le CallManager ainsi que pour contrôler une conférence.

II.2.4. Le protocole ENUM

ENUM, spécifié dans le RFC 6116 et RFC 6117, est un mécanisme permettant d'utiliser un numéro de téléphone comme clé de recherche dans le DNS pour trouver la manière de joindre une personne ou une autre entité. Les hypothèses de départ sont:

qu'il existe déjà une infrastructure pour allouer les numéros de téléphone et que des milliards sont déjà attribués, que ces numéros sont des clés "naturelles" pour beaucoup de gens. ENUM s'appuie sur le système DDDS (Dynamics Delegation Discovery System RFC 3401) et sur les enregistrements NAPTR du DNS. Une recherche ENUM par un résolveur ENUM commence par un numéro de téléphone à la norme UIT E.164, comme [phone].

Ce numéro est transformé en nom de domaine en l'inversant (comme on fait pour trouver un nom de domaine à partir d'une adresse IP, ici, cela donnerait 9.8.7.6.5.4.3.2.1.3.3.e164.arpa.

II.3. Les codecs

Dans le monde de la ToIP, les codecs sont utilisés pour coder la voix pour la transmission via les réseaux IP. Ils sont aussi appelés vocodeurs (codeur voix). Les codecs offrent généralement une capacité de compression pour économiser la bande passante du réseau. Certains codecs également supportent la suppression des silences, où le silence n'est pas codé ou transmis.

Nous pouvons énumérer les codecs G711 , G729 , H263 , H264 , VP8 pour ne citer que cela .

II.4. Etudes des passerelles VOIP

II.4.1. Concepts de ports FXS et FXO

II.4.1. 1. FXS

L'interface Foreign eXchange Subscriber est le port qui raccorde la ligne analogique de l'abonné. En d'autres termes, la « prise murale » qui fournit la tonalité, le courant de charge et la tension de sonnerie.

Figure II.5 ports FXS et FXO

Une passerelle FXS s'utilise pour connecter une ou plusieurs lignes d'un PBX traditionnel au système téléphonique VoIP ou opérateur. Vous pouvez aussi l'utiliser pour connecter des téléphones analogiques au système téléphonique VoIP. Vous aurez besoin d'une passerelle FXS pour connecter des ports FXO (qui sont normalement connectés à l'opérateur télécom) à Internet ou à un système VoIP.

Figure II.6 passerelle FXO/FXS

II.4.1.2. FXO

L'interface Foreign eXchange Office est le port qui reçoit la ligne analogique. C'est la prise du téléphone ou du fax, ou la (les) prise(s) de votre réseau téléphonique analogique. Le FXO offre un indicateur d'état raccroché/décroché . Puisque le port FXO est raccordé à un appareil, tel un téléphone ou un fax, il est souvent appelé « périphérique FXO ». Pour établir une connexion entre les lignes téléphoniques analogique et un système de ToIP , vous aurez besoin d'une passerelle FXO. Ce qui vous permettra de connecter le port FXS au port FXO de la passerelle, qui traduira ensuite la ligne téléphonique analogique en appel VoIP. Il existe plusieurs passerelles FXO disponibles.

II.4.2. Présentations de quelques cartes RNIS

RNIS est un réseau de télécommunications constitué de liaisons numérique autorisant une meilleure qualité et des vitesses pouvant atteindre 2 Mbit/s( accès E1) contre 56 kbit/s pour un modem classique.

II.4.2.1. PRI (accès primaire)

L'accès primaire comprend 30 canaux B et un canal D à 64 kbit/s en Europe, en Afrique, en Amérique du Sud, au Moyen-Orient, en Asie (hors Japon) : 30B+D. Aux États-Unis, au Canada et au Japon la définition est différente : 23B+D. Seule la protection des marchés explique les différences de définition entre l'Europe, les États-Unis, le Canada et le Japon. Cet accès est l'équivalent RNIS des liaisons T1/E1 à 1 544 kbit/s et 2 048 kbit/s.

II.4.2.2. BRI (accès de base)

L'accès de base ou Basic Rate Interface (BRI ou T0) comprend 2 canaux B et un canal D pour la signalisation : 2B+D.

II.4.3. Présentations de quelques passerelles dans la téléphonie

Une passerelle VoIP est un périphérique réseau permettant de convertir en temps réel des appels fax et vocaux entre le réseau téléphonique commuté (RTCP) et le réseau IP. Les fonctions principales d'une passerelle VoIP englobent la compression / décompression, paquétisation , acheminement des appels et contrôle de signalisation. Le principal but d'une telle passerelle est de connecter facilement un système téléphonique VoIP au réseau public.

II.4.3.1. La passerelle Smart Node

La passerelle Smart Node permet grâce à un UCA (Unified Communications Agent) combinant les systèmes de téléphonie PBX et connexions PSTN existantes avec des systèmes de communications unifiées. La passerelle gère le SIP, H323, ISDN, et offre un routage intelligent des appels à moindre coût, QoS, la gestion du trafic et la priorité à la voix.

II.4.3.2. La passerelle RTCP

Pour l'interfonctionnement entre SIP et le RTCP, il est nécessaire d'introduire un Gateway RTCP/SIP qui s'interface d'une part au RTCP et d'autre part à un réseau SIP. Passerelle SIP/PSTN Ce Gateway a deux fonctions :

Ø Traduction de la signalisation ISUP (ISDN User Part) en signalisation SIP et inversement ;

Ø Conversion des signaux audio en paquets RTP et inversement ;

en effet ce Gateway établit des canaux logiques RTP avec le terminal SIP et établit des circuits de parole .

II.4.3.3. La passerelle GSM

Les « hérissons », ou « passerelles mobiles » ou «GSM gateways » sont des équipements qui peuvent être raccordés à un commutateur et qui permettent d'écouler du trafic vers les réseaux mobiles en utilisant deux boucles locales radio au lieu d'une. La première boucle locale radio permet d'acheminer l'appel du « hérisson » jusqu'au réseau de l'opérateur mobile ; la deuxième permet d'acheminer l'appel du réseau de l'opérateur mobile jusqu'au terminal mobile du destinataire de l'appel.

II.4.4. Présentations de quelques fournisseurs Voip en Europe et USA

Les opérateurs SIP, sont des opérateurs de VoIP utilisant principalement le protocole SIP afin de proposer leurs services.

II.4.4.1. IPPI

IPPI est un opérateur SIP d'origine française qui se distingue principalement par un offre gratuite très agressive regroupant de nombreux services innovants (Web call back, click to call, sms call back, téléconférence..), comprenant le compte SIP ou le trunk SIP multi-canaux, le numéro géographique gratuit, les appels gratuits entre membres, vers les autres réseaux SIP, vers Skype (SIP to Skype) et vers Google Talk (SIP to Gtalk).

Les tarifs pour les appels sortants vers les fixes et les mobiles sont très compétitifs et la facturation se fait à la seconde. Des forfaits illimités sont également disponibles pour appeler les fixes et les mobiles en France ou dans le monde. Offre est sans engagement.

Codec autorisés : G711, G729, GSM & ILBC.

II.4.4.2. SIPLY

Siply est un fournisseur de trunk SIP nouvelle génération d'origine américaine, destiné aux professionnels, centres d'appels et grands comptes. Cet opérateur télécom propose de la terminaison A-Z en qualité premium uniquement, à des tarifs très avantageux et sans engagement. Siply est compatible avec la plupart des IPBX du marché (Asterisk, 3CX, Cisco, Gigaset, Mitel, Snom, Avaya, Polycom, Tiptel, Yealink, Yeastar..). Siply permet une connexion par identifiant ou adresse IP.

Avantages : tarifs acceptables, qualité premium, sans engagement, canaux illimités, compatible tous IPBX.

II.4.4.3. VONAGE

Vonage est l'un des principaux acteurs de téléphonie IP dans le monde. Vonage propose de nombreux forfaits illimités pour le grand-public et les professionnels. Vous bénéficiez de nombreuses fonctionnalités d'un standard téléphonique évolutif (Centrex) intégré à travers une gestion web centralisée.

II.4.5. Présentation de quelques solutions SIP

II.4.5.1. Asterisk

Asterisk est un logiciel libre et Open Source (licence GPL ou alternative en accord avec la société Digium) apparu à la fin des années 1990. Sa première version, publiée par Mark Spencer, date exactement du 5 décembre 1999. Il s'inscrit dans la mouvance, apparue à la même époque, des logiciels libres de télécommunication développés autour de H.323 ou SIP, comme OpenH323. Asterisk est né du besoin très pragmatique d'un jeune directeur de société de services d'assistance autour de Linux et des logiciels libres, nommé Mark Spencer, qui souhaitait améliorer l'efficacité du service d'assistance technique en offrant la possibilité aux clients de laisser des messages téléphoniques et en les dirigeant vers le technicien à même de les traiter.

II.4.5.2. Kamailio

Kamailio est un fork de SER (SIP Express Router). Ses auteurs sont une équipe d'ingénieurs roumains qui, à l'époque des premiers développements, préparaient leur thèse à l'institut Fraunhoffer de Berlin et travaillaient de façon intensive sur SER, la première implémentation libre d'un proxy SIP.

Kamailio est un logiciel modulaire capable de traiter des milliers de messages SIP par seconde. Mieux, ses fonctions de répartition de charge autorisent une montée en charge simple par ajout de matériel. L'intérêt que peut susciter un tel logiciel (gratuit et libre !) chez les opérateurs est ainsi facilement compréhensible.

II.4.5.3. FreeSwitch

Freeswitch est une solution open source de téléphonie sur IP, sous une licence MPL (Mozilla Public License), développé en C. Il peut être utilisé comme un simple commutateur, un IPBX, une passerelle ou un serveur d'applications IVR (Interactive Voice Réponses) en utilisant des scripts ou des fichiers XML permettant d'automatiser certaines taches et de développer de nouveaux services. Freeswitch fonctionne sur plusieurs systèmes d'exploitation, notamment Windows, Mac OS X, Linux, BSD et sur les deux plates-formes Solaris (32 bits et 64 bits). Freeswitch supporte les caractéristiques standards et avancées du protocole SIP, permettant de mettre en place un serveur de conférence, un serveur de Voicemail,... Il utilise aussi les protocoles IAX2, Jingle et H323.

II.4.5.4. FusionPbx

Fusionpbx est un serveur qui dispose de plusieurs fonctionnalités. Il dispose aussi de plusieurs modules parmi lesquels on a :

Ø Le module mod_sms

Ø Le module mod_smpp

Ø Le module mod_python

Le module mod_sms permet d'effectuer du chat entre client du serveur, et le module mod_smpp permet de joindre des clients des autres opérateurs. Fusionpbx utilise un serveur nommé freeswitch pour pouvoir effectuer des appels. L'interface de communication de freeswitch est ESL.

Fusionpbx utilise aussi un serveur web appelé Nginx très puissant qui peut gérer la gestion du RAM malgré l'augmentation des opérations à exécuter. Il dispose aussi d'un autre serveur FPM qui permet d'exécuter les codes PHP avec Nginx.

Donc fusionpbx est un ensemble constitué d'une base de données (postgresql), de code php, d'un serveur web Nginx, d'un serveur FPM et en plus d'un serveur freeswitch.

II.4.6. Présentation de quelques plateformes VOIP

II.4.6.1. A2billing

A2Billing est une plateforme de télécommunication complète et un softswitch incluant un portail client, la facturation, le reportind, et les statistiques pour la téléphonie IP et traditionnelle. Il peut être configuré pour fournir une grande variété de services, de tarifs, de facturation ainsi que différentes méthodes de paiement.

A2Billing est par conséquent une excellente plateforme pour les services providers désirant déployer les services suivants :

Ø Services de carte d'appel (Traditional Calling Card services)

Ø Services de rappel (Callback services)

Ø Services hébergés de VoIP chez un hébergeur (VoIP résidentiel services)

Ø Vente en gros de ligne VoIP (VoIP wholesale termination)

Ø SDA et redirections (Direct Inward Dialing or DID termination and redirection)

II.4.6.2. Elastix

Elastix est un logiciel libre autocommutateur téléphonique privé (PBX) ou IPBX, basé sur le logiciel libre Asterisk.Elastix encapsule Asterisk et l'interface FreePBX dans une interface web globale de style Trixbox. Elastix est 100 % libre et sous licence GPLv2. Il inclut le noyau CentOS pour le système d'exploitation, Asterisk, pour la partie IPBX et interface web, et Flash Operator Panel (FOP) pour la partie graphique de l'interface web.Une fois le produit installé, l'administration de Elastix est entièrement réalisé depuis une interface web. Un accès SSH est parfois utile lors de l'ajout de nouveaux modules fonctionnels, comme les modules de gestion des téléphones SIP de Aastra Technologies.

Conclusion

Ce chapitre nous a permis d'effectuer une étude détaillée du protocole de signalisation SIP. Il nous a permis de comprendre l'interfonctionnement du SIP et RTP. Ce qui nécessite une étude détaillée de freeswitch.

Chapitre III. PRESENTATION DETAILLEE DE FREESWITCH

Introduction

Dans ce chapitre , nous allons faire une étude détaillée de freeswitch, expliquer la notion de contexte dans freeswitch et présenter les modules relatifs à notre projet.

III.1. Historique et philosophie de Freeswitch

III.1.1. Historique de Freeswitch

Freeswitch est une plateforme de téléphonie open source conçue pour router ou interconnecter les protocoles de communications populaires en utilisant l'audio, la vidéo, le texte ou toute autre forme de média. Il a été créé en 2006, il fournit également une plateforme de téléphonie stable sur laquelle de nombreuses applications peuvent être développées en utilisant une large gamme d'outils gratuits.

III.1.2. Philosophie de Freeswitch

Freeswitch est une solution open source de téléphonie sur IP, sous une licence MPL (Mozilla Public License), développé en C. Il peut être utilisé comme un simple commutateur, un IPBX, une passerelle ou un serveur d'applications IVR (Interactive Voice Response) en utilisant des scripts ou des fichiers XML permettant d'automatiser certaines taches et de développer de nouveaux services.Freeswitch fonctionne sur plusieurs systèmes d'exploitation, notamment Windows, Mac OS X, Linux, BSD et sur les deux plates-formes Solaris (32 bits et 64 bits).

Freeswitch supporte les caractéristiques standards et avancées du protocole SIP, permettant de mettre en place un serveur de conférence, un serveur de Voicemail ,...

Il utilise aussi les protocoles IAX2, Jingle et H323, Les langages de programmation supportés par cette solution sont :

Ø JavaScript

Ø Python

Ø Perl

Ø Lua

Ø C/C++

Ø JAVA

III.2. Les notions de modules et présentation des modules relatifs à notre projet.

III.2.1. Les notions de modules

Freeswitch est modulaire et comprend des modules qui offrent de nombreuses applications : conférence, réponse vocale interactive, synthèse et reconnaissance vocale, messagerie instantanée . La fonctionnalité de Freeswitch peut être étendue par l'ajout de modules qui exécutent une tâche particulière, si cette tâche est simple ou complexe. Les modules peuvent être regroupés en grandes catégories comme marqués avec des étiquettes sur leurs pages de modules individuels.

III.2.2. Présentation des modules relatifs à notre projet

III.2.2.1. Module sms

Le module sms permet d'effectuer du chat personnalisé entre les clients du serveur.Il fournit un moyen pour acheminer les messages dans FreeSwitch, permettant potentiellement l' un pour construire un système de discussion puissant comme dans XMPP en utilisant SIP simple sur les clients SIP.

III.2.2.2. Module smpp

Le module smpp permet de joindre des clients des autres opérateurs. SMPP est le sigle de Short Message Peer to Peer, un protocole standard d'échange qui permet d'envoyer des SMS vers des opérateurs téléphoniques.

III.3. Définitions de quelques concepts liés à Freeswitch

III.3.1. La notion de contexte

Freeswitch utilise plusieurs «contextes» pour empêcher les extensions internes d'être exposés au monde. Les deux contextes dans la configuration de vanille FS sont appelés "Public" et "Default" (mais ces noms sont arbitraires et peuvent être soigneusement modifiés ou ajoutés d' autres contextes).

Default : c'est le contexte par défaut pour tous les utilisateurs inscrits

Public : c'est le contexte utilisé pour les appels provenant de l'extérieur

III.3.2. La notion de sip_profiles

Les profils par défaut sont «interne» et «externe» et servent chacun un objectif général.profils SIP externes sont généralement utilisés pour communiquer avec votre fournisseur de services «Gateway», comme société similaire fournissant un service de téléphonie via le protocole SIP pour vous. Le sip_profile interne est généralement utilisé pour communiquer avec les périphériques de votre réseau local.

III.3.3. La notion de dialplan

Le plan de numérotation Freeswitch est un mécanisme complet, basé sur XML. Il est recommandé que vous compiliez Freeswitch avec la configuration par défaut et assurez-vous qu'il fonctionne avant de commencer à faire des personnalisations. Notez que les fichiers de configuration par défaut, y compris le plan de numérotation de default.xml, sont souvent mis à jour.

III.4. Présentations des modules lua et python

III.4.1. Présentations du module lua

Lua est un langage de script libre, réflexif et impératif. C'est un langage de script préféré pour les applications personnalisées basées sur Freeswitch. Le module lua il permet d'interagir avec freeswitch à l'aide de scripts écrits en langage lua.

III.4.2. Présentation du module python

Python est un langage de programmation orienté objet puissant pour écrire des programmes. le module python il permet d'interagir avec FreeSwitch à l'aide de scripts écrits en langage python.

III.5. Notions de Gateway

Gateway est un système qui permet de coupler freeswitch avec un autre système de téléphonie. Pour que les utilisateurs de freeswitch puissent appeler et recevoir des appels de l'extérieur (1 autre ipbx) il faut faire appel aux notions de passerelles ( Gateway ).

Figure III.1 Architecture d'une passerelle

III.6. Dialplan avancé et applications externes

Dialplans sont utilisés pour acheminer un appel destiné à son critère d'évaluation appropriée, qui peut être une extension, la messagerie vocale, de réponse vocale interactive (IVR) menu traditionnel ou une autre application compatible. Dialplans sont extrêmement flexibles.

Dialplans peuvent être séparés en «contextes» nous permettant d'avoir Dialplans séparés pour différents types d'appels. Les appels peuvent être remis hors de différents contextes. Par exemple, pour soulager les problèmes de sécurité, vous pouvez avoir deux dialplans, qui gère les appels en provenance du réseau téléphonique public (PSTN) et qui gère les appels provenant de postes internes. Les fichiers de configuration de l'échantillon FreeSwitch utilisent cette méthode, forçant un appel PSTN entrant à travers un certain contrôle supplémentaire avant d'être transféré au dialplan interne. Une autre utilisation d'un contexte de dialplan vous permet de partager un seul PBX avec plusieurs locataires dans un immeuble de bureaux. Étant donné que chaque locataire aura probablement leur propre ensemble de (et souvent contradictoires) des extensions, des menus vocaux, etc., il est logique de séparer les locataires dans leurs propres dialplans indépendants pour faciliter la configuration et la maintenance.

Conclusion

Ce chapitre nous a permis d'effectuer une étude détaillée de freeswitch . Il nous a permis de cerner le système de téléphonie freeswitch et ainsi que les concepts qui tournent au tour . Ce qui nécessite une étude détaillée de la facturation dans ce environnement .

Chapitre IV. PRESENTATION DE LA FACTURATION

Introduction

Dans ce chapitre nous allons présenter la facturation et parler des concepts liés à cette dernière puis ressortir les différents types de comptes existants dans un la facturation.

IV.1. Quelques concepts liés à la facturation

La facturation est une fonction fondamentale d'un fournisseur de services de télécommunication. L'opération de facturation doit être effectuée avec précision et fiabilité. Les modèles de facturations sont devenus importants avec l'introduction de l'IP, puisqu'il y aura un certain nombre de nouveaux types de services présentés aux utilisateurs. En effet La convergence de la voix, vidéo et données permet aux développeurs de fournir des services riches pour les utilisateurs. De ce fait Des facteurs tels que l'augmentation du nombre de services, la composition du service et la qualité du service offert constituent les moteurs de la recherche des stratégies de facturation innovantes. Donc la migration vers un réseau tout IP permet aux développeurs de produire des services plus sophistiqués qui nécessitent des modèles de tarification plus complexes. Un exemple des services basés sur la localisation flexible, où les utilisateurs peuvent être facturés différemment en fonction de leur emplacement

IV.1.1. Facturation en ligne et hors ligne

La facturation hors ligne se réfère à une facturation qui est effectuée après consommations de ressources. Par exemple, si un utilisateur lance un appel ; l'utilisateur serait facturé après l'appel. Cela signifie que les informations recueillies ne sont pas affectées au service concerné. En effet concernant la facturation hors ligne, les informations de facturation sont envoyées à un système de facturation externe. Nous notons que La fonction de ce système de facturation externe ne fait pas partie du standard 3GPP et ni au transfert de données à partir du réseau au système de facturation. Avec facturation en ligne, le compte d'utilisateur est vérifié pour déterminer s'il y a suffisamment de crédit pour utiliser le service.

En effet la facturation en ligne peut être définie comme une approche qui a une interaction en temps réel avec le service qui est offert. Contrairement à la facturation hors ligne, la facturation en ligne est effectuée en faisant usage d'un système de facturation en ligne conforme à la norme 3GPP. Il y a trois scénarios qui peuvent être identifiés pour facturation en ligne que nous allons illustrer plus loin à savoir le débit direct, l'unité de réservation en fonction d'évènement et de session.

· Avec le débit direct, les unités sont immédiatement déduites du compte du client en une seule transaction.

· Avec l'unité de réservation, avant d'autoriser le service à continuer, le système de facturation en ligne (OCS) réserve des unités sur le compte du client. Ceci est principalement fait parce que l'OCS ne connaît pas la durée de la prestation à l'avance. Après la fin du service, les unités consommées seront déduites et celles inutilisées seront libérées et ajoutées au compte du client.

Il y a deux approches principales en facturation à la fois en ligne et hors ligne :

v facturation basée sur l'événement :

· Avec la facturation basée sur l'événement, un événement est déclenché avec une seule transaction effectuée par un utilisateur. Par exemple l'envoi d'un message multimédia.

· La facturation basée sur l'événement résulte dans la création d'un seul CDR. le CDR contient les informations de facturation telles que l'heure d'appel, la durée de l'appel la quantité de donnée transférée, etc.

v La facturation liée à la session

· Celle-ci est caractérisée par l'établissement d'une session pour l'utilisateur, tel qu'un appel téléphonique.

· La facturation liée à la session résulte à la facturation de multiples événements qui pourraient entraîner plusieurs CDRs.

IV.1.2. Types de comptes

Il existe deux principaux types de comptes qui sont utilisés par les utilisateurs, à savoir les comptes prépayés et comptes post-payés. Avec un compte de post-payé, l'utilisateur reçoit une facture énumérant les charges qui ont été engagées après une certaine période. Ceci permet de mettre en oeuvre un système de facturation simple. Un accord contractuel est nécessaire entre l'opérateur du réseau et le client d'un compte de post-payé. Le compte prépayé ne nécessite pas de contrat ; cependant avant d'utiliser les services offerts par le fournisseur du réseau, l'utilisateur doit disposer d'un crédit dans son compte.

Une tendance a montré qu'il y a eu une augmentation du nombre d'utilisateurs de comptes prépayés. Cela est dû que le compte prépayé nécessite moins d'administration par rapport au compte post- payé. Ce dernier nécessite généralement un contrat qui doit être signé entre l'utilisateur post-payés et le prestataire de services

IV.1.3. Modèles d'affaires

Un modèle d'affaire peut être défini comme une relation entre une entreprise et le service qu'elle fournit. Il existe trois principaux modèles d'affaires dans l'industrie des télécommunications à savoir les fournisseurs de contenu, fournisseurs de services et opérateurs de réseaux.

· Les fournisseurs de contenu se concentrent principalement sur la fourniture de contenu téléchargeable comme la musique.

· Les fournisseurs de services se concentrent sur la prestation de services aux utilisateurs.

· Les opérateurs réseaux offrent un accès au réseau.

Les entreprises peuvent combiner deux ou plusieurs de ces modèles d'affaires. Les opérateurs de réseaux prennent souvent le rôle de prestataires de services ou fournisseurs de contenu. Avec la convergence de réseaux de téléphonie et IP, les opérateurs devront miser sur le modèle de prestation de services afin de rester compétitif.

IV.1.4. Différents types de frais

Les principaux types de frais appliqués dans le secteur des télécommunications sont :

· Les frais de service sont les redevances fondées pour l'utilisation de services particuliers.

· frais d'accès au réseau sont les redevances fondées pour accéder au réseau.

· les frais de contenu sont les redevances fondées sur le contenu téléchargé par les clients.

IV.2. Modèles de facturations

Les Modèles de facturations sont utilisés par les fournisseurs de services afin de recouvrer des coûts et de générer des revenus. Il est impératif d'avoir un modèle de facturation adapté pour les services . Dans cette section, nous passerons en revue quelques-uns des modèles de facturations.

IV.2.1. La facturation sur l'abonnement

Avec le modèle de facturation sur abonnement, les utilisateurs paient un montant fixe sur une période de temps. Le modèle sur abonnement encourage plus l'utilisation des ressources puisque le client paie un montant fixe qui est indépendant de la quantité de ressources utilisées. Le principal avantage du modèle sur abonnement est que les utilisateurs peuvent prévoir leurs frais.

IV.2.2. La facturation en fonction du volume

Dans le modèle de facturation basé sur le volume, l'utilisateur est facturé en fonction de la quantité de données transférées. L'avantage de ce modèle est le faite que les utilisateurs sont facturés pour la quantité de contenu qu'ils ont reçu ou envoyé.

IV.2.3. La facturation sur l'évènement

La facturation sur événement est basée sur des événements facturables qui se produisent. Un événement facturable est une seule transaction, par exemple envoi d'un MMS. En outre, une facturation basée sur un événement utilise un seul CDR.

IV.2.4. La facturation en fonction du temps

Le modèle de facturation en fonction du temps est basé sur les unités de temps que l'utilisateur consomme. Il s'agit d'une approche populaire de facturation traditionnelle utilisée par les entreprises de télécommunications . Avec l'introduction de l'IMS ce modèle de facturation sera en mesure de répondre à la variété des services auxquels les utilisateurs auront accès.

IV.2.5. La facturation Basée sur la récompense

Le modèle de facturation basé sur la récompense est fondé sur les critères d'utilisation des utilisateurs sélectionnés. Ce modèle est utile pour créer la fidélité à la marque. Par exemple, plus l'utilisateur consomme un service, plus le prix n'est réduit car ils continuent à consommer ce service particulier.

IV.3. Stratégies de prix

Il y a un certain nombre de stratégies de prix disponibles. Les stratégies de facturations sont utilisées par les fournisseurs de services pour attribuer des prix sur leurs services. Nous distinguons un certain nombre de stratégies de facturation à savoir:

IV.3.1. Prix forfaitaire

Cette Stratégie de prix forfaitaire est basée sur un montant de souscription fixe que le client paie à l'avance pour un service. Cette stratégie permet à l'utilisateur de consommer les services ou ressources durant une période de temps souhaitée. Dans les réseaux de télécommunications, le prix forfaitaire permettrait aux utilisateurs d'utiliser les ressources de manière illimitée. Cette stratégie de prix est la plus simple à mettre en oeuvre.

IV.3.2. Prix réactif

Cette stratégie de prix réactif est principalement basée sur le trafic du réseau. Si le trafic du réseau est élevé, le prix est ajusté à un prix plus élevé et quand il est faible prix est réduit. Cette stratégie est efficace pour contrôler la quantité de trafic dans le réseau. La Stratégie de prix réactif nécessite plus de ressources de réseau liées à l'information de signalisation.

IV.3.3. Prix de capacité prévue

Avec cette stratégie, les prix varient en fonction de la quantité de capacité qui est attendue sur le réseau. L'utilisateur n'est pas limité à consommer plus de ressources lorsque le réseau est encombré, mais il sera facturé à un prix plus élevé. Cette stratégie incite aux utilisateurs de consommer des ressources lorsque le réseau n'est pas encombré pour la réduction du prix. En outre, cette stratégie se traduit directement par le coût que les fournisseurs encourus.

IV.3.4. Prix prioritaire

Cette stratégie met l'accent sur la priorité que l'utilisateur reçoit sur la structure du réseau. Une priorité plus élevée se traduirait par un prix plus élevé que l'utilisateur sera facturé. Le prix de priorité peut être utilisé pour créer des profils avec QoS, car il est directement lié au control de Trafic.

Conclusion

Ce chapitre nous a permis de comprendre les différentes types de facturation et les concepts liés à cette facturation.

Chapitre V. CONCEPTS D'API ET NOTION DE SECURITE RESEAU

Introduction

Dans ce chapitre nous aborderons la notion des API et leur architecture puis présenter le framework flask-resplus. Enfin l'aspect de sécurité des réseaux.

V.1. Concept d'API

V.1.1. Définition

 Une API est un ensemble normalisé de classes, de méthodes ou de fonctions qui sert de façade par laquelle un logiciel offre des services à d'autres logiciels. Elle est offerte par une bibliothèque logicielle ou un service web, le plus souvent accompagnée d'une description qui spécifie comment des programmes consommateurs peuvent se servir des fonctionnalités du programme fournisseur. Des logiciels tels que les systèmes d'exploitation, les systèmes de gestion de base de données, les langages de programmation, ou les serveurs d'applications comportent une interface de programmation.

V.1.2. Architecture d'API

V.1.2.1. SOAP

SOAP est un protocole de RPC orienté objet bâti sur XML. Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur. Le transfert se fait le plus souvent à l'aide du protocole  HTTP, mais peut également se faire par un autre protocole, comme  SMTP.

Figure V.1 Architecture SOAP

V.1.2.2. REST

REST ??est un style architectural composé d'un ensemble coordonné de composants, des connecteurs et des éléments de données dans un distribué hypermédia système, où l'accent est mis sur les rôles des composants et un ensemble spécifique d'interactions entre les éléments de données plutôt que les détails de mise en oeuvre.  Son but est d'induire la performance, l' évolutivité , la simplicité, la visibilité, la portabilité et la fiabilité.  REST est le logiciel style architectural du World Wide Web

Figure V.2 Architecture REST

V.1.3. Présentation de Flask-Restplus

Python est un langage de programmation objet, multi-paradigme et multiplateformes. Il favorise la programmation impérative structurée, fonctionnelle et orientée objet. Il est doté d'un typage dynamique fort, d'une gestion automatique de la mémoire par ramasse-miettes et d'un système de gestion d'exceptions ; il est ainsi similaire à  Perl,  Ruby,  Scheme, Smalltalk et Tcl.

Figure V.3 Image Python

Flask est un micro framework open-source de développement web en Python. Son but principal est d'être léger, afin de garder la souplesse de la programmation Python, associé à un système de templates. Il est distribué sous licence BSD.

Figure V.4 Image Flask

Flask-Restplus est une api de développement web basé sur le framework flask et le langage de programmation python.

Figure V.5 Image Flask-restplus

V.2 Notion de sécurité réseau

V.2.1. Présentation de la sécurité réseau

La sécurité des systèmes d'information (SSI) est l'ensemble des moyens techniques, organisationnels, juridiques et humains nécessaires et mis en place pour conserver, rétablir, et garantir la sécurité du système d'information. Assurer la sécurité du système d'information est une activité du management du système d'information.

Aujourd'hui, la sécurité est un enjeu majeur pour les entreprises ainsi que pour l'ensemble des acteurs qui l'entourent. Elle n'est plus confinée uniquement au rôle de l'informaticien. Sa finalité sur le long terme est de maintenir la confiance des utilisateurs et des clients. La finalité sur le moyen terme est la cohérence de l'ensemble du système d'information. Sur le court terme, l'objectif est que chacun ait accès aux informations dont il a besoin. La norme traitant des SMSI est l'ISO/CEI 27001 qui insiste sur : Disponibilité - Intégrité -Confidentialité.

V.2.2 Les protocoles sécurisés

V.2.2.1. HTTPS

L'HyperText Transfer Protocol Secure, plus connu sous l'abréviation HTTPS «protocole de transfert hypertexte sécurisé » est la combinaison du HTTP avec une couche de chiffrement comme SSL ou TLS. HTTPS permet au visiteur de vérifier l'identité du site web auquel il accède, grâce à un certificat d'authentification émis par une autorité tierce, réputée fiable (et faisant généralement partie de la liste blanche des navigateurs internet). Il garantit théoriquement la confidentialité et l'intégrité des données envoyées par l'utilisateur (notamment des informations entrées dans les formulaires) et reçues du serveur. Il peut permettre de valider l'identité du visiteur, si celui-ci utilise également un certificat d'authentification client. HTTPS est généralement utilisé pour les transactions financières en ligne : commerce électronique, banque en ligne, courtage en ligne, etc. Il est aussi utilisé pour la consultation de données privées, comme les courriers électroniques, par exemple. Depuis le début des années 2010, le HTTPS s'est également généralisé sur les réseaux sociaux. Par défaut, les serveurs HTTPS sont connectés au port TCP 443.

Figure V.6 Architecture HTTPS

V.2.2.2. VPN

Un réseau privé virtuel, quelquefois abrégé RPV au Québec et VPN ailleurs, de l'anglais Virtual Private Network, est un système permettant de créer un lien direct entre des ordinateurs distants. On utilise notamment ce terme dans le travail à distance notamment, ainsi que pour l'accès à des structures de type cloud computing.

La connexion entre les ordinateurs est gérée de façon transparente par le logiciel de VPN, créant un tunnel entre eux. Les ordinateurs connectés au VPN sont ainsi sur le même réseau local (virtuel), ce qui permet de passer outre d'éventuelles restrictions sur le réseau (comme des pare-feux ou des proxys).

Le VPN permet également de construire des réseaux overlay, en construisant un réseau logique sur un réseau sous-jacent, faisant ainsi abstraction de la topologie de ce dernier. L'utilisation de VPN n'est généralement pas légalement restreinte. Les connexions VPN ne sont pas nécessairement chiffrées. Cependant, si l'on ne chiffre pas, cela peut permettre à des éléments intermédiaires sur le réseau d'accéder au trafic du VPN, ce qui peut être problématique si les informations qui y transitent sont sensibles. De plus, des techniques de DPI permettent à des pare-feux de filtrer le trafic du VPN s'il n'est pas chiffré.

Figure V.7 Architecture VPN

Conclusion

Ce chapitre nous a permis de comprendre l'aspect de sécurité réseau et ses enjeux puis de cerner la notion des API.

Chapitre VI : CONCEPTION ET IMPLEMENTATION DE LA SOLUTION

Introduction

Ce chapitre présente la conception du système de facturation et du système de vente de crédit. Nous allons présenter les différents outils qui ont été utilisés pour la conception du système, présenter la conception du SMSC et des services à valeur ajoutée, présenter la méthode de développement utilisée pour le système de vente de crédit.

VI.1. Conception de la solution

VI.1.1 Conception du système de facturation

VI.1.1.1 Présentation des serveurs d'application

1. Asterisk

Figure VI.1 Image Asterisk

Asterisk est un logiciel libre open source fonctionnant sous Linux ou Windows. Il a été créé en 1999 par Mark Spencer, et a été le support de lancement de la société Digium, permettant à un micro-ordinateur de type PC de se comporter comme un PABX IP. Il permet à cet ordinateur d'offrir toutes les fonctionnalités des PABX.

Le développement du logiciel est financé par la vente de solution matérielle telles que des cartes permettant à Asterisk de se comporter comme une passerelle VoIP / Téléphonie classique. La licence sous laquelle Asterisk est fourni a permis à de nombreux acteurs de s'impliquer eux aussi dans le développement du logiciel, et il a ainsi rapidement acquis de nombreuses fonctionnalités.Ainsi Asterisk permet de mettre en place une messagerie vocale, des conférences à plusieurs utilisateurs, des serveurs vocaux, la distribution, le transfert des appels... Il supporte notamment les protocoles H323, SIP, MGCP en plus de son protocole IAX (« Inter-Asterisk eXchange », permettant de connecter entre eux plusieurs serveurs Astérisk). Asterisk est à l'origine développé pour tourner sur plateforme Linux avec processeur Intel IA32. Il permet en outre de passer du monde IP vers les réseaux téléphoniques publics (analogique / RNIS / 2G-3G) par l'adjonction de cartes ou boîtiers passerelles.

Cependant il a été conclu pour être portable, cette portabilité associée à un faible besoin en ressources processeur rend Asterisk particulièrement intéressant dans le monde embarqué: il devient possible de créer des boitiers IPBX de faibles dimensions, et ainsi de les positionner dans le monde des petites et moyennes entreprises comme une solution intéressante à plus d'un titre face aux solutions propriétaires.

2. A2billing

Figure VI.2 Image A2billing

A2billing est un logiciel de taxation, très complexe, qui permet non seulement de gérer les tickets d'appels, de gérer des comptes clients, de créditer de différentes manières ces comptes mais aussi de les débiter en fonction des appels passés, ...

A2billing offre plusieurs fonctionnalités parmi lesquelles nous allons étudier ces trois grandes actions

· Admin

Il est l'administrateur de la plateforme, il est chargé de la création des comptes aux clients, de la création des agents, des trunks, de fixer la taxation aux clients, de la politique des droits que les clients pourront effectuer sur l'interface,...

· Agent

Un agent est un distributeur, un associé au fournisseur qui est chargé de faire écouler les produits de son fournisseur. Ici par exemple en tant que administrateur on peut ajouter du crédit à un agent qui à son tour pourra le distribuer aux clients.

· Custumer

Le custumer est un client qui une fois l'administrateur lui crée un compte il dispose de son nom d'utilisateur (login) et de son mot de passe (password), ces deux informations lui permettront de pouvoir se connecter à la plateforme et d'acquérir toutes les informations lui concernant. Il dispose d'une interface qui lui permet d'avoir plusieurs actions à effectuer comme par exemple la création de compte à ses clients, de consulter ses factures, de voir l'historique des appels, des payements,... L'administrateur peut définir des politiques de droit que son client pourra avoir sur la plateforme. Pour bien contrôler les actions des clients sur l'interface, l'administrateur doit associer à chaque client un groupe.

De ce fait on aura besoin de créer une liste de numéro pour que tout client qui arrive puisse être identifié.

Le custumer a la possibilité de créer ses propres clients, mais pour que ceux-ci puissent atteindre d'autres clients dans un autre opérateur il est impérative qu'ils passent par le provider VoIP, celui-ci via une passerelle (Gateway) permettra une communication vers d'autres opérateurs. Le fournisseur de service qui définit les modalités de facturation des clients. Ceci se fait au niveau de l'interface du serveur lors de la création des SDAs (Sélection Directe à l'Arrivée) en anglais on dira DIDs. Chaque client est associé un DID.

L'association d'un DID à un client se fait au niveau de la rubrique Inbound DID ensuite dans Destination de l'interface du serveur.

Donc une fois le Custumer crée on crée un DID qui lui sera associé, de la même manière qu'on peut créer un groupe de Custumer, on peut aussi créer un groupe de DID pour faciliter la gestion des utilisateurs ou clients.

Il faut noter qu'a2billing dispose de quatre méthodes de facturation des clients:

· VoIP registration: ici le client est inscrit à a2billing avec son nom d'utilisateur et Son mot de passe;

· IP address: tous les appels sont acceptés à partie d'une adresse IP spécifique;

· PIN authentification: c'est l'utilisation d'un code PIN unique;

· CallerID: c'est l'utilisation du CID pour l'authentification des clients.

N.B: La dernière méthode sera celle que nous allons utiliser dans notre travail parce qu'elle nous permettra de pouvoir gérer des clients des autres opérateurs.

3. Freeswitch

FreeSwitch est une plateforme de téléphonie open source conçue depuis 2006 pour router et interconnecter les protocoles de communications populaires en utilisant l'audio, la vidéo, le texte ou tout autre forme de média. Freeswitch dispose de plusieurs modules qui offrent de nombreuses fonctionnalités:

Conférence, réponse vocale interactive, synthèse et reconnaissance vocale, messagerie instantanée.

VI.1.1.2. Conception du SMSC

1. Protocole Simple

SIMPLE, est un protocole permettant de faire de la messagerie instantanée en s'appuyant sur un service de présence. Il est basé sur le langage XML et est greffé sur le protocole SIP en tant que mécanisme de paquet d'événement. Comme le protocole XMPP, et contrairement à la grande majorité des protocoles de messagerie instantanée et de présence utilisés aujourd'hui, SIMPLE est un standard ouvert. SIMPLE n'autorise que les échanges en mode connecté. En d'autres termes, un message envoyé à un utilisateur déconnecté n'est pas reçu à sa reconnexion.

2. Présentation du module SMS de FreeSwitch

Le module SMS fournit une possibilité de router des messages dans FreeSwitch et offre ainsi la possibilité de construire un puissant système de messagerie à l'image de XMPP. Le module SMS dispose d'un plan de routage des messages appelés chatplan. Le principe de fonctionnement du module est le suivant:

ü D'abord il se connecte via ESL sur le système d'événement de FreeSwitch ;

ü Ensuite il capte l'ensemble des événements de type MESSAGE ;

ü Puis il les route vers le chatplan ;

ü Enfin, les instructions du chatplan sont exécutées .

Cependant si le chatplan n'est pas défini, alors l'échange de message d'effectue entre utilisateurs de manière point à point.

3. Les modes de fonctionnement du module SMS

Nous allons présenter le mode de fonctionnement suivant deux cas de figure. On suppose que dans le premiers cas, les correspondants (expéditeur/destinataire) sont en ligne et détectés par le serveur de présence et dans le dernier cas que le destinataire n'est pas en ligne.

a. Envoi SMS en mode destinataire connecté

ü Architecture fonctionnelle.

Figure VI.3 Architecture fonctionnelle du mode destinataire connecté

ü Fonctionnement du SMSC en mode destinataire connecté

Dans cette section nous présentons le principe de fonctionnement du SMSC sur l'envoi de message à un utilisateur qui est connecté. La figure ci-après présente ce principe.

Figure VI.4 Fonctionnement du SMSC en mode destinataire connecté

v Description du principe

La description du fonctionnement du SMSC en mode destinataire connecté est la suivante :

1. L'utilisateur1 « User1 » envoie un message à l'utilisateur2 « User2 », le SMS passe par le SMSC qui écoute les événements REGISTER de Freeswitch et voit que l'utilisateur2 est connecté.

2. Le SMSC vérifie dans la base de données si l'utilisteur1 dispose de crédit suffisant pour envoyer un SMS.

3. Le SMSC voit que l'utilisateur a du crédit pour envoyer un SMS.

4. Le SMSC envoi le SMS au destinataire le « User2 » puis il défalque le montant de l'envoi sur son compte.

5. Si l'utilisateur1 ne dispose pas de crédit suffisant dans son compte.

6. Le SMS n'arrivera pas à destination, il est perdu.

b. Envoi SMS en mode destinataire non connecté

ü Architecture fonctionnelle.

Figure VI. 5 Architecture fonctionnelle du mode destinataire déconnecté

ü Fonctionnement du SMSC en mode destinataire déconnecté

Cette section présente le fonctionnement du SMSC sur l'envoi de message à un destinataire déconnecté. La figure ci-dessous présente ce principe.

Figure VI.6 Fonctionnement du SMSC en mode destinataire non connecté

v Description du principe

La description du fonctionnement du SMSC en mode destinataire non connecté est la suivante:

1. L'utilisateur1 « User1 » envoie un message à l'utilisateur2 « User2 », le SMS passe par le SMSC qui écoute les événements REGISTER de Freeswitch et voit que l'utilisateur2 est non connecté.

2. Le SMSC vérifie dans la base de données si l'utilisteur1 dispose de crédit suffisant pour envoyer un SMS.

3. Si le SMSC voit que l'utilisateur a du crédit pour envoyer un SMS, il défalque son compte.

4. Le SMSC stocke le SMS dans la base de données.

5. Si le SMSC voit que l'utlisateur1 ne dispose pas de crédit suffisant pour envoyer un SMS.

6. Le SMS ne sera pas envoyer, il est perdu.

c. Destinataire reconnecté

ü Architecture de fonctionnement en mode reconnexion

Figure VI.7 Architecture de fonctionnement en mode reconnexion

Le principe de fonctionnement de l'architecture est décrit dans la section suivante.

ü Fonctionnement du SMSC en mode destinataire reconnecté

Cette section constitue la reconnexion de l'utilisateur qui était déconnecté. La figure ci-dessous présente le fonctionnement du SMSC en cas de reconnexion du destinataire qui a un message en absence.

Figure VI.8 Fonctionnement du SMSC en mode destinataire reconnecté

v Description du principe

La description du fonctionnement du SMSC en mode destinataire absent et reconnecté est :

1. L'utilisateur2 était déconnecté pendant que l'utilisateur1 lui envoyait un SMS, le SMS était stocké dans la base de données par le SMSC, à la reconnexion de l'utilisateur2, le SMSC récupère le SMS de la base de données ;

2. Le SMSC envoi le SMS au destinataire reconnecté.

d. Présentation du SMSC dans le cas des réseaux 2G/3G

Le GSM (Global System for Mobile communications) est une norme de la seconde génération des réseaux de téléphonie mobile . Dans son architecture, il apparait un composant dénommé SMSC pour Short Message service Center (Centre de service des messages court en français) qui permet de gérer le transfert de messages(SMS) limités à 160 caractères entre téléphones mobiles. Les réseaux 3G sont l'évolution des réseaux 2G . Le SMSC des réseaux 3G est la même que celui du réseau 2G. La 3G propose d'atteindre des débits supérieurs à 144 kbit/s, ouvrant ainsi la porte à des usages multimédias tels que la transmission de vidéo, la visioconférence ou l'accès à internet haut débit. Les réseaux 3G utilisent des bandes de fréquences différentes des réseaux précédents: 1885-2025 MHz et 2110-2200 MHz.

Figure VI.9 Architecture des réseaux GSM et UMTS

VI.1.2. Conception du système de vente de crédit

1. Présentation de la méthode de développement

La méthode RAD

RAD est une méthode de développement rapide d'applications basée sur le prototypage et le développement incrémental sans planification spécifique impliquée. Elle repose sur un certain nombre de principes tels que:

· le développement doit s'effectuer en faisant appel à une méthodologie formalisée ;

· l'équipe de développement RAD doit disposer d'outils puissants qui automatisent le développement dans sa globalité ;

· l'équipe de développement doit être correctement gérée, par un encadrement encourageant la réutilisation des composants ;

· les utilisateurs finaux doivent s'impliquer dans le processus de développement.

La méthode RAD structure le cycle de vie du projet en cinq (5) phases:

Ø Initialisation : l'objectif est d'informer les intervenants des contraintes du projet RAD. En effet, dans cette phase, on détermine le périmètre général et le plan de communication du projet. De même, le travail est structuré par thèmes et les acteurs pertinents du projet sont identifiés ;

Ø Cadrage : qui couvre l'analyse des besoins, la définition du périmètre et la planification de l'itération ;

Ø Design : encore appelée la phase de conception et de modélisation. Lors de cette phase, une modélisation de la solution est faite et un premier niveau de prototypage présentant l'ergonomie et la cinématique générale de l'application est validé ;

Ø Construction : dans cette étape, l'équipe doit construire l'application module par module dans un délai limité avec la participation régulière des utilisateurs. Elle fusionne les étapes de codage, de tests unitaires et de tests d'intégration ;

Ø Finalisation: il s'agit, dans cette phase, d'officialiser une livraison globale et de transférer le système en exploitation et maintenance après avoir réalisé toutes les recettes et élaboré la documentation ;

2. Présentation des outils

Les outils utilisés pour le développement du produit sont classés suivant leur utilité au niveau du projet. Ainsi on distingue:

· Le langage de modélisation

v Présentation d'UML

UML, c'est l'acronyme anglais pour « Unified Modeling Language » traduit par « langage de modélisation unifié ».

C'est un langage visuel constitué d'un ensemble de schémas, appelés des diagrammes, qui donnent chacun une vision différente du projet à traiter.

UML est né de la fusion des trois méthodes qui ont influencé la modélisation objet au milieu des années 90: OMT, Booch et OOSE. Il s'agit d'un compromis qui a été trouvé par une équipe d'experts: Grady Booch, James Rumbaugh et Ivar Jacobson. UML est à présent un standard défini par l'OMG.

v Les diagrammes UML

Depuis sa normalisation en 1997 par l'OMG, UML en est aujourd'hui à sa version 2.5.

Cette version comporte quatorze (14) diagrammes classés en trois (3) grandes catégories : les diagrammes structurels (diagramme de classes, diagramme d'objets, diagramme de packages, diagramme de composants, diagramme de structure composite, diagramme de déploiement et diagramme de profils), les diagrammes d'interaction (diagramme de séquence, diagramme de collaboration, diagramme d'interaction et diagramme de temps) et les diagrammes comportementaux (diagramme de cas d'utilisation, diagramme d'activités et diagramme d'état-transition).

v Le diagramme de cas d'utilisation

Il permet de représenter les fonctionnalités d'un système ou sous-système. Il se compose d'acteurs, de cas d'utilisation et de relations qui les associent.

Un acteur est celui qui bénéficie de l'utilisation du système. C'est une entité qui joue un rôle dans le système. Dans le formalisme UML, un acteur est représenté symboliquement par un « bonhomme » (« stick man » en anglais) et est identifié par son nom ou est formalisé par une classe stéréotypée « actor »

Un cas d'utilisation est une manière spécifique d'utiliser un système. Il réalise un service de bout en bout, avec un déclenchement, un déroulement et une fin pour l'acteur qui l'initie. Il est représenté dans UML par une ellipse.

Plusieurs types de relation peuvent exister entre les cas d'utilisation :

· Une relation d'inclusion matérialisée par le stéréotype « include » (« inclure ») permet d'indiquer qu'un cas d'utilisation fait appel à un autre cas d'utilisation ;

· Une relation d'extension matérialisée par le stéréotype « extends » (« étendre ») permet d'indiquer qu'un cas d'utilisation étend le comportement d'un autre cas d'utilisation.

v Le diagramme de classes

Ce diagramme permet de donner la représentation statique du système à développer. Cette représentation est centrée sur les concepts de classe et d'association. Une classe est une abstraction des entités du monde réel possédant une structure commune, un comportement commun, des relations identiques et une sémantique identique. Les liens entre les entités du monde réel se traduisent par des associations entre classes. Dans UML, une classe est représentée par un rectangle découpé en trois (3) parties contenant respectivement le nom de la classe, la liste des attributs, et la liste des opérations (comportement).

v Le diagramme de séquence

Le diagramme de séquence permet de décrire l'ordre des interactions entre les objets qui composent le système : il représente la dynamique du système. Les objets sont des entités appartenant au système, des instances de classe. Dans UML, à chaque objet est associée une ligne de vie qui montre ses actions et réactions, ainsi que les périodes pendant lesquelles il est actif.

v Les outils de modélisation : Visual Paradigme

C'est un logiciel de modélisation qui permet la création des diagrammes UML et des modèles qui en sont à l'origine. Ceux-ci peuvent alors générer du code dans un langage de programmation déterminé. Il propose également la création d'autres types de diagrammes, comme celui qui permet la modélisation des bases de données pouvant, lui aussi, générer des canevas d'applications basé sur des Framework et Pattern mais en plus, générer du code SQL qu'il peut ensuite déployer automatiquement dans différents environnements.

3. Analyse des besoins

· Les paquets du système

Pour permettre un couplage faible entre les composants de notre système, on a commencé par découper le système en packages. Chaque package contiendra une partie des fonctionnalités du système. Nous aurons le package appel, le package message et le package demande de crédit:

1. Diagramme de package du système

Nous aurons ainsi quatre sous-systèmes: la gestion des revendeurs, la gestion des appels, la gestion des messages et la gestion des demandes de crédit.

o Sous-système « gestion des revendeurs »

Nous allons dans cette section illustrer, à l'aide de diagramme de cas d'utilisation UML, les fonctionnalités du sous module « gestion des revendeurs ». Le diagramme ci-dessous montre ses différentes fonctionnalités:

2. Diagramme des fonctionnalités dans « gestion des revendeurs »

Pour une bonne compréhension, nous allons illustrer le diagramme à l'aide de diagramme de séquence d'UML pour la réalisation du cas d'utilisation « supprimer revendeur ».

o Sous-système « gestion des appels »

Nous allons dans cette section illustrer, à l'aide de diagramme de cas d'utilisation UML, les fonctionnalités du sous module « gestion des appels ». Le diagramme ci-dessous montre ses différentes fonctionnalités :

3. Diagramme des fonctionnalités dans « gestion des appels »

Pour une bonne compréhension, nous allons illustrer le diagramme à l'aide de diagramme de séquence d'UML pour la réalisation des cas d'utilisation « supprimer appel » et « lister appel ».

4. Diagramme de séquence du cas d'utilisation « supprimer appel »

o Sous-système « gestion des messages »

Nous présentons ici à l'aide de diagramme de cas d'utilisation, les fonctionnalités du sous-module « gestion des messages » et ensuite détailler un cas pour expliquer les échanges entre les objets du système pour réaliser une fonctionnalité. Le diagramme ci-dessous montre le diagramme de cas d'utilisation dans ce module.

5. Diagramme gestion des demandes de credit

o Sous-système « gestion des demandes de crédit »

Nous présentons dans cette section le diagramme de cas d'utilisation, les fonctionnalités du sous-module « gestion des demandes de crédit » et ensuite détailler un cas pour expliquer les échanges entre les objets du système pour réaliser une fonctionnalité. Le diagramme ci-dessous montre le diagramme de cas d'utilisation dans ce module.

7. Diagramme de cas d'utilisation « gestion des demandes de crédit »

8. Diagramme de séquence du cas d'utilisation «solder »

4. Présentation du diagramme de classe du système de vente de crédit

Nous présenterons ici le de classe du système. Dans ce diagramme, les fonctionnalités sont représentées dans chaque classe. Le diagramme ci-dessous décrit les fonctionnalités du système et les différentes interactions du système.

9. Diagramme: Diagramme de classe du système

VI.1.2. Implémentation de la solution

1. Architecture de la solution

Apres étude , nous avons porté notre choix sur Freeswitch comme serveur d'application et a2billing comme système de facturation

Figure VI.10 Architecture de vente de crédit

2. Présentation des résultats de la facturation des SMS

a. Envoi de SMS à un utilisateur en mode connecté

Le client 802 décide d'envoyer un message en destination du client 801, celui-ci est connecté, donc un événement REGISTER de sa part est détecté par le SMSC comme le montre la capture suivante:

Capture 1: enregistrement user 801 et 802

Avant l'envoi de sms:

Capture 2: Users dans a2billing avant l'envoi de sms

Capture 3 : SMS en mode connecté

La capture montre l'événement register du user 801 est détecté par le SMSC et qu'il ne dispose pas de nouveaux messages, c`est-à-dire au moment de son enregistrement, le SMSC a consulté la base de données pour vérifier si le 801 avait un message en absence. On voit bien les informations que le SMSC nous notifie à savoir: user connecté message envoyé!! Ce message est récupéré par le SMSC qui le stocke dans la base de données avant de procéder au transfert vers le destinataire.

Après l'envoi de sms:

Capture 4: Users dans a2billing apès l'envoi de sms

b. Envoi de SMS à un utilisateur en mode non connecté

Dans le même principe le client 801 est déconnecté et le client 802 lui envoie un message en absence, celui-ci est intercepté par le SMSC qui vérifie dans sa base de données sqlite share-présence et ne trouve pas d'événement REGISTER pour le client 801, donc il (SMSC) stocke le message dans une autre base de données MySQL holding-sms, cette base permet de stocker les messages en absence. C'est dans cette base que le message sera récupérer en cas de reconnexion du client 801. La capture suivante illustre ce phénomène :

Capture 5: SMS en mode non connecté

Dans cette capture on voit que le message envoyé par l'expéditeur 802 en destination du 801 a été sauvegardé car le user 801 est non connecté. A la reconnexion du 801, on voit les informations à savoir:

Capture 6: SMS en absence pour 802 et reconnexion

3. Présentation des résultats de la facturation de la voix

La facturation des appels est gérée grâce à a2billing qui est un outils de facturation.

Connexion de user 801

Capture 7: Enregistrement des users

Connexion de user 802

Avant l'appel

Après l'appel

4. Réalisation du système de vente de crédit

Après la mise en place du système de vente et de la plateforme, nous allons présenter les différents résultats.

A. Coté administrateur

Ici nous utilisons a2billing pour gérer cela:

a. Page d'accueil de l'application

Capture 8: Interface d'accueil a2billing

b. Page de connexion de l'administrateur

L'administrateur peut voir:

· Lister les CDRs des appels émis

· Lister les CDRs de demande de credit

· voir la liste des revendeurs, pour ne citer que cela

B. Système côté Revendeur

Le revendeur interagit avec le système grâce à une API mise en place et développée avec le Framework Flask-Restplus.

Pour les revendeurs, ils accèdent au système via une URL de l'API qu'on a mise en place.

API d'envoi de SMS et de vente de crédit

v Interface revendeur et présentation des résultats

Pour le revendeur, nous avons développé une application web respectant les critères d'un opérateur de transfert d'argent qu'on nomme AkhiKachMoney.

Capture 10: Interface de connexion du revendeur

Le revendeur se connecte avec son login et son mot de passe, une foi qu'il valide, il obtient la page suivante:

Capture 11: Page de d'accueil du revendeur

Toutes ces fonctionnalités sont liées à l'API et permettent au revendeur d'effectuer des actions comme l'achat de crédit, la vente de crédit, consultation de crédit, et l'envoi de message. Le revendeur du numéro 810 vend du crédit au client 801, la capture suivante illustre ce fait:

Capture 12: Interface de vente de crédit du revendeur

Une foi le revendeur valide, le client reçoit le message suivant:

Capture 13: Message reçu après achat de crédit au revendeur

Conclusion

Dans ce chapitre, nous avons effectué la conception des systèmes de facturation et de vente de crédit en ligne. Nous avons aussi présenté les différents diagrammes de cas d'utilisation et de classe qui ont été mise en place pour la réalisation des systèmes de facturation et vente de crédit. Ensuite nous avons présenté les différents résultats du système de facturation mais aussi du système de vente de crédit.

Conclusion générale et perspective

Ce projet de mémoire de licence nous a permis de mieux appréhender le fonctionnement des logiciels de facturation et surtout l'aspect de la programmation puis la compréhension des API. Les compétences en télécommunications et en informatique nous ont permis d'atteindre les objectifs fixés.

L'objectif de ce projet était de concevoir et de déployer un système de vente de crédit pour les opérateurs de transfert d'argent basé sur le protocole SIP et pouvoir facturer les utilisateurs.

Etant entendu que le protocole SIP permet l'acheminer des paquets d'un émetteur vers un récepteur, plusieurs problèmes peuvent être noté sur le transport d'application multimédia telles que la voix, la vidéo et les données etc.

Comme perspective nous avons :

· Conversion de crédit d'un opérateur vers un autre

· Développer des services à valeur ajoutés sous Android

Nous avons pu retenir de cette expérience que les logiciels libres bien qu'étant gratuits, nous offrent d'importants services selon nos besoins.

BIBLIOGRAPHIE

[B1]: Guy Pujolle, Les Réseaux-Edition 2011; roupe Eyrolles ISBN : 978-2-212-12359-3

[B2]: Anthony Minessale, Michael S Collins, Darren Schreiber, Raymond Chandler, Build robust, high-performance telephony systems using FreeSWITCH, FreeSWITCH 1.2, Second Edition.

WEBOGRAPHIE

[W1]: https://freeswitch.org/confluence/display/FREESWITCH/mod_sms (consulté le 09 août 2016)

[W2]: https://freeswitch.org/confluence/display/FREESWITCH/mod_lua (consulté le 01 août 2016)

[W3]: https://freeswitch.org/confluence/display/FREESWITCH/mod_python (consulté le 01 août 2016)

[W4]: https://flask-restplus.readthedocs.io/en/stable/ (consulter le 23 avril 2016)

[W5]: http://www.asterisk2billing.org/documentation/ (consulter le 20 avril 2016)

[W6]: https://openclassrooms.com/courses/utilisez-des-api-rest-dans-vos-projets-web (consulter le 11 mai 2016)

ANNEXE

A. Installation freeswitch

sudo apt-get update

sudo apt-get install autoconf automake devscripts gawk g++ git-core libjpeg-dev libncurses5-dev libtool make python-dev gawk pkg-config libtiff4-dev libperl-dev libgdbm-dev libdb-dev gettext sudo equivs mlocate git dpkg-dev devscripts sudo wget sox flac lua-socket-dev libvpx-dev libopus-dev opus-tools libpng-dev libsqlite3-dev libpcre3-dev libspeexdsp-dev libsqlite3-dev libcurl-dev libldns-dev libedit-dev nasm

cd /usr/src

git clone -b v1.6 https://freeswitch.org/stash/scm/fs/freeswitch.git

cd freeswitch.git

./bootstrap.sh

./configure --with-python=/usr/bin/python2.7

make

make install

B. Installation a2billing

Cd /usr/local/src/

wget https://github.com/star2Billing/a2billing/archive/v2.0.5.tar.gz

tar -xvzf v2.0.5.tar.gz -C /usr/local/src/a2billing

C. Installation flask

D. Code API