REPUBLIQUE DEMOCRATIQUE DU CONGO

MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET UNIVERSITAIRE

UNIVERSITE CHRETIENNE BILINGUE DU CONGO

FACULTE DES SCIENCES APPLIQUEES/GÉNIE INFO

d
RÉALISATION D’UNE APPLICATION WEB DE
COMMUNICATION EN TEMPS RÉEL DANS UN RÉSEAU
D’ENTREPRISE AVEC LA TECHNOLOGIE WEBRTC

Par : TSONGO KIKAMA Israël

Encadreur : Maître Djabu Elisé
Directeur : Maître Salama

ANNEE ACADÉMIQUE : 2020-2021

Resume
 CHAPITRE 1. INTRODUCTION GENERALE
1.1 PRÉAMBULE

Il n’y a pas de doute que la VoIP (Voix sur IP) est une technologie qui est en train
de modifier complètement le système de communication des entreprises. Elle convertit la voix
en paquets de données permettant ainsi la transmission, sur Internet et de bénéficier d’une
téléphonie plus efficace avec de nombreuses prestations et une meilleure qualité. Cependant, Si
vous avez déjà visité le réseau de communication interne, de la plupart d'entreprise vous
constaterez que celui-ci est réalisé moyennant le SIP (Session Initiation Protocole) mais l'ennuie
c'est que Le SIP présente des défauts, sur le plan coût de l'infrastructure à mettre en place pour
assurer une communication de haute qualité entre personnels de l'entreprise , en plus au niveau
de la flexibilité cad le SIP n’est pas multi plateforme car il n’est pas nativement supporte par les
ordinateurs. Il nécessite les téléphones IP, des adaptateurs pour assurer la compatibilité entre les
équipements, il nécessite une installation ce qui nécessitera une main d’œuvre qualifier c’est
coûteux, des investissements en matériel physique et en logiciel sont nécessaires. Les
applications populaires de chat comme Skype, Instagram, Messenger ou WhatsApp sont dans le
top 10 des applications mobiles, les plus utilisé dans le monde, et selon les derniers statistiques,
plus de 4 milliards des personnes les utilisent. Il n’est donc pas rare que, par soucis de
simplicité, les entreprises fassent recours a celles-ci dans les échanges avec leurs clients pour
établir un appel vidéo, ou une discussion instantanée des messages en dépit du fait que ces
applications n’aient pas vocation à être utilisées à des fins professionnelles suite aux haut risque
d’enregistrement des données des employés par l’entreprise propriétaire de l‘application
mobile, la sécurisation et confidentialité des données ne sont pas garanties , autres chose c’est
que les fonctionnalités ne peuvent pas être personnalisées à volonté, car on est limité par ce que
l’entreprise propriétaire de l’application à implémenter. Les applications gratuites fournissant
une communication en temps réel sont donc largement répandues, mais sont nombreuses et
inadaptées au contexte professionnel1.

1
https://urgentime.com/les-benefices-du-webrtc-pour-de-lappel-video/
 1.2 PROBLÉMATIQUE

Malgré la multiplicité des systèmes proposant des communications dans une organisation, Les
problèmes de communication demeure dans les entreprises. Ne pas les résoudre peut causer des
dommages au sein de l’organisation : perte de temps et d’argent, baisse de la productivité mais
surtout un désengagement de la part des employés concernés voir même des clients de l'entreprise2.

De nos jours dans la plupart d'entreprise la communication en entreprise que ça soit dans
l'intranet ou sur internet, elle est réalisée moyennant le protocole SIP Mais alors le SIP affiche des
faiblesses et limites suite à l'évolution des modes de communication moderne à l'exemple de la
visioconférence, dont la mise en place, s’avère complexe avec le SIP. Voici quelques difficultés du
protocole SIP, les plus remarquables :

 La mise en place est très coûteuse pour une couverture en étendu souhaité. Pour
pouvoir l’utiliser, l’achat d’un ensemble des nouveaux équipements comme les
téléphones IP, IPBX, serveur SIP auxquels j’ajoute l’installation d’un software
spécialisé, coûtant souvent très cher.

 Nécessite des configurations complexe, lesquelles configurations nécessitant un

expert qualifie.

 Une grande sensibilité du signal transmis ou reçu aux variations pendants la

transmission ou réception des données via celle-ci

 Son non flexibilité se traduisant par l’impossibilité d’émission ou de réception

d’appels depuis les dispositifs non supporte par cette technologie. Seuls les
téléphones IP ou les softphone

Ainsi, les défaillances ci-haut nous ont poussé à nous poser les questions suivantes :

 Quelle serait la solution d'entreprise pouvant permettre à celle-ci de bénéficier des

fonctionnalités de base du VoIP entre autres un appel vocal, discussion instantanée ainsi

2
https://www.journaldunet.com/management/efficacite-personnelle/1208295-et-les-cinq-plus-gros-problemes-
de-communication-en-entreprise-sont/
 que le transfert de fichier, appel vidéo (avec possibilité facile de faire une vidéoconférence),
sans avoir besoin d'installer un nouvel équipement qui pourrait le pénaliser au niveau coût
de mise en place ?

 Comme pour tout entreprise, les données étant d’importance capitale de telle sorte que leurs
sécurités ainsi que leurs confidentialités étant impérieuse : quelle serait une solution
d’entreprise d'échange des données entres les terminaux, fiables du point de vue sécurité et
confidentialité en communication ?

1.3 HYPOTHÈSE
Par rapport aux questions ci – haut posées nous avons quantitativement formule des réponses
suivantes

 La réalisation d’une application web grâce au Framework WebRTC, et s’exécutant dans un

navigateur standard pour établir une communication utilisant des canaux audio, vidéos et de
données, sans contrainte sur le type de service fourni par l’application web, en serait une
solution.

 Le WebRTC posséderait un avantage considérable sur la plupart des services VoIP dans le
domaine de la sécurité et confidentialité, il est fiable.

1.4 OBJECTIF DU TRAVAIL

1.4.1 Objectif principal

L’objectif principal de ce travail est de permettre une communication sécurisée

entre employés d’une entreprise, du type multi plateforme càd accessible sur mobile, PC et
tablette et cela a un coût réduit, sans faire recours à des logiciels externe souvent non
professionnel et propriétaire (comme Skype, WhatsApp, Messanger) enfin de favoriser la
productivité de l’entreprise dans le milieu des affaires .
1.4.2 Objectif spécifique
En vue de mieux élucider l'objectif principal, les spécifications suivantes s’avèrent
impérieuse :

Nous réaliserons une application web grâce au Framework WebRTC, qui s’exécutera dans un
navigateur standard.

1.5 CHOIX ET INTÉRÊT DU SUJET

Notre choix s'est porté sur ce sujet suite aux multiples difficultés rencontre souvent
en entreprise lors de la réalisation d’un système de communication VoIP permettant une
collaboration efficace entre personnels à coût moindre.

Intérêt social :

Aux personnels de l’entreprise : Le système permettra une amélioration de la productivité au

sein de l’entreprise.

Pour l’entreprise : Le système permettra une économie financière pour l’entreprise, un gain en
productivité mais aussi une autonomie dans ses moyens de communications.

Intérêt personnel :

Non seulement le choix du travail a été motivé par l’opportunité d’implémentation d’un
système avec une technologie peu connue dans nos milieux, mais aussi le présent travail constitue une
opportunité de mise en pratique de certaines théories apprises durant notre parcourt académiques
en premier cycle de Licence LMD.

Intérêt scientifique :

Ce travail servira de base pour les chercheurs qui voudront traiter un sujet en rapport
avec les communications du type VoIP utilisant le Framework WebRTC comme technologie.

1.6 DELIMITATION
Vue la complexité d'une mise en place d'un système de communication moderne et surtout
du type pair à pair, notre travail sera limité par rapport au contenu, espace et par rapport au temps :
Par rapport au contenu :

Notre travail consistera à mettre en place une application web pour une entreprise ou
organisation pour son intranet, qui permettra aux personnels se trouvant dans des lieux différents
d’initier ou de rejoindre une communication du type pair à pair.

Par rapport à l’espace :

Nous nous sommes situés par rapport aux réalités de la province du NORD-KIVU en
République Démocratique du Congo dans la ville de Beni et surtout à toute entreprise ou
organisation de la place, désirant un système de communication à faible coût propre à
l’organisation.

Par rapport au temps :

Ce travail de recherche s’étend sur une période allant du début du mois d’Octobre 2020
jusqu’à Mai 2021.

1.7 SUBDIVISION

Hormis la partie introductive ainsi que, de la conclusion, ce travail est structuré en quatre chapitres
qui sont :

 Généralité et revue de littérature :

Dans ce chapitre on parlera de la communication Voice Over IP en général, et de ses avantages

dans monde actuel, on va parler également de la technologie WebRTC. Enfin on va présenter
quelques travaux déjà réalisé dans le secteur du Voice Over IP

 Méthodes de recherche et outils de travail :

Dans ce chapitre nous présentons la méthodologie utilisée pour la réalisation de ce travail. Nous
présentons également les outils ou technologie à utiliser pour la réalisation de l'application.

 Modélisation et conception du système :

Ce chapitre se focalise essentiellement sur la conception des tables de notre application.

 Implémentation du système et présentation des résultats :

Dans ce chapitre nous réalisons l’application web de communication et qui sera

accessible dans un réseau local (intranet).
 CHAPITRE 2. GENERALITE ET REVUE DE LITTERATURE

2.1 GENERALITE

2.1.1 Introduction

Les communications vidéo et audio font désormais partie intégrante de toutes les sphères de
la vie. Deux protocoles de communication en temps réel couramment utilisés pour les
communications vidéo et audio IP sont le protocole d'initiation de session (SIP) et les
communications en temps réel sur le Web (WebRTC). Ces deux protocoles sont largement utilisés
dans les applications de téléphonie logicielle et de visioconférence.

L’internet ainsi que les technologies modernes de l‘information permettent aux

particuliers et aux entreprises d’être toujours connectés les uns avec les autres et de travailler
ensemble à distance grâce à des réunions en ligne moyennant la vidéoconférence ou n’importe
quelle application collaborative. La technologie WebRTC est celle qui permet de réaliser ces genres
d’applications pour les navigateurs modernes en permettant au navigateur de communiquer en
temps réel en utilisant des connexions du type pair à pair, sans plugin. Selon les derniers statiques
de 2021 près de 4,54 milliards sont constamment connecte à internet. L’usage des PC,
Smartphones et des tablettes est en croissance considérable, du fait qu’on peut faire quasiment tout
c a d passer des appels de tout type comme des appels audio, appels vidéo, envoie des fichiers,
discussion instantanée entre utilisateur grâce à l’utilisation des ordinateurs, tablettes et des
smartphones. De façon inévitable, le besoin d’une meilleure communication émerge, et c’est là que
le WebRTC intervient. Le WebRTC signifiant Web Real Time Communication (communication
web en temps réel) qui est simplement un standard ouvert pour intégrer des capacités de
communications multimédia en temps réel, directement dans un navigateur web. La structure du
standard ouvert s’affranchit des téléchargements des logiciels et plugins. L’effort du WebRTC est
en cours de standardisation au niveau de l’API par le W3C, et au niveau du protocole par l’IETF.

Étant donné qu’un travail scientifique a toujours ses terminologies appropriées, Après avoir
présenté l’introduction générale dans la partie précédente, il est important, dans cette partie, que
nous définissions et détaillions les différents concepts constituant le cadre de notre travail. Nous
passerons également en revue les travaux des chercheurs qui se sont lancés dans le domaine du
Voice Over IP tout particulièrement ceux qui ont utilisé la technologie WebRTC pour enfin dégager
l’originalité de notre recherche. Enfin, nous présentons la spécification d’exigences logicielles qui
décrira le comportement externe de l’application à concevoir.
2.1.2 Réseau d’entreprise

a) Définition

Le réseau d’entreprise permet de relier chaque ordinateur d’une entreprise entre eux via un
serveur qui va gérer l’accès à Internet, les e-mails, les droits d’accès aux documents partagés et le
travail collaboratif. Chaque utilisateur du réseau se connecte avec un nom d’utilisateur et un mot de
passe et est authentifié par le serveur. L’utilisateur peut accéder à ses données et au partage de
fichiers. Le réseau en entreprise permet à l’entreprise de centraliser ses données, les sécuriser et de
travailler en équipe de manière productive3.

b) Schéma type d’un réseau d’entreprise

Dans une entreprise, il existe une hiérarchie au niveau des employés. C’est la même chose
au niveau des ordinateurs : l’un des ordinateurs va jouer le rôle du patron, on l’appelle le serveur
d’entreprise. C’est une machine plus puissante que les autres et qui a beaucoup de responsabilités.
Ce serveur est géré par le service des systèmes d’information (SSI) ou service informatique. La
personne en charge de ce serveur est l’administrateur et il est le seul à avoir accès à la salle des
serveurs.

c) Schéma d'un réseau d'entreprise

Le schéma type d’un réseau d’entreprise

3
https://cours-informatique-gratuit.fr/cours/reseau-informatique-entreprise/
2.1.3 Qu’est-ce que le p2p dans le contexte de WebRTC

2.1.4 Qu’est-ce que la communication en temps réel

