République Algérienne Démocratique et Populaire

Ministère de l’Enseignement Supérieur et de la Recherche Scientifique

Université des Sciences et de la Technologie Houari Boumediene

Faculté d’Electronique et d’Informatique

Département Informatique

Mémoire de Licence
Filière : Informatique

Spécialité : GTR
Thème
Conception et Réalisation d’une Application
Web Basée sur WebRTC à Travers
un Serveur TURN

Sujet Proposé par :

M (e) BENMERAR TARIK ZAKARIA
Soutenu le : .../.../ Présenté par :
Devant le jury composé de : OUZANE RIADH
SALEM SALAH

M……………. Président (e)

M……………… Membre

Binôme n° : 212 / 2021

 Remerciements

Nous tenons tout d’abord à remercier Dieu le tout puissant de nous avoir permis d’investir
dans notre travail avec autant de conviction, et de foi profonde.

Tous nos reconnaissances et remerciements à notre promoteur Mr Tarik Zakaria benmerar

de nous avoir pris sous son aile, dirigé, assisté et sa disponibilité et surtout ses judicieux
conseils et aide durant ce travail.

Nous tenons aussi à remercier toutes les personnes qui ont contribué au succès de notre
mémoire et qui nous ont aidées lors de la rédaction de ce mémoire.

Nos vifs remerciements vont également aux membres du jury pur l’intérêt qu’ils ont porté à
notre recherche en acceptant d’examiner et de juger notre travail et de l’enrichir par leurs
remarques.

Enfin, nous tenons à remercier nos parents, pour leurs soutiens constants et leurs
encouragements.

Merci à toutes et à tous

 Résumé

Dans ce mémoire, nous proposons la mise en œuvre d’une application de vidéoconférence

pair à pair avec WebRTC et les serveurs WAMP, STUN et TURN. Routeur WAMP est
chargé de recevoir et diffuser tous les messages des pairs avant l’établissement d’une
communication pair à pair. STUN et TURN fournirons un service permettant de recueillir des
informations publiques des pairs et créerons un canal de communication stable entre les deux
clients.

L'utilisation de ces outils a été un succès, et elle a prouvé que notre application fonctionne
bien dans la pratique. Des implémentations futures possibles sont également présenté afin
d'ajouter encore plus de valeur à notre application.

Abstract

In this brief, we propose the implementation of a peer-to-peer videoconferencing application

with WebRTC and the WAMP, STUN and TURN servers. WAMP Router is responsible for
receiving and broadcasting all messages from peers before establishing a peer-to-peer
communication. STUN and TURN will provide a service to collect public information from
peers and create a stable communication channel between the two clients.

The use of these tools has been successful, and it has proven that our app works well in
practice. Possible future implementations are also presented in order to add even more value
to our application.
 Sommaire

INTRDUCTION GÊNÊRALE .................................................................................................. 1

CHAPITRE 1 : ETAT DE L’ART ............................................................................................. 2
1.1 Introduction ................................................................................................................. 2
1.2 Présentation du WebRTC ............................................................................................ 2
1.3 Structure du WebRTC ................................................................................................. 2
1.3.1 Les APIs WebRTC ............................................................................................... 3
1.3.2 Les protocoles WebRTC ...................................................................................... 4
1.4 Méthodes de connexion ............................................................................................... 4
1.5 Signalisation ................................................................................................................ 4
1.5.1 L‘initialisation de la communication ................................................................... 4
1.5.2 Serveur de signalisation (WAMP) ....................................................................... 5
1.5.3 Les informations échangées lors de la signalisation ............................................ 6
1.6 Les serveurs ICE (STUN / TURN) .............................................................................. 7
1.6.1 Problématique de la complexité des réseaux ....................................................... 7
Conclusion .............................................................................................................................. 8
CHAPITRE 2 : Analyse et Conception ...................................................................................... 9
2.1 Introduction ................................................................................................................. 9
2.2 Unified Modeling Langage .......................................................................................... 9
2.2.1 Définition ............................................................................................................. 9
2.2.2 Choix d’UML comme outil de modélisation ....................................................... 9
2.3 Architecture du Système .............................................................................................. 9
2.4 Diagramme de cas d’utilisation ................................................................................. 10
2.4.1 Identification des acteurs ................................................................................... 10
2.4.2 Diagramme de cas d’utilisation global............................................................... 11
2.5 Diagramme de séquence ............................................................................................ 11
2.5.1 Inscription d’un utilisateur ................................................................................. 11
2.5.2 Authentification d’un utilisateur ........................................................................ 13
2.5.3 Diagramme de séquence de signalisation avec routeur WAMP ........................ 14
2.5.4 Diagramme de séquence entier .......................................................................... 15
 2.6 Base de données......................................................................................................... 18
2.6.1 Description de la table principale....................................................................... 18
Chapitre3 : Réalisation ............................................................................................................. 19
3.1 Introduction ............................................................................................................... 19
3.2 Environnement de travail........................................................................................... 19
3.2.1 Environnement matériel ..................................................................................... 19
3.2.2 Environnement logiciel ...................................................................................... 19
3.2.3 Langages d’implémentation ............................................................................... 21
3.3 Interfaces de l’application.......................................................................................... 22
3.3.1 Interface d’inscription ........................................................................................ 22
3.3.2 Interface d’authentification des utilisateurs ....................................................... 23
3.3.3 Interface de de lancement d’appel ...................................................................... 23
3.3.4 Interface de profil de l'utilisateur ....................................................................... 25
Conclusion Générale ................................................................................................................ 26
Bibliographie ............................................................................................................................ 27

