Memoire JOSUE

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 Master en Télécommunications et Réseaux
SUJET : Conception et Déploiement d’une Plate-forme de Téléconsultation
Lieu de stage : Groupe RTN
Présenté et soutenu par: Professeur Encadreur:
Josué NUMBI LUHEHO Dr. Samuel OUYA
Année Universitaire: 2016-2017

Mémoire de fin de cycle Master 2016-2017
DEDICACES
Je dédie ce mémoire à :
 Mon père Numbi Nzuzi JUSTIN, qui peut être fier et trouver ici le résultat de longues années de
sacrifices pour m'aider à avancer dans la vie. Puisse Dieu faire en sorte que ce travail porte son fruit ;
Merci pour les valeurs nobles, l'éducation et le soutien permanent venu de toi;
 Ma mère Kenge Ngimbi CHANTAL, qui a œuvré pour ma réussite, de par son amour, son soutien,
tous les sacrifices consentis et ses précieux conseils, pour toute son assistance et sa présence dans ma
vie, reçois à travers ce travail aussi modeste soit-il, l'expression de mes sentiments et de mon
éternelle gratitude ;
 Mes frères et sœurs, qui m'ont encouragé tout au long de mes études, malgré la distance, ils n'ont
cessé de m'offrir leur amour et leur soutien infaillible;
 Mes proches, qui n'ont cessé d'être pour moi des exemples de persévérance, de courage et de
générosité ;
 Mes professeurs de l'EC2LT qui doivent voir dans ce travail la fierté d'un savoir bien acquis.
Conception et Déploiement d’une Plate-forme de Téléconsultation 2

REMERCIEMENTS
Avant toutes choses, je tiens à rendre grâce à Dieu le Tout Puissant, le Miséricordieux pour la force
qu'il m'a donné dans les moments difficiles d'éditer ce mémoire et pour la patience et courage durant ces
longues années d’études. J’exprime ma plus profonde reconnaissance à :
 Tout le corps professoral de l’EC2LT, qui ont su nous donné une formation didactique et appréciable
durant toute notre formation, pour la qualité de ses enseignements, leurs disponibilités et conseils ;
 Mes parents, qui m'ont toujours entouré et motivé sans cesse à devenir meilleur ;
 Mes frères et sœurs, qui m'ont aidé à avancer dans les moments difficiles ;
 Mon Encadreur Docteur Samuel OUYA, pour sa disponibilité, rigueur et recommandations ;
 Mes amis et amies de par le monde qui n'ont cessé de m'encourager;
 ISMAEL, pour sa disponibilité et son soutien durant la réalisation de ce travail ;
 Tous mes compagnons de promotion
 Tous ceux qui, de près ou de loin, m’ont aidé à la réalisation de ce travail

AVANT-PROPOS
L’Ecole Centrale des Logiciels Libres et de Télécommunications (EC2LT) de Dakar en partenariat

avec le groupe RTN (Réseaux et Techniques Numériques) offre une formation en Master de niveau BAC+5
adaptée aux secteurs des Télécommunications et des technologies en Réseaux permettant d’acquérir une
double compétence en Réseaux et en Télécommunications : le Diplôme de Master en Réseaux et
Télécommunications.
L’objectif de cette formation est de former des étudiants doués d’aptitudes professionnels,
compétents et capables de répondre aux besoins des entreprises dans les domaines des Réseaux
Informatiques et des Télécommunications, de développer des applications autour des logiciels libres. Ceux-
ci doivent être capables de comprendre les problèmes réels posés dans les entreprises et en particulier en
Afrique, de concevoir et implémenter les solutions matérielles et logicielles basées sur les outils open source
permettant d'améliorer efficacement le vecteur de communication dans les entreprises.
La formation s’étale sur cinq ans. L’enseignement comporte des cours théoriques et pratiques ainsi
qu’un stage de fin de formation de trois(4) à quatre(5) mois en entreprise ou dans un laboratoire. A la fin de
ce stage, l’étudiant est tenu de présenter devant un membre du jury un projet de mémoire. C’est dans cette
optique que ce présent travail dont le sujet s’intitule « Conception et Déploiement d’une Plate-forme de
Téléconsultation » a été réalisé au sein du département d'Etude de l’Entreprise RTN.
Cette société œuvre principalement dans les domaines de la gestion des projets de
Télécommunications, Réseaux et Informatiques basés sur les logiciels libres ayant trait aux études,
conception, réalisations et planifications.
Nous tenons, au terme de ce travail, à exprimer l’honneur qui nous est fait par les membres du jury
en acceptant de juger mon travail.

RESUME
Avec l'apparition des technologies de l'information et de la communication, les communications se

sont profondément modifiées. Il va en va de même dans le domaine médical, la télémédecine est une forme
de pratique médicale à distance utilisant les TIC.
Cette pratique médicale va transformer le rapport entre les patients et les médecins dans le but
d'améliorer l'accessibilité aux soins dans les zones d'accès difficile grâce aux TIC.
La rencontre physique entre un médecin et patient n'est pas toujours nécessaire puisque des
nombreux problèmes médicaux peuvent être réglés en ligne, sans que vous ayez besoin de vous déplacer.
Par ailleurs, le présent projet a pour but de mettre en évidence la conception et le déploiement d'une plate-
forme de téléconsultation intégrant la technologie WebRTC.
WebRTC est un projet libre et gratuit qui permet aux navigateurs web de se doter des capacités de
communications multimédias en temps réel par l'ajout de simples API Javascript. Il permet de mettre en
place des applications telles que le chat, de partage de fichier, de jeux, de vidéoconférence.
Grâce à ce projet, nous avons mis en place une plate-forme de téléconsultation en temps réel
accessible à travers les navigateurs web permettant de faire la consultation à distance où ni le patient, ni le
médecin n'est présent physiquement.


TABLE DES MATIERES
TABLE DES MATIERES
LISTE DES TABLEAUX..................................................................................................................................9
LISTE DES FIGURES....................................................................................................................................10
SIGLES ET ABREVIATIONS.......................................................................................................................11
INTRODUCTION...........................................................................................................................................12
I. Présentation Générale...............................................................................................................................14
I.1. Présentation de la Structure d’accueil...............................................................................................14
I.1.1. Présentation de L’Entreprise RTN.............................................................................................14

I.1.2. Mission de RTN.........................................................................................................................14
I.1.3. Organigramme de RTN..............................................................................................................15
I.1.4. Domaine d’activité.....................................................................................................................16
I.2. Présentation du Projet........................................................................................................................18
I.2.1. Contexte.....................................................................................................................................17
I.2.2. Problématique.............................................................................................................................19
I.2.3. Objectifs..................................................................................................................................... 20
II. Généralités sur la Télémédecine...............................................................................................................21
II.1. Qu’est-ce que la Télémédecine ?.......................................................................................................21
II.2. L’intérêt de la Télémédecine.............................................................................................................22
II.3. Les composantes de la Télémédecine................................................................................................22
II.3.1. La Téléconsultation....................................................................................................................22
II.3.2. La Télé-expertise........................................................................................................................22
II.3.3. La Télésurveillance....................................................................................................................22
II.3.4. La Téléassistance........................................................................................................................22
II.4. Les dispositifs médicaux connectés.................................................................................................. 24

II.5. Avantages et Inconvénients...............................................................................................................25
III. Présentation de WebRTC..........................................................................................................................27
III.1. Définition et Principes......................................................................................................................26
III.2. Architecture générale de WebRTC...................................................................................................28
III.3. Fonctionnement.................................................................................................................................30
III.3.1. Architecture de fonctionnement.................................................................................................30
III.3.2. La Signalisation..........................................................................................................................31
III.3.3. La Traversée de NAT.................................................................................................................33
III.4. La Description de session SDP.........................................................................................................41
III.5. Les Protocoles de transport (SRTP, RTP, RTCP)............................................................................ 42
III.6. Les Codecs........................................................................................................................................45
III.7. Les APIs............................................................................................................................................46
III.8. Avantages et Inconvénients.............................................................................................................. 46
IV. Analyse et Conception de la Plate-forme................................................................................................. 61
IV.1. Architecture et Fonctionnement ...................................................................................................... 61
IV.2. Choix des outils et technologies.......................................................................................................62
IV.2.1. Les Langages de programmation............................................................................................... 62
IV.2.2. Les Protocoles http et WebSocket............................................................................................. 64
IV.2.3. La Base de données (Mongo DB)..............................................................................................65
IV.3. Conception du système..................................................................................................................... 66
IV.3.1. Modélisation du système........................................................................................................... 66
IV.3.2. Environnement de développement............................................................................................ 68
IV.4. Architecture du déploiement................................................................................................................71
IV.5. Présentation des résultats.................................................................................................................72
CONCLUSION................................................................................................................................................75
BIBLIOGRAPHIE ET WEBOGRAPHIE.......................................................................................................76

LISTE DES TABLEAUX
LISTE DES TABLEAUX

LISTE DES FIGURES
LISTE DES FIGURES

SIGLES ET ABREVIATIONS
SIGLES ET ABREVIATIONS
EC2LT Ecole Centrale des Logiciels Libres et de Télécommunications
RTN Réseaux et Techniques Numériques

INTRODUCTION
INTRODUCTION
Actuellement, les technologies de l'information et de la communication ont connu un essor

remarquable tant dans les domaines de télécommunications que d'informatique. Les progrès technologiques
se sont traduits par le développement d'une multitude d'applications et services dans tous les secteurs
notamment dans le domaine de la télémédecine.
En effet, les technologies de l'information et de la communication permettent d'envisager de

nouvelles façons d'exercer la médecine notamment la téléconsultation.
La téléconsultation est une consultation médicale qui met en relation, à distance et en temps réel, un
patient et un médecin. Elle permet la consultation, le diagnostic et le suivi du patient à distance.
Durant ces dernières années, l'on assiste à une grande évolution du Word Wide Web, qui est dotée
des fonctionnalités avancées avec la capacité de faire passer de la voix et de la vidéo via des navigateurs.
C'est dans ces perspectives que Google a lancé le projet WebRTC qui intègre les fonctions de
communications temps réel peer-to-peer dans les navigateurs Web avec la première implémentation de l'API
WebRTC. Il se focalise sur des protocoles et des codecs existants.
Ainsi, le projet suivant a été proposé : « Conception et Déploiement d'une plate-forme de dernière
génération. » ; dont l'étude et la réalisation font l'objet d'obtention du diplôme de fin de cycle en Master
Télécommunications et Réseaux.
Le but de ce projet est de mettre en place une plate-forme de téléconsultation permettant au médecin
d’effectuer, à distance et en temps réel une consultation avec un patient.
C'est dans cette optique que la démarche pour mieux appréhender les contours de ce projet nous a
amenés à structurer le présent document en quatre (04) chapitres :
 Le premier chapitre consiste à faire une présentation générale : Nous aborderons la
