mise en place d'un système de classes virtuelles utilisant le webRTC + openfire,ldap,php,html,css,javascript

Bassirou Dime webRTC au sein du département génie informatique
ii
Mémoire de fin de cycle Mise en œuvre d’un système de classes virtuelles utilisant le
Je dédie ce mémoire :
A mon père et modèle Babacar Dime qui n’a su ménager aucun n’effort pour
m’accorder une éducation de qualité et dans les meilleures conditions, merci pour
tout;
A ma mère amie et complice Yandou Basse pour ses innombrables prières et conseils
vraiment merci ;
A mes petits frères Makhtar, Alioune, Ousmane et ma petite sœur Gnagna ;
A toute la famille Dimé depuis la Sicap liberté 1 particulièrement à ma grande mère
Anta Sarr que j’aime énormément, merci pour les prières ;
À toute la famille Basse
A tous mes amis du Camp Abdou Diassé et d’ailleurs
A tous les étudiants de la promotion télécommunication et réseaux 2014-2016 A
toutes les personnes qui de près ou de loin m’ont soutenue
DEDICACES

iii
REMERCIEMENTS
J’adresse mes sincères remerciements :
A Mes parents pour leur soutien moral
Monsieur Samuel Ouya qui m’a encadré et soutenu lors de ce mémoire et ce en dépit
de toute ses occupations et hautes responsabilités
A monsieur Diaw, notre responsable pédagogique pour son soutien et sa disponibilité
A Tout le corps professoral du Département Génie Informatique pour la qualité de
leur enseignement et pour leur disponibilité
A toutes les personnes qui ont contribué à la réalisation de ce document

iv
Table des matières
Sigles et abréviations …………………………………………………………………………vi
Table des figures ……………………………………………………………………………..vii
Introduction …………………………………………………………………………………..1
CHAPITRE 1 PRESENTATION GENERALE DE L’ESP .......................................................
2
1.1.Présentation de la structure d’accueil
………………………………………………………2
1.1.1 Présentation de l’Ecole Supérieure Polytechnique de Dakar ....................................... 2
1.1.2 Historique ..................................................................................................................... 2
1.1.3 Missions ....................................................................................................................
3
1.1.4 Présentation du Département Génie Informatique (DGI) .......................................... 4
1.2 Contexte du projet
………………………………………………………………………6

v
1.2.1 Présentation du cadre d’application du projet
.............................................................. 6
1.2.2 Problématique
............................................................................................................... 6
1.2.3 Objectifs
........................................................................................................................ 6
CHAPITRE 2 Les Protocoles et langages utilisés dans ce projet
.......................................... 8
2.1 Présentation générale du webRTC .................................................................................... 8
2.1.1 Description générale de la norme ...........................................................................
9
2.1.2 Peerconnection .................................................................................................... 11
2.1.3 Data Channels
.............................................................................................................. 12
2.1.4 Multiplexage Data /Media ......................................................................................
13
2.1.5 Les problèmes du webRTC et solutions potentiels
..................................................... 13
2.1.5.1 Problèmes de sécurité des applications ............................................................. 13
2.1.5.2Problème de perte de paquets ................................................................................ 14
2.1.5.3 Transite au travers d’un PARE-FEU
................................................................... 14
2.1.5.4 Transite au travers d’un NAT
............................................................................. 15
2.2 Présentation de LDAP ........................................................................................................ 15
2.2.1 Les Caractéristiques du protocole LDAP .............................................................. 16
2.2.1 Concept d’annuaire et ses entrées.......................................................................... 17

vi
2.2.2 Déploiement d’un service LDAP ............................................................................
18
2.3 Les langages de programmation utilise …………………………………………………..19
2.3.1HTML (HyperText Markup Language) ....................................................................... 19
2.3.2 CSS (Cascading Style Sheets) .................................................................................... 20
2.3.3 PHP (Hypertext Preprocessor) ................................................................................... 20
2.3.3 JavaScript ................................................................................................................... 21
CHAPITRE 3 Les outils utilisés pour la mise en œuvre en œuvre .................................... 22
3.1 Présentation d’Openfire ................................................................................................. 22
3.1.1 Pourquoi le choix d’Openfire .................................................................................... 22
3.1.1 Quelques caractéristiques d’Openfire ........................................................................ 23
3.2 Présentation d’Open Meeting .......................................................................................... 24
3.2.1 Pourquoi le choix d’open Meeting ............................................................................. 24
3.1.2 Quelques caractéristiques d’Open Meeting ............................................................... 24
Chapitre 4 Mise en œuvre du système ........................................................................... 26
4.1 La Création d’un annuaire .................................................................................................. 27
4.1 Installation et configuration d’Openfire .......................................................................... 32
4.2 Installation et activation d’Open meeting...........................................................................
37
4.3 Conception de l’interface de connexion .............................................................................
38
Conclusion générale ................................................................................................................. 51
WEBOGRAPHIE .....................................................................................................................
52

vii
API application programming interface
UDP User Datagram Protocol
RTP Internet Engineering Task Force
ICE Interactivce connectivity establishement
FEC Forward error correction
HTML (HyperText Markup Language)
IETF Internet Engineering Task Force
TURN Traversal Using Relays around
SRTP Secure Real-time Transport Protocol
DTLS Datagram Transport Layer Security
webRTC Web Real Time Communication
DGI Département Génie Informatique
LDAP Lightweight Directory Access Protocol
LDIF LDAP Data Interchange Format
Sigles et Abréviations

i
SCTP Stream Control Transmission Protocol
XMPP Extensible Messaging and Presence Protocol
XML. Extensible Markup Language

Mémoire de fin de cycle présentation générale de l’esp
Bassirou Dime chapitre 1
Figure 1.1: Organisation de l'ESP en département ..................................................................... 4
Figure 2.1: Architecture d'une application WebRTC ............................................................... 10
Figure 2.2: Etablissement d’une connexion entre deux clients utilisant le webRTC ............... 11
Figure 2.3 Structure de la pile de protocoles utilisée par WebRTC dans un échange de
données……………………………………………………………………………………….13
Figure 4.1:Architecture du système .......................................................................................... 26
TABLE DES FIGURES

vii
Introduction
Dans le cadre de la validation de notre cursus de deux années en télécommunication et
réseaux, nous avons effectué un stage d’un mois qui a porté sur le thème de: mise en
place d’un système de classes virtuelles utilisant le webRTC au sein département génie
informatique, de l’école supérieure polytechnique, département qui m’a offert une
éducation de qualité et ma formé tout au long des 2 ans.
Le système qui nous a été demandé de mettre en place sera basé sur le webRTC.
Le webRTC est une technologie qui permet de connecter deux ou plusieurs personnes.
Il utilise une communication en temps réel grâce à sa pile de protocole.
L’une des possibilités qu’offre le webRTC est la vidéoconférence permettant de voir et de
dialoguer avec son interlocuteur.
Cette solution de création de classes virtuelles utilisant le webRTC nous a été proposé
dans le but d’alléger la peine des étudiants qui sont obligés pendant les mémoires de fin
d’études de venir quotidiennement à l’école rencontrer leur professeur encadrant ou leur
maitre de stage
Ce système peut être donc un gain en productivité, en temps et en coût pour l’enseignement
supérieur.
Dans ce rapport, nous allons d’abord procéder à une présentation de notre structure
d’accueil ensuite nous allons parler des concepts fondamentaux à connaitre, des outils
utilisés et enfin passer à la mise en œuvre concrète de notre système pour finir par une
conclusion