Liste des Figures

Figure 1.1 : la pile de protocoles WebRTC dans le plan media ................................................. 2

Figure 1.2 : Schéma illustrant les APIs WebRTC [3] ................................................................ 3

Figure 1.3 : processus de signalisation [5] ................................................................................. 5

Figure 1.4 : utilisation de protocole STUN [STUN] .................................................................. 7

Figure 1.5 : utilisation de protocole TURN [TURN] ................................................................. 8

Figure 2.1 : Architecture générale de notre système ................................................................ 10

Figure 2.2 : Diagramme de cas d’utilisation global ................................................................. 11

Figure 2.3 : diagramme de séquence d’inscription .................................................................. 12

Figure 2.4 : diagramme de séquence d’authentification........................................................... 13

Figure 3.1 : Capture de l'interface de crossbar ......................................................................... 20

Figure 3.2 : Captures de l'interface d'inscription de l'application web et les messages d'erreurs ......... 23

Figure 3.3 : Captures de l'interface de connexion de l'application web et les messages d'erreurs ........ 23

Figure 3.4 : Captures de l'interface de lancement d'appel de l'application web ................................... 24

Figure 3.5 : Captures de l'interface de profil de l'utilisateur de l'application web ................................ 25

Liste des Tableaux

Tableau 1.1 : Les champs SDP obligatoire et optionnelle ......................................................... 6

Tableau 2.1 : Schéma de la table principale de la base de données de notre système ............. 18
Tableau 2.2 : Description de la table principale ....................................................................... 18
Tableau 3.1 : Description de la table principale ...................................................................... 19
 Liste des abréviations

WebRTC: Web Real Time Communication

P2P : Pair à Pair

API: Application Programming Interface

STUN: Simple Traversal of UDP Through NATs

NAT: Network Address translation

ICE: Interactive Connectivity Establishment

TURN: Traversal Using Relays Around NAT

OSI: Open Systems Interconnection

UDP: User Datagram Protocol

TCP: Transmission Control Protocol

IP: Internet Protocol

SRTP : Secure Real-Time Communication

DTLS : Datagram Transport Layer Security

W3C: World Wide Web Consortium

IETF: Internet Engineering Task Force

SDP : Session Description Protocol

WAMP: Web Application Messaging Protocol

RPC: Remote Procedure Call

PUB/SUB: publish/Subscribe

RFC: Request for Comments

VOIP: Voice Over Internet Protocol

 INTRDUCTION GENERALE

Dans ce mémoire nous nous intéressons plus particulièrement à la construction d’une

application permettant la communication audio et vidéo en temps réel entre deux personnes.
Cette application permet la vidéoconférence qui est un outil indispensable dans plusieurs
domaines, en particulier dans la formation et le travail à distance. En ce moment, cet outil est
devenu de plus en plus important avec la conjoncture sanitaire causé par le covid-19.

Les applications permettant les vidéo-conférences sont largement facilitées par l’utilisation
du protocole WebRTC. C’est le diminutif de Web Real-Time-Communication qui est
globalement un ensemble de standards permettant de mettre en place une communication
instantanée directement accessible depuis le navigateur et depuis le WEB d’une façon plus
générale en évacuant la nécessité d’une installation préalable. Avant l’avenue du WebRTC
pour mettre en place une communication par vidéo conférence, il fallait installer sur son
ordinateur ou son téléphone mobile des outils tiers souvent payant. Ce qui n’est pas très
pratique.

Bien que la communication de base WebRTC utilise le mode Peer-to-Peer, l’étape initiale
d’établissement de cette communication requiert de la coordination. Cette coordination est
fournie par un canal de signalisation.

La signalisation n'est pas spécifiée par la norme WebRTC et n'est pas implémentée par ses
API afin de permettre une flexibilité dans les technologies et les protocoles utilisés.
La signalisation et le serveur bidirectionnel qui la gère sont laissés au développeur de
l'application WebRTC.

Le WebRTC n’aura aucun problème lorsque la connexion s’établit au sein d’un même
réseau (réseau local). Des soucis peuvent se poser lorsqu’un pair souhaite atteindre un autre
pair en dehors du réseau. Ceci s’explique par le fait qu’il devra percer plusieurs couches telles
qu’un proxy un pare-feu ou encore un NAT.

Afin de répondre à ces problèmes, nous proposons l’implémentation d’un serveur de

signalisation pour l’initialisation de la connexion. Et Pour contourner les problèmes liées la
communication entre deux pairs via internet nous utiliserons la technique ICE basée sur les
serveurs TURN et STUN.

Notre mémoire est organisé comme suit :

Le premier chapitre présente une Étude de la technologie WebRTC et des solutions

qui permettent la communication entre les Navigateurs web.

Le deuxième chapitre est consacré pour la conception de notre système.

