Académique Documents
Professionnel Documents
Culture Documents
MSc Dissertation
Remote Support Services Using Peer to Peer
Communication Between Browsers (WebRTC)
Author:
Yann Guillon - Ydg2
Supervisors:
Dr. Frank Wang
Dr. Matteo Migliavacca
January 4, 2015
Contents
1 Introduction
1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Background: WebRTC and the real-time web
2.1 The real-time web . . . . . . . . . . . . . . . .
2.1.1 Overview . . . . . . . . . . . . . . . . .
2.1.2 HTTP-based Techniques . . . . . . . . .
2.1.3 WebSocket . . . . . . . . . . . . . . . .
2.2 WebRTC . . . . . . . . . . . . . . . . . . . . .
2.2.1 Overview . . . . . . . . . . . . . . . . .
2.2.2 Technical aspects . . . . . . . . . . . . .
2.2.3 Browsers support . . . . . . . . . . . . .
3
3
3
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
4
6
6
6
8
12
3 Technologies
3.1 Considerations . . . . . . . . . . . . . . . . . . . . . .
3.1.1 A future oriented architecture . . . . . . . . . .
3.1.2 An environment built for real time interactions
3.1.3 Scalability and cloud computing . . . . . . . .
3.2 The development Stack . . . . . . . . . . . . . . . . .
3.2.1 The MEAN Stack as a base . . . . . . . . . . .
3.2.2 Stack Additions . . . . . . . . . . . . . . . . . .
3.3 RTCMultiConnection . . . . . . . . . . . . . . . . . .
3.3.1 Initialization . . . . . . . . . . . . . . . . . . .
3.3.2 Sessions . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Rooms management . . . . . . . . . . . . . . .
3.3.4 Signaling . . . . . . . . . . . . . . . . . . . . .
3.3.5 Media streams gathering . . . . . . . . . . . . .
3.3.6 Error Handling and browser capabilities . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
13
13
14
14
14
16
17
17
17
18
18
18
18
4 Project architecture
4.1 Overview . . . . . . . . . . . . . . . .
4.2 Application flow and features . . . . .
4.3 Application architecture . . . . . . . .
4.3.1 The client side (1) . . . . . . .
4.3.2 The server side (2) . . . . . . .
4.4 System architecture . . . . . . . . . .
4.4.1 The development environment
4.4.2 The production environment .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
19
19
19
19
20
21
22
22
23
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Project implementation
5.1 Key points . . . . . . . . . . . . . . . . . . .
5.1.1 Signaling server strategies 1 . . . . . .
5.1.2 AngularJS and WebRTC . . . . . . .
5.2 Teamwork strategy : pair programming . . .
5.3 Contribution to the related communities . . .
5.3.1 Contributions to RTCMulticonnection
5.3.2 Contributions to the MEAN Stack . .
5.4 Future work . . . . . . . . . . . . . . . . . . .
5.4.1 Full cloud integration . . . . . . . . .
5.4.2 Screen interactions . . . . . . . . . . .
5.4.3 Files transfer . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
23
24
25
26
26
26
26
26
26
26
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
27
27
27
27
27
27
29
29
29
7 Conclusion
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
30
8 Annexes
30
8.1 Project resources . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1 This
1
1.1
Introduction
Context
Since the very early ages of its creation, internet have been mainly used to
communicate. During the late 1970s, the introduction of Bulletin Board Systems
allowed people to send direct messages to each other. A decade later, with the
tremendous expansion of the World Wide Web, blogging platforms and social
networks started to appear. But users wanted more : in the early 2000s, with
appearance of the Web 2.0 and the explosion of social media, video through the
internet was made popular by software like Skype, iChat, or MSN Messenger.
The considerably big amount of data to carry with the transmission of videobased content has always been a problem for software companies. The most
efficient and less broadband consuming solution found by software creators was
to use peer-to-peer direct communication between the software of each participant. Each company created its own proprietary or open-source software to do
so.
In in concern of unification and standardization, the WebRTC project was
created by Google in 2013. Its aim is to provide a set of technologies to allow
flawless Peer-to-Peer communication directly between web browsers without the
need of any external plug-in. It includes audio, video, screen-sharing, and data
transfer. It focuses on the refashioning of the real-time communication world,
targeting businesses and individuals.
1.2
Objectives
1.3
Chapter Overview
2
2.1
2.1.1
Overview
The real-time web consists of sending data though the web as soon as it is made
available by its publisher(s). The evolution of the on-line media is the main
reason of the expansion of this technology since the early 1990s: everybody
wants to know everything before everyone.
Ajax
The purpose of Ajax (Asynchronous JavaScript + XML) is to send asynchronous requests to any HTTP server. Ajax is implemented using JavaScript,
a language that is automatically interpreted by every recent browser at the loading of any HTTP page. The JavaScript layer of the website submits the request
in a defined format, and fetches the response from the HTTP server without the
need to reload the page. It can be triggered by the user, via JavaScript events,
such as mouse or keyboard interactions. Ajax is the most famous way to build
HTTP-based real-time interactions. [5]
2.1.2
HTTP-based Techniques
Since its invention, the HTTP protocol has been built on a request-response
structure, and was not designed for real-time interactions. The browser submits
a request to a HTTP server, which submits a response as a result of the request
made. [5]
the new data, but if no change is made, a response is still given, resulting in an
exceed of resources and bandwidth usage from both the client and the server
[7].
WebSocket
WebSocket is a protocol that allows to get a bidirectional real-time communication from a single connection, between a web browser and a server. WebSocket is directly integrated to every recent web browsers. WebSocket is a
standard within the HTML5 project, managed by the World Wide Web Consortium (W3C) authority. As the HTTP-based techniques, the JavaScript layer
loaded in the web browsers handle the connection and communication with the
server. On the server side, a custom server is to be used. It needs to implement
the WebSocket RFC, and the Berkeley Sockets protocol [7]. WebSocket solves
all the problems raised by HTTP solutions for real-time interactions (2.1.2).
2.2
2.2.1
WebRTC
Overview
WebRTC is a project that aims to regroup a set of standards, in order to provide real-time web communication without the need of any external plug-in or
6
2.2.2
Technical aspects
the participants. The second configuration, known as trapezoidal, allows multiple signaling server instances to handle different clients, using messages known as
jingles to share the session information between the signaling servers. Those
two architecture are very similar, and in a matter of simplicity, we will only
focus on the triangular architecture [4].
Establishment
The establishment of a WebRTC session is done in five steps.
Like any other Website, the first step is to fetch the public files from
the server. It includes the JavaScript layer mentioned in section 2.2.1,
alongside the HTML and CSS code. The JavaScript is loaded into the
browser, and the connection between the JavaScript and the signaling
server is instantiated.
Once the client is connected to the signaling server, messages following
the Session Description Protocol (SDP) are exchanged with the server to
define the set of technologies to use during the session (2.2.2).
The initiation of the session using the signaling server is then finished.
The browser itself now needs to establish a peer-to-peer link with the
other browsers involved. To do so, the ICE Hole punching technique is
used. Described in section 2.2.2, this technique uses a distant server to
instantiate a bidirectional access to each client, regardless of the topology
of their network.
The next step is a handshake about the secure pass-phrases to transfer, if
an eventual secured transfer (using SRDP, see 2.2.2) occurs.
Finally, the media session is opened, using either RDP or SRDP, and the
communication can start [4].
11
Browsers support
WebRTC is not yet supported by every popular web browsers available today.
In fact, we can note huge gaps between the features supported by each browser.
They can be classified in three groups.
Good participation: Google and Mozilla, respectively with their browsers
Chrome and Firefox, are doing great efforts to include each WebRTC specification to their browsers, and that since the beginning of the WebRTC project.
Both browsers almost include the whole specification, with a slight advantage
for Google Chrome, that can be understood by the fact that WebRTC is carried
by Google since the appearing of this technology.
Medium participation: In March 2014, Opera Software released a version
of its browser including the most basic functionalities of WebRTC, which shows
an interest in this technology. As it is recent, just simple audio and video calls
are possible.
No participation yet: Apple and Microsoft did not show any interest in the
WebRTC project yet. Microsoft is envisaging the integration of Object Realtime Communications (ORTC) to Internet Explorer, a WebRTC variant, which
is an object oriented protocol, where all the data transfer is automated and sent
using peer-to-peer communication only.
12
3
3.1
3.1.1
Technologies
Considerations
A future oriented architecture
WebRTC is still at its early development stages, and will surely evolve with
technologies that will become popular in an early future. In a matter of accuracy,
we focused on the most recent technologies currently available that are becoming
popular. We also took a look at the key projects already developed for WebRTC,
to decide what technologies will be the most adequate to our implementation.
The guidelines of the WebRTC and RTCWEB projects have also been taken in
count.
3.1.2
13
3.1.3
3.2
3.2.1
Presentation
The MEAN stack is an open-source development stack, featuring the very
latest web technologies (MongoDB as a database, Express as back-end web
framework, AngularJS as a front-end web framework and NodeJS as a back-end
technology). This stack provides very useful features for developers. First, it
wraps all the technologies cited before in a coherent, ready to use environment,
as every component is linked to the others. This results in a considerable gain
of time, as developers do not need to build their own stack, which can be a very
long task if the technologies are not perfectly mastered by them. Second, it offers
powerful Command Line Interface (CLI) tools for monitoring and debugging,
such as the uptime of each component. Third, it includes many productivitybased tools, such as the live reload of both the server and the web page if any
changes have been detected in the code.
Two different but very similar implementations of the MEAN stack are
available : the MEAN.io version, which is owned by Linovate Corp. and
MEAN.js, maintained by the original creator of the MEAN stack.
The MEAN.io stack was more adapted to this project, as it is more popular and structured, and provides a package manager. The fact that a whole
company is behind the project also ensures more evolutions and quicker communication on eventual bugs or requests.
The MEAN stack has two drawbacks for the implementation of our project.
First, the learning curve is significant. The fact that every components of the
library are integrated to each other, and the difficulty to understand the whole
architecture without a good knowledge of each element, makes it very hard to
master it at the early stages of the development. Second, it doesnt provide a
web-socket architecture by default - which is essential for our signaling server but it can be easily added to the express framework.
NodeJS and Express
1 Platform
14
15
tainable code. Its regroups the following features : dynamic data binding directly inside the HTML, the possibility to repeat DOM elements, helpers to
build HTML forms and finally, setting up HTML modules to be reused. Its
structure is based on three main components:
The view can be seen as the structure of what is going to be displayed
on the web page. It regroups HTML and CSS, and uses data bindings to
display the dynamic data.
The controller uses the Angular API to fetch the dynamic data from
the server, and then makes it available to the view.
The model allows to structure the data that is going to be exchanged on
the web page, either from the server through the controller, or from user
input. It also features validation helpers, in example if a form needs to be
filled on the page.
Stack Additions
16
The MEAN Stack does not provide tools for real-time interactions by default. We chose Socket.io, a JavaScript library to establish real-time eventdriven communications using either HTTP techniques (2.1.2) or WebSockets
(2.1.3). Socket.io is made of two distinct libraries, for the client and the server.
Its main strength is its ease of use, as minimal code needs to be written for each
side. Its event-driven architecture is also simplistic yet powerful. Events are
identified by a name, and contains a message. A comportment just have to be
defined by each party in case of the reception of each event.
3.3
RTCMultiConnection
Initialization
Sessions
connection . session ({
audio : true , // audio only connection
video : true , // audio + video connection ( disables audio only )
screen : true , // screensharing
data : true // direct data transfer , i . e files
}) ;
17
3.3.3
Rooms management
3.3.4
Signaling
The RTCMulticonnection library has its own signaling server strategy. It creates
multiple channels (identified by a unique hash) for each data stream. The default implementation of signaling uses the Web-socket JavaScript library. However, the whole signaling method can be changed by overriding the openSignalingChannel() method. Therefore, any kind of real time web service that handles
the Pub/Sub mechanism can be used to handle signaling.
1
2
3
4
connection . o p e n S i g n a l i n g C h a n n e l = f u n c t i o n ( config ) {
var channel = config . channel || def aultChan nel ;
// connection to the main channel , expressing the need
to join a sub - channel have to be done here
5
6
7
8
var socket ;
// The sub channel has to be opened here , using the
channel variable as an identifier , and needs to be
stored locally ( in the socket varaible in this
example )
9
10
11
12
13
};
The openSignalingChannel() function is called every time that RTCMulticonnection needs to open a channel. The config variable passed to the function
contains the channel to open. The first step is to connect to the main channel,
to tell the server that a sub channel connection is required. Then connect to
the sub channel and finally override the send method on the socket, as send in
bind by RTCMulticonnection.
3.3.5
Many methods are available to simplify the complex error handling of WebRTC.
All the following methods can be overridden to display errors to fit any user
interface.
18
Errors
The onError() method handles RTCMulticonnection errors.
The onMediaError() method handles the general media errors of WebRTC
media connections, such as stream errors and connection-related issues.
Browser Capabilities
The DetectRTC object detects if media devices, such as the web camera,
microphone, or eventual external plug-ins are present.
The connection.UA object contains various information about the browser.
4
4.1
Project architecture
Overview
4.2
OpenHangouts is a simple and easy to use conferencing website. After an authentication step, using local or social media authentication, users are able to
join conferencing rooms. The user that wants to create the room simply copies
the room identifier given when the room is opened, and gives it to the other
participants. People who joined the room can then communicate using audio
and video.
A role of presenter also exists : the presenter can share what is displayed on
its screen (or a part of it) with all the other participants in the conference. This
role is first assigned to the creator of the session, and the current presenter can
then send this role with any other participant.
4.3
Application architecture
The purpose of this section is to explain how the different technologies listed in
section 3 interact with each other in the scope of the project, and to highlight
the main developing parts that we made.
19
AngularJS
AngularJS (see 3.2.1), as a MVC font-end framework handles the whole
client-side display and interactions of the client-side of the project. It simply
uses a URL routing system, to display the content dynamically depending on the
URL requested by the browser. If an URL matches a defined route, a targeted
controller will be called. It will generate a view with dynamic content depending
on the data sent by the server via an API.
WebRTC as an AngularJS service
Angular JS (3.2.1) is modular : non specific modules can be added as services, that are query-able by the controllers for data or actions. Bindings of
the RTCMulticonnection library are integrated to a service. It regroups all the
actions that can be executed on the WebRTCMulticonnection library, and a
callback system that notifies controllers if a change is made directly within the
service, in example the connection of a new participant.
20
4.3.2
The server side is composed of two distinct servers. First, Express.js handles
the HTTP requests made by the browser, following the MVC architecture on
the server side. Its controllers interact with Mongoose, using two main data
models (User and Channel) using classic CRUD actions. Second, the socket.io
server handles the role of signaling server. It includes sub-channels, known
as name-spaces, to handle its role. It also uses the channel controller from
Express.js to access the Channel model.
The signaling management is split in two different groups of name-spaces.
Socket.io offers the opportunity to create namespaces easily, which have their
own logic, and can be seen as rooms. It can be easily implemented using a
simple URL parameter.
From a server point of view :
1
2
3
4
5
When a client connects to the signaling server, it first connects to the main
socket.io server, and submits multiple requests to access different namespaces.
The first name-spaces to join concerns classical WebRTC signaling actions,
they are created dynamically by the RTCMulticonnection library.
For each session, one other name-space is joined : created by us, this
namespace is used to manage extra actions, in our case the presenter
management.
21
4.4
System architecture
22
4.4.2
Project implementation
5.1
Key points
5.1.1
Problem
We wanted to offer the possibility to build custom features on top of the
signaling server basic capacities. As seen in section 2.2.2, the RTCMulticonnection library uses the openSignalingChannel() method each time that a user
needs to connect to a specific signaling channel, to get or send control messages.
The openSignalingChannel() method uses a channel stored in the configuration of RTCMulticonnection, and no control is given over the channels that are
opened, as RTCMulticonnection uses this method for its own signaling strategy.
Resolution
We went through multiple tests before finding the most appropriate solution
to this problem.
First, we tried to add the extra methods directly in the sockets opened by
the openSignalingChannel method, but it resulted in the extra methods
being called multiple times on the clients. As multiple channels are created
by RTCMulticonnection through the same function, the socket function
was bind for each channel opened.
We tried setting the config.channel variable in the connection of WebRTC.
The problem is this channel variable can be rewritten an any time by
RTCMulticonnection, blocking every possibility of overriding it ourselves.
To finally solve this problem, we created a method that is analogue to
openSignalingChannel(), but where we have full control of the behaviour
of the signal sent through it, and that is called at the creation of a room.
1 This
23
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// ...
5.1.2
Problem
We wanted to get the data on the front-side of our application to be automatically updated each time that a modification is made in our angularJS
service. AngularJS controllers use the $scope variable to store and update the
variables in real time. The problem is that the queries to our AngularJS service
are only single-sided: if any variable changes within the service, the controller
couldnt know that any modification have been done, as the controller was only
active when the user was active.
Resolution
To solve this problem, we used the observer design pattern of JavaScript.
The AngularJS controller simply says that he wants to observe the modifications
through a registerObserverCallback() method. Each time that a modification
within the service itself is made, a notifyObserver() method is triggered and the
controller is notified of the changes.
1
2
24
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
var n ot if yO b se rv er s = f u n c t i o n () {
angular . forEach ( observerCallbacks , f u n c t i o n ( callback ) {
callback () ;
}) ;
};
// The r e g i s t e r O b s e r v e r C a l l b a c k is exposed to the caller
return {
r e g i s t e r O b s e r v e r C a l l b a c k : f u n c t i o n ( callback ) {
o b s e r v e rC a l l b a c k s . push ( callback ) ;
},
};
// In the controller , the registering method can be called , and the
data , in that case the stream of the screen currently shared ,
is updated automatically .
WebRTC . r e g i s t e r O b s e r v e r C a l l b a c k ( f u n c t i o n () {
$scope . screen = WebRTC . getScreen () ;
$scope . $apply () ;
}) ;
// The $scope variable is bind by to the elements in the view ,
allowing elements to update automatically
// The <div > element containing the screen stream only appears if
the $scope . stream is set ( ng - show directive ) , and uses the
$scope . screen . stream as a source .
< div class = " screen - container container " >
< video ng - show = " screen " ng - src = " {{ screen . stream }} "
autoplay > </ video >
</ div >
5.2
My co-worker and I tried to figure out what was the most effective way to
produce the best quality software possible in the time given for the realization
of this project. We came to the conclusion that pair programming was the
most suitable for us. We can talk about pair programming when two developers
work on the same feature of a project behind a single screen. Our choice was
motivated by the following reasons:
Our background knowledge in the technologies required at the beginning
of the project was small.
We were sure to gain skills at the same time and always have the same
level of knowledge of the project.
It also helped producing a better quality code, as one can see a better way
to do a certain task.
The complexity of various parts of the project really required two developers working on them at the same time, especially the integration of the
AngularJS WebRTC service (5.1.2), and the signaling server (5.1.1).
At the beginning and the end of the project, we took the liberty to do small
and non blocking tasks separately, such as small features to improve the usability
25
of the project, the design and its integration, and finally the error handling.
5.3
5.3.1
The mean stack offers the possibility to create code packages to be installed
directly in any MEAN code structure, using the built in package manager or
Node Package Manager (see 3.2.1). We decided to release the code created as
one of those packages, allowing to include our whole conferencing website to
any kind of application with a minimalistic code integration to do.
5.4
5.4.1
Future work
Full cloud integration
Only one step is missing to manage a full cloud integration and scaling in our
application. Horizontal scaling balances the load on different exact same instances of the application, using a shared database. As those two first points
are already included in our project, the only thing to add is to be able to share
WebSocket server connection between multiple instance, using, in example a
Redis1 shared database.
5.4.2
Screen interactions
Files transfer
Peer-to-peer files transfer could also be included easily, as a raw data connection
is present by default in WebRTC. This feature is quite basic and do not consider
a real breakthrough unlike screen sharing and video sharing.
1 Redis
26
6.1
6.1.1
Internet has to be seen as a public resource : the quality of the internet connection of users is subject to many factors, such as the coverage of their country,
the type of connection used (Modem, ADSL, optical fibre, 3G, etc.), and the
various parameters within their area (quality of the line, distance of the internet relay). We decided to run an experiment to test the quality of WebRTC
connections by limiting the bandwidth allowed to it, and compare it with the
performance and the usability of WebRTC services.
6.1.2
Testing environment
The computer used for the test was a Lenovo Thinkpad W520 running
two distinct Google Chrome instances.
The internet connection used was a fast optical fibre connection, with a
bandwidth highly superior of the bandwidth needs of each test.
The OpenHangouts project was run distantly at the following url:
https://openhangouts.uni.me
6.1.3
Process followed
The bandwidth have been limited using a call to the RTCMulticonnecton library
to manually restrict the bandwidth allocated for each type of stream.
For each test, we reached the point where the media would not be displayed.
We then increased the bandwidth until the usability changed slightly.
To benchmark the video displayed, we modified a benchmarking code1 using
Google Chrome system functions, allowing to get an accurate frame-rate and
resolution of the video to analyse.
6.1.4
27
Figure 12: Results of bandwidth tests on the video and audio streams
WebRTC allows to have a decent conversation quality even at very low upload rates, but as seen on almost every result, a high activity on the web camera
conducts the frames per second to drop to a very low value.
An automatic resizing of the video is also to note, even if it is minor. The
WebRTC algorithms favour high resolution over the frames per seconds available, as the resolution of the video could have been reduced a lot more, implying
a gain of frames per second.
Finally, we can see that bandwidths around 300kb/s ensures a very good
quality of conversation, even with high activity on the web camera.
Screen sharing
28
6.2
6.2.1
Security concerns
Data security
The first concern is about data and media security. Most of the already implemented WebRTC applications mainly use unprotected data transfer using
RTP, in a matter of speed or simplicity, that can result in the interception of
those media. It is also a problem of transparency between the user and the
actions realized by WebRTC. Once the media sharing have been accepted by
a user, it is remembered by the browser and malicious record of data can be
operated. A client may also be infected by a virus or malicious software that
can load on top of WebRTC and fetch the shared media from all the parties in
the conference. To counter those problems, the use of secure protocols for the
transmission of the data itself can be set-up by the developers, by encrypting
the streams themselves by both parties.
6.2.2
The signaling server implementation is also a key point when it comes to security. As this part is not standardized, and is important because it deals with
29
Conclusion
The implementation of this project have been very profitable for us. First
it allowed us to learn a lot about various cutting-edge technologies alongside
WebRTC. We also went through a complete process of research and implementation, to end with a finished product usable on-line. Working on very recent
concepts is far from easy. Our teamwork strategies helped us to finish the
project in time despite the complexity of some parts of the implementation.
This project will hopefully be reused by the WebRTC community, especially by
developers wanting to either include WebRTC features to the MEAN stack, or
to an AngluarJS project.
WebRTC on its own is a very promising technology that considers a major
breakthrough in the world of web conferencing, by its simplicity of use and its
support by the most trusted authorities on the web. The performances shown
by WebRTC are good but can be improved on large conferences, with, in example, the possibility to use relay servers to manage the data transfer for users
with a limited bandwidth. The possible success of WebRTC is based first on the
want of the major web browsers owners to implement it. Second, the actors of
the web scene can also decide if WebRTC can become the only real time communication standard on the web, by using it in popular projects. The support
of ORTC by Internet Explorer shows that the real time communication on the
web may be divided in two sides, or WebRTC may evolve in a different way.
8
8.1
Annexes
Project resources
30
Developers can also get full access to the code using our public repository.
It can be used to analyse the structure of the project, modify it or report bugs
or wanted ameliorations.
http://github.com/overlox/openhangouts
A brief documentation for installation and use can also be found at :
http://github.com/overlox/openhangouts/wiki
References
[1] D. K. Bryan Ford, Pyda Srisuresh, Peer-to-peer communication
across network address translators.
http://www.brynosaurus.com/pub/net/p2pnat/, feb 2005.
[2] S. Dutton, Getting started with webrtc.
http://www.html5rocks.com/en/tutorials/webrtc/basics/, jul 2012.
[3] M. Handley and V. Jacobson, RFC 2327: SDP: Session description
protocol, Apr. 1998. Status: PROPOSED STANDARD.
[4] A. B. Johnston, B. D., and D. C., WebRTC: APIs and RTCWEB
Protocols of the HTML5 Real-Time Web, Digital Codex LLC, USA, 2012.
[5] J. Lengstorf, Realtime web apps HTML5 WebSocket, Pusher, and the
webs next big thing, Apress Computer Bookshops distributor, Berkeley,
Calif. Birmingham, 2013.
[6] A. Narayanan, C. Jennings, B. A., and B. D., WebRTC 1.0:
Real-time communication between browsers, W3C working draft, W3C,
Sept. 2013. http://www.w3.org/TR/2013/WD-webrtc-20130910/.
[7] R. Rai, Socket.io Real-time Web Application Development, Packt Pub,
Birmingham, 2013.
[8] H. Schulzrinne, S. L. Casner, R. Frederick, and V. Jacobson,
RTP: A transport protocol for real-time applications. IETF Request for
Comments: RFC 3550, jul 2003.
[9] L.-L. Tsahi, Seven reasons for webrtc server-side media processing.
http://networkfuel.dialogic.com/webrtc-whitepaper, apr 2014.
31