présentation de la structure d’accueil et la présentation du sujet ;
 Le deuxième chapitre consiste à faire une étude sur la télémédecine ;

 Le troisième chapitre parlera de la technologie WebRTC, la signalisation dans le WEBRTC

ainsi que les codecs ;
 Le quatrième chapitre abordera la conception de la plate-forme, le choix de différents outils
utilisés et enfin la mise en œuvre.

Chapitre I
I. Présentation Générale
I.1. Présentation de la Structure d’accueil
I.1.1. Présentation de L’Entreprise RTN
RTN est une société dirigée par une équipe de professionnels qualifiés, et est spécialisée dans le
domaine de Télécommunications, de Réseaux et de l’Informatique. Elle est composée de techniciens,
d’ingénieurs, de professeurs, spécialisés dans le domaine de l’utilisation de logiciels libres et sont centrés sur
les services informatiques, techniques numériques et de télécommunications. RTN offre un ensemble de
formations rigoureuses basées sur des supports des cours, fruits de recherches approfondies. Ces supports
testés et avérés permettent aux apprenants de la dite école d’être aussitôt opérationnels.
I.1.2. Mission de RTN
La mission de RTN vise à accroître la compétitivité de ses clients par la valorisation des composants
informatiques, logiciels 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. Leurs principaux objectifs sont de conseiller et de former le personnel des
entreprises qui veulent disposer des logiciels libres et adaptés à leurs besoins minimisant ainsi les coûts
d’investissements en réseaux informatiques tout en leur apportant une sécurité avancée.

I.1.3. Organigramme de RTN
Figure I.1: Organigramme de RTN
RTN dispose de trois laboratoires de recherches qui sont :
 Laboratoire de Virtualisation et de Cloud Computing (LV2C)
 Laboratoire de Technologies de l’Information et de la Communications pour les
Enseignements (LTICE)
 Laboratoire de NGN et Applications Mobiles

I.1.4. Domaine d’activité
La société RTN offre une palette de services dans le domaine de la technologie de l’information et de
la communication. Les services de RTN sont orientés Open Source et sont réalisés selon les besoins et
l'exploration des opportunités d'entreprise. Elle répond par conséquent aux problèmes réels.
Ainsi, elle met également un accent sur le développement des services à valeurs ajoutées, et sur
l’interconnexion des réseaux Linux et Windows, participant de ce fait à la cohabitation et l’harmonisation
des réseaux hétérogènes Linux-Windows.
La RTN intervient aussi dans les domaines suivants :
 Conseils et orientations professionnelles pour la gestion d’un réseau d’entreprise

dynamique ;
 Formation et accompagnement des personnels d’entreprises ;
 Mise à niveau du personnel des entreprises sur les technologies de l’information et de
la communication
La RTN dispense aussi d’un éventail de formations dont la liste non exhaustive est la suivante :
 Développement :
 Initiation à la programmation JAVA

 Android : Développement d’applications mobiles
 Développement de site Web HTLM5&CSS3
 Site Web avec framework : Python&Django
 Services :
 Téléphonie sur IP avec l’IPBX open source Asterisk (SIP, SCCP, UNISTIM)
 Téléphonie sur IP avec le protocole H323
 Téléphonie sur IP avec Call Manager de Cisco
 Téléphonie sur IP avec Call Manager Express
 Interconnexion Call Manager Express-Asterisk
 IMS : De la théorie à la pratique
 Messagerie Collaborative
 L’annuaire LDAP
 Sécurité Réseaux
 Services Réseaux (DNS, DHCP, NFS, TFTP, etc)
 Certification :
 Certification JAVA
 Certification CISCO
 Certification Linux LPI 1&2
 Cœur de Réseau IP :
 MPLS : La technologie du cœur de l’operateur

 QoS : Déploiement de la qualité du service

I.2. Présentation du Sujet
I.2.1. Contexte du Sujet
Les nouvelles technologies de l’information et de la communication ont permis le développement

de la télémédecine et a donné naissance à de nouvelles formes de consultation et de diagnostic des
patients : la téléconsultation
La téléconsultation permet de réduire les contraintes liées au déplacement des patients et peut
être avantageux pour les personnes âgées ayant des difficultés à se déplacer pour pouvoir simplement
émettre un diagnostique
C'est ainsi qu'il serait intéressant de mettre en place une plate-forme qui va grandement améliorer
l'accessibilité médicale, particulièrement en région éloignée.
Pour cela, la révolution du web à travers la technologie WebRTC permet de faire de la

téléconsultation en utilisant les technologies du web

I.2.2. Problématique
Pendant longtemps, la consultation médicale s'est toujours faite en se déplaçant à l’hôpital ou à

domicile en faisant appel à un médecin. Aujourd'hui, nous assistons à une révolution technologique où il est
possible de le faire à distance et en temps réel, le médecin et le patient peuvent être en contact tout en étant
physiquement à des milliers de kilomètres l’un de l’autre d'où la téléconsultation.
Vous souffrez d'une maladie qui vous impose des déplacements réguliers à l’hôpital, vous habitez
dans une zone isolée où c'est difficile de vous rendre à chaque fois ; la téléconsultation est la solution idéale.
La téléconsultation permet d’améliorer la qualité de vie des patients, mais aussi de leur faciliter
l’accès aux soins.
Pour pallier à ces problèmes, j'ai effectué mon stage dans le Laboratoire de NGN et Applications
Mobiles où j'ai travaillé sur le projet qui s'intitule : Conception et Déploiement d'une plate-forme de
téléconsultation de dernière génération.
Ce projet consiste en la mise en œuvre d’une plate-forme de téléconsultation dans le but de poser un
diagnostic et d’initier un traitement à distance.
I.2.3. Objectifs et démarches à suivre
L'objectif principal de ce projet de mémoire est la mise en place d'une plate-forme de

téléconsultation en temps réel via le web en utilisant la technologie WebRTC.
Les démarches que nous suivrons consistera à :
 Maîtriser la technologie WebRTC, les protocoles, son fonctionnement, les architectures

etc.
 Maîtriser l’utilisation de ses API
 Etudier de manière détaillée les protocoles de signalisation supporté par le Web tels
que : SIP, XMPP et Websocket.
Chapitre II
II. Généralités sur la Télémédecine
II.1. Qu’est-ce que la Télémédecine ?
La télémédecine est une forme de pratique médicale à distance utilisant les technologies de
l’information et de la communication. Elle met en rapport, entre eux ou avec un patient, un ou
plusieurs professionnels de santé, parmi lesquels figure nécessairement un professionnel médical et, le
cas échéant, d’autres professionnels apportant leurs soins au patient.
Elle permet d'établir un diagnostic, d'assurer, pour un patient à risque, un suivi à visée
préventive ou un suivi post-thérapeutique, de requérir un avis spécialisé, de préparer une décision
thérapeutique, de prescrire des produits, de prescrire ou de réaliser des prestations ou des actes, ou
d'effectuer une surveillance de l'état des patients.
Les premières expériences de télémédecine datent de 1960, lors d’une expérience de

téléconsultation réalisée par le Nebraska Psychiatric Institute, expérience justifiée par l’isolement des
patients dans un Etat américain peu peuplé.
La télémédecine sera développée dans les années 1980, pour l’armée américaine, mais aussi à
destination de l’espace. C’est dans les années 1990 que se multiplient des projets d’envergure, avec le
concours et l’incitation de la Commission Européenne, jetant les bases de l’e-Santé dans les régions
européennes.
Les années 2000 consolident l’expérience acquise dans les différents secteurs de l’e-Santé, et
l’on peut penser que la décennie à venir concrétisera les développements et les réalisations de cette
discipline.
II.2. L’intérêt de le Télémédecine
Comme on peut le constater, la télémédecine n’est pas une nouvelle discipline médicale mais un
nouveau mode d’exercice de la médecine, pouvant s’appliquer à chacune des spécialités, dont l’objectif
est lors d’une prise en charge médicale, de minimiser les problèmes de distance entre différents
intervenants en faisant voyager les données médicales plutôt que les patients.
 Développer les soins à domicile

 Limiter les déplacements aux personnes âgés ou handicapés
 Faciliter l’accès aux soins dans les zones d’accès difficile
 Raccourcir les délais d’attente
 Apporter un soutien psychologique aux malades, de sorte à ce qu’ils ne se sentent plus
seuls face à leur maladie
 Faciliter la concertation entre médecins
II.2. Les composantes de la Télémédecine
 la téléconsultation : cette pratique de télémédecine permet à un professionnel médical de consulter un

patient à distance. Dans le cadre d’une téléconsultation, le patient peut avoir à ses côtés un
professionnel de santé assistant le professionnel à distance ainsi qu’un psychologue,
 la téléexpertise : cette pratique de télémédecine consiste, pour un professionnel médical, à solliciter

l’avis d’un ou de plusieurs professionnels médicaux experts à partir d’éléments du dossier médical du
patient,
 la télésurveillance médicale : cette pratique de télémédecine permet à un professionnel de santé

d’interpréter à distance les données nécessaires au suivi médical du patient pour prendre des
décisions sur sa prise en charge,
 la téléassistance médicale : cet acte qui relève de la télémédecine permet à un professionnel médical
d’assister à distance un autre professionnel au cours de la réalisation d’un acte,

II.3. Les dispositifs médicaux connectés
Aujourd'hui les technologies de l'information et les objets connectés permettent de réaliser des
consultations médicales à distance et de maintenir des patients à domicile. Il est possible grâce à ces
dispositifs médicaux connectés, que le médecin puisse poser un diagnostic à distance
II.3.1. Quelques dispositifs médicaux connectés et ses caractéristiques
Un dispositif médical (DM) est tout instrument, appareil, équipement, matière ou autre article, utilisé
seul ou en association, utilisé chez l'être humain pour le diagnostic, prévention, traitement d'une maladie,
d'une blessure ou d'un handicap, ou d'étude ou remplacement ou modification de l'anatomie ou
d'un processus physiologique.
Il est destiné par le fabricant à être utilisé chez l'être humain à des fins médicales et dont l'action
principale voulue n'est pas obtenue par des moyens pharmacologiques, immunologiques, métaboliques, mais
dont la fonction peut être assistée par de tels moyens.
II.3.2. Quelques dispositifs médicaux connectés et ses caractéristiques
 Thermomètre USB