Le troisième chapitre représente la mise en œuvre concrète de notre système, pour

finir par une conclusion.

1
 CHAPITRE 1 : ETAT DE L’ART

1.1 Introduction
Ce chapitre permet de donner une vision générale sur le projet. Commençant par l’étude
De protocole WebRTC puis le mécanisme de signalisation, Et enfin les problèmes liés à la
complexité du réseau et les solutions pour remédier à ça.

1.2 Présentation du WebRTC

Le « WebRTC » est un projet open-source composé d’un ensemble d’interfaces de
programmation (API) permettant aux usagers d’utiliser leur navigateur comme application
pour la communication en temps réel sans plugins [1]. C’est le premier standard élaboré pour
normaliser les communications en temps réel pair à pair. Il est à ce jour totalement supporté
par les navigateurs aux standards ouverts, tels que Google Chrome, Mozilla Firefox et Opera.
[2].

WebRTC se distingue d’abord par le choix du protocole de transport qui le soutient. En

effet WebRTC a déterminé UDP comme couche de transport (du modèle OSI) qui se prête
particulièrement bien au contexte temps-réel où la latence devient critique. Si UDP n’offre
aucune garantie par rapport à TCP (qui garantit l’arrivée des paquets, mais aussi l’ordre de
ceux-ci), il se prête beaucoup mieux aux flux multimédias en temps réel qui peuvent
généralement supporter la perte de certaines données (codecs audio et vidéo). [3]

1.3 Structure du WebRTC

Figure 1.1: la pile de protocoles WebRTC dans le plan media. [4]

La figure 1.1 montre comment Les navigateurs envoient leurs médias utilisateurs à l’aide de
l’API RTCPeerConnection via le protocole SRTP et des données personnalisées à l’aide de
l’API RTCDataChannel via SCTP.

2
1.3.1 Les APIs WebRTC

Le WebRTC se traduit par l’ajout de trois APIs dans le navigateur assurant chacun une
fonction spécifique : [3]

• L’API Media Stream

Permet accéder au contenu audio/vidéo capturé par l’appareil hôte (comme ceux
provenant de la webcam, du microphone ou du partage d’écran).

L’objet Media Stream permet un tel accès simplifié par la méthode getUserMedia, mais
encapsule aussi de puissants moteurs de traitement audio/vidéo internes permettant d’en
améliorer la qualité (encodage, décodage, synchronisation, gestion de la bande passante,
dissimulation des paquets perdus, réduction des bruits dans la bande audio, amélioration
de l’image dans le flux vidéo, etc.)

• L’API RTCPeerConnection

L’API RTCPeerConnection permet la communication entre pairs des contenus audio et

vidéo via leur navigateur respectif. C’est par cette interface que deux pairs vont apprendre
à communiquer ensemble et vont établir un tunnel de partage de contenu multimédia (par
SRTP).

RTCPeerConnection s’occupe des étapes d’initialisation de la connexion entre les pairs

la gestion de la session, l’envoi des flux multimédias et l’état de la communication.

Figure 1.2 : Schéma illustrant les APIs WebRTC [3]

La figure 1.2 montre le rôle de RTCPeerConnection dans l’architecture WebRTC.

3
• L’API Data Channel

Permet d’envoyer et de recevoir des données autres qu’audio/vidéo (transfert des fichiers,
contrôle des machines à distances…) à travers un canal de communication pair à pair.

1.3.2 Les protocoles WebRTC

En général, WebRTC implémente l'ensemble des protocoles suivants : [3]

• Secure Real-time Transport Protocol (SRTP) : utilisé pour l'échange Avec des médias tels
que l'audio et la vidéo.

• Secure Real-time Control Transport Protocol (SRTCP) : utilisé pour Échanger avec des
statistiques et des données de contrôle pour une connexion SRTP.

• Stream Control Transmission Protocol (SCTP) : utilisé pour l'échange Avec des données
non médiatiques.

• Datagram transport layer Security (DTLS) : utilisé comme couche obligatoire de sécurité
et de cryptage.

1.4 Méthodes de connexion

WebRTC utilise le balayage réseau pour créer des connexions appariées à travers des
passerelles NAT et des pares-feux. IL tente successivement les méthodes suivantes :

• Hôte : à privilégier, réseau local ou adresse IP externe directe connectée à Internet.

• Serveur réfléchi : obtenu à l'aide du protocole STUN pour découvrir l'adresse IP
externe réelle du pair si celui-ci est protégé par un pare-feu ou une passerelle NAT.
• Relais : l'ensemble du trafic entre pairs est relayé via un serveur commun TURN.
Utilisé lorsque la connexion pair à pair directe via la méthode hôte ou serveur réfléchi
échoue.

1.5 Signalisation

1.5.1 L’initialisation de la communication

La signalisation consiste à établir une connexion entre un client et un serveur bidirectionnel

afin d’échanger des messages de contrôle de session (offre/réponse SDP) ainsi que des
messages liés à l’état du réseau (candidats ICE).
Ce processus est volontairement exclu de la spécification WebRTC. Les développeurs
peuvent choisir le protocole de signalisation qu’ils estiment efficace pour leur implémentation
Ou utiliser un mécanisme propriétaire.