C’est très simple, un exemple suffit à l’expliquer.

Un email n’est PAS une communication en temps réel (pas nécessite de réponse a l’immédiat), un
appel téléphonique, par contre, lui l’est.

Par définition, la communication en temps réel est toute forme de télécommunication par laquelle
tous les utilisateurs peuvent échanger des informations instantanément ou avec une latence
négligeable. Le temps réel est également synonyme du “Live”.
 Figure 1 Architecture générale de la communication en temps réel

2.1.5 Qu’est-ce que le SIP (Session Initiation Protocol) ?

a) Définition
Le SIP (Session Initiation Protocol) est un protocole de signalement utilisé pour établir une
“session” entre deux ou plus de participants, modifier cette session, et finalement terminer cette
session. Son utilisation est devenue MAJEURE dans le monde de la téléphonie IP. Le fait que le
SIP est un standard ouvert a généré un intérêt énorme sur le marché de la téléphonie, et les
constructeurs de téléphones SIP ont connu une croissance phénoménale dans ce secteur.

b) Session Initiation Protocol, qu'est-ce que le SIP

Le protocole SIP est un protocole texte, ressemblant beaucoup au protocole HTTP. Les messages
sont sous forme de texte, et le mécanisme de requête-réponse permet un dépannage facile. La
transmission des données elles-mêmes est effectuée par le Transmission Control Protocol (TCP) ou
le User Datagram Protocol (UDP) au niveau 4 du modèle OSI. Le Session Description Protocol (or
SDP) contrôle quel protocole est utilisé. Le message SIP décrit l’identité des participants lors d’un
appel, et comment ces participants peuvent être joints sur un réseau IP. A l’intérieur des messages
SIP, on voir parfois une déclaration SDP. Le SDP (Session Description Protocol) définira le type de
canaux média qui seront établis pour la session – il décrira quels codecs sont disponibles et
comment les terminaux médias peuvent se joindre sur le réseau IP. Une fois que cet échange de
messages est terminé, le média est échangé via un autre protocole, en général le RTP (Real-Time
Transmission Protocol). Le SIP a été développé par IETF et publié en tant que RFC 3261. Sa
flexibilité lui a permis de remplacer quasiment entièrement le protocole H.323 dans le monde de la
VoIP4.

2.1.6

Figure 2 Les entités d’une architecture SIP

Qu’est-ce que le Protocole RTP ?

Le protocole RTP (Real Time Transport Protocol) – décrit le format de paquet

standard de la transmission audio et vidéo sur Internet. Il est défini dans le RFC 1889. Développé
par Audio Vidéo Transport Working Group, il a été publié pour la première fois en 1996. Ce
protocole est largement employé dans le domaine des communications et des loisirs qui comprend
le streaming media comme la téléphonie, les applications de téléconférence vidéo, les services de
télévision et des fonctionnalités push-to-talk basées sur le web.

a) Description du protocole RTP

Le RTP et le RTCP sont étroitement liés. Tandis que le premier livre les données (par exemple
audio et vidéo), le RTCP est utilisé pour surveiller les statistiques de transmission, et la qualité du
service, il contribue aussi à la synchronisation de plusieurs services. Le RTP est généré et reçu sur
des numéros de port pairs, et la communication RTCP associée utilise le numéro de port impair le
suivant le plus élevé. Le RTP est l’un des fondements de la VoIP et il est utilisé avec le SIP qui
contribue à la configuration des connexions à travers le réseau.

4
https://www.3cx.fr/voip-sip/sip/
 b) Avantages et usage du protocole RTP

Comme son nom l’indique, le but principal du protocole RTP est la transmission en temps réel
de données liées au média, de bout en bout. Le RTP inclut des mécanismes pour la détection des
pertes de paquets, ainsi que la délivrance de paquets hors d’usage, des problèmes qui sont
particulièrement communs avec les transmissions UDP (User Datagram Protocol) via IP. Parce que
le RTP permet le transfert de données à des destinations multiples en parallèle via multicast IP,
c’est le standard principal employé pour les transferts IP audio et vidéo.

Des applications comme la VoIP qui ont besoin de transmettre des données multimédia en
temps réel ont une tolérance variable en termes de pertes de paquets. Par exemple, la perte de
paquets audio dans une application VoIP peut faire perdre quelques millisecondes de données
audios. Cette perte peut être correctement gérée par des algorithmes de compensation d’erreur pour
que ces pertes soient imperceptibles pour les interlocuteurs de l’appel. Le TCP (Transmission
Control Protocol) est aussi standardisé pour un usage RTP, bien qu’il ne soit pas typiquement
employé dans les applications à cause d’un mécanisme de contrôle des erreurs qui peut créer des
délais et gêner la livraison des paquets en temps et en heure. Pour cette raison, la plupart des
applications RTP doivent en général baser leur implémentation sur l’UDP5.

2.1.7 Le protocole DTLS

Le Datagram Transport Layer Security (DTLS) est un protocole conçu pour protéger les
données privées en prévenant la falsification, les écoutes, et la contrefaçon dans les
communications. Il est basé sur le Transport Layer Security (TLS), qui est un protocole qui sécurise
les réseaux de communications informatiques. La différence principale entre le DTLS et le TLS est
que le DTLS utilise l’UDP et le TLS utilise le TCP. Il est utilisé via la navigation web, le mail, la
messagerie instantanée et la VoIP. Le DTLS, tout comme le SRTP, est l’un des protocoles de
sécurité utilisé pour la technologie WebRTC6.

2.1.8 Le Protocole SRTP

Le SRTP -Secure Real -Time Transport Protocol Le SRTP aussi connu sous le nom de
Secure Real – Time Transport Protocol, est une extension d’un profil de RTP (Real-Time Transport
Protocol) qui ajoute davantage de fonctions de sécurité, comme le message d’authentification, la
confidentialité et la protection anti-replay, principalement prévues pour les communications VoIP.
Ce protocole utilise l’authentification et l’encodage afin de minimiser les risques d’attaques comme
5
https://www.3cx.fr/voip-sip/rtp/, visite le 20 mars 2021 19h 33

6
https://www.3cx.fr/voip-sip/dtls/, visite le 20 mars 2021 17h 44
celles par déni de service. Il a été publié en 2004 par l’IETF (Internet Engineering Task Force) en
tant que RFC 3711. Ce protocole, tout comme le DTLS est l’un des protocoles de sécurité utilisé
par la technologie WebRTC7.

2.1.9 Protocole SCTP

Le SCTP (Stream Control Transmission Protocol) est un protocole de transport fiable de la

suite des protocoles Internet permettant la transmission de messages de télécommunication à travers
des réseaux IP. Il réunit plusieurs caractéristiques des protocoles TCP (orienté connexion) et UDP
(sans connexion) servant également au transfert des données, et comprend notamment des
mécanismes de gestion des congestions (Congestion Control) et d’amélioration de la tolérance aux
erreurs lors de l’envoi des paquets. Grâce à sa grande flexibilité, le SCTP est également utilisé dans
d’autres applications (par exemple pour la gestion et l’administration de pools de serveurs). SCTP
n'est jamais utilisé. Et quand c'est le cas, c'est par la communauté VoIP et pour les communications
de serveur à serveur. Mais maintenant, dans WebRTC, il est utilisé pour la livraison arbitraire de
données peer-to-peer entre les navigateurs. Le canal de données existe pour les cas d'utilisation dont
nous n'avons aucune idée. Là où nous ne connaissons pas vraiment les types d'exigences.

TCP UDP SCTP

Fiabilité Fiable Non fiable Configurable
Livraison Ordonnée Non ordonnée Configurable
Transmission Oriente connexion Oriente donnée Oriente donnée
Contrôle de flux Oui Non Oui
Contrôle de Congestion Oui Non Oui
Comparaison du TCP vs UDP vs SCTP

 Fiabilité - si j'envoie un paquet - est-ce que j'ai la confiance (reconnaît) qu'il a été
reçu à l'autre extrémité ?

 Livraison - si je reçois 2 paquets - suis-je sûr que l'ordre dans lequel ils ont été reçus
est celui dans lequel ils ont été envoyés ?

 Transmission - est-ce que j'envoie des paquets ou un flux infini d’octets ?

7
https://www.3cx.fr/voip-sip/srtp/, visite le 21 mars 2021 20h 53
  Contrôle de flux / contrôle de la congestion - le protocole lui-même agit-il de
manière responsable et traite-t-il seul les réseaux congestionnés ?

Pour SCTP, la fiabilité et la livraison sont configurables - je peux décider si je veux ces
caractéristiques ou non. Pourquoi est-ce que je n'en veux pas ? Tout a un prix. Dans ce cas, latence
et hypothèses faites sur mon cas d'utilisation.

Il y a donc des moments où je voudrais plus de contrôle, ce qui penche vers UDP. Mais je veux
aussi faire la vie aux développeurs, donc je préfère faire allusion au protocole sur mes besoins et le
laisser s'en occuper.

Le Data Channel est conçu pour l'innovation. Et dans ce cas, utiliser un outil ancien et inutilisé était
la meilleure approche8.

2.1.10 Rôle d’un Codec dans la technologie WebRTC

Les codecs font référence à la compression et à la décompression du flux multimédia. Pour

que les pairs puissent procéder à un échange de média réussi, ils ont besoin d'un ensemble commun
de codecs à convenir pour la session. Les codecs de liste sont envoyés entre eux dans le cadre de
l'offre et de la réponse ou SDP dans le protocole SIP. Un codec est un appareil ou un logiciel
capable d’encoder ou de décoder un flux numérique ou un signal pour la transmission sur le réseau
de données. Les codecs sont divisés en deux catégories : sans perte et avec perte. Les codecs sans
perte retiennent toute l’information contenue dans le flux d’origine, préservant ainsi la qualité
vidéo/audio dans un signal, alors que les codecs avec perte réduisent la qualité de la compression
mais utilisent aussi moins de données de bande passante.

 Compression sans perte : Un algorithme de compression des données qui permet la

compression et décompression des fichiers sans perte de qualité.

 Compression avec perte : Un algorithme de données qui élimine certaines données pour
faciliter la transmission. Cela est surtout utilisé quand la connexion réseau n’est pas idéale.
Cette compression est surtout reconnaissable avec des fichiers vidéo qui ressortent pixélisés.

8
https://bloggeek.me/sctp-data-channel/,visite le 25 mai 2021
 Avec les fichiers audio et visuels, il existe une interaction complexe entre la qualité de la vidéo,
le bit rate, le codage et décodage des algorithmes, la réactivité à la perte de données et la latence. Le
WebRTC a besoin d’un codeur/décodeur efficace pour enfin transmettre le flux audio et vidéo
recueilli respectivement depuis la caméra et au microphone. Ceci limite l’utilisation de la bande
passante du canal de transmission9.

2.1.11 Qu'est-ce que le WebRTC

WebRTC est une nouvelle technologie, qui permet aux navigateurs de

Communiquer directement entre eux en temps réel. Cette technologie permet la communication
multimédia en temps réel comme la voix, la vidéo et d'autres flux de données pour être envoyé entre
les navigateurs modernes. WebRTC est développé et standardisé par le biais du W3C et de l'IETF
(Internet Engineering Task Force), en collaboration avec des leaders des navigateurs comme
Google, Firefox, Opera et Apple [1]. Il est gratuit à utiliser, et open source avec pour mission
principale : « permettre à ce que des applications de communication du type real time, riches, de
haute qualité soient développe pour les navigateurs modernes ,pour les plates-formes mobiles et
pour les objet connecte (IoT), et enfin faciliter à tous ces composants précités de communiquer via
un ensemble de protocoles commun. L'initiative WebRTC est un projet soutenu entre autres par
Google, Mozilla et Opera » [2]

2.1.12 Architecture du WebRTC

WebRTC ne vise pas à intégrer dans le navigateur des services de haut niveau de
type softphone (Skype,Messenger, WhatsApp). L’idée est plutôt de spécifier les primitives
nécessaires à la mise en œuvre de tel service en conjonction avec des serveurs externes. En
particulier, l’objectif est de permettre à ce qu’une application JavaScript intégrée au sein d’une page
Web et s’exécutant dans un navigateur standard puisse établir une communication utilisant des
canaux audio, vidéos et de données et ce, sans contrainte sur le type de service fourni par
l’application Web. Un service de type softphone pourra ainsi être fourni par une application
JavaScript implémentant un widget téléphone et mettant en œuvre un protocole de signalisation
basé par exemple sur les WebSockets. Cette application utilisera les primitives WebRTC pour
capturer les flux audio et vidéo de la webcam, les encoder et les transmettre au correspondant [3].

9
https://bloggeek.me/sctp-data-channel/, visite le 25 mai 2021
 Figure 3-Architecture générale du WebRTC 2.1.13
Exigences pour WebRTC du point de vue du développeur