Le thermomètre USB détecte l'humidité et la température de l'air et la mémorise internement. Ce

thermomètre USB en format réduit et une grande mémoire (jusqu'à un max. de 32000 valeurs / 16.000
valeurs par paramètre) sert surtout au registre prolongé des données (comptoirs réfrigérés des supermarchés,
transports réfrigérés, entrepôts, salles climatisé pour PC).
Le thermomètre USB fonctionne comme enregistreur de données autonome qui enregistre les valeurs
climatologiques dans les espaces de temps désirés. Ce thermomètre USB peut transmettre toutes les valeurs
à un ordinateur. Le registre du thermomètre USB peut s'activer manuellement. Il est aussi possible de
programmer préalablement le thermomètre USB (temps de début, fin, date et part de mesure) et le laisser
enregistrer in situ. Une fois les valeurs transmises, vous pourrez les analyser dans l'ordinateur.

De plus, le logiciel inclus dans la livraison du thermomètre USB calcule le point de rosée. L'horloge
interne avec date du thermomètre USB permet à l'usager d’attribuer avec précision les résultats. Une des
caractéristiques spéciales de ce thermomètre USB est l'alimentation par batterie lithium interne de longue
durée de 3,6 V. Selon l'usage, la durée de vie de cette batterie de thermomètre USB est d'environ un an
 Endoscope vidéo
La nouvelle génération - ultra-compacte avec la LED intégrée
- Poids réduit et mobilité améliorée

- Première portée ultra-compacte dans le monde
- Puissance élevée intégrée LED
- Technologie avancée d'image (AIT)
- Le meilleur rapport coût-performances
- Connexion d'USB directement
- Seulement un câble
- Aucune alimentation d'énergie de sept. n'a eu besoin
 Dermatoscope vidéo / à LED / de poche / USB
Le podologue et son patient peuvent voir les images en temps réel sur un ordinateur portable, une
tablette ou ordinateur de bureau. Une source de lumière externe n'est pas nécessaire à l'étude, car le
PodoScope intégrés de la lumière avec huit LED blanches lumineuses. Le PodoScope et son éclairage sont
alimentés via le port USB, de sorte que le PodoScope est toujours prêt et ne dépend pas de piles.
 STÉTHOSCOPE USB
Le nouveau stéthoscope PCP-USB se connecte via le port USB d'un PC, d'un MAC ou d'un appareil
mobile et crée un canal audio identifiable dans le périphérique.
 Convivial. Le patient, l'examinateur ou le professionnel de la santé, se branche dans le

stéthoscope à un port USB ou USB d'un PC ou d'une tablette Windows®.
 Pratique pour le clinicien. Seuls les écouteurs sont nécessaires. Des réglages de volume

faciles et des filtres audio sont inclus pour faciliter la qualité et la clarté du son.

 FDA approuvé. Contrairement à certains stéthoscopes téléphoniques sur le marché, les PCP-1 et

PCP-USB sont approuvés par la FDA pour transmettre des données sur Internet. Les deux sont
considérés comme des dispositifs médicaux de classe II par la Food and Drug Administration.
 Capacités de technologie vidéo. Ces stéthoscopes peuvent être déployés aux côtés de tout système de
vidéoconférence. Le stéthoscope PCP-USB n'a pas besoin d'une carte audio et, par conséquent,
fournit aux patients et aux cliniciens une interface vraiment simple et transparente.
II.4. Avantages et Inconvénients
II.4.1. Avantages
 Beaucoup de patients se sentent mal à l'aise d'aller à l'hôpital ou au cabinet médical. Ce système crée
une communication entre les patients et les professionnels de la santé qui maintiennent la commodité
et l'engagement. De plus, grâce à la télémédecine, les informations et les images médicales sont
gardées confidentielles et transférées en toute sécurité d'un endroit à l'autre. Ainsi, les gens peuvent
croire à ce système et se sentir à l'aise pour demander de l'aide.
 Cela permet d'économiser des vies dans les situations d'urgence, alors qu'il n'y a pas de temps pour
emmener le patient à l'hôpital.
 Dans de nombreuses communautés rurales ou dans des endroits éloignés ou post-catastrophe, des
soins de santé cohérents ne sont pas disponibles. La télémédecine peut être appliquée dans ces
endroits ou situations pour fournir des soins de santé d'urgence.
 Ce système est utile pour les patients résidant dans des zones inaccessibles ou des régions
isolées. Les patients peuvent recevoir des soins médicaux cliniques de leur domicile sans voyage
pénible à l'hôpital.
 Les innovations modernes de la technologie de l'information telles que la collaboration mobile ont
permis un partage et une discussion faciles d'informations sur les cas médicaux critiques chez les
professionnels de la santé de plusieurs endroits.
 La télémédecine a facilité la surveillance des patients grâce à une technologie informatique ou de

tablette ou de téléphone qui a réduit les visites ambulatoires. Maintenant, les médecins peuvent
vérifier la prescription ou superviser le contrôle des drogues. De plus, les patients domiciliés

peuvent demander de l'aide médicale sans passer à la clinique par ambulance. Ainsi, le coût des soins de
santé a été réduit.
 Ce système facilite également l'éducation à la santé, car le niveau primaire des professionnels de la
santé peut observer la procédure de travail des spécialistes des soins de santé dans leurs domaines
respectifs et les experts peuvent superviser les travaux du novice.
 La télémédecine élimine la possibilité de transmettre des maladies infectieuses entre les patients et
les professionnels de la santé.
II.4.2. Inconvénients
 Le coût global du système de télécommunication, en particulier les appareils de gestion de données

et la formation pratique des professionnels de la santé est génial.
 Le traitement clinique virtuel diminue l'interaction humaine entre les professionnels de la santé et les
patients qui augmentent le risque d'erreur dans les services cliniques, si le service est dispensé par un
professionnel inexpérimenté. En outre, des informations médicales confidentielles peuvent être
divulguées par un système électronique défectueux.
 La télémédecine pourrait prendre plus de temps pour les difficultés liées à la connexion de la

communication virtuelle en raison de la faible vitesse de l'Internet ou du problème du serveur. En
outre, ce système ne peut pas fournir un traitement immédiat, par exemple des antibiotiques.
 La faible qualité des enregistrements informatiques de la santé, comme les radiographies ou d'autres
images, les rapports de progrès clinique, etc. courent le risque d'un traitement clinique défectueux.
 Le système de télémédecine nécessite une réglementation légale difficile pour prévenir les

fournisseurs de services non autorisés et illégaux dans ce secteur.

Chapitre III
III. Présentation de WebRTC
III.1. Définition et Principes de la WebRTC
III.1.1. Définition
La WebRTC est une technologie permettant de faire de la communication en temps réel entre les
navigateurs Web en mode peer-to-peer. Elle permet aux applications telles que les appels vocaux, vidéos,
chat, de même que les applications liées au partage des fichiers et à la visioconférence de se faire à travers
un navigateur en temps réel sans passer par des protocoles propriétaires et sans nécessité de plugins, de
téléchargement, ou d’installation.
Elle est une initiative de RTCWeb qui vise à intégrer dans les navigateurs de communications en
temps-réel. Il est en effet l’implémentation d’un standard ouvert préparé par IETF au sein du groupe de
travail RTCWeb Working Group.
Pour permettre à ces applications de s’exécuter, le standard WebRTC met en œuvre trois API :
 MediaStream (aka getUserMedia)

 RTCPeerConnection
 RTCDataChannel
C’est grâce à ces API que la technologie WebRTC arrive à exécuter ses applications web que nous
verrons de manière plus détaillée dans le chapitre suivant.
III.1.2. Principes
WebRTC est un Framework open source (libre) pour le web pouvant activer de communication en
temps réel dans un navigateur. Pour cela, il inclut les bases de conception fondamentales pour des
communications de hautes qualités sur le web ; sur les réseaux de même que des composants audio et
vidéo utilisés dans les applications de visioconférence. Ces composants, quand ils sont implémentés dans
un navigateur peuvent être utilisés via une API JavaScript, ce qui facilite l’implémentation des
applications WebRTC.

Ainsi, beaucoup d’applications et de services web utilisent déjà des fonctionnalités RTC, mais ces
derniers ont besoin de faire des téléchargements, d’installer des applications natives ou des plugins. Il
s’agit notamment de Skype, Facebook (Facebook Messenger) et Google Hangouts (Google Talk plugin).
Or le téléchargement, l’installation et la mise à jour des plugins peuvent s’avérer complexes, sujets aux
erreurs.
Cependant, ces plugins peuvent être difficiles à déployer, déboguer, dépanner, tester et à maintenir.
Ils peuvent exiger des licences et l’intégration de technologies souvent complexes et coûteuses.
La WebRTC est supportée par quelques navigateurs, c’est-à-dire que cette dernière est implémentée
dans ces navigateurs. Il s’agit notamment de : Chrome25, Mozilla, Opera, Aurora.
III.2. Architecture générale de WebRTC
WebRTC offre aux développeurs d’applications web la possibilité d’écrire des applications riches
en multimédia en temps réel (chat, partage de fichiers, visioconférence), sur le web sans nécessiter de
plugins, de téléchargements ou d’installation. Le but de WebRTC est d’aider à construire une solide plate-
forme RTC qui fonctionne sur plusieurs navigateurs web à travers de multiples plateformes.
Cependant, l’architecture générale de WebRTC est la suivante :
Figure II.1: Architecture des primitives WebRTC(5)

L’architecture WebRTC est organisée en plusieurs couches :
 WebRTC C++ natif API
Cette couche est une API qui permet aux fabricants de navigateurs d’implémenter facilement les
composants web pour les communications audio/vidéos proposés par les API web.
 Session management
Cette couche est nécessaire à l’établissement de session entre instances de navigateurs. Elle
communique avec les couches Transport, Vidéo Engine et Voice Engine.
 Session/Transport
Cette couche est responsable du transport des messages de signalisation et des flux échangés entre
deux instances. Cette couche est constituée de trois composantes :
- Stack RTP
Une pile réseau pour le protocole RTP, protocole de transport en temps réel
- STUN/ICE
C’est un composant qui permet d’utiliser les mécanismes STUN et ICE pour établir des connexions
entre différents types de réseaux (utilisé pour régler les problèmes de traversée de NAT)
 La couche Voice Engine