2
1
1.1. Présentation de la structure d’accueil
Il s’agira dans cette section, de présenter l’Ecole Supérieure Polytechnique (ESP) de
Dakar avant de s’intéresser particulièrement à notre structure d’accueil à savoir le
Département Génie Informatique (DGI).
1.1.1 Présentation de l’Ecole Supérieure Polytechnique de Dakar
Établissement public à caractère administratif doté de la personnalité juridique et de
l'autonomie financière, l'École Supérieure Polytechnique (ESP) fait partie intégrante
de l'Université Cheikh Anta DIOP (UCAD) de Dakar. Elle est un centre d’excellence
d’étude supérieure créé en 1977.
1.1.2 Historique
L'ESP est née de la fusion entre : l'École Polytechnique de Thiès (EPT), la division
industrielle de l'École Nationale Supérieure Universitaire de Technologie (ENSUT),
et la section Sciences et Techniques Industrielles de l'École Normale Supérieure
d'Enseignement Technique et Professionnel (ENSETP).
L'ESP de Dakar ne regroupe donc en son sein que la division industrielle de l'ex
Institut Universitaire de Technologie (IUT) de Dakar, première dénomination de cette
PRESENTATION GENERALE DE L’ESP
CHAPITRE 1

école qui a subi une déformation pour donner naissance à l'ex École Nationale
Supérieure Universitaire de Technologie (ENSUT).
 L'ex ENSUT
Le 20 Mai 1964, un décret présidentiel porte création de l'Institut Polytechnique,
établissement technique supérieur, dépendant de l'Université de Dakar. Le 15

4
novembre 1967, un nouveau décret présidentiel transforme l'Institut Polytechnique en
Institut Universitaire de Technologie (IUT).
Le 30 avril 1973, avec la promulgation de la loi 73-387, une nouvelle étape est
franchie puisque l'IUT est constitué en établissement public doté de la personnalité
juridique et de l'autonomie financière au sein de l'Université de Dakar.
Par ailleurs, divers décrets portant statut de l'Université de Dakar, notamment le décret
74-716 du 19 juillet 1974 précise que, dans sa composition, elle regroupe les Écoles
Nationales Supérieures ayant statut de faculté et en particulier l'IUT.
A la rentrée universitaire de 1973, l'École Nationale des Travaux Publics et Bâtiments
(ENTPB) qui formait des adjoints techniques pour le Ministère de l'Équipement est
intégrée au département de génie civil de l'IUT. Les formations de l'IUT sont
également réformées et permettent des formations complémentaires qui sont les
Diplômes d'Ingénieurs Technologues (DIT) et les Diplômes d'Étude Supérieure de
Gestion et d'Administration des Entreprises (DESGAE).
Suite à l'ouverture de ces formations complémentaires en 1973, la Direction et le
Conseil d'Établissement adoptent la nouvelle dénomination d'École Supérieure
Nationale Universitaire de Technologie pour remplacer l'IUT.
Cet historique nous permet de voir l’évolution rapide de l’école et la nécessité
d’améliorer son système de gestion.
1.1.3 Missions
L'ESP a pour missions de :
Former tant sur le plan théorique que pratique des :
 Techniciens Supérieurs ;
 Ingénieurs de Conception ;
 Masters ;
 Managers en Gestion d'Entreprises ;  Docteurs.

5
Dispenser un enseignement supérieur en vue de préparer aux fonctions
d'encadrement dans :
1.1.4 Présentation du Département Génie Informatique (DGI)
Le DGI est l’un des six départements que compose l’ESP comme la montre la
figure ci-après :
Figure 1.1: Organisation de l'ESP en département

6
Créé quinze ans après l’ouverture de l’ESP, le DGI vise d'abord à ce que les étudiants
sortants de ses différents cycles de formation soient capables de participer à la
conception, la réalisation et la mise en œuvre de systèmes informatiques
correspondant aux besoins des utilisateurs et à l’environnement actuel (économique
et industriel).
L’enseignement proposé est :
Fondamental, pour acquérir des connaissances, des concepts de base et des méthodes de
travail ;
Appliqué, pour faciliter l'apprentissage de ces concepts et déployer des Savoir-faire
professionnels ;
Évolutif, pour intégrer les progrès technologiques et les exigences du monde
professionnel ;
Ouvert, pour développer les facultés de communication indispensables aux
informaticiens dans l'exercice de leur métier.
Les cycles de formation assurés par le DGI sont :
Le cycle de Master (Bac+5)
Le cycle Licence (Bac+3)
Le cycle d'Ingénieur de Conception (Bac+5)
Le cycle de Technicien Supérieur (Bac+2)
En plus de la formation en informatique, le DGI forme depuis quelques années des
techniciens supérieurs et des ingénieurs en Télécommunications et Réseaux.

7
D’ailleurs en 2015 on a assisté à la sortie de la première promotion d’ingénieur en
Télécommunications et Réseaux.
Au-delà des missions de l’ESP, le DGI s’est fixé comme missions :
Former des Techniciens supérieurs, des Masters en Génie Logiciel et Systèmes Réseaux
et Télécommunications, des Ingénieurs en Informatique Téléinformatique et en
Télécommunication ;
Procéder à des expertises dans le cadre de la formation à l’intention des entreprises
publiques et privées.
Nous allons dans la section suivante procéder à la présentation du sujet
1.2 Contexte du projet
Pour une meilleure compréhension du sujet nous allons parler dans ce qui suit de la
présentation du cadre d’application du sujet
1.2.1 Présentation du cadre d’application du projet
Dans le cadre des stages et préparation des mémoires au sein du département
génie informatique et vu la forte sollicitation des professeurs pendant cette période, il
nous a été demande de mettre en place un système ou une plateforme de classes virtuelles
qui permettra de diminuer les distances entre professeurs et étudiants.
Ce système devra permettre aux étudiants en stage dans les entreprises comme dans
l’école de gagner du temps dans l’évolution de leur mémoire.
1.2.2 Problématique
Le département génie informatique accueille beaucoup d’étudiant pendant les stages de
fin d’études. La plupart de ces étudiants viennent chaque jour à l’école pour rencontrer
leur maitre de stage ou leur professeur encadrant. Ce qui est parfois difficile vue la
disponibilité des professeurs. C’est dans cette optique que nous avons pensé mettre en
place un système de classe virtuelle.
1.2.3 Objectifs