Pour réaliser une application WebRTC, il faut établir une connexion entre les
navigateurs qui veulent communiquer. WebRTC fournit la solution juste pour l’échange des médias
mais n’implémente pas la signalisation, c’est-à-dire comment les informations d’un client devrait
être envoyé aux pairs distants afin d'initier une connexion paire à pair. Cette étape d’initialisation
est appelée signalisation. La signalisation peut être mise en œuvre de plusieurs manières et c'est
donc aux développeurs eux-mêmes de choisir une solution pour cela. Une solution efficace pourrait
être un serveur utilisant WebSockets. WebSockets crée une connexion bidirectionnelle entre un
navigateur et un serveur. Cela signifie que le navigateur et l'interaction avec le serveur est basée sur
les événements et le navigateur n'a pas à interroger le serveur pour une réponse chaque fois que des
données doivent être échangées contrairement au protocole HTTP pour qui le serveur doit
nécessairement recevoir une requête avant de générer une réponse correspondante [4]. Il en résulte
une communication rapide et interactive qui convient très bien à un serveur de signalisation.

Figure 4-Architecture WebRTC avec un Serveur de signale

 Un serveur de signalisation n'est pas la seule pièce nécessaire pour réaliser une application
WebRTC. Pour envoyer et recevoir des données vers un autre navigateur, le personnel doit disposer
des informations sur son pair. L’information la plus importante est l’adresse IP du client. Chaque
pair à travers son navigateur doit connaître les informations de connexion (IP, port, Codec.) du pair
homologue afin de recevoir une connexion entrante d'un autre pair. Pour une communication paire a
pair réalise via internet, il est parfois difficile pour le client de connaître sa propre adresse IP
publique, surtout si le client est derrière un pare-feu ou un NAT, ce qui est très courant ces jours-ci
[5]. Pour surmonter cela, WebRTC recommande l’utilisation d'un serveur STUN. Un serveur STUN
permet aux pairs de découvrir leur propre adresse IP publique, quel type de NAT les couvre.
Parfois, il peut être difficile d'aller chercher les informations, en fonction du NAT cad le niveau de
restriction du NAT est élevé, et dans ce cas, un serveur TURN peut aider le processus. Nous
n'entrerons pas trop loin dans la mise en œuvre de ces serveurs, mais retenons que le serveur TURN
est une alternative sur le serveur STUN qui se déclenchera si le STUN échoue en relayant les flux
multimédias aux deux clients [5].

Les informations recueillies avec STUN peuvent ensuite être exploiter ou manipuler avec le
Framework ICE (Interactive Connectivity Establishment) pour coordonner la connexion entre les
clients [5]. ICE est un Framework utilisé par WebRTC et ICE décrit comment la connexion doit
fonctionne et aide le client à découvrir des informations afin qu'une connexion d'égal à égal puisse
être établi. Sous le capot, ce que ICE résout pour nous, c'est d'essayer systématiquement toutes les
possibilités de connexions entre les pairs désirant communiquer grâce à ce qu’on appelle «
candidats » ou « ICE candidate » (utilisant les informations reçues du serveur STUN). ICE
Essaiera de découvrir quelle paire d’adresses IP et port des utilisateurs fonctionnera lors d’une mise
en contact (P2P). En pratique, de nombreuses combinaisons d’informations reçues par le
Framework ICE ne fonctionneront pas et c’est pourquoi ICE aide à résoudre ce problème [6].
 Figure 5-Une architecture WebRTC : La traversée du NAT

Serveur, STUN et serveur TURN

Signalons que pour ce travaille nous ne ferons pas recours aux serveurs STUN et TURN du fait que
nous implémenterons ce système dans un réseau local. L’agent ICE n’aura pas besoin d ‘interroger
le serveur STUN a la recherche de l’adresse IP des pairs. Une connexion UDP suffira pour établir la
connexion. Si dans le réseau de l’entreprise il y a des pares-feux il faudra autorise les ports UDP
utilise par la connections des pairs.

2.1.14Architecture d’application WebRTC

 Nous avons vu que pour débuter avec les flux d'échanges entre navigateurs on peut faire
recours a divers serveurs, permettant par exemple la traversée de Firewalls, proxys ou NAT, grâce
au framework ICE qui est intégré dans le framework WebRTC. L'architecture de l'API WebRTC
repose sur une construction triangulaire impliquant un serveur et deux pairs. Les deux navigateurs
téléchargent depuis un serveur une application JavaScript vers leur contexte local. Le serveur est
utilisé comme point de rencontre afin de coordonner les échanges entre navigateurs jusqu'à ce que
la connexion directe entre navigateurs soit établie. L’application téléchargée utilise l'API WebRTC
pour communiquer avec le contexte local. Le but est d'avoir une application cliente en JavaScript et
HTML5 interagissant avec le navigateur au travers de l'API WebRTC.

Figure 6-Architecture application WebRTC

2.1.15
Établissement de la communication

Afin d'établir une connexion utilisant le standard WebRTC, les navigateurs A et B

doivent être connectés simultanément à la page du service (serveur web) et télécharger la page
HTML ainsi que le code JavaScript permettant de maintenir la connexion ouverte par HTTPS ou
socket. Lorsque le navigateur « A » souhaite établir la connexion avec « B », l'API instancie un
objet PeerConnection qui, une fois créé, permet d'établir des flux de médias ou de données. Il est
aussi nécessaire, pour une vidéoconférence par exemple, que les utilisateurs A et B acceptent le
partage de leur webcam et/ou de leur microphone [7] [8].

Figure 7-Etablissement d'une connexion entre deux clients utilisant WebRTC

 Une fois cet objet PeerConnection créé par « A », le navigateur envoie au serveur un paquet
contenant les informations sur les médias partagés ainsi qu'une empreinte liant la connexion à « A
». Le serveur va décoder ce paquet et identifier qu'il s'agit d'une communication à destination de B
et enverra donc un signal à « B ». « B » est notifié du souhait de A d'établir une connexion et
accepte ou non sa requête. Si elle est acceptée, le même processus a lieu entre « B » et « A » cette
fois afin d'établir la connexion bidirectionnelle. Une fois celle-ci établie, les flux de médias ou de
données peuvent être ajoutés à la connexion librement [7] [8].

La démarche est résumée comme suit :

1 : A demande au serveur une connexion avec B.

2 : Le serveur relaie la demande de A.

3 : Si B accepte, il envoie une demande de connexion à A.

4 : Le serveur relaie la demande à A.

5 et 6 : Les PeerConnection bidirectionnelles sont établies.

2.1.16 Modèle architecture WebRTC

Dans le modèle WebRTC en Trapèze, les deux navigateurs sont en cours d'exécution d'une
application Web, qui est téléchargée à partir d'un serveur Web différent. Les messages de
signalisation sont utilisés pour mettre en place et mettre fin à la communication. Ils sont transportés
par le protocole HTTP ou WebSocket via des serveurs Web qui peuvent modifier, traduire, ou gérer
selon le besoin.

Figure 8-Modèle WebRTC en trapèze

 En ce qui concerne le chemin de données, un PeerConnection permet aux médias de faire
un lien direct entre les navigateurs sans intervention de serveurs tiers. Les deux serveurs web
peuvent communiquer en utilisant un protocole de signalisation standard telle que SIP. Le scénario
de WebRTC plus commun est susceptible d'être celui où les deux navigateurs s’exécutent sur la
même application Web, c’est-à-dire ils téléchargent l’application à partir de la même page Web,
dans ce cas Trapèze devient un Triangle [7].

Figure 9-Modèle WebRTC en triangle 2.1.17 Les

Composants WebRTC

Le principal avantage de WebRTC par rapport aux autres frameworks est qu'il inclut
l'établissement de connexion interactive (ICE) [9] [10].

2.1.17.1 SDP : Session Description Protocol

Pour que la communication débute entre avant tout les pairs ont besoin d'un moyen
d'échanger des informations sur la configuration des appels. C'est là que SDP entre en jeu. SDP
contient métadonnées sur un navigateur avant la connexion de l'homologue (pair).
Les nouvelles sessions sont annoncées par initiation, invitation et échange d'informations.
L'information à échanger comprennent ; Médias vidéo et audio capacités, informations sur les
codecs, informations sur l'utilisateur qui incluent l'adresse IP et les numéros de port, sécurisés
Protocole de transmission de données RTP P2P, disponible bande passante, fonctionnalités de
session telles que nom, identifiant et le temps actif [11].
2.1.17.2 STURN server

Le NAT(Network Address Translation) fournit à un appareil une adresse IP à utiliser dans

un environnement privé (réseau local), mais cette adresse ne peut pas être utilisée en externe, et
sans adresse publique il n y a aucun moyen pour les pairs WebRTC de communiquer. Pour
contourner ce problème, WebRTC utilise les utilitaires de traversée de session pour NAT
(STUN) serveurs, pour essayer d'obtenir une adresse externe à un pair. Dans un monde simple,
chaque application WebRTC pourrait connaître son adresse externe qu'il pourrait échanger avec
d'autres pairs afin de communiquer directement. En réalité, la plupart les périphériques existent
derrière une ou plusieurs couches de NAT, de pare-feu, de proxy et de logiciels antivirus ce qui
peut bloquer certaines adresses, ports et protocoles. STUN est un serveur qui aide les protocoles
traitant la traversée du NAT, il peut être utilisé par un périphérique pour déterminer l'adresse IP
de celui-ci et son port qui lui est alloué par son NAT. Il peut également être utilisé pour vérifier
la connectivité entre deux points de terminaison, et en tant que protocole keep-alive pour
maintenir les liaisons NAT [13] [12].

Un serveur STUN a une tâche simple, vérifier l'adresse IP et le port d'une requête
entrante à partir d'une application qui s'exécute derrière un NAT et renvoyer cette adresse en
tant que réponse. Les applications WebRTC peuvent utiliser un serveur STUN pour découvrir
le <IP>: <port> à partir d'un perspective. Cela permet à un pair d'obtenir sa propre adresse
accessible au public, puis de la transmettre à un autre pair via un serveur de signalisation afin
d'établir une liaison directe [14].
 Figure 10-Utilisation du serveur STUN

2.1.17.3 Server TURN

La traversée à l'aide de relais autour des serveurs NAT (TURN) est le dernier recours lors de
la tentative de création d’une connexion P2P avec WebRTC. Si un hôte se trouve derrière des
proxys, des pares-feux ou des NAT stricts et STUN ne parvient pas à obtenir l'adresse IP publique
d'un pair, il est alors impossible d'établir une connexion P2P. Lorsque cela se produit, au lieu
d’échouer, la connexion WebRTC se replie pour utiliser les serveurs TURN pour relayer les
données entre les deux hôtes.

Figure 11- Ce diagramme montre TURN en action : le STUN pur n'a pas réussi, donc chaque
pair utilise un serveur TURN pour échanger des médias
 Si WebRTC a besoin d'utiliser un serveur TURN pour relayer les données, la communication
ne sera pas P2P mais en l'utilisant comme solution de secours. WebRTC augmente les chances
d'établir des connexions avec succès pour une grande variété d'appareils, comme le montre Les
serveurs TURN ont une adresse publique afin qu'ils puissent être contactés par des pairs même si le
pair est derrière un pare-feu ou un proxy. Ils ont une tâche théoriquement simple, relayer des
données entre deux pairs. Mais contrairement aux serveurs STUN, ils auront une énorme charge de
bande passante qui les entraîne doit être plus robuste que les serveurs STUN. Les serveurs TURN à
utiliser par l'application est spécifié dans IceConfiguration à l'objet PeerConnection.

2.1.18 WebRTC API

Le WebRTC W3C 1.0 API permet à une application JavaScript de profiter des capacités en
temps réel du navigateur. La fonction de navigation en temps réel mis en œuvre dans le noyau du
navigateur fournit les fonctionnalités nécessaires pour établir la communication audio, vidéo et les
canaux de données. Tous les médias et les flux de données sont cryptés en utilisant DTLS.1 Pour
assurer un niveau d'interopérabilité entre les différentes fonctions du navigateur implémentant le
temps réel, l'IETF travaille sur la sélection d'un ensemble minimal d’obligation pour soutenir le
codec audio et vidéo. Opus (RFC 6716) et G.711 ont été sélectionnés pour les codecs audio et VP8
et dernièrement VP9 pour les vidéos. L'API est conçue autour de trois concepts principaux :
MediaStream, PeerConnection, et DataChannel.

2.1.18.1 MediaStreams

Un MediaStream est une représentation d'un flux de données spécifique audio ou vidéo.
Il permet la prise en charge des actions sur le flux média telles que l'affichage, l'enregistrement et
l'envoi à un pair distant. Un MediaStream peut être local ou distant. L'API MediaStream gère les
flux audio et vidéo et indique à l'application qu'elle doit donner accès à la webcam, aux haut-
parleurs et au microphone. Structure de la pile de protocoles utilisée par WebRTC dans un échange
de médias : Afin d'être utilisé, un MediaStream local doit demander l'accès aux ressources
multimédia de l'utilisateur via la fonction getUserMedia (). L'application spécifie le type de média
(audio ou vidéo) auquel elle souhaite accéder et le navigateur autorise ou refuse l'accès à la
ressource demandée. Une fois que le média n'est plus utilisé, l'application peut révoquer son propre
accès avec la méthode stop () sur le flux média local.

Les flux médias sont transportés par le biais du protocole RTP, utilisable sur tout protocole de
transport implémentant une abstraction de datagram. La confidentialité, l’authentification des
messages et la protection contre les répétitions sont assurées par SRTP.
 Figure 12-Structure de la pile de protocoles utilisée par WebRTC dans un échange de
médias.