4
 Figure 1.3 : processus de signalisation [5]

Lorsque le mécanisme de signalisation a été complété avec succès, la connexion pair à pair
entre les utilisateurs peut s’établir et fonctionner en autonomie à partir de cet instant pour
l’échange de flux de données.

1.5.2 Serveur de signalisation (WAMP)

Dans le cadre de notre étude nous avons choisi le routeur WAMP comme serveur de
signalisation.

Il s’agit d’un protocole open source basé sur Web Socket permettant de faire communiquer
des technologies différentes ainsi que des processus et machines différentes découplés en
temps réel. [6]

1.5.2.1 fonctionnements d’un routeur WAMP

Le routeur WAMP offre deux méthodes essentielles pour la gestion des messages en temps
réel :[7]

• RPC (remote procedure call) : permet d’appeler une fonction d’un autre code à distance à
travers une Web Socket.
• PUB/SUB : un client s’abonne (SUB) à un évènement et un autre client publie (PUB) un
évènement sur ce sujet.
D’une manière générale, tous les clients abonnés à un évènement en particulier reçoivent
des messages.
Chaque session créer entre un routeur WAMP et le client est définit par un royaume qui
représente le domaine de séparation entre l’administration et le routage car le routage des
appels et les événements sont séparé sur chaque domaine vu qu’on peut définir une politique
d’administration sur chaque domaine. Ce qui implique que les utilisateurs qui sont dans des
domaines différents ne peuvent pas s’entendre et communique.

5
1.5.3 Les informations échangées lors de la signalisation

1.5.3.1 Protocole SDP (Session Description Protocol)

Lors du lancement des téléconférences multimédias, il est nécessaire de transmettre les

détails du média. SDP fournit une représentation standard de ces informations, quel que soit le
mode de transport de ces informations.

Un message SDP est composé d’une série de lignes appelées champs dont les noms sont
abrégés par une lettre minuscule. Chaque ligne respecte un ordre précis afin de simplifier
l’analyse lexicale. [8]

Champ Nom Obligatoire Optionnel

v= Oui
Numéro de version du protocole
o= Oui
Origine et identification de session
s= Oui
Nom de la session
i= Oui
Information sur la session
c= Oui
Information de connexion
t= Oui
Début et fin de session
a= Attribut de ligne Oui

m= Oui
Information sur le média
a= Oui
Attribut de média

Tableau 1.1 : Les champs SDP obligatoires et optionnelles

Le SDP ne livre pas le média lui-même, mais utilisé par l'émetteur et le destinataire pour la
négociation du type et du format du média, et les propriétés associées. L'ensemble des
paramètres d'une session est souvent appelé un profil de session.

SDP n'incorpore pas de protocole de transport, et il est destiné à utiliser différents

protocoles de transport selon le besoin.

6
1.5.3.2 Description du mécanisme ICE

Son objectif est de trouver le meilleur chemin pour chaque communication.

Les pairs échangent des candidats ICE négociés et hiérarchisés jusqu'à ce qu'un compromis
de connexion commun soit convenu.

Tout pair (c'est-à-dire une application utilisant WebRTC) qui tente de communiquer avec
un autre pair génère un ensemble de candidats ICE. Les candidats représentent une
combinaison donnée d'adresse IP, de port et de protocole de transport à utiliser. Notez qu'un
seul ordinateur peut avoir plusieurs interfaces réseau (sans fil, filaires, etc.), il peut donc se
voir attribuer plusieurs adresses IP, une pour chaque interface.

ICE rassemble les connexions réseau disponibles, et utilise le serveur de signalisation pour
communiquer les meilleurs chemins via candidate ICE. [9]

1.6 Les serveurs ICE (STUN / TURN)

1.6.1 Problématique de la complexité des réseaux

Souvent les utilisateurs sont cachés derrière un NAT, ce qui vouloir dire que dans la plupart
des temps les appareils ne connaissent pas leurs adresses IP publique.

D’autre part, le pare-feu autorisent le passage de certains paquets d’internet, mais

uniquement lorsqu’un hôte du réseau local a d’abord envoyé un paquet à travers le
Pare-feu [10].

C’est ici que la technique ICE intervient pour permettre à WebRTC de communiquer en
faisant abstraction de la complexité des réseaux formant la réalité d’Internet. ICE va utiliser
des serveurs STUN et TURN pour pallier aux problèmes causés par le pare-feu, les routeurs
NAT et autres restrictions potentielles.

1.6.2 Les fonctions des serveurs STUN/TURN

Un serveur STUN permet à l’utilisateur de connaître les informations réseaux qu’il

expose à l’externe, soit son adresse IP publique, le port, mais aussi le type de routeur
NAT devant lui.

Figure 1.4 : utilisation de protocole STUN [STUN]

7
 Un serveur TURN est une extension à STUN, lorsque celui-ci ne parvient pas à établir la
connexion. Il va permettre de relayer le média d’un utilisateur à l’autre, et devra être
présent durant toute la communication contrairement à STUN. TURN est une opération
définitivement plus exigeante et la communication directe devrait en tout temps être
privilégiée.

Figure 1.5 : utilisation de protocole TURN [TURN]

Différents niveaux de solutions s’offrent aux développeurs pour l’utilisation des serveurs
STUN/TURN à savoir :

1) Utiliser des serveurs gratuits sur lesquels on n’a aucun contrôle