C’est un framework qui gère les codecs audio pris en compte par la carte son. Elle supporte les
codes iLBC, iSAC, opus
- NetEQ
C’est un tampon de gigue dynamique et un algorithme de masquage d’erreur utilisé pour réduire
les effets négatifs de la gigue réseau et la perte de paquets. Il maintient la latence la plus faible possible
tout en conservant la meilleure qualité vocale.
- Acoustic Echo Canceler (AEC)

Le suppresseur d’écho est un logiciel à base de composants de traitement de signal qui supprime, en
temps réel, l’écho acoustique résultant de la voix étant jouée entrée dans le microphone actif.

 Noise Reduction
C’est un composant du traitement de signal permettant de supprimer certains types de bruits de
fond du signal.
 La couche Video Engine
C’est un support pour la chaîne vidéo, à partir de la caméra sur le réseau, et à partir du réseau à
l’écran. Cette couche prend en compte les codecs vidéos tels que : VP8, Jitter Buffer Vidéo, et un
composant servant à l’amélioration d’images.
III.3. Fonctionnement
Le fonctionnement de la technologie WebRTC prend en compte 3 entités respectives que sont ;

l’architecture, la signalisation et la traversée de NAT.
III.3.1. Architecture de fonctionnement
Figure II.2: Architecture de Fonctionnement de WebRTC

L’objectif de la WebRTC est de permettre à une application JavaScript de s’exécuter dans un

navigateur standard afin qu’il puisse établir une communication en temps-réel audio et vidéo. Une
application peut utiliser un protocole de signalisation basé sur le WebSockets, et aussi les primitives RTC
pour capturer les flux audio et vidéo de la webcam, les encoder et les transmettre au correspondant.
En effet, cette figure montre que l’accès à une application WebRTC se fait selon les étapes
suivantes :
o L’accès aux ressources médias (Microphone, Webcam etc) par l’intermédiaire de l’API
GetUserMédia ;
o La transmission de ces flux dans le réseau grâce à l’API PeerConnection ;
o La liaison bidirectionnelle entre le client (Navigateur) et le serveur maintenue grâce au

protocole WebSockets.
III.3.2. La signalisation
WebRTC utilise RTCPeerConnection pour communiquer des données en continu entre les
navigateurs (aka pairs), mais il faut aussi un mécanisme pour coordonner la communication et pour envoyer
des messages de contrôle, un processus connu sous le nom de signalisation. Or ces méthodes et protocoles
de signalisation ne sont pas spécifiés par WebRTC c’est-à-dire que la signalisation n’en fait pas partie de
l’API RTCPeerConnection. (4)
En effet, les développeurs d’application WebRTC peuvent choisir n’importe quel protocole de
messagerie qu’ils préfèrent, tels que SIP, XMPP, WebSocket, et toute autre duplex approprié (dans le deux
sens) canal de communication. Nous verrons ces protocoles dans la partie signalisation de ce chapitre.
L’architecture suivante explique réellement l’établissement de session en utilisant le protocole JSEP

(Protocole JavaScript Etablissement de Session).
Figure II.3: Etablissement d’une session peer-to-peer entre deux navigateurs
L’établissement d’une session entre deux navigateurs se fait selon les phases principales suivantes:
 D’abord, l’acquisition des ressources audio/vidéo dans le navigateur de l’émetteur par

l’utilisation de l’API GetUserMedia ;
 Ensuite, la transmission de ces flux sur le réseau et le rendre sur le navigateur du récepteur
grâce à l’API PeerConnection ;
 Et enfin, le rendu sur le navigateur du récepteur.
Il est à noter qu’une fois la signalisation établie entre les navigateurs, les flux multimédias passent
directement entre ceux-ci. Ainsi, pour atteindre ce but, nous utiliseront deux principales API WebRTC :
 MediaStream : manipule les ressources multimédias

 PeerConnection : assure la communication à travers le réseau
En résumé, l’API WebRTC permet : ()
 D’obtenir le streaming audio, video ou autres données ;

 D’obtenir des informations réseaux telles que l’adresse IP et le port d’échange avec d’autres
clients WebRTC(connu sous le nom de pairs ou peers) ;
 De coordonner la communication de signalisation pour signaler les erreurs et lancer ou
fermer les sessions ;
 D’échanger des informations sur les médias et la capacité du client, telles que la résolution et
les codecs ;
 De diffuser le streaming audio, video ou de données.
Cependant, deux problèmes majeurs ont été relevés par les développeurs d’applications
WebRTC :
 La gestion de la signalisation laissée à l’appréciation du développeur parce que WebRTC ne

spécifie pas un protocole ;
 Le problème de traversée de NAT commun à toutes les applications TOIP quand elles se trouvent
derrière un routeur NAT. C’est-à-dire que si les deux clients se trouvent deriière un routeur NAT,
la signalisation passe mais les flux média ne passeront pas
III.3.3. Traversée de NAT
L’un des problèmes importants liés aux protocoles de signalisation au niveau du filtrage des flux.
Avant, les entreprises utilisaient des mécanismes de translation d’adresse (NAT), incompatibles avec les
flux multimédias. Raison pour laquelle, les boîtiers NAT et les pare-feux imposèrent les trois verrous
suivant à la traversée des flux ToIP :
 Les protocoles de signalisation pour la ToIP standard, à l’instar de H.323, SIP et MGCP,
annoncent l’adresse IP des correspondants à l’intérieur des messages qu’ils envoient. Or si ces
adresses IP sont privées, elles ne sont pas exploitables en dehors du réseau local déployant le
NAT ;
 Un boîtier NAT n’effectue pas la correspondance d’une adresse IP locale privée avec une
adresse IP publique correspondante que si le terminal local effectue une connexion réseau. Par
conséquent, si un terminal distant tente de joindre le terminal derrière le NAT, aucune règle
n’est ajoutée dans le boîtier NAT, et le correspondant derrière le NAT est injoignable. Il peut
émettre un appel, mais n’en recevra pas ;
 Les ports utilisés dans le canal de données sont négociés dynamiquement dans le canal de
contrôle par les protocoles de signalisation. Un pare-feu ne peut donc statiquement pas ouvrir
les ports du canal de données puisque ces choix sont imprévisibles.
Pour pallier ce problème de traversée de NAT, il va falloir passer par l’intermédiaire d’un serveur
STUN, TURN ou ICE que nous verrons dans le point suivant.
Figure II.4: Traversée de NAT par un serveur STUN (4)
III.3.3.1. Le protocole STUN
STUN est un protocole destiné à la traversée des routeurs NAT. il permet d’établir des connexions
d’un poste, qui est situé derrière des routeurs NAT de découvrir son adresse IP publique ainsi que le type
de routeur NAT derrière lequel il est. Ces informations sont utilisées pour échanger correctement des
données UDP avec l’extérieur d’un réseau NATé. Pour ce faire, le poste situé en réseau privé émet des
requêtes vers le serveur STUN public. Le serveur STUN renvoie l’adresse publique et le port du routeur
NAT associé au réseau privé du poste. Il permet également aux terminaux de détecter dynamiquement le
type de NAT qui leur est appliqué.
L’idée de base du protocole STUN consiste pour un client à demander l’adresse IP publique à un
serveur externe comme l’illustre la figure suivante. En connaissant cette adresse, l’application peut
reporter l’information dans ces messages.
Figure II.5: Demande et Réponse entre un client et un serveur STUN
Le protocole STUN est un modèle client-serveur qui distingue deux catégories d’éléments :
 Client STUN : entité qui émet des requêtes STUN, et qui doit se trouver dans un domaine privé. Le client
STUN est implémenté au sein d’une application devant traiter et envoyer des données dont le contenu (hors
en-tête) comporte des adresses IP. C’est généralement le terminal de l’utilisateur qui a ce besoin, mais il peut
aussi s’agir d’un terminal quelconque ;
 Le serveur STUN : entité qui reçoit et répond aux requêtes STUN. Pour exécuter correctement sa fonction, le
serveur STUN doit se trouver à l’extérieur du réseau privé, généralement dans le réseau internet ;
Le protocole STUN est standardisé, ce qui en fait une méthode privilégiée pour garantir aux
applications la meilleure compatibilité possible. Son coût est modique, puisqu’il ne nécessite que l’ajout
d’un serveur placé à une position stratégique. Le serveur reçoit des demandes brèves et y répond de façon
analogique, ce qui en fait une entité faiblement sollicitée par chaque utilisateur.
Cette opération n’est toutefois pas transparente pour l’utilisateur, puisque les applications doivent
prendre en compte ce mécanisme dans les échanges qu’elles établissent.
Il est à noter que la méthode STUN, ne s’applique pas au NAT symétrique. En effet, la translation
d’adresses dépend également de la destination des messages envoyés. En utilisant le protocole STUN,
l’appelant contacte un serveur STUN et est vu par ce dernier avec une adresse IP qui peut être différente
de celle que l’appelant utilisera plus tard pour contacter son véritable destinataire. Autrement dit, le
serveur STUN retourne des informations d’adressage qui ne sont factuelles que pour lui et erronées pour
tout autre correspondant. Le NAT symétrique lui échappe donc. C’est pour résoudre ce problème que la
méthode TURN a été introduite.
III.3.3.2. Le protocole TURN
TURN se base sur le protocole STUN par exemple pour le partage de clé cryptographie et
l’authentification du serveur et du client. C’est–à-dire que dans la pratique, les clients partagent avec le
serveur un secret permettant de les authentifier. Lors de l’envoi de données, les clients émettent une
requête sécurisée par TLS. Là encore, la communication doit être initiée par le terminal local au
mécanisme de NAT. Dès lors, l’utilisateur ne peut communiquer qu’avec un seul correspondant distant en
passant par le serveur TURN.
Le protocole TURN est soumis à l’IETF en octobre 2003, avec une révision en juillet 2004, il a été
conçu pour les restrictions posées par la méthode STUN et permet aux utilisateurs qui se trouvent derrière
un réseau avec NAT ou derrière un pare-feu de communiquer quelle que soit la forme de NAT qui leur est
appliquée.
Tout comme pour STUN, l’idée est de disposer d’un serveur à l’extérieur du réseau natté, mais,
contrairement à STUN, le serveur ne se contente pas d’informer le client sous la forme de NAT qui lui est
appliquée. Il joue un rôle beaucoup plus actif et participe à l’acheminement des données en tant que relais.
Un client qui souhaite établir une communication avec un correspondant doit envoyer toutes ses requêtes et
données vers le serveur STUN, les transmet ensuite au correspondant.
III.3.3.3. La plateforme ICE
ICE par contre n’est pas un protocole, mais une méthodologie pour le passage des flux qui sont
soumis à des translations d’adresses. Elle prescrit l’utilisation des protocoles STUN et TURN et fournit un
cadre d’application au cas par cas. Cependant il est en étude sous forme de draft IETF.
III.4. Signalisation
III.4.1. Définition
La signalisation désigne un ensemble de signaux nécessaire à l’établissement et la supervision des