La gestion des clés pour SRTP est assurée par DTLS et donc par le flux de
données. Il est donc impossible d'avoir un flux média indépendant d'un flux de données là où
l'inverse est envisageable. Il est possible d'associer plusieurs flux médias sur une même connexion
SRTP qui utiliseront des ressources médias différentes ou non. Dans ce cas, les sources de chaque
flux (audio et vidéo) sont clairement identifiées comme des SSRC (Synchronization Source) [8].

2.1.18.2 PeerConnection

L'API RTCPeerconnection représente le lien établi avec un navigateur distant, reposant sur
le protocole UDP (habituellement une autre instance de la même application JavaScript s’exécutant
sur le client distant). Afin d'établir cette connexion paire à pair, il est nécessaire de s'appuyer sur un
canal de communication établi par un serveur web et utilisant par exemple un objet
XMLHttpRequest ou une WebSockets. Une fois la connexion établie par les pairs, les flux de
médias peuvent être envoyés directement dans le navigateur distant.
Pour obtenir une connexion, l'un des pairs doit obtenir les informations locales (telles que les
protocoles supportés pour l'audio ou la vidéo). Cette étape est permise par l'API
RTCPeerconnection via Session Description Protocol. SDP se base sur la RFC 3264 de l'IETF
définissant une approche requête / réponse. Lors de l'établissement d'une session, un pair crée une
requête qui décrit ce qu'il désire faire et l'autre répond en spécifiant les options qui ont été
sélectionnées [15].

RTCPeerconnection (simplement appelé PeerConnection) est un composant qui gère les

communications multimédia entre deux pairs, en s'assurant que les flux sont stables et efficaces. Il
est une API qui contient des fonctions de chiffrement et de gestion de la bande passante. Lors de la
configuration d'une connexion, les deux homologues doivent initialiser leur objet PeerConnection.
Le paramètre de configuration est facultatif et contient des formations pour trouver les serveurs
utilisés par Interactive Connectivity Establishment (ICE), [15]. Il peut y avoir plusieurs serveurs de
chaque type (STUN ou TURN) et si aucune configuration n'est définie, les paramètres par défaut
seront utilisés.

2.1.18.3 ICE: Interactive Connectivity Establishment

ICE est utilisé pour activer les pairs participants pour comprendre comment
échanger Données multimédias. ICE détermine la meilleure voie pour de tels communication
basée sur les informations échangées entre pairs via filaire ou sans fil Interfaces réseau. En
essayant de simplifier le processus de trouver le meilleur chemin à travers NAT, ICE choisit le
l'algorithme le plus efficace pour NAT lorsqu'il tente de créer une connexion à l'aide de
l'adresse IP et du port de l'hôte obtenu via le système d'exploitation et l'appareil Carte
d'interface de réseau. Si cette tentative échoue en raison d’homologue derrière NAT, dans ce
cas, ICE utilise STUN serveur pour générer une adresse IP publique ou externe équivalente
adresse. Et si cela échoue également, un serveur TURN sera utilisé pour acheminer l'adresse IP
publique sur l'appareil de l'autre pair. NAT convertit dynamiquement l'adresse IP privée en une
adresse IP publique lorsqu'une demande sortante est transmise par. De même, les demandes
entrantes vers une adresse IP publique sont reconverties en une adresse IP privée pour garantir
un routage sur le réseau interne. Cela implique que le privé Les adresses IP à elles seules ne
suffisent souvent pas à établir une connexion à un autre pair [16].
2.1.18.4 DataChannel 

L’API DataChannel offre un moyen d'échange de données génériques bidirectionnel et pair

à pair. Cette composante de WebRTC permet l'échange de données telles que des images ou des
textes.Ces canaux de données sont créés entre pairs en utilisant l'objet PeerConnection. Ces données
autres que les flux médias sont échangées via le protocole SCTP, lui-même encapsulé dans
DTLS.Cette solution permet au flux de données d'être intégré dans le même paquet que les flux de
médias et donc de partager le même numéro de port pour les échanges. SCTP supporte nativement
plusieurs flux de données de façon bidirectionnel (jusqu'à 65535 dans chaque direction) au sein
d'une association SCTP et gère les priorités. De cette façon, il est possible de favoriser les messages
de haute priorité face aux gros objets à la priorité basse. Chaque flux représente une connexion
logique unidirectionnelle.

Afin d'assurer la confidentialité et l'authenticité des paquets SCTP échangés, chaque flux repose sur
le protocole DTLS. Au sein d'un canal de données, les applications peuvent transmettre des
messages de façon ordonnée ou désordonnée. L'ordre de remise est préservé uniquement dans le cas
d'une transmission de paquets ordonnés envoyés sur le même lien de données. Un flux de données
est créé lorsque l'un des pairs appelle une méthode CreateDataChannel () pour la première fois
après avoir créé un objet PeerConnection. Chaque appel suivant à CreateDataChannel () créera un
nouveau flux de données au sein de la connexion SCTP existante.

Le protocole DTLS n'a pas pour seul rôle d'encapsuler les paquets SCTP. Dans le cadre d'un
multiplexage avec des flux médias, le protocole DTLS encapsule la gestion des clés et la
négociation des paramètres pour le protocole SRTP, utilisé pour la gestion des flux médias. Il y a
donc dépendance du flux média vis-à-vis du flux de données. C'est un canal bidirectionnel et réside
en tant que composant de l'API PeerConnection [8]. Chaque application utilisant le DataChannel,
on peut le configurer pour fournir les éléments suivants :

 Livraison fiable ou partiellement fiable des messages envoyés (proche du TCP)

 Livraison dans l’ordre ou dans le désordre des messages envoyés (proche de UDP)
Figure 13- Structure de la pile de protocole utilisée par WebRTC dans un
échange des données

2.1.19 WebRTC dans les navigateurs

Le WebRTC est un travail en cours, avec des implémentations avancées sur les navigateurs
Chrome et Firefox. La raison de la création du WebRTC est de s’attaquer aux questions de
confidentialité qui se posent en exposant les parties locales de l’ordinateur, ou en espionnant depuis
l’extérieur les données échangées.

Une application web WebRTC (généralement écrit en HTML et JavaScript) interagit avec des
navigateurs Web par le biais de l'API WebRTC standardisé, ce qui lui permet de bien exploiter et
contrôler la fonction de navigateur en temps réel.

L'API WebRTC doit donc fournir une large fonctionnalité, comme la gestion de connexion (dans un
mode peer-to-peer), l'encodage/décodage pour la capacité de négociation de la connexion, la
sélection et le contrôle, le contrôle des médias, le pare-feu et la traversée du NAT [9].
Figure 14- La communication en temp réel dans le navigateur

2.1.19.1 Chrome

Google Chrome : une intégration de la technologie est arrivée dans la branche de

développement en janvier 2012, et dans la version stable numéro en juin 2012

Figure 15- Logo Google Chrome

2.1.19.2 Mozilla Firefox

Mozilla Firefox : Mozilla a fait une démonstration en avril 2012. Le 8 janvier 2013, Firefox
18 a fait l'objet d'une implémentation préliminaire du WebRTC. La fondation a fait plusieurs
démonstrations de cette fonction au sein de son navigateur. Mozilla a activé, par défaut, WebRTC
dans Firefox 22 sorti le 25 juin 2013. La prise en charge de WebRTC dans Firefox mobile sur la
plateforme Android est incluse depuis la version 24. [9]

Les choses se font plus sérieuses chez Mozilla autour de WebRTC. Cette technologie doit permettre
les communications de type audio et vidéo entre les produits qui l’utilisent. À la différence toutefois
d’un Skype ou de nombreux autres produits pensés pour communiquer, WebRTC peut s’utiliser
sans requérir la moindre création de compte. Un argument d’ailleurs mis en avant par Mozilla dans
son annonce [16].
 Figure 16-Logo Firefox avec WebRTC
2.1.19.3 Interopérabilité

WebRTC ou Web Real-Time Communication, est l’avenir de la communication Web ! Il

s’agit d’une technologie HTML5 qui transforme votre navigateur en un outil de communication
embarquant l’audio et la vidéo. Le seul problème, c’est que celle-ci ne fonctionne que si les deux
utilisateurs sont sur le même navigateur. Mais ça c’était avant ! En effet, en bossant conjointement,
Mozilla et Google ont trouvé un moyen de contourner cela. Les deux sociétés Google et Mozilla ont
annoncé que RTCPeerconnection connu sous le nom plus simple de PeerConnection ou encore PC,
apporte à ses clients l’interopérabilité WebRTC à la fois sur Firefox et Chrome. Ainsi, cela va
permettre aux utilisateurs de ces deux navigateurs de se livrer à des conversations vidéo/audio en
utilisant simplement la puissance du Web au lieu de compter sur des plugins tiers, venant à la
fois ralentir le navigateur, mais pouvant également apporter des failles de sécurité [17] .
RTCPeerConnection est disponible depuis la version bêta 25 de Chrome et la version nightly de
Firefox.

Figure 17-Interoperabilite de FireFox et Chrome

2.1.20 Les fonctionnalités du WebRTC

L’internet n’arrête pas de nous surprendre. En effet, aujourd’hui, pour la première fois depuis
la création de l’univers, les navigateurs peuvent communiquer directement entre eux et ce
nativement, sans “plugin”. Voici les 3 grandes fonctionnalités de WebRTC :

2.1.20.1 Donner accès au navigateur à votre caméra et à votre micro

La capture des flux audio et vidéo peut être utilisée à d’autres fins que le transfert p2p. Il est
possible d’utiliser les Canvas ou WebGL pour créer des effets impressionnants sur la vidéo capturée
(exemple) ou encore de créer des visualisations du flux audio [18].

2.1.20.2 Permettre le transfert p2p des flux audios et vidéo

Ce volet assure le transfert des données récupérées via la première fonctionnalité. De plus, il
assure l’encodage des médias et leur cryptage pour un transfert sécurise. La gestion de la bande
passante est aussi effectuée dans cette partie [1].

2.1.20.3 Permettre le transfert de toutes autres données de l’application en

p2p
WebRTC permet le transfert de toutes données d’un navigateur à un autre. On parle ici
d’une révolution sans précédent pour les applications web et le domaine des jeux vidéo multi-
joueurs dans un navigateur [1].

 Sécurité

La question de savoir si la technologie WebRTC est sécurisée en trouble beaucoup. Le

WebRTC est une technologie open-source disponible gratuitement pour tous les navigateurs (sans
installation de plug-in). Les utilisateurs de WebRTC craignent donc que des hackers puissent
écouter des conférences, accèdent aux données utilisateurs, ou même à leur réseau privé. La sécurité
du WebRTC est donc cruciale. La sécurité a été mise de l’avant avec ce standard par le cryptage des
données obligatoire ainsi qu’une interface utilisateur avec opt-in d’autorisation explicite dans le
navigateur. La sécurité et le cryptage ne sont pas de fonctionnalités optionnelles du WebRTC,
puisqu’il dispose de fonctions intégrées liés à ces aspects. De plus, le WebRTC offre des flux
cryptés entre chaque entité assurant en temps réel la sécurité et la confidentialité des
communications. Le WebRTC requiert que l’utilisateur autorise explicitement l’accès à sa caméra
et à son microphone. Assurant que l’utilisateur soit bien informé que ces périphériques sont activés.
Quand l’utilisateur autorise l’accès, un point rouge apparaît, fournissant une indication claire à
l’utilisateur. Avant d’utiliser le WebRTC, les utilisateurs sont notifiés qu’un site spécifique essaie
d’accéder à leur caméra et microphone. Si un onglet accède à ces périphériques, les utilisateurs sont
aussi notifiés par le navigateur avec un spot rouge clignotant sur l’onglet.

Pour que le WebRTC fasse transiter des données en temps réel, celles-ci sont d’abord cryptées en
utilisant le protocole DTLS (Datagram Transport Layer Security). C’est un protocole inclut dans
tous les navigateurs supportant le WebRTC (Chrome, Firefox et Opera). Sur une connexion
encryptée l’écoute et la falsification d’informations ne peuvent être appliquées. En plus du DTLS, le
WebRTC crypte l’audio et la vidéo via le protocole SRTP (Secure Real-Time Protocol) s’assurant
que les communications IP – votre flux voix et vidéo – ne peuvent être vues ou écoutées par des
tiers. Comme tous ce que vous faites en ligne, comme télécharger une application VoIP du type
Skype, un film, ou même transférer des fichiers par mails, cela présente un risque d’intrusions.
Toutefois, la Technologie WebRTC sécurise la transmission de données sensibles comme expliqué
précédemment, assurant une sécurisation en temps réel des communications. Notons aussi les
composant du WebRTC sont toujours exécuter sur les navigateurs dans un SandBox [19]

 Compatibilité