8
Pour mener à bien ce projet, les objectifs suivants ont été définis :
 déployer un système qui permet de mettre en relation visuelle et sonore, deux ou
plusieurs interlocuteurs éloignés sans qu'ils aient à se déplacer grâce au protocole
webRTC avec également la possibilité de partage interactif.
 Permettre une meilleure communication entre professeurs et étudiant pendant les
stages de fin de cycle
 Eviter les files d’attente des étudiants dans les locaux du département
Apres avoir présenté la structure d’accueil, le cadre d’application du projet et les
objectifs, nous allons par la suite entamer le chapitre suivant à savoir les Protocoles et
langages utilisés dans ce projet

Les
Protocoles et langages utilisés dans ce projet
Bassirou Dime CHAPITRE 2
9
Mémoire de fin de cycle
2.1 Présentation générale du webRTC
Aujourd’hui sur 7 milliards d’habitants, 3.2 milliards sont constamment connectés à
internet. L’usage des Smartphones et des tablettes est en croissance considérable, parce
qu’à présent, on peut faire quasiment tout ce que l’on veut en utilisant des appareils
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) 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 logiciels, plugins et téléchargements. 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.
Le WebRTC est un travail en cours, avec des implémentations avancées sur les
navigateurs Chrome et Firefox. Il est supporté par Google Chrome, Mozilla Firefox et
Opéra. La raison de la création du WebRTC est de s’attaquer aux questions de
confidentialités qui se posent en exposant les parties locales de l’ordinateur, ou en
espionnant depuis l’extérieur les données échangées.
Le projet WebRTC est extrêmement important car il marque la première fois qu'une
norme de communication en temps réel (RTC) puissante est ouverte pour la
Les Protocoles et langages utilisés dans ce projet
CHAPITRE 2

Les
10
consommation publique. Il ouvre la porte à une nouvelle vague d’applications web en
temps réel qui va changer la façon dont nous communiquons aujourd’hui.
Avec le WebRTC, les entreprises ont l’opportunité de transformer leurs
communications en s’assurant des communications fiables et sûres. Il peut améliorer les
réunions en ligne, les collaborations vidéo, et bien plus.
2.1.1 Description générale de la norme
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
rendez-vous 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 HTML interagissant avec le navigateur au travers de l'API
WebRTC. Les flux d'échange entre navigateurs peuvent rencontrer divers serveurs qui
se chargeront de modifier, traduire ou gérer le signal au besoin, permettant par exemple
la traversée de pare-feu, proxys ou NAT.
Afin d'établir une connexion utilisant le standard WebRTC, les navigateurs A et B
doivent être connectés simultanément à la page du service 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 caméra et/ou de leur microphone

Les
11
Figure 2.0.1: Architecture d'une application 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.
Dans le cadre par exemple d'un streaming vidéo en peer-to-peer entre navigateurs,
l'utilisateur télécharge depuis un serveur les métadonnées de la vidéo qu'il souhaite
regarder ainsi qu'une liste de paires disponibles et ayant tout ou partie de la vidéo.
L'établissement d'une connexion avec les paires permet, par le flux de données, le
téléchargement des morceaux de la vidéo qui sont réassemblés après vérification de
leur intégrité puis lancement de la vidéo dans un lecteur HTML5.

Les
12
Figure 2.2: Etablissement d’une connexion entre deux clients utilisant le webRTC
2.1.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 en pair à 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 Web Socket. Mozilla et
Google en ont réalisé une démonstration technique en février 2013.Pour obtenir une
connexion, l'une des paires doit obtenir les informations locales (telles que les
protocoles supportés pour l'audio ou la vidéo).
Il Représente donc une connexion WebRTC entre l'ordinateur local et un hôte distant.
Il est utilisé pour gérer la diffusion efficace des données entre les deux pairs. Afin
d'assurer la continuité de la connexion en cas de conversion d'adresse par NAT et éviter

Les
13
le blocage par les pare-feu (notamment en entreprise), l'objet Peerconnection utilise les
protocoles UDP STUN et ICE.
Une fois cette connexion en pair à pair établie, chaque partie peut établir des MediaStreams
ou DataStreams
2.1.3 Data Channels
Le canal de données est conçu pour fournir un service de transport générique
permettant aux navigateurs Web d’échanger des données génériques dans un mode
bidirectionnel Peer-to-peer. 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'une des paires appelle une méthode
CreateDataChannel() pour la première fois après avoir créé un objet PeerConnection.
Chaque appel à la méthode 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

Les
14
données.
Figure 2.3 Structure de la pile de protocoles utilisée par WebRTC dans un échange de données
2.1.4 Multiplexage Data /Media
WebRTC prévoit le multiplexage de flux données ou média reposant sur une seule
connexion de niveau transport. Ce multiplexage fait que les trois protocoles STUN,
SRTP et DTLS coexistent au même niveau du modèle et qu'il est nécessaire de
démultiplexer les paquets arrivants. Pour cela, le premier octet indiquant la nature du
contenu UDP sert à déterminer de quel protocole il s'agit. Une valeur de 0 ou 1
indique un paquet STUN, une valeur entre 20 et 63 indique un paquet DTLS une
valeur de 128 à 191 indique un paquet SRTP.
L’intérêt principal de ce multiplexage est qu'en partageant un même paquet de niveau
transport, les flux de médias et de données passent plus facilement des NAT ou pare-
feu en évitant, par exemple, qu'un paquet portant un flux de média ne soit bloqué
alors qu'un paquet de données passe.

Les
15
2.1.5 Les problèmes du webRTC et solutions potentiels
2.1.5.1 Problèmes de sécurité des applications
Plusieurs problèmes de sécurité se posent lors de l'utilisation de WebRTC :
L'application JavaScript (le code utilisant WebRTC) peut être téléchargée
Depuis n'importe quel site sans consentement de l'utilisateur.
L'exploitation de ressources média locales (par exemple les caméras et
Microphones) doit requérir l'approbation de l'utilisateur.
La confidentialité et l'authentification doivent être garanties dans tout échange
Pour éviter les attaques telles que l'attaque de l'homme du milieu.
Les informations privées de l'utilisateur ne doivent pas être dévoilées à des tiers sans
le consentement de celui-ci.
Si certains de ces problèmes sont inhérents à toute communication sur l'Internet,
d'autres problèmes ont été résolus par l'implémentation de WebRTC. Ainsi les
échanges de médias sont sécurisés par le protocole SRTP
2.1.5.2Problème de perte de paquets
Le protocole UDP étant déconnecté et n'utilisant pas de système de vérification de
réception des paquets (contrairement au protocole TCP par exemple), la perte de
paquets est un problème pouvant se poser lors des transmissions en pair à pair de flux
médias. Deux méthodes se présentaient afin de limiter la perte de paquets dus aux
problèmes de réseaux :
 NACK qui permet de signaler à l'émetteur une réception échouée ou l'absence de