communications. C’est un ensemble de messages de services échangés entre les commutateurs de réseau
ou entre ceux-ci et les équipements des utilisateurs, qui sont nécessaires à l’établissement et à la gestion
des communications. Ces messages portent sur l’état des liaisons du réseau et sur la nature des
équipements des utilisateurs. Elle concerne tous les échanges d’informations nécessaires pour la fermeture
et la maintenance d’un service de télécommunication.
La signalisation est utilisée pour échanger trois types d’informations :
 Les messages de contrôle de session : pour initier ou fermer la communication et signaler

les erreurs ;
 La configuration réseau : ici, il est question de savoir quelle est l’adresse IP et le port du
service ?
 Les capacités des médias : là encore, il s’agit de déterminer quels codecs et quelles
résolutions peuvent être supportées par mon navigateur et le navigateur qu’il souhaite
communiquer avec le mien ?
La signalisation comprend les signaux requis pour la gestion des connexions :
 Etablissement ;
 Contrôle de facturation ;
 Supervision et maintenance.
Cependant, la signalisation est le mécanisme par lequel les paires envoient des messages de contrôle
à chacun dans le but d’établir le protocole de communication, le canal et la méthode. Mais ceux-ci ne sont
spécifiés dans le standard WebRTC. C’est-à-dire que dans le cas de la technologie WebRTC, aucun
protocole requis n’est défini. Alors le développeur peut choisir n’importe quel type de protocole de
message (comme SIP, XMPP/Jingle), et n’importe quel type de canal de communication duplex (comme
WebSocket ou XMLHTTPRequest).
Cependant nous allons nous consacrer à l’étude des protocoles de signalisations supportées par le
Standard WebRTC.
III.4.2. Protocoles de Signalisation
Dans le standard WebRTC, aucun protocole de signalisation n’est spécifié. Cependant, il est laissé
à l’appréciation des développeurs de choisir parmi les protocoles de messagerie (comme SIP, XMPP), où
de n’importe quel canal de communication duplex tel que WebSocket etc.
III.4.2.1. SIP
SIP est un protocole de signalisation défini par l’IETF permettant l’établissement, la libération et la
modification de sessions multimédias. Il hérite de certaines fonctionnalités des protocoles http (Hyper Text
Transport Protocol) utilisées pour naviguer sur le Web, et SMTP (Simple Mail Transport Protocol) utilisé
pour transmettre des messages électroniques.
Le protocole SIP n’est qu’un protocole de signalisation. Une fois la session établie, les participants
de la session s’échangent directement leur trafic audio/vidéo à travers le protocole RTP (Real-Time
Transport Protocol) et RTCP (Real-Time Control Protocol). Hormis le transport de la voix, le protocole
SIP est utilisé dans la visioconférence, la messagerie instantanée et les jeux vidéo.
Par ailleurs, SIP n’est pas un protocole de réservation de ressource, il ne peut donc pas assurer la
QoS. Il s’agit d’un protocole de contrôle d’appel et non d’un contrôle du média. SIP n’est pas non plus un
protocole de transfert de fichier tel que http, utilisé afin de transporter de grands volumes de données. Il a
été conçu pour transmettre des messages de signalisation courts afin d’établir, maintenir et libérer des
sessions multimédia. Des messages courts non relatifs à un appel peuvent néanmoins être transportés par
SIP de la même manière que les SMS.
III.4.2.2. XMPP
XMPP est un ensemble de protocoles standard ouverts de l’IETF pour la messagerie instantanée.
XMPP est également un système de collaboration en quasi-temps-réel et d’échange multimédia via le
protocole Jingle, dont la voix sur IP (Téléphonie sur Internet), la visioconférence et l’échange de fichiers
sont d’exemples d’applications. Il est basé sur une architecture client-serveur permettant des échanges de
messages instantanés.
Ce protocole hérite directement du protocole de messagerie Jabber qui a la vocation initiale de

proposer des fonctionnalités d’échange de messages instantanés et de notification de présence, ou plus
généralement d’un statut, entre les utilisateurs connectés au service. Il s'agit d'un protocole client-serveur à
authentification. Le trafic est transporté par TCP sur les ports standards 5222 entre le client et le serveur et
5269 entre serveurs. XMPP est un protocole décentralisé. Les flux sont chiffrés par TLS/SASL.
Chaque utilisateur est identifié par un identifiant unique nommé JID (Jabber ID). Le JID se
construit sous la forme :
[nœud "@" ] domaine_xmpp [ "/" ressource]
exemple : josue@rtn.sn/Bureau
Le nœud et la ressource sont des éléments facultatifs. Évidemment, il n'est pas aisé de
communiquer avec josue du domaine rtn.sn si l'on omet de spécifier le nœud. La ressource permet
d'envoyer un message à une destination choisie si le correspondant est connecté plusieurs fois avec le
même identifiant de domaine.
Exemple : josue@rtn./Bureau et allier@rtn.sn/Maison
Dans le cas où la ressource n'est pas spécifiée, le message sera délivré à la connexion de plus haute
priorité, propriété de la connexion au moment de son établissement, d'une valeur choisie par le client.
Le domaine est un domaine XMPP. Il s'agit en pratique d'un FQDN qui sera résolu par des
enregistrements de type SRV du DNS. Une adresse IP est aussi acceptée. Un même domaine XMPP peut
ainsi être géré par plusieurs serveurs, tout comme un serveur peut bien sûr gérer plusieurs domaines
XMPP.
III.4.2.3. WebSocket
Le protocole WebSocket est un mécanisme pour les applications Web, qui nécessite une
communication bidirectionnelle avec le serveur, et qui ne repose pas sur plusieurs connexions http
(utilisation de XMLHTTPRequest, d’iframe, ou de long polling).
Ils sont disponible sur les dernières versions de navigateurs les plus connus tels que Firefox,
Google Chrome, Opera et Safari.
L’API WebSocket est donc développée par le W3C (le 20 Septembre 2012), pour créer une
instance de WebSocket, le seul argument que nous devons fournir est l’URL du serveur avec lequel nous
souhaitons établir une liaison. Elle commence obligatoirement par ws:// ou wss:// pour une connexion
sécurisée.
Les attributs fonctionnels permettant de gérer les évènements sont :
 onopen : ouverture d’une WebSocket ;

 onmessage : réception d’un message ;
 onerror : erreur(s) survenue(s);
 onclose : fermeture de WebSocket.
Cependant, les messages envoyés par le serveur sont notifiés par l’évènement onmessage
contenant le message du serveur sous forme de chaîne. Les évènements onerror, onopen et onclose
permettent de suivre en temps réel l’état de la connexion.
Les WebSocket fournissent deux méthodes :
 send (data_string) pour envoyer un message au serveur ;
 close () pour fermer le socket.
Ainsi, une fois la connexion établie en mode WebSocket, les données peuvent être envoyées et
reçues entre le client et le serveur en mode full duplex.
III.5. Description de session SDP
SDP est destiné à la description des sessions multimédia pour les annonces de session, l’invitation
à une session, et d’autres formes d’initiation de session multimédia. SDP est un protocole de description
de session pour les sessions multimédia. Un mode d’utilisation courant est celui qui permet à un client
d’annoncer une session de conférence en multidiffusion périodiquement et un paquet d’annonces à des
adresses et ports en multidiffusion bien connus en utilisant le protocole d’annonce de session.
L’objectif de SDP est de convoyer des informations sur les flux de support dans les sessions
multimédia pour permettre aux receveurs d’une description de session de participer à la session. SDP est
principalement destiné en inter réseau, bien qu’il soit suffisamment généreux pour pouvoir décrire des
conférences dans d’autres environnements de réseau.
SDP inclut:
 le nom et l’objet de la session ;

 L’heure où les heures à laquelle ou auxquelles la session est active ;
 le support comprenant la session ;

 les informations pour recevoir ces supports (adresses, ports, formats, etc).
Puisque les ressources nécessaires à la participation à une session peuvent être limitées, certaines
informations supplémentaires peuvent être aussi souhaitables :
 Des informations sur la Bande passante à utiliser par conférences ;

 Des informations de contact pour la personne responsable de session. En générale SDP doit
convoyer des informations suffisantes pour être capable de se joindre à une session (avec
l’exception possible des clés de chiffrement) et pour annoncer les ressources à utiliser que des non-
participants peuvent avoir besoin de connaître.
SDP inclut des informations sur le support :

 Le type de support (vidéo, audio, etc) ;
 Protocole de transport (RTP/UDP/IP, H320, etc) ;
 Le format de support (vidéo, H261, audio, MPEG, etc).

Pour une session IP en multidiffusion sont aussi envoyés :
 L’adresse de multidiffusion pour le support ;

 Le port de transport pour le support ;
Ces adresses et ports sont l’adresse et le port de destination du flux multidiffusion, qu’il soit
envoyé, reçu ou les deux.
Pour une session en monodiffusion, sont envoyés :
 L’adresse distante pour le support ;

 Le port de transport pour l’adresse de contact.
La session description protocole (SDP) est un format de description des médias en streaming
paramètres d’initialisation. SDP est destiné à la description multimédia de session de communication aux
fins d’annoncer la session, d’invitation à une session, et de négocier de paramètres. SDP ne fournit pas les
médias lui-même mais il est utilisé pour la négociation entre les points d’extrémités du type de support, le
format, et toutes les propriétés associées. L’ensemble des propriétés et les paramètres sont souvent appelés
profil de session.
SDP a commencé comme une composante d’annonce de session protocole (SAP), mais à trouver
d’autres utilisations en fonction avec le RTP (temps réel transport protocole), en temps réel Streaming
Protocole (RTSP), session initiation protocole (SIP) et même comme un format autonome pour décrire
multicast session.
III.6. Protocoles de transport (SRTP, RTP, RTCP)
Avec quel protocole transporter les flux de ToIP et plus généralement tous les flux multimédias,
soumis à des contraintes temporelles particulièrement fortes dans les réseaux IP ? Le protocole TCP exige
de nombreuses procédures de contrôle, qui le rendent peu adapté au transport des données multimédias
avec de fortes contraintes de délai. À l’inverse, le protocole UDP ne propose aucun mécanisme de
contrôle, ce qui ne le qualifie guère pour le traitement des données multimédias.
Le protocole TCP est donc inadapté au temps réel, puis que tous les contrôles qu'il met en place
pour le transport des paquets pénalisent ses délais de transmission. La contrainte de fiabilité n'étant pas
compatible avec la contrainte de délai imposée par la ToIP. TCP, n'est donc pas un bon protocole pour les
transferts de type temps réel.