Les versions à jour de Chrome et Firefox supportent l’API. Bien que la spécification
WebRTC soit relativement stable, tous les navigateurs n'ont pas entièrement implémenté toutes ses
fonctionnalités. De plus, certains navigateurs ont encore des préfixes sur certaines ou toutes les API
WebRTC. Bien que vous puissiez coder manuellement pour résoudre ces problèmes, il existe un
moyen plus simple. L'organisation WebRTC fournit sur GitHub l'adaptateur WebRTC pour
contourner les problèmes de compatibilité dans les implémentations WebRTC de différents
navigateurs. L'adaptateur est un code JavaScript qui permet à votre code d'être écrit selon la
spécification afin qu'il "fonctionne simplement" dans tous les navigateurs prenant en charge
WebRTC. Il n'est pas nécessaire d'utiliser conditionnellement des API préfixées ou d'implémenter
d'autres solutions de contournement. Pour chaque version de chaque navigateur prenant en charge
WebRTC, adapter.js implémente les polyfills nécessaires, établit les noms non préfixés des API et
applique toutes les autres modifications nécessaires pour que le code d'exécution du navigateur soit
écrit selon la spécification WebRTC peut importer le niveau d’incompatibilité du navigateur par
rapport à la Technologie WebRTC10.

10
https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/adapter.js?language=en-US
 Figure 18- Compatibilité des navigateurs avec WebRTC

2.1.21 Les topologies pour la vidéoconférence

Il existe trois approches pour déployer une application de vidéoconférence pluripartite :

Mesh, MCU et SFU [20].

2.1.21.1 L’approche Mesh (Réseau maillé)

Mesh est l’approche par défaut, à savoir que chaque participant va envoyer son média à
chacun des autres participants. Cette approche échoue rapidement au-delà de 3-4 participants, en
termes de limite de la bande passante et de nombre de connexions. Un participant devra
téléverser(Upload) son média à chacun des autres participants et télécharger (Download) le média
de chacun de ceux-ci.
 Figure 19-Illustration du modèle Mesh

2.1.21.2 L’approche MCU

MCU pour Multipoint Conferencing Unit ou Multipoint conferencing unit est l’approche
dans laquelle les différents participants vont tous communiquer avec une unité centrale (un serveur
de media) qui va s’occuper de décoder et encoder les flux audio et/ou vidéo puis mixer ou composer
les différents flux en un seul flux audio-vidéo (mais un seul sera envoyé aux participants). C’est
définitivement la meilleure approche en termes de charge sur le réseau et de nombre de connexions.
Cette approche limite à une connexion entrante et sortante entre le client et le serveur, peu importe
le nombre de participants. Quand le nombre de clients augmente, la complexité de la mise en œuvre
augmente également. Alors en fin de compte, nous obtenons une vidéo de haute qualité en même
temps que cela coûte cher par rapport à d’autres architectures car le serveur de media doit être
puissant en termes de ressources[20].
 Figure 20-Modèle Multiparting Conferencing Unit (MCU).

2.1.21.3 L’approche SFU (Selective Forwarding Unit)

Par ailleurs, la troisième approche SFU propose que chaque participant envoie son média à
un serveur central (le serveur de media) qui s’occupe de le rediriger (router) aux autres participants
si ceux-ci en font la demande. On limite ainsi à un le nombre de téléversement (upload) par rapport
à Mesh (n participants), mais on garde le nombre de téléchargements de flux égal au nombre de
participants, ce qui entraîne une consommation de plus de bande passante pour la liaison
descendante que la
liaison montante.

Figure 21-Modèle Selective Forwarding Unit (SFU).

Choisir le bon modèle pour votre cas d’utilisation

Si on peut croire que MCU est le modèle le plus intéressant, il faut savoir qu’un tel
serveur central doit s’occuper de tous les traitements, à savoir la réception, le décodage des flux, la
composition du nouveau flux, le ré encodage des différents flux et l’envoi : tous des traitements
extrêmement exigeants côté CPU. Plus la taille des flux vidéo augmentera (4k, mais bientôt 8k),
plus ce temps de traitement croîtra largement avec cette approche et un déploiement à grande
échelle basé sur le modèle MCU demande des dizaines, voire des centaines de machines
supplémentaires par rapport à SFU [20].

En fait, c’est l’approche SFU qui est de plus en plus privilégiée dans le contexte
WebRTC, quoique les différentes solutions offrent souvent des modèles hybrides. WebRTC étant
multi-flux par nature, le modèle SFU s’inscrit parfaitement dans cette logique : le client reçoit de
multiples flux audio et vidéo qu’il doit décoder individuellement et afficher à l’écran. SFU limite le
serveur intermédiaire aux tâches simples et peu exigeantes à savoir la réception, la sélection et
l’envoi des flux.

L’approche SFU pure a le désavantage d’être exigeante au niveau de la bande

passante d’un participant qui doit après tout télécharger plusieurs flux on résout ce problème. Ainsi,
certaines approches SFU offrent parfois l’encodage et le décodage des contenus ne serait-ce que
pour pouvoir offrir un contenu adapté aux participants (Adaptative Bitrate Streaming) et ainsi
maximiser l’expérience utilisateur en limitant les interruptions a l’exemple du simulcast ou du
SVC.

L’autre option est d’utiliser un codec supportant l’extensibilité (H.264 SVC / Scalable VP9) ou le
Simulcast pour bénéficier d’une architecture purement SFU avec l’adaptation de contenu. Dans un
tel modèle SFU [20].
 2.2 REVUE DE LITTERATURE

Le domaine de communication en temps réel étant devenu incontournable dans

les systèmes de communication moderne on ne peut manquer ceux qui avant nous ont proposés
des solutions scientifiques et informatique dans le dit domaine. Dans cette partie nous allons
présenter quelques travaux de nos prédécesseurs et montrer le point de démarcation qui existe
entre notre travail et ces derniers.

D. Johansson et M. Holmgren, dans leur articles intitule “Towards Implementing

Web-Based Adaptive Application Mobility Using Web Real-Time Communications,”, ils
expliquent l'importance du système décentralisé. Même si les systèmes centralisés utilisent ici
un serveur de migration pour connecter l'extrémité points. Ce qui entraîne finalement
l'utilisation d'un grand réseau, est susceptible de la perte ou lorsque suppression des nœuds clés
et compliqué par rapport au système décentralisé. Cet article proposait également de résoudre
les problèmes liés au nœud en mettant en place une connexion à des pairs. L'objet de connexion
homologue est créé pour surmonter les problèmes de NAT en utilisant le serveur STUN afin
que l'homologue puisse localiser le nœud qui est en dehors du sous-réseau. Lorsqu'un client
crée une demande de connexion à l'aide de la création d'une offre dans WebRTC, le les
informations sont combinées par le serveur STUN avec les informations locales fournies par le
client et envoyé au serveur. Si le serveur reçoit les mêmes informations du les autres clients
ainsi que le serveur contactera le client qui propose le signal d'origine, alors les deux clients
peuvent se connecter l'un à l'autre. Ces deux appareils sont identifiés et ajoutés au réseau, afin
qu'ils puissent communiquer directement sans aucune exigence du serveur. Ces clients peuvent
facilement se retirer du réseau peer-to-peer en en utilisant des messages de déconnexion. Ainsi,
l’ID de contexte du client est supprimé du serveur. Lorsqu'un client essaie d'abord de se
connecter au réseau, l'appareil exécute un gestionnaire de migration (MM) qui est responsable
du démarrage et de la réception des demandes. Cet article enfin conclut que lorsque les MM
sont intégrés à tous les appareils migrables de notre système, qui sont développés en utilisant
les dernières technologies telles que HTML5, CSS3 et JavaScript. Bien que cet article explique
la migration réussie du serveur depuis un hôte vers un autre hôte, architecture complète et
utilisation efficace de WebRTC mais il ne parvient pas à mettre en œuvre l'environnement
complet.

Dans l'article de B. Sredojev, D. Samardzija, et D. Posarac, intitule “WebRTC

technology overview and signaling solution design and implementation,” Sredojev décrit la
mise en œuvre du WebRTC technologie et sa mise en œuvre de la signalisation client, serveur.
Il déclare principalement que dans les méthodes de signalisation WebRTC ne sont pas
spécifiées pour éviter la redondance et augmenter la compatibilité avec les technologies
établies. Ce processus de signalisation utilise principalement les protocoles tels que SIP
(Session Initiation Protocol), XMPP (Extensible Messaging and Presence Protocol), XHR (Xml
Http Request) et SIP sur WebSocket. Dans cet article pour la signalisation, il utilise SIP sur
Websocket. Dans la connexion WebSocket une fois pair est connecté au serveur, la connexion
reste ouverte jusqu'à ce qu'elle soit fermée.Les messages peuvent être du texte ou des binaires,
ils sont échangés entre les pairs et le serveur.

Dans l’article de A. Heikkinen, T. Koskela, et M. Ylianttila, intitule “Performance

evaluation of distributed data delivery on mobile devices using WebRTC,” ils expliquent
comme quoi l'utilisation de systèmes P-2-P diminue également le point standard et les dépenses.
Il déclare que WebRTC est une application et un plug-in multiplateformes gratuits à utiliser sur
tout type d'appareil. Dans cet article, les auteurs se sont principalement concentrés sur la
performance évolution du WebRTC dans les appareils mobiles avec respectivement des coûts
d'établissement Connexion WebRTC, efficacité du WebRTC dans plusieurs transferts de
données simultanées, l’utilisation des ressources causée par plusieurs transferts de données
simultanés dans WebRTC. Là, les défis de performance des appareils mobiles sont dus à leurs
capacités matérielles, bande passante sans fil et autonomie de la batterie. Arto Heikkinen a fait
leur performance évolution sur WebRTC sur les appareils mobiles en termes de fichiers
simultanés multiples transferts, délai d'établissement de session et surcharge. Les auteurs l'ont
fait pleinement mise en œuvre de l'architecture WebRTC avec différents appareils mobiles et
différentes combinaisons de bande passante et de navigateurs.

Dans l’article de M. Phankokkruad et P. Jaturawat, avec pour titre “An evaluation

of technical study and performance for real-time face detection using Web Real-Time
Communication,”, parle surtout de la technique de détection de visage et ses avantages en
temps réel les communications ont été expliquées. Les techniques de détection de visage ont
généralement des dépendances comme la plate-forme ou le système d'exploitation Windows.
Cet article explique comment résoudre ces problèmes type de problèmes en utilisant l'API de
script java qui sont facilement table Integra et peuvent être utilisées dans les communications en
temps réel. Cet article a également évalué deux détections de visage différentes technique
d'algorithmes, CLM Constrained Local Model et CCV. Enfin ils ont conclu par dire que la
détection de visage peut jouer un rôle clé dans WebRTC. WebRTC a aussi interprété très bien
en termes de détection de visage dans divers scénarios tels que la bande passante sur Wifi et
Lan, efficacité du tracking etc. Enfin, cet article propose que l'algorithme CLM soit ayant le
plus d'importance pour détecter le visage dans presque toutes les conditions d'éclairage.

Dans l'article, G. Carullo, M. Tambasco, M. D. Mauro, et M. Longo, intitule “A

performance evaluation of WebRTC over LTE,” il est montré que l'évolution des
performances du WebRTC sur LTE est terminé. LTE est également une technologie qui aide les
téléphones mobiles à communiquer sur les données mobiles (4G). Dans cet article, l'évaluation
des performances se fait sur la base du débit, de la gigue, de la perte de paquets. Cette
expérience est menée dans le NS-3 L'environnement pour le LTE et le WebRTC est hébergé sur
un PC utilisant Node.Js. Cette procédure expérimentale se fait dans 4 scénarios différents. Pour
les travaux futurs, ce document a proposé l'évolutivité de l'augmentation du nombre de nœuds.

2.3 SPECIFICATION D’EXIGENCES LOGICIELLES

Dans cette partie de notre travail nous allons décrire le comportement externe de
notre système. Nous allons donner une idée globale décrivant comment notre système
fonctionnera et nous allons aussi décrire les caractéristiques des utilisateurs de notre système.
2.3.1 Description globale

2.3.1.1 Perspective du logiciel

Pour la mise en place du système de communication de l’entreprise grâce

à la technologie WebRTC, nous aurons besoin de réaliser une application web, qui devra être
héberge sur un serveur d’application de l’entreprise. Les personnels de celle-ci devront avoir un
appareil avec un navigateur installe, au besoin il doit être à jour. Ce système fonctionnera de la
manière suivante : les navigateurs A et B de deux personnels qui désireront communiquer
doivent être connectés simultanément à la page du service (serveur d’application de
l’entreprise) et télécharger la page HTML ainsi que le code JavaScript permettant de maintenir
la connexion ouverte par HTTPS ou socket. Lorsque le navigateur « A » souhaite établir la
connexion avec « B », l'API instancie un objet PeerConnection qui, une fois créé, permet
d'établir des flux de médias ou de données. Il est aussi nécessaire, pour une vidéoconférence par
exemple, que les utilisateurs A et B acceptent le partage de leur webcam et/ou de leur
microphone.

Une fois cet objet PeerConnection créé par « A », le navigateur envoie au serveur
d’application, un paquet contenant les informations sur les médias partagés ainsi qu'une empreinte
liant la connexion à « A ». Le serveur va décoder ce paquet et identifier qu'il s'agit d'une
communication à destination de B et enverra donc un signal à « B ». « B » est notifié du souhait de
A d'établir une connexion et accepte ou non sa requête. Si elle est acceptée, le même processus a
lieu entre « B » et « A » cette fois afin d'établir la connexion bidirectionnelle. Une fois celle-ci
 établie, les flux de médias ou de données peuvent être ajoutés à la connexion librement. La