transmission ;
 FEC, un code de contrôle qui permet au récepteur de vérifier que la totalité des
paquets est arrivée correctement

Les
16
Dans le cadre de l'API WebRTC, une solution hybride entre NACK et FEC a été
implémentée, accompagnée de contrôles temporels afin d'équilibrer la qualité de la
vidéo, sa fluidité et le temps de réponse d'une extrémité de la connexion à l'autre.
2.1.5.3 Transite au travers d’un PARE-FEU
WebRTC peut être difficile à utiliser en entreprises dans la mesure où celles-ci ont
souvent des politiques de sécurité en informatique incompatibles avec les besoins de
l'API. En effet, WebRTC est basé sur des flux Peer-to-Peer entre navigateurs et ces flux
sont très sensibles à la latence lors qu'il s'agit de flux médias. En outre, les serveurs
utilisés pour faire transiter les paquets peuvent être éloignés géographiquement des
paires qui communiquent ou avoir une bande passante trop faible pour permettre un
transit correct des paquets.
Des approches existent déjà pour franchir un pare-feu :
 Le RTP symétrique est une implémentation de RTP basée sur UDP qui utilise
les mêmes ports en entrée et en sortie, afin de simuler un flux bidirectionnel et
éviter le blocage arbitraire de paquets.
 Le protocole ICE, qui utilise des paquets de test pour déterminer les règles de
filtrage du pare-feu et est aussi utilisé pour traverser un NAT.
Néanmoins les entreprises utilisent de plus en plus des SBC, des pare-feu de niveau
application, utilisant un contrôle des flux de signaux et médias (ALG). Ces SBC posent
des difficultés pour WebRTC dans la mesure où le flux de signaux n'est pas standardisé
par l'API et l'implémentation est laissée libre.
2.1.5.4 Transite au travers d’un NAT
Afin d'être utilisable si l'une des paires se situe derrière un NAT, WebRTC utilise le
protocole ICE. Deux techniques principales sont utilisées pour traverser ce genre de
difficultés.

Les
17
La première technique est souvent appelée HolePunching: l'appareil à l'intérieur
du NAT envoie un paquet STUN à un serveur en dehors du NAT. Le serveur
répond en informant l'émetteur de l'adresse IP et du port apparent avec lequel le
paquet a été envoyé, sur lequel les deux communiqueront.
La seconde technique utilise un relais intermédiaire. Le protocole utilisé pour
cela est Traversal Using Relays around NAT : l'entreprise déploie un serveur
TURN au sein de la zone démilitarisée (DMZ) avec lequel la paire interne
communique et se charge de vérifier qu'il a les droits requis et de surveiller les
flux médias qui passent par lui.
2.1 Présentation de LDAP
Lightweight Directory Access Protocol (LDAP) est à l'origine un protocole permettant
l'interrogation et la modification des services d'annuaire. Ce protocole repose sur
TCP/IP. Il a cependant évolué pour représenter une norme pour les systèmes
d'annuaires, incluant un modèle de données, un modèle de nommage, un modèle
fonctionnel basé sur le protocole LDAP, un modèle de sécurité et un modèle de
réplication. C'est une structure arborescente dont chacun des nœuds est constitué
d'attributs.
Le nommage des éléments constituant l'arbre (racine, branches, feuilles) reflète souvent le
modèle politique, géographique ou d'organisation de la structure représentée. La tendance
actuelle est d'utiliser le nommage DNS pour les éléments de base de l'annuaire (racine et
premières branches, domain components ou dc=…). Les branches plus profondes de
l'annuaire peuvent représenter des unités d'organisation ou des groupes
(organizationalunits ou ou=…), des personnes (commonname ou cn=… voire user
identifier uid=…)

Les
18
L'assemblage de tous les composants (du plus précis au plus général) d'un nom forme son
distinguished name, l'exemple suivant en présente deux :
dc=sn
|
dc=esp_memoire
/
ou=étudiant ou=professeur
/
cn=bassirou cn= ouya
2.2.1 Les Caractéristiques du protocole LDAP
Dans la plupart des cas, LDAP sert d'annuaire téléphonique virtuel, permettant aux
utilisateurs d'accéder facilement aux coordonnées d'autres utilisateurs. Mais le protocole
LDAP est beaucoup plus flexible qu'un annuaire téléphonique traditionnel car il peut
renvoyer un demandeur vers d'autres serveurs LDAP de par le monde, fournissant ainsi
un référentiel d'informations global et improvisé. À l'heure actuelle cependant, le
protocole LDAP est plus généralement utilisé au sein de grandes organisations comme
des universités, des services gouvernementaux et des entreprises du secteur privé.
Lightweight Directory Access Protocol permet de:
 Fournir aux utilisateurs des informations fiables, facilement accessibles
 Permettre aux utilisateurs de mettre à jour eux-mêmes leurs informations personnelles
 Rendre les informations accessibles de façon contrôlée
 Eviter la redondance d’informations : un seul annuaire pour l’ensemble des services

Les
19
 Faciliter la gestion (administration) des postes de travail, des équipements réseau Et tout
ceci est fait sans remettre en cause les applications existantes.
LDAP fournit également:
 le protocole permettant d'accéder à l'information contenue dans l'annuaire,
 un modèle d'information définissant le type de données contenues dans l'annuaire.
 un modèle de nommage définissant comment l'information est organisée et référencée.
 un modèle fonctionnel qui définit comment on accède à l’information,  un modèle de
sécurité qui définit comment données et accès sont protégés.
 un modèle de duplication qui définit comment la base est répartie entre serveurs.
 des APIs pour développer des applications clientes.
 LDIF, un format d'échange de données.
Il existe cependant des serveurs LDAP mais aussi des clients LDAP :
Exemples de serveurs LDAP : Openldap, Oracle Internet Directory,
Microsoft Active Directory,…
Exemples de clients LDAP : LDAP Admin, PHPLDAPadmin, Jxplorer,…
2.2.1 Concept d’annuaire et ses entrées
Un annuaire est comme une base de données où on peut y mettre des informations et les
consulter Cependant un annuaire est spécialement dédié à la lecture plus qu’à l’écriture
et l’accès aux données se fait par des recherches multicritères.
Son objectif est de maintenir de façon cohérente et contrôlée une grande quantité de données.