2) Souscrire à un service payant

3) Créer son propre serveur en utilisant par exemple une solution open source.

Conclusion

Dans la mise au point d’un système de communication instantanée, le WebRTC nous offre
que la partie basique pour des raisons de compatibilités. Toute l’architecture autour du
WebRTC qui consiste à construire des serveurs permettant de vous donner votre adresse, le
chemin accessible pour vous contacter ainsi que ceux qui redirigent les trafics des flux, est
laissé à la charge du développeur. Le WebRTC n’est pas un outil directement exploitable.

8
 CHAPITRE 2 : ANALYSE ET CONCEPTION

2.1 Introduction
Dans ce chapitre, notre conception va se baser sur la création du système WebRTC pour la
communication (vidéo et audio) entre deux pairs qui nécessite deux entités un serveur de
signalisation (routeur WAMP) pour la coordination ainsi qu'un serveur TURN pour surmonter
les limitations de la VOIP.

2.2 Unified Modeling Langage

2.2.1 Définition

UML est un langage permettant de modéliser nos classes et leurs interactions. Autrement
c’est un ensemble de notations graphiques s’appuyant sur des diagrammes et permettant de
spécifier, visualiser et de documenter les systèmes logiciels orientés-objet. [11]

2.2.2 Choix d’UML comme outil de modélisation

Dans notre conception on a utilisé le langage UML comme outil de modélisation car il nous
a permet de :

• Identifier les acteurs et leurs rôles principaux.

• Schématiser le fonctionnement de notre application à travers les échanges.

2.3 Architecture du Système

Notre système est basé sur la configuration des API WebRTC qui représente le cœur de
notre application car il permet de lancer les Stream local des deux côtés ainsi que la gestion
des flux lors de la communication.

Les entités principales pour la conception de notre système sont 3 serveurs :

• Serveur de signalisation

• Serveur STUN

• Serveur TURN

9
 SDP
SDP Serveur de signalisation

ICE candidats ICE candidats

Flux SRTP
L'API L'API
RTCPeerConnection RTCPeerConnection

Flux SRTP

Navigateur de l'appelant TURN Navigateur de l'appelé

Rassemblement
Rassemblement des informations
des informations de candidats
de candidats
STUN

Figure 2.1 : Architecture générale de notre système

2.4 Diagramme de cas d’utilisation

2.4.1 Identification des acteurs

Les acteurs sont des personnes physiques qui possède des autorisations dans notre
système et capable d’effectuer des opérations sur ce dernier. On distingue 2 acteurs :

➢ Administrateur : c’est le superviseur qui possède toutes les permissions sur le

système (ajouter un compte, modifier un compte, supprimer un compte)

➢ Utilisateurs : c’est des simples utilisateurs qui possède tous les droits sur les
opérations de l’utilisation dans notre système (créer un compte, supprimer leurs
propres comptes, modifier les informations liées à leurs comptes, lancer une
visioconférence).

10
2.4.2 Diagramme de cas d’utilisation global

Lancer l'appel

Inclur
Recevez l'appel e
Inclur
e
Inclur
Modifier les Inclur S'authentifier e S'inscrire
informations de e
compte
Inclur
e
Supprimer le
compte

Figure 2.2 : Diagramme de cas d’utilisation global

2.5 Diagramme de séquence

Diagramme de séquence permet de décrire comment les éléments du système interagissent

entre.
Pour réaliser les diagrammes des séquences nous avons utilisé une seule opération
d’intersection qui est :
• Alternative (Alt) : opérateur qui désigne que le fragment représente un choix de
comportement.

2.5.1 Inscription d’un utilisateur

11
 L'utilisateur L'application web Base de données

1-Accéder au site Web

2-Afficher la page de
connexion

3-Cliquer sur inscrirez vous

4-Afficher le formulaire
d'inscription

5-remplissage de formulaire
6-Vérification des informations
saisies

Alt
Transfère les
Données Afficher message données au BDD
Mal saisie d’erreur
Traiter les données
Compte créer avec succès
[Sinon] Afficher la page de
connexion

Figure 2.3 : diagramme de séquence d’inscription

12
 2.5.2 Authentification d’un utilisateur

L'utilisateur L'application web Base de données

Accéder au site web

Afficher la page
principale de connexion

Entre l'email de l'utilisateur

et le mot de passe
Transférer les données
Vérification
Envoyer les résultats
Des données

Alt

Email ou mot de passe incorrect

Afficher un message d'erreur

[Sinon]
Afficher la page d’accueil

Figure 2.4 : diagramme de séquence d’authentification

13
2.5.3 Diagramme de séquence de signalisation avec routeur WAMP

Peer A Serveur Peer B

WAMP

Connecter au realm1
Connecter au realm1

Créer la session
Créer la session

Registre la procédure
avec son identifiant
Registre la procédure
avec son identifiant

L'offre SDP
L'offre SDP
La réponse SDP
La réponse SDP