démarche est résumée comme suit :

 1 : A demande au serveur une connexion avec B.

 2 : Le serveur relaie la demande de A.

 3 : Si B accepte, il envoie une demande de connexion à A.

 4 : Le serveur relaie la demande à A.

 5 et 6 : Les PeerConnection bidirectionnelles sont établies.

2.3.1.2 Fonctionnalités du logiciel

Enfin qu’un personnel de l’entreprise puisse avoir accès au système il devra avant tout, créer
un compte utilisateur. Pour que le personnel puisse être capable de lancer ou de rejoindre un appel
vers les autres personnels de l’entreprise, il faudra que ceux-ci se loguent enfin que l’on sache ceux
qui sont connectés voir même appliquer certain droit d'accès sur certaines ressources. Signalons que
l’initiateur de l’appel sera d’office l’administrateur. Après s’être logue le personnel pourra initier ou
rejoindre un appel vocal, une discussion instantanée, effectuer un appel vidéo, rejoindre une vidéo
conférence entre les personnels, effectuer un transfert de fichier, suivant leurs domaines de service
(service financier, économie, administration …), avec ses confrères grâce à un navigateur web. Les
personnels avec leurs domaines de service ainsi que les conversations texte des personnels seront
enregistré dans la base de données.

2.3.1.3 Caractéristiques des utilisateurs

Une fois réalisé cette application web qui permet une communication entre deux
ou plusieurs personne sera utilisable dans toute entreprise ou organisation désirant son propre
système de communication à faible coût. L’entreprise ou organisation qui adoptera ce système
doit être équipe d’ordinateurs sur les postes de travail de personnels ou appareil ayant un
navigateur installe, au besoin il doit être à jour. Le système exige que les employés sachent
comment naviguer sur un site internet avec un navigateur.

2.3.1.4 Dépendances et suppositions

Avant tout il faudra s’assurer que le serveur d’application qui héberge l’application
JavaScript est en marche si non l’application web ne sera pas disponible sur le réseau. De même
le serveur de base de données doit avoir été démarré car c’est lui qui stocke les informations du
système de communication. Quant au navigateur des appareils informatiques, ils devront être à
jour enfin de bénéficier des dernières fonctionnalités de la technologie WebRTC et éviter des
bugs qui pourrait exister avec les versions précédentes du navigateur.

2.3.1.5 Fonctionnalités reportées à une version ultérieure

Le cas où les personnels voudront collaborer entre eux via internet ou établir une
communication avec une personne de l’extérieur via internet sera ajouté dans la version
ultérieure de cette application.

2.3.2 Performance

Notre travail utilisera la technologie WebRTC pour atteindre l’objectif qu’on s’était fixe, c’est
pourquoi le système a réalisé d’office héritera des performances du WebRTC. Compte tenu des
nombreux avantages que WebRTC offre aux utilisateurs et aux développeurs, il est logique de
savoir pourquoi il y a tant de battage médiatique autour de lui. Tout, de la livraison à faible
latence à l'interopérabilité, en fait un choix attrayant11.

 Latence intrinsèquement faible :

La technologie WebRTC le fait sortir du parc en ce qui concerne la vitesse de

livraison. Avec une latence verre à verre inférieure à 500 millisecondes, WebRTC offre la
méthode la plus rapide pour transporter la vidéo sur Internet.

 Indépendance des plates-formes et des appareils :

Tous les principaux navigateurs modernes et appareils prennent en charge

WebRTC, ce qui facilite l'intégration dans une large gamme d'applications sans
infrastructure dédiée. Étant donné que WebRTC utilise des API HTML5, il vous permet
d'utiliser de nombreuses fonctionnalités intégrées dans le langage de programmation HTML5
via un cadre léger et intégré. De plus, le codage basé sur le navigateur garantit une expérience
utilisateur plus accessible pour tous.

 Open Source et standardisé :

11
https://www.wowza.com/blog/what-is-webrtc
 Le framework open-source est normalisé par l'IETF et le W3C, éliminant ainsi tout
défi d'interopérabilité lié aux technologies de streaming propriétaires. Shan Sinha, de Computer
world, explique : « WebRTC profite du fait que des milliers de développeurs de logiciels y
travaillent de concert, normalisent les protocoles de conférence et réduisent l’interopérabilité.
La plupart des entreprises ne peuvent pas rivaliser avec des milliers de développeurs
indépendants contribuant au code d'une plate-forme - même des organisations aussi grandes que
Google et Apple font pâle figure par rapport à un effort mené par la communauté Web"

 S'adapte aux conditions du réseau.

WebRTC garantit une publication fiable dans des conditions de réseau

médiocres avec un codage réseau adaptatif. C’est parce qu’il prend en charge une capacité
appelée « diffusion simultanée » - à ne pas confondre avec la diffusion vers plusieurs
destinations, qui est la définition traditionnelle de ce terme. Avec la diffusion simultanée
WebRTC, le client génère plusieurs flux à des débits et une qualité variable, de sorte que les
mauvaises conditions du réseau ne gênent pas la contribution vidéo. Contrairement au
streaming à débit adaptatif, où le flux s'ajuste dynamiquement pendant la lecture, cela a lieu du
côté de la publication et fournit plusieurs encodages plutôt que la possibilité d'adapter le débit
binaire au milieu du flux.

 Qualité vocale et vidéo avancée

WebRTC utilise le codec audio Opus qui produit une voix haute-fidélité. Le codec
Opus est basé sur la technologie de codec SILK de Skype. Le codec VP8 est utilisé pour la
vidéo. Ces sélections garantissent l'interopérabilité et évitent d’avoir à télécharger des codecs
susceptibles de contenir du code malveillant12.

 WebRTC lui-même ne nécessite pas de processeur puissant,

Il fonctionnera bien sur les vieux ordinateurs. Avec l’architecture Mesh du WebRTC,
qui est par défaut lorsque le navigateur capture une vidéo brute à partir d'une caméra Web, il
doit l'encoder dans un format compact et l'envoyer au réseau et cela à tous les pairs en
12
https://www.networkcomputing.com/networking/9-advantages-webrtc
communication. De plus, lorsque vous recevez un flux vidéo / audio venant d’autres
utilisateurs, vous devez le décoder et le lire sur votre écran / casque. Cette architecture est
réalisable tant que le nombre de participants est petit au maximum 3-6 utilisateurs selon la
bande passante ou la puissance de calcul disponible. Mais cette architecture est avantageuse en
termes de coût du fait que la connexion est directe de bout à bout sans serveur central. Pour que
le mécanisme d'encodage / décodage consomme du CPU. Plus la qualité vidéo est élevée, plus
la charge du processeur est importante. Plus vous avez besoin de vidéos à traiter, plus la charge
du processeur est importante. On résout ce problème en faisant recours à un serveur de media
qui se charge d’envoyer les media des différents utilisateur une fois reçu en provenance de
chacun des utilisateurs. La limite maximale de connexions homologues est de 256 (sur
chrome). Cela signifie que 256 utilisateurs peuvent être interconnectés. Mais L'établissement de
plusieurs connections entraînera une utilisation énorme du processeur et de la bande passante.

P2P (MESH) SELECTIVE MULTIPOINT

FORWORDING CONTROL
UNIT(SFU) UNIT(MCU)

Débit en Upload Élevé Faible Faible

Débit en Download Élevé Faible Élevé

Utilisation du CPU Élevé Faible Moyen

client

Utilisation du CPU - Élevé Faible

serveur

Latence possible Dépend de la bande Dépend de la Dépend de la

passante réseau puissance du bande passante
processeur réseau
Capacité de - Oui Non
Transcodage

Capacité de diffusion - - Oui

simultanée/SVC

Performance du système selon le model choisi

2.4 Fiabilité
WebRTC est un projet ouvert et gratuit qui fournit aux navigateurs et aux
applications mobiles des capacités de communication en temps réel (RTC) via de simples API.
WebRTC représente également la dernière évolution dans le monde de la communication en
temps réel. WebRTC réutilise de nombreux protocoles et standards (SDP Protocol, RTP,
RTCP) pour créer des communications en temps réel entre différents appareils. D'autres
normes, telles que TURN / ICE / STUN, sont également utilisées par WebRTC. La complexité
de l'utilisation de ces normes est cachée derrière un simple ensemble d'API JavaScript au sein
du navigateur, qui sont immédiatement disponibles pour les développeurs via les navigateurs.
WebRTC donne vie au meilleur des technologies de communication en temps réel standardisées
et, dans la plupart des scénarios, permet de véritables communications peer-to-peer entre les
terminaux. Afin de garantir la confidentialité, un cryptage de pointe a été choisi à l'aide de
DTLS. WebRTC prend en charge les codecs audio suivants : Opus, G.711a, G.711u et G.722
sont utiles pour permettre les communications avec les points d'extrémité SIP standard. Lorsque
les deux terminaux sont compatibles WebRTC, Opus est le meilleur choix.Les codecs vidéo
pris en charge sont VP8 et h264. Chrome a également récemment ajouté la prise en charge de
VP913.

2.5 Sécurité

13
https://blog.wildix.com/webrtc-real-time-communications/
 Av
optionnelles. Toutes les données transmises sont toujours cryptées en utilisant les protocoles
DTLS et SRTP. Les données transmises ne peuvent donc être ni lues ni vues ni écoutées ou
falsifiées par un tiers. Les données sont partagées en Peer-to-peer, c’est-à-dire directement
entre les interlocuteurs sans passer par un serveur intermédiaire. Il n’y a aucun moyen
d’utiliser le WebRTC sur des sites Web non desservis par HTTPS. Cela signifie que le
WebRTC oblige les développeurs à utiliser des connexions sécurisées. Le WebRTC requiert
que l’utilisateur autorise explicitement l’accès à sa caméra et à son microphone, assurant que
l’utilisateur soit bien informé que ces périphériques sont activés. Il ne requiert pas de
télécharger un logiciel, ce qui réduit les risques d’intrusion Dernier point, mais non des
moindres : étant une technologie en Open-source, le WebRTC tirerait avantage au quotidien de
la collaboration de milliers de développeurs de la communauté internet ce qui facilite la
détection d’un code malveillant s’il y en a. Couplez cela au fait que tous les navigateurs l’ont
intégré : vous obtiendriez une qualité de maintenance et d’amélioration hors du commun,
continue, et gratuite.

2.6 Portabilité
Le fait que la technologie WebRTC soit intégrée dans une application web fait à ce que
le système de communication que nous allons réaliser soit portable. Cad on pourra l’héberger
sur n’importe quel serveur de l’entreprise dédié pour recevoir l’application Web sans se soucie
de son environnement ni de son système.

Dans ce chapitre nous avons tout d’abord défini certains concepts clés de notre travail,
ainsi que passé en revue la littérature et enfin chuté par les exigences logicielles.

CHAPITRE 3. METHODOLOGIE ET CONCEPTION

Les chercheurs en informatique utilisent plusieurs méthodes de recherche scientifiques,

notamment la revue de la littérature, le prototypage, de la preuve mathématique, de
l’expérimentation, de l’enquête, de l’étude des cas, de l’argumentation de la conception
d’algorithme ou de la simulation [22].

Dans ce chapitre nous expliquons les méthodologies utilisées pour la collecte et

l’analyse des données pour parvenir à la résolution des problèmes que nous avons invoqués ci-
haut. Notons que les méthodes de recherche nous ont servi de règles à suivre mais aussi d’un
guide de raisonnement Pour arriver à matérialiser les différents objectifs que nous nous sommes
fixés au début de ce travail.

Quant à la méthodologie utilisée nous nous focaliserons sur la revue de la littérature

la modélisation, ainsi que la simulation, et l’expérimentation tandis que pour les techniques
utilisées nous utiliserons la documentation et le prototypage pour achever le présent travail.

Les outils, quant à eux, nous ont permis de s’assurer de la bonne évolution de notre
travail en tenant compte des limites de notre sujet de recherche enfin de concevoir et réaliser
notre système.

3.1 METHODOLOGIE ET TECHNIQUES

3.1.1 METHODES

La méthode peut être définie comme « un ensemble d’opérations intellectuelles

permettant d’analyser, de comprendre et d’expliquer la réalité étudiée ». Selon GRAWITZ
Madeleine, elle est définie comme « un ensemble des opérations intellectuelles par lesquelles
une discipline cherche à atteindre les vérités qu’elle poursuit, les démontre et les vérifie ». [23]
[24]

3.1.1.1 Revue de littérature

Étant donné que nous ne sommes pas le seul à traiter un sujet du domaine de la
communication en temps réel, et que dans le passé plusieurs autres chercheurs ont déjà abordé
ce concept de différentes façons. Pour épingler la richesse et l’originalité du présent travaille
nous avons procédé par la collecte et la lecture d’un certain nombre d’ouvrages traitant la
communication en temps réel en usant la technologie WebRTC. En effet, cette revue, vue la
surabondance des données et la variété des supports, nous a permis non seulement à mieux
énoncer la problématique de notre travail par rapport aux recherches précédentes, mais aussi à
identifier des documents fiables que nous avons consultés. Elle nous a, essentiellement, été utile
lors de la rédaction de ce travail en entièreté et elle nous a également permis de mieux
comprendre le fonctionnement de la technologie que nous voulons utiliser pour résoudre le
problème évoqué ci-haut.
3.1.1.2 Modélisation