Le protocole UDP ne comporte que des fonctionnalités de transport pur, sans aucun mécanisme de
contrôle. L’adressage des données avec les ports de communication utilisés est sa seule fonction
fondamentale. C’est un atout par rapport aux éléments contraignants mentionnés pour le protocole TCP.
UDP notamment plus rapide que ne l’est TCP. Donc il est bon pour la communication en temps réel.
Des deux protocoles candidats au transport des données multimédias, l’un est « trop complet » et
l’autre est trop limité. Il est cependant possible de partir du protocole UDP et de lui ajouter des
fonctionnalités d’ordonnancement. Le protocole RTP a été proposé à cette seule fin de reconstitution de
l’ordre du flux d’origine. Pour sa part, RTCP a été conçu pour offrir une vision de l’état du réseau et
permettre à une application d’adapter les flux en conséquence.
Les protocoles RTP et RTCP
Comme indiqué précédemment, le couple de protocoles RTP/RTCP a été conçu dans le but
d’enrichir les fonctions d’UDP et de fournir à ce dernier ce dont il a besoin pour gérer efficacement les
données multimédias temps réel. Aujourd’hui, ce couple s’utilise systématiquement dans les applications
multimédias interactives, à la fois pour la téléphonie, la vidéo, les jeux vidéo et la réalité virtuelle.
RTP (Real-time Transport Protocol)
RTP est utilisé pour le transport de bout en bout de flux ayant des contraintes temporelles fortes,
typiquement pour les flux multimédias avec interactivité, tel le service de téléphonie sur IP.
Initialement, RTP était conçu pour un environnement multicast, dans lequel un émetteur diffuse
son contenu vers plusieurs récepteurs en parallèle. Le cas d’un flux unicast, dans lequel un émetteur
n’émet que pour un unique récepteur, n’est qu’un cas particulier et plus simple d’application multicast.
RTP assure un contrôle spécifique des données temps réel. Il permet de reconstituer les propriétés temps
réel des flux médias en opérant sur deux niveaux, la synchronisation des flux d’un côté et la reconstitution
de l’ordre des paquets émis et la détection des pertes de paquets de l’autre :

 Synchronisation des flux. Si l’audio et la vidéo sont transmis séparément, le destinataire doit jouer la séquence
audio de façon à ce que cette dernière coïncide avec la séquence vidéo. Pour cela, RTP ajoute aux paquets
émis une estampille de date, appelée horodatage, ou timestamp.
Cette estampille indique le moment pendant lequel le paquet a été émis, ce qui permet de reproduire les
mêmes délais inter paquet et de jouer les paquets audio et vidéo de manière synchronisée ;
 Reconstitution de l’ordre des paquets émis et détection des pertes de paquets. Les paquets IP sont transmis
indépendamment les uns des autres. En conséquence, leur ordre d’arrivée chez le destinataire n’est pas
forcément conforme à leur ordre d’émission.
RTCP (Real-time Transport Control Protocol)
Décrit dans la RFC 3550, RTCP est un protocole de contrôle et de supervision du réseau. Il opère
comme une sonde qui rend compte aux émetteurs des performances dont la communication en cours
bénéficie. Son objectif est d’offrir aux participants d’une session une vision sur l’état du réseau et de s’y
adapter de façon dynamique. Il fournit de ce fait un rapport sur la qualité de distribution, incluant le délai
de bout en bout, la gigue et le taux de pertes. Ce rapport est envoyé de façon périodique afin que les
intervenants puissent disposer d’une mise à jour fréquente de l’état du réseau.
Par exemple, si un utilisateur fait de la téléphonie et que, par le biais du protocole RTCP, son
correspondant lui envoie des rapports signalant un fort taux de perte de paquets, il peut considérer que le
codec qu’il utilise est trop gourmand pour être supporté dans les conditions actuelles du réseau. Il peut dès
lors sélectionner un codec de qualité plus fiable mais nécessitant moins de ressources.
Dans sa spécification, RTCP n’est aucunement indispensable pour le fonctionnement de RTP.

Néanmoins, leur association apporte une cohérence globale dans le traitement des communications
multimédias. Tous deux doivent être pensés et intégrés au niveau applicatif. Les rapports fournis par
RTCP peuvent optimiser la qualité de la transmission.

SRTP
SRTP a été conçu par Cisco et Ericsson. Il a été publié en mars 2004 par IETF dans la RFC 3711. Ce
protocole est une extension de RTP (Protocole de Transport en temps réel) qui intègre des fonctions de
sécurité. Tout comme RTP, SRTP est destiné VoIP (Voice over IP). Il est destiné à fournir le cryptage, le
chiffrement, l’authentification et l’intégrité de messages et la protection dans la relecture des données
RTP dans les deux unicast et multicast.
III.7. Codecs
Cependant, le tableau ci-dessous fait une comparaison entre les différents entités et codecs mis en jeu.
Tableau II.1 : Comparaison des codecs classiques et WebRTC
VoIP Classique WebRTC
Protocoles de SIP/H323 Non définie

Signalisation
Protocoles de RTP/RTCP RTP/RTCP

Transport des Médias
Sécurité SRTP dans SIP SRTP

H.335 dans H.323
Traversée de NAT STUN/TURN/ICE dans SIP STUN/TURN/ICE

H.450.X dans H.323
Codecs Vidéo H.263, H.264 VP8
Codecs Audio La série des codecs G.7xx G.711, ilBC, ISAC

III.1. Les APIs?
III.1. Qu’est-ce-qu’une API?
Une API (Application Programming Interface) est un ensemble de classes et de méthodes ou des
fonctions normalisés qui sert de façade par laquelle un logiciel offre de services à d’autres logiciels. Elle
est souvent 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 de
programme fournisseur.
Ainsi, dans le cas de WebRTC, les API suivants tels que MediaStream, PeerConnection et
RTCDataChannel sont intégrés dans le navigateur. Cependant, l’étude de ces API s’avère nécessaire pour
l’implémentation ou la conception d’une application Web.
III.2. API MediaStream (Aka GetUSerMedia)
L’API MediaStream permet de contrôler les différentes interfaces de périphériques multimédia du

terminal (microphone, haut-parleur, camera, etc) et de capturer les flux multimédia. Le Stream API, et en
particulier son objet MediaStream est au cœur de WebRTC. Toute la partie multimédia passe par elle,
quelles que soient la source et la destination du trafic. La figure suivante illustre l’acquisition des flux
multimédia par l’API MediaStream.
Figure III.1:Traitement des flux audio et vidéo par GetUserMedia
Un flux média (MediaStream) contient et traite les pistes audio et vidéo. Ces flux peuvent provenir
de différentes sources (locales ou distantes) et sont émis à des destinations variables (locales ou distantes
également). Au sein de cette interface, seul l’objet MediaStream reste immuable quelle que soit le cas de
figure considéré. Les différentes étapes illustrées sur la figure ci-dessus sont les suivantes :

1. Construction de l’objet MediaStream
L’objet MediaStream prend en paramètre soit une connexion distante (PeerConnection, voir ci-
après), soit un objet LocalMediaStream ayant accès aux ressources locales du terminal. Pour des raisons
de sécurité, ces accès sont explicitement donnés par l’utilisateur via l’usage de bouton (Par exemple
diffuser ma vidéo). La fonction GetUserMedia () récupère simultanément ou séparément (il est possible
d’appeler plusieurs fois), les différentes sources afin de les traiter par la suite.
2. Sources Locales
Ces sources peuvent émaner de différentes origines, notamment d’équipements de capture en temps
réel (microphone, webcam, camera, …) ou de fichiers locaux au terminal. Le support de ces différentes
sources est assuré grâce aux nouvelles fonctionnalités offertes par HTML5 (File API Media Capture)
3. Gestion de différent flux
Un MediaStreamTrack est créé pour chacun des flux, audio, vidéo. S’il existe plusieurs flux
simultanés, ceux-ci sont stocker au sein de type MediaStreamTrackList. Ces listes sont utilisées pour créer
le flux média.
Grâce à ces listes, l’objet MediaStream est dynamique. Il devient en effet possible d’ajouter et de
retirer à la volée des flux multimédia sans avoir besoin de recréer un nouvel objet (fonction add () de
l’objet MediaStreamTrackList).
Les pistes audio peuvent contenir un nombre de variables de canaux (mono, stéréo, 5.1 …)
permettant leur utilisation dans des multiples situations. Ces canaux sont les plus petites unités d’un
MediaStream.
4. Utilisation du MediaStream
Cet objet MediaStream peut ensuite être utilisé dans divers cas de figures :
 Le flux peut être directement affiché dans le navigateur local, ce qui peut servir à
afficher le retour d’une webcam locale ou le flux en provenance d’un tiers via un
objet PeerConnection en entrée ; -Les flux peuvent être enregistrés dans de fichiers
locaux ;

 Les flux peuvent être envoyés à un tiers à l’aide d’un objet PeerConnection ce qui
est l’objet défini de WebRTC.
Le schéma suivant illustre le fonctionnement de l’API MediaStream
La figure ci-dessus illustre un cas d’usage typique du fonctionnement de MediaStream. La

fonction getUserMedia() (1), déclenchée par un bouton, autorise l’accès aux différents équipements
(microphone, webcam …) (2) afin d’en récupérer les flux audio/vidéo.
Ces LocalMediaStream ou MediaStreamTrack sont traités par la fonction appelée (callback) en cas
de succès, afin de les ajouter aux MediaStreamTrackList d’un objet MediaStream, créant
effectivement le flux média. Celui-ci peut ensuite être ajouté à une connexion sortante
(4) PeerConnection afin de transmettre le flux à un destinataire.
La pratique veut que ces objets MediaStream disposent d’une URL pour l’objet binaire qu’elle
représente (BLOB ou Binary Large Object). La fonction CreateObjectURL crée cet URL. Les données
de l’objet que cet URL représente doivent être compréhensibles directement par les éléments HTML5
audio ou vidéo.

III.3. API PeerConnection
L’objet PeerConnection est primordial pour l’établissement d’une connexion de manière