Publier les candidates

ICE Abonner au Peer A
Les candidates ICE
Les candidates ICE

Publier les candidates

Abonner au Peer B ICE
Les candidates ICE Les candidates ICE

Figure 2.5 : Diagramme illustrant les opérations effectuées par le routeur WAMP dans notre
cas.

14
Scénario

1- Connecter au serveur de signalisation, en définissant aussi le royaume (realm) que les

clients vont être attaché. Dans notre cas on a défini un seul realm pour tous les utilisateurs
qui possèdent un compte dans notre application, sous aucun politique défini ce qui veut
dire que tous les actions de publication des évènements et l’abonnement à des sujets sont
autorisés.

2- Ouverture de la connexion entre le client et le routeur.

3- Enregistrer la procédure de l’utilisateur sous son nom d’utilisateur

4- Lors de lancement d’appel on fait appel à la procédure de l’autre pair par son identifiant.

5- Envoie de l’offre SDP

6- Envoie une réponse à l’offre SDP

7- Publier les candidats ICE par le pair A

8- Abonnée au pair A pour la réception des candidats ICE

9- Publier les candidats ICE par le pair B

10- Abonnée au pair B pour la réception des candidats ICE

2.5.4 Diagramme de séquence entier

Le diagramme de séquence entier nous permet de voir la conception de tout notre système
basé sur WebRTC avec les serveurs ICE (STUN/TURN) ainsi que notre serveur de
signalisation (routeur WAMP).

15
 Peer A Serveur Serveur Serveur Peer B
STUN WAMP TURN

Connecter Connecter

Ouvrir la caméra
et audio Ouvrir la caméra
et audio
Créer une
connexion webrtc Créer une
connexion webrtc
Récupère les flux
de la caméra et Récupère les flux
l'audio de la caméra et
l'audio
Ajouter les flux au
peerConnection Ajouter les flux au
peerConnection
Créer une offre
SDP

Définit l'offre SDP

comme une
description locale Offre SDP
Offre SDP
Récupérer l'offre
SDP reçu
Définit l'offre SDP
comme une
description distante
Générer une
réponse SDP
Définit l'offre SDP
comme une
Réponse SDP description locale
Réponse SDP
Définit l'offre SDP
comme une
description distante

16
 Adresse Relay ??
Adresse Relay

Mon
adresse ??
Votre
adresse
Candidates ICE (A)
Candidates ICE (A)
Ajouter les
candidates ICE
Adresse Relay ??

Adresse Relay

Mon adresse ??

Votre adresse

Candidates ICE (B)

Candidates ICE (B)
Ajouter les
candidates ICE

Alt

Connexion directe
Echange des flux

[Sinon]
Echange des flux Echange
des flux

Figure 2.6 : Digramme de séquence entier notre système

17
2.6 Base de données

Le schéma de notre base de données est décrit dans la figure 2. Suivante :

Compte

Username
Email
Password

Tableau 2.1 : Schéma de la table principale de la base de données de notre système

2.6.1 Description de la table principale

Le nom du champ Type de données Description Clef

Username Varchar (30) Identifiant de Primaire
l’utilisateur
Email Varchar (50) Email de Primaire
l’utilisateur
Password Varchar (20) Mot de passe de
l’utilisateur

Tableau 2.2 : Description de la table principale

Cela veut dire que l’utilisateur peut créer plusieurs comptes avec même username mais
différent adresse email et vice versa.

Conclusion

Nous avons présenté dans ce chapitre une modélisation de notre système en utilisant le
langage UML.
Un ensemble de diagramme a été tracé (diagramme de cas d’utilisation, diagramme de
séquence) qui nous a permet de voir la conception de WebRTC avec des serveurs
(STUN/TURN/WAMP).
Dans le chapitre suivant nous allons présenter notre application Web ainsi que les différents
outils pour la réaliser.

18
 CHAPITRE 3 : REALISATION

3.1 Introduction

La mise en œuvre de l’étude théorique, conceptuelle que nous avons faite précédemment
Nous permettons d’avoir une vue assez complète afin de réaliser une application de
visioconférence basé sur le protocole WebRTC.
Dans ce chapitre, nous exposons l’architecture de notre application et son fonctionnement,
les principales fonctionnalités et l’environnement de développement à travers la définition
des outils utilisés pour cette réalisation.

3.2 Environnement de travail

3.2.1 Environnement matériel

Pour le développement de cette application nous avons utilisé deux machines. Voici les
détails sur le matériel utilisé :

Matériel Pc portable 1 Pc portable 2

Marque Aspire E 15 Toshiba
Système d’exploitation Windows 10 (64bits) Kali Linux (64bits)
Micro-processeur (CPU) Intel(R) Core (TM) i3- Intel(R) Core (TM)2 Duo
4005U CPU @ 1.70GHz CPU T6570 @ 2.10GHz
1.70 GHz
RAM 4,00 Go 6,00 Go

Tableau 3.1 : Description de la table principale

3.2.2 Environnement logiciel

• WampServer

WampServer est une plateforme de développement web, permettant de faire