Pour mieux maîtriser la complexité de notre système nous nous sommes servis de la
méthode de modélisation. Cette méthode nous a permis de réduire la complexité du système à
réaliser en éliminant les détails qui n'influencent pas son comportement de significative. Pour la
construction de notre système nous avons utilisé le langage de modélisation UML. (Langage de
Modélisation Unifié). Le langage 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, OOSE. Il est à présent
un standard défini par l’Object Management Group (OMG). UML est un langage visuel
constitué d’un ensemble de schéma, appelés des diagrammes, qui donnent chacun une vision
différente du projet à traiter [22].

Nous avons porté notre choix sur le langage UML, car ce dernier renferme un
certain nombre d’avantages14 : « UML c’est un langage formel et normalisé, il permet un gain
de précision et de stabilité. Il permet également, grâce à sa représentation graphique, d’exprimer
visuellement une solution objet, de faciliter la comparaison et l’évolution de solution. Son
caractère polyvalent et sa souplesse en font un langage universel » [24]

Lors de la conception de notre application web de communication en temps réel et

grâce à l’outil Astah Community, avec la méthodologie UML nous nous baserons sur ses trois
axes de modélisation : axe fonctionnel, axe statique et axe dynamique.

14
https://www.memoireonline.com/12/09/2917/m_Algorithmes-dapprentissage-pour-la-classification-de-
documents3.html/
 Figure 22-Les axes du Langage UML

3.1.1.2.1 Axe fonctionnel

L’axe fonctionnel nous permettra de représenter les différents cas d’utilisation, les
interactions entre les acteurs et voir qui fait quoi dans le système. A part cela dans cet axe il
existe aussi le diagramme de séquence ou d’activité pour la représentation des acteurs et leur
fonction dans le système.

3.1.1.2.2 Axe statique

Cet axe nous aidera a représenté les objets et entités du système. Par cette
représentation on sera en mesure d’élaborer le diagramme de classes, de paquetage, de
déploiement et le diagramme de structure composite. Notons que ce dernier ne sera pas abordé
Le diagramme de classe est le point central dans un développement orienté objet. Cet ainsi que
l’axe statique de notre système sera centré sur le diagramme de classe car ce diagramme met en
œuvre des classes, qui sont constitués des attributs et des opérations, et reliées par des
associations, dans le but d’avoir une idée claire sur le code qui constituera la partie logicielle de
notre système.

3.1.1.2.3 Axe dynamique

Cet axe nous donne un aperçu sur le diagramme d’activité étant le point central dans
l’axe dynamique. Ce diagramme est un ensemble de scénarios alternatifs avec exceptions si
elles existent. Car avec le diagramme de cas d’utilisation il est souvent difficile de représenter
toutes les actions d’un acteur.

3.1.1.3 Simulation

Pendant l’évolution de la réalisation du système on n’a toujours pas besoin d’avoir

tous les équipements. L’informatique offre les outils qui permettent de faire la simulation des
opérations se passant dans le système. Au cours de notre réalisation, nous avons procéder à la
simulation de certains matériels suite à l’inaccessibilité de ces derniers, notamment les
matériels réseaux (router), serveur de media.

3.1.1.4 Expérimentation
 Sachant que l’expérimentation faisant référence au fait d’apprendre ou de découvrir
par la pratique et l'expérience, personnelle ou scientifique. L’expérimentation est une méthode
bien adaptée aux travaux de simulation. Plusieurs tests de notre application nous ont permis
d’expérimenter la solution car en seul l’observation ne suffit pas. Cette méthode permet
également de comprendre les exigences ou contraintes du système comme par exemple le type
de serveur, logiciel à utiliser, l’environnement qu’il faut surtout pour notre cas la version du
navigateur a utilisé. Par cette méthode nous avions effectué le teste de nos hypothèses pour voir
s’ils sont valides ou non. Après plusieurs tests de notre application nous avons réalisé que la
solution de notre application a atteint son objectif.

3.1.2 TECHNIQUES

3.1.2.1 Technique documentaire

C’est une technique permettant de consulter tous les documents nécessaires en vue
de l’obtention des informations fiables. Ces documents peuvent être des natures très variées
comme par exemple des livres, des travaux de fin d’étude, des ouvrages, des revues et différents
sites web pour une bonne compréhension de notre sujet.

3.1.3 OUTILS DE TRAVAIL

Lors du développement de notre système de communication en temps réel

fonctionnant dans une organisation nous nous somme servis des outils suivants :

3.1.3.1 Environnement matérielle cote Hardware

 Ordinateur : l’ensemble des outils présentés ci-haut ont été exécuté sur un
ordinateur de marque HP Probook ayant :

- Disque dur : 500 Go ;

- Modèle du processeur : Intel i3 ;

- Vitesse du processeur : 2.3 GHz ;

- Mémoire RAM : 4 Go
  Téléphone : Sachant que l’application web que nous avons développé doit
fonctionner sur un téléphone mobile via son navigateur elle a été testée sur un
téléphone Android de marque TECNO K7 en utilisant le navigateur Chrome et
Firefox

3.1.3.2 Environnement de développement et autres logiciels :

 Système d’exploitation Linux Debian x 64 : Debian est un système d'exploitation libre,
gratuit et communautaire, basé sur le noyau Linux et démarré en 1993 par Ian Murdock avec
le soutien de la Free Software Foundation. Avec l'une des plus grandes communautés open
source au monde (plus de 1600 développeurs), le projet Debian est la distribution la plus
complète disponible, avec près de 30 000 packages dans la version 6. La distribution est
éditée en accord avec la philosophie communautaire qui a donné naissance au logiciel libre,
et constitue une référence en termes de qualité et de stabilité. Debian est une distribution
GNU/Linux non commerciale 15.

 Node.js : Node.js est un environnement d’exécution open source et multiplateforme pour le

développement d’applications cote serveur et réseau. Node.js est construit sur
l’environnement d’exécution Javascript de Chrome pour créer facilement des applications
réseau rapides et évolutives. Node.js utilise un modèle d'E/S non bloquant basé sur les
événements qui le rend léger et efficace, parfait pour les applications en temps réel
gourmandes en données qui s'exécutent sur des appareils distribués16. Node.js étant juste un
environnement d’exécution il nous a permis d’exécuter du code javaScript du cote serveur .
Notre choix d’utiliser cette technologie est dû au fait que Nodejs permet la conception des
applications réseau de haute performance et rapide, comparativement aux applications
réseaux réalisées avec un autre langage de programmation.

 Visual studio code : Visual Studio Code est un éditeur de code source créé par Microsoft
pour Windows, Linux, MacOs. Les fonctionnalités incluent la prise en charge du débogage,

15
https://www.debian.org/index.fr.html

16
https://www.tutorialspoint.com/nodejs/nodejs_introduction.htm
 de la coloration syntaxique, de la complétion intelligente du code, Les utilisateurs peuvent
modifier le thème, les raccourcis clavier les préférences et installer des extensions qui ajoutent
des fonctionnalités supplémentaires. Cet outil nous a aidé à faire la saisie des codes de
langages de programmation, notamment, le HTML, le CSS et le JavaScript.

 Nginx : Nginx est un logiciel open source pour le service Web, le proxy inverse, la mise en
cache, l'équilibrage de charge (load balancing), la diffusion multimédia en continu
(Streaming), etc. Il a commencé comme un serveur Web conçu pour des performances et
une stabilité maximale17.Nous avons utilise Nginx suite a sa performance dans le media
streaming sa latence est faible par rapport à son concurrent apache.

 Astah Community : Nous avons utilisé cet outil dans la conception des modèles qui
constituent notre système. Par cet outil, nous avons réalisé les différents diagrammes
représentant le fonctionnement de notre système.

 MongoDB : MongoDB est un système de gestion de base de données No-SQL orientée

document. Elle est utilisée pour le stockage de volumes massifs de données. Contrairement à
une base de données relationnel SQL traditionnelle, MongoDB ne repose pas sur des
tableaux et des colonnes. MongoDB stocke les données dans des documents flexibles de
type JSON, ce qui signifie que les champs peuvent varier d'un document à l'autre et que la
structure des données peut être modifiée au fil du temps. Il est écrit en C++. L’utilisation de
MongoDB a été motive par le fait que les base de donne No-SQL sont mieux équipé pour
gérer les énormes quantités de données produit par les applications en temps réel et ont été
conçue avec la vitesse comme considération principale .

3.1.3.3 Les langages de programmation

 JavaScript : est un langage de programmation employé dans les pages web Interactives
mais aussi pour les serveurs avec utilisation (par exemple) de Node.js. C’est un langage orienté
objet en prototype, c’est-à-dire que les bases du langage et ses principales interfaces sont
fournies par des objets qui ne sont pas des instances de classes, mais qui sont chacun équipés

17
https://www.nginx.com/resources/glossary/nginx/
des constructeurs permettant de créer leurs propriétés, et notamment une propriété de
prototypage qui permet d’en créer des objets héritiers personnalisés18.

 HTML : est un langage utilisé pour créer de pages web. Il est supporté et développé par
L’organisationW3C.

 CSS : CSS est l'acronyme de « Cascading Style Sheets » ce qui signifie « feuille de style en
cascade ». Le CSS correspond à un langage informatique permettant de mettre en forme des
pages web (HTML).

 UML : est un langage de modélisation, il nous a permis de faire la conception et La

modélisation de notre système avec différents diagrammes.

3.2 CONCEPTION DU SYSTEME

Dans cette partie il est question de comprendre le fonctionnement de notre

système mais aussi modéliser et concevoir notre application web fournissant une
communication en temps réel.

3.2.1 BESOIN FONCTIONNELS :

Dans le but de permettre une communication sécurisée entre employés d’une
entreprise, notre système est constitué des fonctionnalités suivantes :

A. Du côté matériel

Du côté matériel, le système nécessite la mise en place d’une architecture réseau

dans l’organisation, où les utilisateurs du système pourront se connecter à un serveur web
lequel sera à son tour connecter à un serveur de base de donnes pour stocker des messages
texte et audio échangés.

Sans la connexion au serveur, et l’authentification, les personnels de l’organisation

ne peuvent pas accéder au système. C’est ainsi que l’organisation doit mettre en disposition des

18
https://googleweblight.com/i?u=https://fr.m.wikipedia.org/wiki/JavaScript
moyens matériel comme un ordinateur par poste de travail (sur lequel est installé un navigateur
qui doit être à jour), un réseau local (avoir des équipements comme des routeurs, points d’accès
ou même des commutateur-Switch) pour permettre à un grand nombre de personnel de se
connecter au système. Notons qu’un serveur de media est nécessaire pour accroître le nombre
des personnels qui doivent participer à une vidéo conférence (SFU).

B. Du cote Logiciel

 Gestion des comptes utilisateur des personnels de l’organisation : Lorsqu’un

personnel est enregistré dans le système, le système lui génère automatique un compte
utilisateur permanent ce qui permet de l’identifier ainsi que gérer ses droits d’accès
chaque fois qu’il se connecte au système .

 Initier un appel vidéo ou audio : Cette fonctionnalité du système permettra aux

correspondants de se voir en même temps qu’ils discutent mais avec une possibilité de
communiquer en audio seule ,en éteignant la camera

 Faire un partage d’écran : Ceci permettra à l’utilisateur la diffusion facile et rapide du

contenu présent sur son écran avec son inter loculaire.

 Échange des messages textuels : Ceci permettra à l’utilisateur d’échanger des messages en
temps réel entre utilisateurs connectée au réseau.

 Effectuer un transfert de fichier : Ce système devra permettre le partage et la réception

des fichiers entre utilisateurs connectée au réseau.

 Initier une vidéo conférence: La tenue d’une réunion virtuelle étant un besoin plus que
souhaité dans la plupart des organisations moderne notre système possédera cette
fonctionnalité en vue de satisfaire ce désir , en plus étant dans une période de pandémie et
sachant que parmi les mesures barrière à observer figure la distanciation entre les gens, cette
fonctionnalité de vidéo conférence viendra en renfort aux mesures barrière dans le milieux
 d’organisation du fait que la réunion pourra se dérouler sans la présence physique des
participants dans une même pièce.

 Consulter la liste des réunions en cours : Les personnels connectée auront la possibilité
de consulter la liste des réunions virtuel qui sont en cours et celles qui ont été planifiée par le
chef de service ou dans l’organisation entière.

 Invitation d’un ou plusieurs personnels : cette invitation permet de choisir de façons

ciblée les personnels qui sont convier à participer à un échange au sein de l’entreprise. Les
invitations différentes selon la portée (ou étendu à couvrir) choisi, elle peut être prive (entre
personnels), entre personnels d’un service ou entre personnels dans toute l’organisation.

3.2.2 VUE FONCTIONNELLE

 Diagramme des cas d’utilisations

Un diagramme de cas d’utilisation est un graphe d’acteurs, un ensemble des cas

d’utilisation englobés par la limite du système, des associations de communication entres les
acteurs et les cas d’utilisation. Ce diagramme est destiné à représenter les besoins utilisateurs
par rapport aux systèmes [25]. Pour ce diagramme, on distingue trois concepts principaux :

 Acteur : c’est un utilisateur ayant la même attitude dans un cas d’utilisation et selon le