transparente, entre deux entités RTCWeb. Définie au sein de la même spécifique que la Stream API, elle
risque d’être altérée en profondeur dans les mois à venir puisque l’IETF est entrain de définir un
framework d’établissement de session pour RTCWeb/WebRTC (JSEP ou JavaScript Session
Establissement Protocol actuellement en draft 00) qui aura un impact sur les routines de l’objet
PeerConnection.
L’objet PeerConnection gère l’ensemble de l’établissement de connexion avec la partie distante.

Comme décrit dans la figure ci-dessus, lors de sa création, il est possible de remarquer qu’il prend deux
paramètres qui traitent deux aspects bien distincts :
 Son premier paramètre spécifie un serveur STUN/TURN pour la traversée de NAT

des flux multimédias qui est systématiquement tentée par l’usage d’ICE ;
 Son second paramètre défini la fonction à appeler (callback) pour envoyer des
messages de signalisation. Il est dès lors possible de manipuler et de personnaliser
les messages envoyés au destinateur via cette fonction.
La signaling callback passée en second paramètre permet de générer les messages de signalisation,
nécessaires pour échanger les informations de connexion, grâce à SDP.
III.4. API Data Channel

Un canal de données (DataChannel) WebRTC permet d’envoyer des données texte ou binaire sur
une connexion active à un pair.
Ainsi que l’audio et la vidéo, WebRTC en charge la communication en temps réel pour les autres
types de données.
L’API de RTCDataChannel permet l’échange peer-to-peer de données arbitraires, avec une faible
latence et un débit élevé.
Il existe de nombreux cas d’utilisation potentiels pour l’API, y compris :
 Jeu de Gaming ;
 Application de bureau à distance ;
Conception et Déploiement d’une Plate-forme de Téléconsultation

 En temps réel le chat texte ;

 Le transfert de fichiers.
L’API à plusieurs fonctionnalités pour profiter au maximum de RTCPeerConnection et permettre

une communication puissante et flexible peer-to-peer :
 Tirer parti de la configuration de session RTCPeerConnection ;

 Canaux simultanés multiples avec des priorités ;
 Sémantique de livraison fiables et peu fiables ;
 La Sécurité intégrée (DTLS) et le contrôle de congestion ;
 Aptitude à utiliser avec ou sans audio ou vidéo.

Chapitre IV
IV. Analyse et Conception de la Plate-forme
IV.1. Architecture et Fonctionnement
Figure IV.1: Architecture de fonctionnement de l’application
La plate-forme de téléconsultation est mise en ligne quelque part sur internet et pour y accéder, il
faudrait d’abord avoir accès à ce réseau.
Cependant, chaque patient et médecin au système doivent s’authentifier avant d’y accéder à la
plate-forme. Une fois l’authentification réussie, les patients accèdent à la page d’accueil du système et
peut consulter un médecin à distance par vidéoconférence.

Ainsi, la figure ci-dessous montre comment un patient ou un médecin accède à la plateforme
IV.2. Choix des outils et technologies
IV.2.1. Les Langage de programmation
IV.2.1.1. UML
Le langage UML (Unified Modeling Language) est un langage de modélisation graphique qui
permet de modéliser des données. Il propose des outils de concept et de modélisation des systèmes
d’informations.
UML est utilisé pour spécifier, visualiser, modifier et construire les documents nécessaires au bon
développement d’un logiciel orienté objet. Il offre un standard de modélisation pour représenter
l’architecture logicielle.
Les différents éléments représentables sont :
 Activité d’un objet/logiciel

 Acteurs
 Processus
 Schéma de base de données
 Composants logiciels
 Réutilisations des composants
La modélisation proposée par le langage UML utilise divers types de diagrammes spécifiques
repartis en deux groupes suivants:

 Diagramme de composants
 Diagramme de paquetages
 Diagramme de déploiement
 Diagramme de Structure Composite
Comportement du système :
 Diagramme d’état de transition
 Diagramme d’activité
 Diagramme de séquence
 Diagramme de collaboration
 Diagramme de vue globale des interactions
 Diagramme de Temps
IV.2.1.2. HTML5/CSS3
HTML5 (HyperText Markup Language 5) est la cinquième version de HTML qui définit de
nombreuses nouvelles fonctionnalités pour les pages web notamment la construction des éléments
dynamiques et multimédia comme les balises audio et vidéo. Elle définit également les WebSockets
comme étant le nouveau protocole de transport pour la communication bidirectionnelle flux duplex entre
le serveur et le navigateur.
IV.2.1.3. JavaScript
JavaScript en abrégé JS est un langage de programmation de scripts principalement utilisé dans les
pages web interactives mais aussi coté serveur. Il est orienté objet à prototype, c’est-à-dire que les bases
du langage et ses principales interfaces sont fournies par des objets. Il permet aussi d’accentuer,
d’améliorer et d’enrichir la partie graphique de votre page HTML (Menu déroulant graphique, changement
de couleur …).

IV.2.2. Les Protocoles http et Websockets
IV.2.2.1. Le protocole http
HTTP est un protocole de communication client-serveur destiné pour le web. Il est situé au
niveau de la couche application du modèle OSI. Il peut fonctionner sur n’importe quelle connexion
fiable, dans les faits, on utilise le protocole TCP comme couche de transport et le serveur http écoute
les requêtes sur le port 80.
Les clients web les plus connus sont les navigateurs web permettant à un utilisateur d’accéder à
un serveur contenant les données.
Ainsi un client http envoie une requête au serveur qui à son tour envoie une réponse comme la
montre la figure ci-dessous :
Figure IV.3: Communication entre un navigateur et un serveur http
En effet, cette communication entre le navigateur et le serveur se fait en deux étapes :
 Le navigateur effectue une requête http.

 Le serveur traite la requête puis envoie une réponse http.