fonctionner localement (sans se connecter à un serveur externe) des scripts PHP.
WampServer n’est pas en soi un logiciel, mais un environnement comprenant deux
serveurs (Apache et MYSQL), un interpréteur de script PHP, ainsi que phpMyAdmin
pour l’administration Web des bases MYSQL. [12]

19
• Docker

Docker est un logiciel libre qui automatise le déploiement d’applications dans des
conteneurs logiciels. « Docker est un outil qui peut empaqueter une application et ses
dépendances dans un conteneur isolé, qui pourra être exécuté sur n’importe quel
serveur ». Ceci permet d’étendre la flexibilité de construction des applications et leurs
portabilités que ce soit sur la machine locale. Un Cloud privé ou publique. [13]
Chaque conteneur est constitué de plusieurs images. Les images c’est des fichiers
statiques non modifiable inclut les bibliothèques et les outils système, et les autres
paramètres des plateformes nécessaires à l’exécution d’un programme logiciel.

• Crossbar.io

Crossbar.io est une plate-forme de mise en réseau open source Avec les bibliothèques
clientes WAMP open source pour les applications distribuées et micro services. Il s'agit
D’une Image de crossbar. Avec une implémentation riche en fonctionnalités, évolutive,
robuste et sécurisée du protocole ouvert de messagerie d'application Web (WAMP). [14]
Cela veut dire que les clients se connecte au crossbar et routeur WAMP transporte les
messages de signalisation en temps réel.

Figure 3.1 : Capture de l'interface de crossbar

20
• Coturn

Coturn est une implémentation gratuite et open source d'un serveur TURN et STUN
pour la VoIP et WebRTC. [15]
Il s’agit dans notre cas d’une image docker qui nécessite des inputs (adresse Relay,
adresse externe).

3.2.3 Langages d’implémentation

• Visual Studio Code

Visual studio code est un éditeur de code open-source développé par Microsoft pour
Windows, Linux et MacOs, supportant un très grand nombre de langages de
programmation. [16]

• HTML

HTML (Hyper Text Markup Language) est un langage de balisage pour la structure
et la présentation des pages Web dans les navigateurs.

• CSS

CSS (Cascading Style Sheets) est un langage de style utilisé pour décrire comment
les éléments HTML doivent être affichés dans la page web (agencement,
positionnement, décoration, couleurs, aille du texte, …). [17]

• JavaScript

JavaScript est un langage de programmation de scripts, orienté objet, principalement

utilisé pour les pages Web interactives. Mais aussi il est utilisé pour d’autres
environnements extérieurs tels que Node.js, Apache. [18]
Il représente le langage principal dans notre code car les API WebRTC sont basés sur
lui.

21
• PHP

PHP (Hypertext Preprocessor) est un langage de scripts libre principalement utilisé

pour produire des pages Web dynamique via un serveur HTTP. Ce langage permet
essentiellement de construire des sites web dynamiques qui sont attaché à une base de
données. Le couple le plus connu est PHP/MYSQL. [19]

• MYSQL

MYSQL (My Structured Query Language) est un gestionnaire de base de données

libre. Il est multithread (peut exécuter plusieurs processus en même temps) et multi-
utilisateurs qui fonctionnent aussi bien sur Windows que sur linux ou Mac OS. [20] Il
est très utilisé dans les projets libres et dans le milieu industriel. MySQL est très
souvent utilisées avec PHP.

3.3 Interfaces de l’application

3.3.1 Interface d’inscription

22
Figure 3.2 : Captures de l'interface d'inscription de l'application web et les messages d'erreurs

3.3.2 Interface d’authentification des utilisateurs

Figure 3.3 : Captures de l'interface de connexion de l'application web et les messages

d'erreurs

3.3.3 Interface de de lancement d’appel

23
Figure 3.4 : Captures de l'interface de lancement d'appel de l'application web

24
 3.3.4 Interface de profil de l'utilisateur

Figure 3.5 : Captures de l'interface de profil de l'utilisateur de l'application web

Conclusion

Ce chapitre était consacré à la réalisation de notre application web de vidéoconférence, nous

avons présenté les outils de travail et les langages de programmation utilisés et les
fonctionnalités de notre système à travers des captures d’écran.

25
 CONCLUSION GENERALE

L’objectif qui nous a été proposé dans ce mémoire de construire une application de
vidéoconférence a était atteint.

L’utilisation de WebRTC basé sur les serveurs STUN/ TURN pour la communication en
temps réel de pair à pair c’est avérer une bonne solution.

Le temps accorder à la réalisation de ce mémoire nous nous pas permet de rendre plus
interactif notre application Web. Des améliorations peuvent être apporté à notre application
tel que :

➢ Présentation plus conviviale a l’interface Web

➢ L’ajout d’un indicateur montrant que la connexion est active
➢ Modifier l’application pour qu’elle puisse rétablir automatiquement la connexion en cas
de coupure.
➢ Créer la possibilité de démarrer l’application avec le son audio et l’utilisateur pourra
activer la caméra par la suite.

En tant que étudiants de la filière génie de télécommunication et réseau(GTR) la conception et

la mise au point des applications Web est une compétence très rechercher dans le monde du
travail.
C’est dans ce sens que ce mémoire a été un enrichissement de notre formation et une
expérience bénéfique pour la suite de notre carrière.