rôle qu’il joue dans le système. Il n’est pas nécessairement une personne, il peut aussi s’agir
d’un autre système considéré comme externe. Un acteur est représenté par un bonhomme.

 Cas d’utilisation : c’est un ensemble d’actions ou d’évènements que le système doit faire
à une requête de l’utilisateur.
 Interaction : c’est une description de la communication entre l’acteur et le cas
d’utilisation.
3.2.3 VUE DYNAMIQUE

 Diagrammes d’activités

Ce diagramme donne une idée sur l’enchaînement des activités propres à une
opération ou un cas d’utilisation. Le diagramme d’activité est attaché à une catégorie des
classes et décrit le déroulement des activités de cette catégorie. Le déroulement s’appelle « flot
de contrôle ». Il indique la part prise par chaque objet dans l’exécution du travail. Il sera enrichi
par les conditions de séquence [26].

Diagramme d’activité de cas « création d’un compte utilisateur »

Figure 23-Diagramme d’activité de cas « création d’un compte utilisateur »

Commentaire : Pour créer un compte utilisateur, Seul l’administrateur doit d’abord
s’authentifier. Si l’authentification est correcte, il va choisir l’option utilisateur.
L’administrateur fait une demande de formulaire, le système renvoie une réponse en retournant
un formulaire à remplir puis saisit les informations de l’utilisateur après il spécifie le droit de
devenir initiateur ou modérateur d’une réunion de service ou de l‘organisation entière, aux
chefs de services et de l’organisation, et enfin, il valide la création du nouveau compte du
personnel de l’organisation.

 Diagramme d’activité de cas « Authentification »

Figure 24-Diagramme d’activité cas « S’authentifier »

Commentaire : Après le lancement de l’application, l’utilisateur doit s’authentifier en
spécifiant son numéro matricule et son mot de passe. Si le numéro matricule et le mot de passe
correspondent à un compte, le système retourne la page d’accueil ou le personnel peux initier
un échange prive avec ses collaborateurs et consulter les réunions en cours et celles qui sont
planifiées ultérieurement dans la journée. Si l’utilisateur est un chef d’un quelconque service
dans l’organisation il pourra initier une réunion ou seul les membres de son service pourront
participer.

 Diagramme d’activité cas « créer/participer/se déconnecter »

 Figure 25-Diagramme d’activité cas « créer/participer/se déconnecter »

Commentaire : Pour initier ou participer à un échange avec ses collaborateurs, l’utilisateur qui
est un personnel de l’organisation doit d’abord s’authentifier et une fois que l’authentification
est correcte, le système va lui afficher une page d’accueil. Depuis sa page d’accueil le personnel
pourra initier un échange vidéo, le partage d’écran, message textuel, un transfert de fichiers.
  Les diagrammes de séquence

Ces diagrammes précisent la logique séquentielle su système et les relations inter

fonctionnelle. Ils permettent de décrire les scénarios des cas d’utilisation en mettant l’accent sur
la chronologie des opérations en interaction avec les objets. La séquence fait apparaître les
interactions entre les éléments sous forme d’échanges observables présentée en séquence de
temps. En particulier, il montre aussi les objets qui participent à l’interaction par leur ligne de
vie et les messages qu’ils échangent présentées en séquence dans le temps [24]

Certaines notions de base sont très capitales sur le digramme de séquences parmi
lesquels on peut citer [25] :

 Scenario : une liste d’actions qui décrivent une interaction entre un acteur et système.

 Interaction : un comportement qui comprend un ensemble de messages échangés par un

ensemble d’objet dans un certain contexte pour accomplir une certaine tâche.

 Message : un message représente une communication unidirectionnelle entre objets qui

transporte de l’information avec l’intention de déclencher une réaction chez le récepteur.

 Diagramme de séquence du cas « créer son compte »

Figure 26-Diagramme de séquence du cas « créer son compte »
 Diagramme de séquence du cas « S’authentifier »

Figure 27-Diagramme de séquence du cas « S’authentifier »

 Diagramme de séquence du cas « créer/participer/se déconnecter »
Figure 28-Diagramme de séquence du cas « créer/participer/se déconnecter »
3.2.4 VUE STATIQUE

 Diagramme de classes

C’est une collection d’éléments de modèle statique, tels que des classes, des
interfaces et leurs relations, connectés entre elles comme un graphe [27].

Il représente la description statique du système en intégrant dans chaque classe la

partie dédiée aux données et celle concentrée aux traitements. C’est le diagramme pivot de
l’ensemble de la modélisation d’un système [28].

Figure 29-Diagramme de Classe

 Une classe est une description d’un groupe d’objet partageant un ensemble commun de
propriétés (les attributs), de comportements (les opérations) et de relations avec d’autres objets
(les associations et les agrégations) [29].

Une classe contient :

 Des attributs ou champs ou variables d’instances : ces attributs décrivent la structure

des objets ou instances.

 Des méthodes ou opération de la classe : elles décrivent les opérations qui peuvent
s’appliquer aux instances de la classe.

Pour décrire les connexions structurelles entre les instances de classe qu’un diagramme de
classe possède, celle-ci utilise différentes associations, parmi lesquelles nous citons :

 L’agrégation : c’est une association qui correspond à une relation qui se lit « « est
une partie de » lorsqu’elle est lue dans un sens et « est composé de », lorsqu’elle se lit
dans l’autre sens.

 La composition : elle est aussi appelée agrégation composite ; elle décrit contenance
structurelle entre instance comme l’agrégation à la différence que la destruction de l’objet
composite implique la destruction de ses composants. Une instance de la partie appartient
toujours à au plus une instance de l’élément composite.

 Diagrammes de déploiement
 Un diagramme de déploiement est un type de diagramme UML qui montre
l’architecture d’exécution d’un système, y compris les nœuds tels que les environnements
d’exécution matériels ou logiciels, et l’intergiciel qui les relie. Les diagrammes de
déploiement sont généralement utilisés pour visualiser le matériel physique et les logiciels
d’un système. En l’utilisant, vous pouvez comprendre comment le système sera
physiquement déployé sur le matériel. Les diagrammes de déploiement aident à modéliser
la topologie matérielle d’un système par rapport à d’autres types de diagrammes UML qui
décrivent principalement les composants logiques d’un système [30].

Figure 30-Diagramme de déploiement

3.2.5 BASE DES DONNEES

Une base de données est une collection d’informations organisées selon différents
types et pouvant être facilement consultables, gérables et mises à jour. Pour les bases de
données relationnel Les données sont stocke dans des tableaux (des donnes ) qui sont constitués
des lignes et des colonne contrairement aux base des données No-SQL qui stocke les données
sous format clé-valeur dans des documents . La création d’une base des données se fait suivant
trois grands niveaux :

Niveau conceptuel : ici nous voyons le diagramme de classe présentée ci-haut à la

figure 30.

Niveau physique : à ce niveau on implémente le modèle dans un Système de

Gestion de Base des Données. Dans notre travaille nous avons choisi MongoDB qui est un
Système de Gestion de Base de Donnée No-SQL.

3.2.6 MODEL RELATIONNEL

Après avoir décrit le système dans le diagramme de classe, voici comment va se

présenter le model relationnel de notre travail :

- Utilisateur [id_user, nom, matricule, email, fonction, password, role, pathPhoto, #fK_service]

- Meeting [id_meeting, titre, url, état ,porte_conf, heure_début, heure_fin, #fkInitiate_user_id,]

- Message [ id_message, contenu, audioPath, #fk_user,date]

- Participant [id_participant, #fk_user, #fk_meet, presence]

- Service [id_service, description]

Dans ce chapitre, nous avons parlé de différents besoins que doit répondre notre
système. A part cela, pour la conception de notre système du côté logiciel, nous nous sommes
servis du langage UML qui regorge différents diagrammes pouvant nous permettre de
modéliser ou représenter toutes les fonctionnalités de notre système. Dans le chapitre suivant,
nous allons implémenter notre système et voir les résultats.

CHAPITRE 4. IMPLEMENTATION DU SYSTEME ET

PRESSENTATION DES RESULTATS
Références

Références

[1] S. Loreto, S. P. Romano, S. S. Laurent, and A. MacDonald, Real-time communication with WebRTC,
Beijing: O'Reilly, 2014.

[2] «WebRTC Home,» WebRTC, [En ligne]. Available: https://webrtc.org/. [Accès le 20 02 2021].

[3] «Des fonctions de communications dans le navigateur Web,» nex, [En ligne]. Available:
http://www.nexcom.fr/tag/webrtc/. [Accès le 15 02 2021].

[4] «Signaling and video calling,» MDN Web Docs, [En ligne]. Available: https://developer.mozilla.org/en-
US/docs/Web/API/WebRTC_API/Signaling_and_video_calling. [Accès le 25 02 2021].

[5] «What are STUN, TURN, and ICE?,» Twilio, [En ligne]. Available: https://www.twilio.com/docs/stun-
turn/faq. [Accès le 26 02 2021].

[6] «“Overview of ICE,” Interactive Connectivity Establishment (ICE): A Protocol for Network Address
Translator (NAT) Traversal,» [En ligne]. Available: https://tools.ietf.org/id/draft-ietf-ice-rfc5245bis-
13.html#rfc.section.2. [Accès le 26 02 2021].

[7] L. Salvator & P. Romano, ««Real-Time Communication with WebRTC»,» o’reilly.

[8] «WebRTC,» [En ligne]. Available: http://fr.wikipedia.org/wiki/WebRTC. [Accès le 02 2021].

[9] H. Arslan, S. Tüncel, and A. G. Yüksek, «Comparison of the Web based multimedia,» chez Signal
Processing and Communications Applications Conference, 2015, pp. 915-918.

[10] D. Johansson and M. Holmgren,, «Towards Implementing Web-Based Adaptive Application Mobility
Using Web Real-Time Communications,,» chez Eighth International Conference on Innovative Mobile
and Internet Services in Ubiquitous, 2014, p. 483–486.

[11] «Session Description Protocol,» chez Wikipedia, the free encyclopedia, 2021.

[12] «Based on 1.5 million minutes of video calls done with WebRTC».

[13] Jonathan, Rosenberg, «Session traversal utilities for nat (stun),» October 2008. [En ligne]. Available:
http://tools.ietf.org/html/rfc5389. [Accès le 15 03 2021].

[14] S. Dutton., «Webrtc in the real world: Stun, turn and signaling,» 2013. [En ligne]. Available:
http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/. [Accès le 15 03 2021].

[15] Daniel Burnett, Adam Bergkvist, «WebRTC 1.0: Real-time Communication Between Browsers,» Mars
2015 . [En ligne]. Available: http://w3c.github.io/webrtc-pc/archives/20150306/webrtc.html. [Accès le
 20 03 2021].

[16] J. Rosenberg., «Interactive connectivity establishment (ICE),» Avril 2010. [En ligne]. Available:
https://tools.ietf.org/html/rfc5245.

[17] «Mozilla veut vous faire tester les communications WebRTC dans Firefox,» Mozilla, [En ligne].
Available: http://www.nextinpact.com/news/89710-mozilla-veut-vous-faire-tester-communications-
webrtc-dans-firefox.htm. [Accès le 17 03 2021].

[18] «Mozilla, Google apporte l’interopérabilité WebRTC à Firefox et Chrome,,» Mozilla, [En ligne].
Available: http://www.blog-nouvelles-technologies.fr/24036/mozilla-google-apporte-linteroperabilite-
webrtc-a-firefox-et-chrome/. [Accès le 17 03 2021].

[19] «Transferts entre navigateurs sans serveur avec WebRTC,» [En ligne]. Available:
http://www.reptiletech.com/blogue/developpement-web/transferts-entre-navigateurs-sans-serveur-
avec-webrtc/. [Accès le 18 03 2021].

[20] Ilya Grigorik, «High Performance Browser Networking,,» O’Reilly Media, 2013.

[21] «Architecture de Video conference avec WebRTC,» [En ligne]. Available: https://cloudeezy.com/blog-
nextcloud/webrtc-p2p-sfu-mcu.html. [Accès le 5 03 2021].

[22] M. Masivi, «Les Méthodes de recherche scientifique,» 2013. [En ligne].

[23] L. (. J. Louis, «Initiation aux méthodes de recherches en sciences sociales,» Paris, L’Harmattan, 2000, p.
p. 120. 20.

[24] GRAWITZ, Madeleine, «Méthodes de recherche en sciences sociales,» Paris, Dalloz, 2001, p. p.35.

[25] Y. H. Z. Mokhtar, « Algorithmes d'apprentissage pour la classification de documents,» chez Université

de Mostaganéme, Algér, 2009.

[26] Pascal PARE Camille ROSENTHAL-SABROUX Nasser KETTANI, Dominique MIGNET, «De Merise à UML,»
france edition éd., Eryolles, Octobre 2001.

[27] J.STEFFE, «De Merise à UML,» E. d. b. edition, Éd., Janvier 2003.

[28] J. GABAY, «Merise et UML pour la modélisation des systèmes d'information,» Dunod éd., mars 2004.

[29] J.-P. LATOUR, «Les diagrammes UML ; les conséquences du passage à l'OO,» Février 2001.
RR