IV.2.2.2. Le protocole WebSockets
Les WebSockets constituent un élément essentiel pour les applications web, qui nécessite une
communication bidirectionnelle avec le serveur, et qui ne repose pas sur plusieurs connexions http. Ils
sont disponibles dans les dernières versions des navigateurs les plus connus tels que Firefox, Google
Chrome, Opera et Safira.
IV.2.3. La Base de données MongoDB
MongoDB (de l'anglais humongous qui peut être traduit par « énorme ») est un système de

gestion de base de données orientée documents, répartissable sur un nombre quelconque d'ordinateurs et
ne nécessitant pas de schéma prédéfini des données. Il est écrit en C++. Le serveur et les outils sont
distribués sous licence AGPL, les pilotes sous licence Apache et la documentation sous licence Creative
Commons2. Il fait partie de la mouvance NoSQL.
MongoDB permet de manipuler des objets structurés au format BSON (JSON binaire), sans

schéma prédéterminé. En d'autres termes, des clés peuvent être ajoutées à tout moment « à la volée »,
sans reconfiguration de la base.
Les données prennent la forme de documents enregistrés eux-mêmes dans des collections, une

collection contenant un nombre quelconque de documents. Les collections sont comparables aux tables,
et les documents aux enregistrements des bases de données relationnelles. Contrairement aux bases de
données relationnelles, les champs d'un enregistrement sont libres et peuvent être différents d'un
enregistrement à un autre au sein d'une même collection. Le seul champ commun et obligatoire est le
champ de clé principale ("id"). Par ailleurs, MongoDB ne permet ni les requêtes très complexes
standardisées, ni les JOIN, mais permet de programmer des requêtes spécifiques en JavaScript.

IV.3. Conception du Système
IV.3.1. Modélisation du système
IV.3.1.1. Etude de Cas
Soit un cabinet médical désirant offrir un service de téléconsultation à ses patients. Cependant, le
cabinet dispose d’une plateforme de téléconsultation.
Ainsi, l’administrateur peut démarrer l’application avant que les patients et les médecins y accèdent
via leurs navigateurs en tapant l’url de l’application.
Avant de se connecter le patient doit avoir un compte. Lors de connexion si l’authentification n’est
pas avérée, il a la possibilité de retaper son login et son mot de passe. Dans le cas il parvient à
s’authentifier, il peut y accéder pour faire la consultation à distance.
S’il veut passer un appel vidéo, alors il pourra entrer en contact avec un médecin disponible.
Une fois l’appel vidéo terminée, un patient peut se déconnecter de l’application. Puis
l’administrateur peut arrêter l’application.
Pour modéliser le système, nous allons suivre les différentes étapes qui suivent.
IV.3.1.2. Liste des acteurs
 Identification des acteurs
Acteurs principaux :
Utilisateur (Patient/Médecin) : s’authentifier, faire la consultation par vidéo

 Identificateurs des cas d’utilisation
 Démarrer le système
 Création compte
 Authentification
 Initialiser mot de passe
 Faire la consultation par vidéo
 Arrêter le système
Cependant, nous allons présenter le cas d’utilisation suivant
IV.3.1.3. Diagramme des cas d’utilisation

IV.3.2. Environnement de développement
IV.3.2.1. Présentation de Node.js
Node.js est une plateforme logicielle utilisée pour développer des applications web rapides et
évolutive coté serveur. Il utilise JavaScript comme langage de script. Node.js utilise un modèle non
bloquant piloté par les événements d’entrée/sortie qui le rend léger et efficace, idéal pour les applications
de données interactives en temps réel.
Cependant, il nous permet de développer très simplement des applications évolutives. Comment ?
En quelques mots : l’idée est d’utiliser des I/O non bloquantes pour gérer toutes les requêtes entrantes,
sortantes ainsi que tout le processus lié à la requête.
Node.js est un serveur dits non bloquants par ce qu’il n’utilise qu’un seul thread pour gérer les
requêtes entrantes. En outre, Node.js ne propose pas, dans ses API, des fonctions bloquantes. Puis toutes
les fonctions fournies par Node.js prennent en paramètre un callback. Une fois que la fonction aura
terminé son traitement, le callback sera appelé avec le résultat en paramètre et une éventuelle erreur.

Ainsi, pendant toute la durée du traitement, le thread sera relâché et pourra être donné à une autre
requête pour effectuer un autre traitement. Nous sommes donc face à un système évènementiel.
Et JavaScript est un très bon choix de langage du fait que l'on peut programmer de manière
fonctionnelle avec celui-ci. Les callbacks dans tous les sens, nous connaissons très bien avec des librairies
comme JQuery qui nous habituent depuis déjà quelques temps à ce type de développement. Contrairement
à ce que l’on peut penser, Node.js n’est pas un serveur HTTP au même titre qu’apache, nginx, lighthttpd
etc…
Node.js est juste un serveur, ce qui signifie qu’il peut se comporter comme un serveur web mais
qu’il n’est pas voué uniquement à ça, il est possible de répondre à toutes sortes de besoins client/serveur
(FTP, mail etc..) à partir du moment où vous lui donnez les bonnes instructions. En effet ce programme
traite les instructions que vous lui donnerez en JavaScript. Ça pourrait paraître surprenant car nous
sommes habitués à voir le JavaScript fonctionné côté client (plus précisément sur le navigateur), et même
si ce dernier a évolué de manière fulgurante ces dernières années (il est loin le temps où JavaScript faisait
uniquement concurrence à flash pour les animations toutes saccadées des menus dépliants) Node.js nous
prouve qu’il est également possible d’utiliser ce langage côté serveur tout comme on le ferait avec du PHP,
ASP, C, Java etc…
IV.3.2.2. Avantages de Node.js
Le JavaScript peut être utilisé comme langage unique pour le serveur et pour la partie cliente, ce
qui homogénéise le programme et facilite la vie du développeur.
Node.js permet de faire des requêtes asynchrone qui permet une gestion des
entrées/sorties de manière non bloquante, très pratique pour les applications qui ont
besoin de temps réel ;
Node.js, utilisé en tant que serveur web, reste très performant (bien plus qu’apache)
en temps de réponse/requête simultané, deux petits graphiques pour vous faire une
idée.

IV.3.2.3. Désavantage de Node.js
Avec Node.js vous devez tout gérer, Node.js est une base, vous ne pourrez pas l’utiliser
directement en tant que serveur web/ftp/webservice/autre… sans avoir à coder. Fort heureusement, il
existe un écosystème de modules déjà écrits, testés et éprouvés qui nous épargnent beaucoup travail (nous
pensons notamment au paquet “Express” qui permet de transformer facilement Node.js en un serveur
Web).
Existe encore très peu de docs francophones sur le sujet,
La maturité12 des librairies à disposition côté serveur serait moins évoluée que celle
de PHP, Python, Ruby, Java etc…
En réalité, le plus gros point faible de Node.js, est précisément sa jeunesse: il est
encore impossible de déterminer si le serveur est fiable sur le long terme en
production.

IV.3. Architecture du déploiement

IV.5. Présentation des résultats
1. Accès à la plate-forme
Un patient lance son navigateur chrome en tapant l’URL du serveur pour y accéder à l’application.
Cependant, si ce dernier possède déjà un compte, il s’authentifie afin d’y accéder. Dans le cas contraire, il
va cliquer sur l’onglet CREER UN COMPTE pour créer un compte.
2. Création d’un compte
Cette rubrique permet à un participant de créer un compte.

3. Authentification
Une fois créer un compte, donc on s’authentifie (avec son login et son mot de passe) pour y
accéder aux fonctionnalités.
4. Accès à la plate-forme
Après authentification, le patient accède à la plate-forme de téléconsultation. Cependant, il peut choisir
dans la liste suivante un médecin disponible pour la consultation vidéo.

On constate qu’il y a trois médecins présents dans la base de données et il suffit juste de cliquer sur un nom
de médecin pour voir sa disponibilité. S’il n’est pas disponible, on lui affiche un message de même s’il a
déjà un appel en cours.
5. Consultation médicale en cours
Cette capture montre qu’un médecin est en plein consultation avec un patient
Pour se déconnecter de la plate-forme, on clique sur déconnexion à gauche

CONCLUSION
.
Les objectifs de ce projet ont été atteints, bien que nous ayons eu à faire face à des difficultés ; nous
avons montré les possibilités qui existent pour faciliter l’accès aux soins des populations grâce à la
téléconsultation.
Ainsi, nous avons étudié la télémédecine dans sa généralité, puis énumérer les principaux outils
nécessaires suivants : Nous avons utilisé node.js comme plateforme logicielle pour développer notre
application. Nous avons mis en place une base de données Mongo DB qui stocke les comptes des patients
et médecins avec leurs paramètres de connexion (login et mot de passe). Nous avons conçu notre plate-
forme de téléconsultation en utilisant ces technologies. Lors de la conception, nous avons relevé quelques
difficultés parce qu’il fallait d’abord comprendre les langages de programmation, et la syntaxe des APIs
WebRTC.
Cependant, pour mener à bien l’étude du projet, il a fallu adopter une certaine démarche ;
Premièrement, nous avons effectué une recherche bibliographique afin de connaitre les différents outils et
moyens indispensable pour concevoir notre plate-forme, en suite nous avons procéder en sa conception et
enfin aux différents choix technologiques.
Par ailleurs, nous disposons déjà d’une plateforme de téléconsultation, mais nous y avons observés
quelques insuffisances que nous devrons améliorer dans le futur afin de disposer d’une application
complète de téléconsultation.
Ce projet peut évoluer en intégrant des nouvelles fonctionnalités telles que la messagerie
instantanée, la prescription d’ordonnance via la plate-forme, la création de dossiers médicaux pour chaque
patient. Ainsi, il faudrait étudier les caractéristiques de la machine serveur qui doit supporter l’application.

BIBLIOGRAPHIE ET WEBOGRAPHIE
BIBLIOGRAPHIE ET WEBOGRAPHIE

ANNEXES
ANNEXES
PARTIE A : INSTALLATION DE L’ENVIRONNEMENT DE

DEVELOPPEMENT
Node.js est notre environnement de développement, cependant, il peut être installé sur les systèmes
suivants : Linux, Windows, et Mac OS. Ainsi, avant d’installer node.js, on installe d’abord son installateur
NPM. Il est à noter que nous travaillons dans un environnement Linux plus précisément Ubuntu 14.04
64bits.
Cependant, l’installation de node.js se fait selon les étapes suivantes :
1. Mise à jour du système
2. Installer Node.js
Il vous suffit donc de rentrer la commande suivante
Pour lancer un serveur nodejs, on tape la commande node nom_serveur.js
Pour voir la version on tape npm –v et node –v

3. Installation des modules
ExpressJS est un module pour nodeJS développé, entre autres, par Tj Holowaychuk. Nous n'allons
utiliser qu'une petite partie des possibilités de ce framework. ExpressJS n'est pas intégré par défaut à
nodeJS, il faut l'installer à l'aide de l'outil npm « node packaged modules ».
À l'aide de la console, placez-vous dans le dossier qui va accueillir votre fichier JavaScript (côté
serveur), puis tapez : npm install express
Pour utiliser MongoDB avec un serveur tournant sous nodeJS, nous allons devoir installer 2 éléments :


Langue

Memoire JOSUE

Transféré par

Informations du document

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Memoire JOSUE

Transféré par

Droits d'auteur :

REPUBLIQUE DU SENEGAL

Ecole Centrale des Logiciels Libres et de

MEMOIRE DE FIN DE CYCLE

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

SUJET : Conception et Déploiement d’une Plate-forme de Téléconsultation

Lieu de stage : Groupe RTN

Présenté et soutenu par: Professeur Encadreur:

Josué NUMBI LUHEHO Dr. Samuel OUYA

Année Universitaire: 2016-2017

Conception et Déploiement d’une Plate-forme de Téléconsultation 2

 Mon Encadreur Docteur Samuel OUYA, pour sa disponibilité, rigueur et recommandations ;

 Mes amis et amies de par le monde qui n'ont cessé de m'encourager;

 ISMAEL, pour sa disponibilité et son soutien durant la réalisation de ce travail ;

 Tous mes compagnons de promotion

 Tous ceux qui, de près ou de loin, m’ont aidé à la réalisation de ce travail

Conception et Déploiement d’une Plate-forme de Téléconsultation 3

L’Ecole Centrale des Logiciels Libres et de Télécommunications (EC2LT) de Dakar en partenariat

Conception et Déploiement d’une Plate-forme de Téléconsultation 4

Avec l'apparition des technologies de l'information et de la communication, les communications se

Conception et Déploiement d’une Plate-forme de Téléconsultation 5

Conception et Déploiement d’une Plate-forme de Téléconsultation 6

TABLE DES MATIERES

TABLE DES MATIERES

LISTE DES TABLEAUX..................................................................................................................................9

LISTE DES FIGURES....................................................................................................................................10

I.1. Présentation de la Structure d’accueil...............................................................................................14

I.1.1. Présentation de L’Entreprise RTN.............................................................................................14

II.1. Qu’est-ce que la Télémédecine ?.......................................................................................................21

II.2. L’intérêt de la Télémédecine.............................................................................................................22

II.3. Les composantes de la Télémédecine................................................................................................22

II.4. Les dispositifs médicaux connectés.................................................................................................. 24

Conception et Déploiement d’une Plate-forme de Téléconsultation 7

II.5. Avantages et Inconvénients...............................................................................................................25

III. Présentation de WebRTC..........................................................................................................................27

III.1. Définition et Principes......................................................................................................................26

III.2. Architecture générale de WebRTC...................................................................................................28

III.3.1. Architecture de fonctionnement.................................................................................................30

III.3.3. La Traversée de NAT.................................................................................................................33

III.4. La Description de session SDP.........................................................................................................41

III.5. Les Protocoles de transport (SRTP, RTP, RTCP)............................................................................ 42

III.6. Les Codecs........................................................................................................................................45

III.7. Les APIs............................................................................................................................................46

III.8. Avantages et Inconvénients.............................................................................................................. 46

IV. Analyse et Conception de la Plate-forme................................................................................................. 61

IV.1. Architecture et Fonctionnement ...................................................................................................... 61

IV.2. Choix des outils et technologies.......................................................................................................62

IV.2.1. Les Langages de programmation............................................................................................... 62

IV.2.2. Les Protocoles http et WebSocket............................................................................................. 64

IV.2.3. La Base de données (Mongo DB)..............................................................................................65

IV.3. Conception du système..................................................................................................................... 66

IV.3.1. Modélisation du système........................................................................................................... 66

IV.3.2. Environnement de développement............................................................................................ 68

IV.4. Architecture du déploiement................................................................................................................71

IV.5. Présentation des résultats.................................................................................................................72

Conception et Déploiement d’une Plate-forme de Téléconsultation 8

LISTE DES TABLEAUX

LISTE DES TABLEAUX

Conception et Déploiement d’une Plate-forme de Téléconsultation 9

LISTE DES FIGURES

LISTE DES FIGURES

Conception et Déploiement d’une Plate-forme de Téléconsultation 10

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

RTN Réseaux et Techniques Numériques

Conception et Déploiement d’une Plate-forme de Téléconsultation 11

Actuellement, les technologies de l'information et de la communication ont connu un essor

En effet, les technologies de l'information et de la communication permettent d'envisager de