Les
20
L’entrée est l’élément de base de l’annuaire. Elle contient les informations sur un objet
de l’annuaire. Ces informations sont représentées sous la forme d’attributs décrivant les
caractéristiques de l’objet.
Toute sorte de classe d’objet (réel ou abstrait) peut être représentée. Une entrée
correspond à un objet abstrait ou concret. Les objets possèdent une description dans une
"classe d'objet". Une classe d'objet donne une représentation modélisée des objets
qu'elle représente en caractérisant tous les attributs des objets. Certaines classes d’objet
ont fait l'objet d'une normalisation et sont réutilisables. Elles sont définies par un nom,
un OID (Object Identifier), la liste des attributs (facultatifs ou obligatoires), et, pour
chaque attribut, un type. Le type est lié à la nature des attributs utilisés.
2.2.2 Déploiement d’un service LDAP
Déployer un service d'annuaire LDAP nécessite en premier lieu une réflexion sur la
nature des données que l'on y met, sur la manière dont on les récupère, sur l'utilisation
que l'on compte en faire et sur la façon de gérer le tout. La mise en place d'un annuaire
LDAP met donc en jeu plusieurs phases de conception que l'on va passer en revue.
Déterminer les besoins en service d'annuaire et ses applications o Déployer un système
d'annuaire se fait généralement sous la contrainte de la mise en place ou du
remplacement d'une application. C'est alors que se pose la question d'élargir le
service à d'autres types d'applications, la première venant à l'esprit étant un annuaire
des personnes. Cette phase consiste donc à prévoir toutes les applications possibles,
actuelles ou futures, d'un annuaire LDAP.
Déterminer quelles données sont nécessaires o Il s'agit d'inventorier la liste exhaustive
des données que l'on souhaite inclure dans le système d'information et de déterminer
ensuite par quelle source les obtenir et les maintenir à jour. Des aspects comme le
format, la taille des données, leur confidentialité, leur pertinence, leur source
(statique, dynamique...), leur pérennité, les personnes susceptibles de les fournir, de
les maintenir et d'y accéder doivent être prises en compte lors de cette phase
Choisir son schéma

Les
21
Dans cette phase de design du schéma, il s'agit de choisir, en fonction des données
que l'on a retenues, quelles sont les classes d'objets et les types d'attributs qui
s'en rapprochent le plus pour construire son annuaire LDAP.
Concevoir son espace (modèle) de nommage o Cette étape consiste à définir comment
les entrées de l'annuaire vont être organisées, nommées et accédées. L'objectif est
de faciliter leur consultation et leur mise à jour mais aussi de prévoir leur
duplication, leur répartition entre plusieurs serveurs ou leur gestion par plusieurs
personnes. En fonction de ces priorités, on privilégiera tel ou tel espace de
nommage.
2.3 Les langages de programmation utilises
Dans le cadre de ce projet nous utiliserons des langages de programmations telles que
PHP5, HTML5, et CSS3 pour mettre en place une interface web qui permettra aux
utilisateurs de s’authentifier avant d’accéder au système ou plateforme de classe
virtuelle.
2.3.1HTML (HyperText Markup Language)
HTML (HyperText Markup Language) est le format de données conçu pour représenter
les pages web. C’est un langage de balisage permettant d’écrire de l’hypertexte, d’où
son nom. HTML permet également de structurer sémantiquement le contenu des pages
et de les mettre en forme, d’inclure des ressources multimédias telles que les images,
des formalités de saisie, et les programmes informatiques. Il permet de créer des
documents interopérables avec des équipements très variés de manière conforme aux
exigences de l’accessibilité du web. Il est souvent utilisé conjointement avec d'autres
langages de programmation et formats de présentation.
HTML n’est pas un langage de programmation proprement dit, mais plutôt un code de
marquage. Il permet de décrire la page Web élément par élément en se servant de balises
de description.

Les
22
Le code HTML est déchiffré par le navigateur du client. Tous les navigateurs existant reconnaissent
parfaitement la syntaxe HTML.
Les pages web faites uniquement avec HTML sont suffixées par l’extension .htm ou encore
.html.
Le langage HTML est un langage de marquage qui ne connaît que l’alphabet ASCII
standard, limité à 128 caractères. Le marquage, réalisé par des balises, décrit la structure
logique du document et est interprété par les navigateurs ou browsers.
2.3.2 CSS (Cascading Style Sheets)
Les CSS, Cascading Style Sheets (feuilles de styles en cascade), servent à mettre en forme des
documents web de type HTML ou XML.
Par l'intermédiaire de propriétés d'apparence (couleurs, bordures, polices, etc.) et de
placement (largeur, hauteur, côte à côte, dessus-dessous, etc.), le rendu d'une page web
peut être intégralement modifié sans aucun code supplémentaire dans la page web. Les
feuilles de styles ont d'ailleurs pour objectif principal de dissocier le contenu de la page
de son apparence visuelle. L'avantage du CSS est qu'il permet :
D'éviter de répéter dans chaque page le même code de mise en forme
De faciliter la lecture du code de la page en ayant la possibilité de changer l'apparence d'un
site web complet en ne modifiant qu'un seul fichier
HTML sert à structurer le contenu document, tandis que CSS sert à formater un contenu
structuré. Bien que HTML permette de formater le contenu d’une page Web, il reste un
peu limité, voir ennuyeux vu que chaque élément doit être formaté séparément. CSS
remédie à ce problème en contrôlant la présentation de la page entière ou de plusieurs
pages par une seule feuille de style et d’une façon plus précise.
2.3.3 PHP (Hypertext Preprocessor)
PHP (Hypertext Preprocessor) est un langage de programmation libre principalement
utilisé pour produire des pages Web dynamiques à travers un serveur HTTP (HyperText
Transport Protocol), mais pouvant également fonctionner comme n'importe quel
langage interprété de façon locale. Il s'agit d'un langage de script utilisé le plus souvent
côté serveur : dans cette architecture, le serveur interprète le code PHP des pages web