26
 BIBLIOGRAPHIE

[1] : Dan Ristic (juin 2015) développe des applications de communication interactives en
temps réel avec WebRTC , 1e éd., BIRMINGHAM_MUMBAI : Sonia Michelle
Cheema,Swati Priya,Neha Vyas.

[2] : Wikipédia (3 juin 2021) WebRTC, Disponible sur

: https://en.wikipedia.org/wiki/WebRTC (Consulté : 13 juin 2021)

[3] : WebRTC et la construction d’une application Web de vidéoconférence | by Renaud

Hébert-Legault | CRIM | Medium (2018).

[4] : Electronics 2020, 9, 462; doi:10.3390/electronics9030462

[5] : Juan Linietsky, Ariel Manzur et la communauté Godot (CC-BY

3.0). () WebRTC, Disponible sur
: https://docs.godotengine.org/fr/stable/tutorials/networking/webrtc.html (Consulté : 17 mai
2021).

[6] : Vayel (samedi 07 novembre 2015) Introduction au protocole WAMP, Disponible sur
: https://zestedesavoir.com/tutoriels/925/introduction-au-protocole-wamp-1/ (Consulté : 2
juin 2021).

[7] (20 déc. 2014) Présentation de WAMP.ws, le protocole pour faire du PUB/SUB et RPC
over Websocket, Disponible sur : https://fr.slideshare.net/sametmax/introduction-wampws-le-
protocole-websocket- pour-faire-du-pubsub-et-rpc-over-websocket-en-tempr (Consulté : 5
juin 2021).

[8] Mark Handley , Van Jacobson (2020-01-21) SDP : Protocole de description de

session, Disponible sur : https://datatracker.ietf.org/doc/rfc2327/ (Consulté : 15 juin 2021)..

[9] Salvatore Loreto , Simon Pietro Romano (mai 2014) Communication en temps réel avec
WebRTC , : O'Reilly Media, Inc..

[10] Reid Stidolph (1 août 2013) Une introduction au problème de NAT/pare-feu de

WebRTC, Disponible sur : https://webrtchacks.com/an-intro-to-webrtcs-natfirewall-
problem/ (Consulté : 2 juin 2021)

[11] MBANJE J Vernack & NAHIMANA Chantal ( Novembre 2014) 'CONCEPTION D'UN
NOUVEAU SYSTEME D'AIDE A LA SUPERVISION DES ACTIVITES D'IMPRESSION
AVEC UML', in (ed.) CONCEPTION ET REALISATION D'UNE APPLICATION WEB
D'AIDE A LA SUPERVISION DES ACTIVITES D'IMPRESSION DANS UNE IMPRIMERIE «
CAS D'IMPRILAC ». Bujumbura, : , p.

[14] () Crossbar.io, disponible sur : https://crossbar.io/docs/Basic-Concepts/ (consulté le 25

mai 2021)
[15] (14 AVRIL 2020) Comment créer et configurer votre propre serveur STUN/TURN avec
coturn dans Ubuntu 18.04, disponible sur : https://ourcodeworld.com/articles/read/1175/how-
to-create-and-configure-your -own-stun-turn-server-with-coturn-in-ubuntu-18-04 (consulté le
29 juin 2021).

[13]: Wahbi Belhadj (9 mars 2018) Virtualisation des serveurs et Sécurisation avec Docker,
Disponible sur: https://fr.slideshare.net/belhadjwahbi (Consulté: 9 juillet 2021).

[19] : JDN (01/08/19) Définition PHP, Disponible sur : https://www.journaldunet.fr/web-

tech/dictionnaire-du-webmastering/1203597-php-hypertext-preprocessor-
definition/ (Consulté : 09 septembre 2021).

[12]: (11 janvier 2021) WampServer, Disponible sur

: https://fr.wikipedia.org/wiki/WampServer (Consulté : 27 juin 2021).

[18] Wikipédia (26 mail 2021) JavaScript, Disponible sur

: https://fr.wikipedia.org/wiki/JavaScript (Consulté : 25 juin 2021).

[17]: () CSS, disponible sur : https://www.futura-sciences.com/tech/definitions/internet-css-

4050 (Consulté : 30 mail 2021).

[16] Wikipédia (22 juin 2021) Code Visual Studio, Disponible sur
: https://en.wikipedia.org/wiki/Visual_Studio_Code (Consulté : 25 juin 2021)

[20]: () Apprendre MySql, Disponible sur : http://creersonsiteweb.net/page-apprendre-

mysql (Consulté : 5 juillet 2021).

[TURN] : Contributeurs MDN (9 juil. 2021) Introduction à l'architecture

WebRTC, Disponible sur
: https://developer.mozilla.org/fr/docs/Web/API/WebRTC_API/Connectivity (Consulté : 6 juin
2021).

[STUN] : Andrew Prokop (21 juillet 2014) COMPRENDRE LES CONNEXIONS MÉDIA
WEBRTC — ICE, STUN, AND TURN, disponible sur
: https://andrewjprokop.wordpress.com/2014/07/21/understanding-webrtc-media-
connections-ice-stun -et-tourner/ (Consulté : 6 juin 2021).