Les
23
demandées et génère du code (HTML, XHTML, CSS par exemple) et des données
pouvant être interprétés et retournées par un navigateur.
Il a été conçu pour permettre la création d'applications dynamiques, le plus souvent
développées pour le Web. PHP est le plus souvent couplé à un serveur Apache. Ce
couplage permet de récupérer des informations issues d'une base de données, d'un
système de fichiers (contenu de fichiers et de l'arborescence) ou plus simplement des
données envoyées par le navigateur afin d'être interprétées ou stockées pour une
utilisation ultérieure.
Parmi les utilisations que l'on en fait, on peut citer le traitement des formulaires avec
un accès aux informations par bases de données. L'accès aux bases de données est aisé
une fois l'installation des modules correspondants effectuée sur le serveur. PHP est
multiplateformes : autant sur Linux qu'avec Windows, il permet aisément de reconduire
le même code sur un environnement à peu près semblable.
2.3.3 JavaScript
JavaScript est un langage de programmation de scripts principalement employé dans les
pages web interactives mais aussi pour les serveurs. C'est un langage orienté objet à
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 de
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és. En outre, les
fonctions sont des objets de première classe.
Le langage a été créé en dix jours en mai 1995 par Brendan Eich pour le compte de la
Netscape Communications Corporation, qui s'est inspiré de nombreux langages,
notamment de Java mais en simplifiant la syntaxe pour les débutants
Le propos de JavaScript est de manipuler de façon simple des objets, au sens informatique, fournis
par une application hôte
Apres avoir fait une présentation générale de la norme webRTC, quelques concepts du
protocole LDAP et avoir présenté les langages de programmation utilisés dans ce

Les
24
projet nous allons passer à l’avant dernier chapitre à savoir le chapitre 3 ou nous allons
parler des outils utilisés pour la mise en œuvre du système.

Mémoire de fin de cycle Les Outils utilisés pour la mise en œuvre du
système
25
Pour pouvoir faire la réalisation de notre plateforme nous aurons à utiliser certains outils
tels que openfire et un plugin d’openfire à savoir open meeting.
Le choix de ces outils ne s’est pas fait de manière hasardeuse, donc repose sur des
critères de performances et de fiabilités afin de pouvoir atteindre les objectifs fixés tout
au début .
3.1 Présentation de Openfire
Openfire (anciennement connu sous le nom de Wildfire et auparavant de
JiveMessenger) est un serveur Jabber/XMPP écrit en Java et distribué sous licence
publique générale GNU. Le projet est lancé par Jive Software en 2002, en partie pour
servir de base à leur outil de support client basé sur une application en ligne, FastPath.
Il s’appelle originellement Jive Messenger, mais change de nom pour Wildfireen 2005,
puis Openfire en 2007 suite à un problème de marque.
Les Outils utilisés pour la mise en œuvre du système
CHAPITRE 3

système
26
Il est basé sur le protocole XMPP et est administrable à distance depuis une interface
web.
Openfire bénéficie du soutien d'une importante communauté.
Openfire travaille avec l'intégration de Jingle et d'Asterisk.
3.1.1 Pourquoi le choix d’Openfire
Notre choix d’utiliser openfire serveur est dû au fait qu’elle présente de nombreux
avantages qui nous permettrons de parvenir aux objectifs attendus.
De plus, comparé aux autres serveurs XMPP, Openfire propose une interface de
configuration HTTP plus simple et, surtout, il est fait en java et peut se poser sur
n'importe quel OS. Openfire offre donc une possibilité de migration simple et une
utilisation plus facile.
Openfire offre aussi la possibilité d’interfaçage avec un grand nombre de composants
externes (bases de données, annuaires LDAP, etc.).
3.1.1 Quelques caractéristiques d’Openfire
Le serveur Openfire présente certaines caractéristiques parmi lesquels :
 Le support complet de Jabber et surtout la facilité d’installation.
 Une interface d'administration très complète et intuitive.
 La possibilité d’interfaçage avec un grand nombre de composants externes
(bases de données, annuaires LDAP, etc.).
 L’intégration de nombreux services (serveur de discussion, PubSub, proxy de
transfert de fichiers, etc.).

système
27
 La possibilité d’utilisation de nombreux plugins.
 Gérer par le biais du web
 Intègre Plus de plugins
 Enregistrer les messages des utilisateurs et des bases de données.
 Inscription de l'utilisateur sur les bases de données externes.
3.2 Présentation d’Open Meeting
Open Meetings est un logiciel utilisé pour la présentation, la formation en ligne, de
conférence Web, de collaboration et d’édition de documents, et le partage de bureau de
l’utilisateur et de dossiers pédagogiques. La communication se fait dans les «salles de
réunion virtuelles" qui peuvent être réglées à différents modes de communication, de
sécurité et de qualité vidéo. Le produit peut être mis en place en tant que produit de
serveur installé, ou utilisé comme un service hébergé.
Les travaux sur Open Meetings ont commencé en 2006, et il a été téléchargé plus de
250 000 fois. Open Meetings est disponible dans 31 langues.
3.2.1 Pourquoi le choix d’open Meeting
Après avoir fait une recherche et une étude comparatif des différentes solutions
disponibles pour la formation pédagogique en ligne, la conférence web et la
collaboration et l’édition de document en temps réel, le choix s’est porté entre Open
Meetings et BigBlueButton.
Open Meeting dispose de plus de fonctionnalité surtout l’intégration de LDAP.
Le second est beaucoup plus simple d’utilisation mais limité en fonctionnalité malgré
le fait qu’il dispose d’un client Android.
Les 2 solutions ont de toute façon un passage en HTML5, ce qui améliore leur
compatibilité avec les solutions mobiles IOS et Android.

système
28
Etant donné que nous voudrions utiliser une authentification avec l’annuaire LDAP
notre choix s’est porté naturellement sur Open Meetings qui est un plugin d’Openfire
qui se couple naturellement avec une base de données et avec LDAP qui sont
indispensable à la bonne marche de notre projet.
3.1.2 Quelques caractéristiques d’Open Meeting
Le plugin d’Openfire à savoir Open Meeting présente certaines caractéristiques parmi
lesquels :

La communication audio
Vidéo conférence
Enregistrement réunion
Le partage d'écran.
Édition collaborative de documents.  Embarquement chat et blanc
Gestion des utilisateurs et des salles de conférences.
Client Mobile pour Android.
Apres avoir fait une présentation des outils utilisés à savoir Openfire et Open
Meeting, et expliquer le pourquoi du choix de ces outils et les caractéristiques de ces
mêmes outils nous allons passer au quatrième et dernier chapitre ou nous allons
parler de la mise en œuvre du système.

système
29

Mémoire de fin de cycle La mise en œuvre du
système
30
Dans ce chapitre nous allons montrer et expliquer de manière claire les démarches et configurations
effectuées pour la réalisation du projet.
Nous commencerons par définir l’architecture du système que nous voulons réaliser ensuite
faire la conception et enfin procéder à des tests.
Mise en œuvre du système
CHAPITRE 4

système
31
Figure 4.1:Architecture du système
4.1 La Création d’un annuaire
Dans le cadre de projet nous allons premièrement mettre en place un annuaire LDAP
qui sera utilisé pour contenir les informations des utilisateurs pouvant accéder à notre
système.
Ainsi nous allons faire les configurations suivantes pour la conception de l’annuaire :
Il existe au préalable des Pré requis :
Au niveau du terminal Ubuntu, on tape les commandes suivantes :
*** On se connecter en tant que super administrateur root avec la commande : sudo–i ***
Faire des mises à jour : apt-get update
Ensuite il faudra installer les paquets suivants :
 slapd : qui contient le serveur Openldap.
 ldap-utils : qui contient des utilitaires en ligne de commandes permettant d’interagir avec
les serveurs LDAD
On peut les regrouper en une seule commande #apt-get install slapd ldap-utils
Apres l’installation de ces paquets on configure slapd qui contient le serveur OpenLDAP avec la
commande #dpkg-reconfigure slapd
Une série de questions s’afficheront pour la configuration comme suit:
 configuration du serveur Openldap on choisit Non

système
32
dans notre cas : esp_memoire.sn
On précise le nom de l’organisation pour laquelle l’annuaire est créé : esp
Ensuite on définit à l’administrateur un mot de passe
Ensuite, on sélectionne comme module de base de données HDB :
Ensuite on choisit le nom de domaine qui sera utilisé dans l’annuaire

système
33
on répond non à la suppression de la base de données à la purge du paquet :
Puis on indique oui au déplacement de l’ancienne base de données :
Et on interdit l’activation de l’ancienne version du protocole LDAP (version
2) :

système
34
La configuration faite, nous allons nous positionner sur le répertoire /etc/ldap pour modifier le
fichier ldap.conf:
Dans ce fichier, nous allons indiquer les valeurs affectées à la base et à l’Uniform Ressource
Identifier (URI):
Ensuite, toujours dans le même répertoire, nous éditerons le fichier users.ldif qui
va servir à ajouter des utilisateurs dans notre annuaire avec la commande
suivante :
 nano users.ldif

système
35
Dans ce fichier, nous mettrons les informations relatives aux utilisateurs qui seront
stockées dans cet annuaire à savoir admin (l’administrateur), bassirou, samuel, mansour,
mbaye .Ces utilisateurs seront les seuls accrédités à accéder au système.
Puis, on envoie les informations contenues dans le fichier users.ldif dans l’annuaire avec
la commande suivante:

système
36
Ceci met fin à la configuration de l’annuaire ldap qui contient déjà les utilisateurs qui pourront
avoir accès à notre système
4.1 Installation et configuration de Openfire
Dans cette partie nous allons installer, configurer openfire et même le coupler avec l’annuaire ldap.
Comme pour toute installation il existe des prérequis.
Installer les dépendances nécessaires au fonctionnement de openfire à savoir le serveur
web Apache2 et la machine virtuelle java openjdk, mais aussi le serveur MySQL qui
est un serveur de gestion de base de données :
apt-get install apache2
apt-get install openjdk
apt-get install mysql server
Lors de l’installation de Mysql-serveur un mot de passe sera demandé à si
l’administrateur ne le donne pas il sera par défaut admin. Ici dans notre cas nous lui
donnons valeur passer
On télécharge ensuite la dernière version d’Openfire a savoir la version 4.0.2

système
37
Le paquet est disponible au lien suivant
http://www.igniterealtime.org/projects/openfire/index.jsp ou bien au niveau du
terminal, taper la commande suivante : wget suivi du lien
 Décompresser le paquet dans le répertoire /opt comme suit:
tar -xvzf openfire 4_0_2 -C /opt
 on se déplace ensuite dans le répertoire /opt/openfire/bin pour lancer l'exécutable d’openfire:
cd /opt/openfire/bin/./ openfire start
Avant la configuration d'Openfire on avait créé une base de données nommée openfire :
On se connecte au serveur Mysql en tant que root qui sera l'administrateur du serveur par :
mysql -u root -p
On utilisera le mot de passe qu'on a spécifié lors de l'installation du serveur pour se connecter
Puis créer la base de données « openfire » par l'instruction : create database openfire ;
Apres la création de la base de donne mysql nous pouvons voir qu’elle est bien été ajoute
au niveau des bases de données avec la commande show databases ;
Apres avoir installé openfire et créer sa base de donnée nous allons configurer openfire en
se rendant sur le lien htpp://localhost:9090.
Ce lien renvoie à l’interface web permettant de configurer openfire.
La première fenêtre qui s’affiche renseigne sur la langue .C‘est là qu’on choisira la

système
38
Langue que nous voulons pour la console d’administration d’openfire.
Dans la fenêtre suivante nous allons donner les paramètres du serveur dont les plus
importants sont le domaine, le port de la console d’administration, le port sécurisé
d’accès à la console.
Domaine : c’est le nom d’hôte ou l’adresse IP du serveur.
Port de la console d’administration : indique le port sur lequel la console d’administration d’openfire
sera accessible.
Port sécurité d’accès à la console indique le port sur lequel la console d’administration d’openfire
sera accessible.
Dans la fenêtre suivante nous allons choisir la base de données qui va nous permettre de
nous connecter à notre serveur openfire.
Nous allons choisir : connexion standard a la base de données
Dans la fenêtre suivante nous allons remplacer [database-name] par le nom de notre base de
données openfire déjà créer et aussi remplacer [host-name] par localhost.
Comme utilisateur de la base de données il y’a root et comme pilote de la base de données on
choisit MYSQL.

système
39
Dans la fenêtre suivante renseignant sur les paramètres de profil nous allons choisir
l’option serveur ldap vue que nous voulons utiliser notre annuaire ldap pour stocker les
informations relatives à nos utilisateurs et parallèlement pouvoir données un accès
sécurisé a notre système.
L’intégration de l’annuaire Ldap se fait en trois étapes à savoir les paramètres de connexion, le
mapping utilisateur, et le mapping groupe
Comme le montre les captures suivantes

système
40
Apres configuration du serveur LDAP et de notre base de données MySQL nommée
Openfire nous devons choisir un administrateur existant dans notre annuaire
Nous avons choisi admin et samuel .Ils seront les seuls habilites à accéder à la console d’administration
d’Openfire
.
La configuration se termine avec l’intégration les administrateurs du système

système
41
Apres avoir mis en place et configuré Openfire, on pourra alors se connecter en tant
qu'administrateur avec comme login admin ou samuel et avec comme mot de passe
celui fourni dans notre annuaire LDAP comme le montre l’exemple suivant
4.2 Installation et activation d’Open meeting
Open meeting est un plugin d’Openfire il est installable et activable à partir de la console
d’administration d’Openfire
Son installation et son activation sont très simple et se fait comme suit :
Ouvrir la console d’administration du serveur.
Aller au niveau de plugins. Un grand nombre de plugins est proposé.

système
42
Sélectionner le signe + au niveau d’Open meeting.
Il est important d’avoir une bonne connexion internet pour que le téléchargement du paquet
open meeting se face correctement.
Il peut arriver que le téléchargement au niveau de la console d’administration pose problème dans
ce cas il faudra le télécharger et l’installer en procédant comme Indiqué
ci-dessous:
Aller à plugins.
Se déplacer jusqu'en bas de la page et cliquer sur Browser.
Sélectionner le paquet.
Puis cliquer sur Upload Plugin.
Si le plugin est bien chargé on reçoit une sorte de notification comme montre la capture suivante
Ceci met fin à la partie installation et configuration d’Open meeting

système
43
4.3 Conception de l’interface de connexion
Nous avons utilisé les langages de programmation tels que php, css, html et même
JavaScript pour la conception de l’interface de connexion de notre plateforme. Nous
allons montrer quelques captures des codes que nous avons eu à faire.
Notre page web tourne au niveau de notre serveur Windows avec wamp et s’appelle esp_memoire.
Php.
Cette page fait appelle a d’autre page soit pour la décoration avec la page mémoire.css
soit pour le compte à rebours avec la page vrai_compte_a_rebours.php qui a son tour
appelle des pages tels que compte.css et monscript.js
Remarque : la page nommé vrai_compte_a_rebours.php n’est pas codée en php
On l’avait attribué l’extension .php pour pouvoir faire une inclusion de page au niveau de
la page esp_memoire.php comme l’illustre les captures d’écran suivantes.

système
44
Extrait de : esp_memoire.php
La page vrai_compte_a_rebours.php se trouve inclue dans la page esp_memoire.php Il y’a aussi au
niveau de notre page esp_memoire.php un lien avec la page mémoire.css
.

système
45
Cette page écrite donc en ccs nous permet d’embellir notre page web
Extrait de : mémoire.css
Les bouts de codes suivants représentent notre page vrai_compte_a_rebours.php

système
46
Extrait de : vrai_compte_a_rebours.php
Cette page contient du code ccs avec compte.css et un script qui gère le compte à rebours
nommé monscript.php écrit en JavaScript.
Nous allons montrer des extraits de ces codes comme suit

système
47
Extrait de:compte.css
Cette page gère la partie décoration du compte à rebours à savoir la couleur, la taille des
éléments qui s’affichent au niveau du compte à rebours.

système
48
Le bout de code suivant gère les fonctionnalités du compte à rebours tel le démarrage
automatique du compteur ainsi que la redirection automatique en cas d’épuisement du
temps reparti par l’administrateur il est écrit en JavaScript
Extrait de : Monscript.js
Les Tests finaux
Apres avoir fait toutes les configurations nous allons passer à la dernière partie de notre projet
consistant à faire des tests pour voir si tout marche convenablement.
Donc nous avons 2 serveurs, un serveur au niveau de notre machine sous linux où nous
avons openfire et open meeting et notre annuaire ldap et un autre serveur sous Windows
avec wamp serveur.
C’est au niveau de notre serveur wamp que les utilisateurs qui veulent accéder à la plateforme
devront passer avant de pouvoir accéder réellement à la plateforme.

système
49
Vu que le serveur n’est pas encore hébergé et qu’il tourne pour l’instant en local
les utilisateurs devront taper au niveau de leur navigateur
http://@ipdelamachineserveur:numport
Le numéro de port est généralement 80 pour le serveur wamp donc dans notre cas aussi.
Ainsi nous avons mis en place une page web que nous pouvons appeler salon d’attente
qui contient un compte à rebours gérer par l’administrateur, et qui sera chargé de rédiger
les utilisateurs sur la plateforme si toute fois le temps d’attente dans le salon est écoulé
comme le montre la capture suivante
Nous voyons que le nombre de minute restant au niveau du compte à rebours est de
3 minutes et 8 secondes .si le temps s’écoule les utilisateurs sont redirigés directement au
niveau du système grâce aux codes PHP, html et JavaScript illustrés plus haut.

système
50
Donc ici la redirection dépend du temps qu’affiche le compte à rebours.
Les utilisateurs sont redirigés vers notre serveur Openfire qui contient l’open meeting et
l’annuaire ldap.
Les utilisateurs redirigés devront avant de bénéficier des services offerts par notre
serveur openfire sous linux s’authentifier, ce qui fait que tout utilisateur ne se trouvant
pas dans notre annuaire ldap ne pourra pas accéder à la plateforme ou système

système
51
Ici on voit bien que l’utilisateur Samuel s’est bien authentifier (accès via un téléphone portable)
Une fois l’authentification faite il accède au système comme le montre la capture suivante

système
52
Le système est aussi accessible depuis un téléphone portable (Android ou Ios)

système
53
Cette plateforme offre plusieurs possibilités dans le domaine pédagogique et
collaborative tel que les vidéos conférences, les chats instantanées, le partage de
bureau, d’écran, de code, de cours sous format PDF, sauvegarde d’une discussion orale
ou écrite et tant d’autres fonctionnalités comme le montre la série de capture suivante

système
54
Partage d’écran
Partage de code
L’utilisateur qui se trouve chez lui c'est-à-dire hors du réseau dans lequel tourne le
serveur openfire pourra accéder à la plateforme grâce à une invitation qu’on lui envoie
et qui contient un lien qui le rédigera directement sur la plateforme comme montre la
capture suivante

système
55
Ceci met donc fin à la partie tests finaux et parallèlement à la dernière partie de notre projet à
savoir la mise en œuvre du système de classes virtuelles

système
56
Conclusion générale
La virtualisation des classes constitue un projet très important pour le Sénégal mais aussi pour
la plupart des pays africains comme la cote d’ivoire, le Ghana qui envoient des consultants au
Sénégal uniquement pour mieux comprendre comment marche concrètement notre université
virtuelle qui est aujourd’hui un modèle de référence pour le continent africain.
C’est dans une démarche de réduire les distances entre les professeurs et les étudiants que
nous avions pensés mettre en place un système, une solution adaptée permettant de répondre
aux difficultés que rencontre les étudiants du département génie informatique en période de
stage de fin d’année .
Ainsi, le gain de temps est le premier avantage qu’offre ce système.
En effet, le temps perdu lié à la nécessité de se déplacer pour rencontrer son maitre de stage
ou son professeur encadrant, les réunions pédagogiques, est précieux et pourrait être consacré
à bien d’autres activités beaucoup plus productives et plus bénéfiques.
L’utilisation de ce système de classes virtuelles non seulement pour les étudiants mais aussi
pour les professeurs s’avère donc être la solution idéale qui permettra d’économiser à la fois
du temps et de l’énergie.
Le partage de fichiers textes interactifs, la vidéo conférence, les chats instantanés le partage de
bureau bref toutes ces fonctionnalités font de notre système de classes virtuelles un moyen
d’apprentissage, pédagogique, collaboratif très utile pour une éducation performante, de
qualité et surtout très propice à nos pays africains, vu le nombre interminable de bacheliers
dans nos universités.
Au cours de ce stage, nous avons eu à mettre en pratique nos connaissances théoriques
acquises au cours de notre formation notamment en téléphonie sur IP, le développement web
et les services réseaux. Cela nous a permis d’apporter des solutions concrètes à des problèmes
réels auxquels nous avons eu à faire face.
Ce fut une expérience professionnelle enrichissante dans la mesure où elle nous a permis
d’apprendre de nouvelles choses et de savoir mettre en pratique ce que nous avons eu à
apprendre au cours de ces deux dernières années.

système
57
WEBOGRAPHIE
https://www.unixmen.com/install-openfire-ubuntu-12-04-lts/ consulté en juillet
https://www.igniterealtime.org/projects/openfire/plugins-beta.jsp consulté en juillet
https://openclassrooms.com/courses/tout-sur-le-javascript consulté en aout
http://openmeetings.apache.org/ consulté en juillet http://www.linux-
france.org/prj/edu/archinet/systeme/ch51.html consulté en juillet

mise en place d'un système de classes virtuelles utilisant le webRTC + openfire,ldap,php,html,css,javascript

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to mise en place d'un système de classes virtuelles utilisant le webRTC + openfire,ldap,php,html,css,javascript

Similar to mise en place d'un système de classes virtuelles utilisant le webRTC + openfire,ldap,php,html,css,javascript (20)

mise en place d'un système de classes virtuelles utilisant le webRTC + openfire,ldap,php,html,css,javascript