Webrtc Meeting Portal

Masaryk University Faculty of Informatics

WebRTC Meeting Portal

Bachelor’s Thesis

Václav Štěbra

Brno, Spring 2016

Declaration

Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Václav Štěbra

Advisor: doc. RNDr. Tomáš Pitner, Ph.D.

Acknowledgement

I am very thankful to my colleagues from SDE for their great and valuable feedback on the implementation of the portal. I would also like to thank my parents for their endless support.

iii Abstract

The goal of the thesis is to build online meeting portal. The portal should be built using the WebRTC technology which enables real-time communication in the web browser. The thesis should also investigate already existing applications that can be used for video conferences.

iv Keywords

online audio communication, online video communication, WebRTC, Javascript, NodeJS, HTML5

Contents

1 Introduction ...... 1 1.1 Motivation ...... 1 1.2 Goal of the thesis ...... 2 2 Online communication ...... 3 2.1 Real-time communication applications ...... 3 2.1.1 Desktop applications ...... 4 2.1.2 Web applications ...... 4 2.2 WebRTC ...... 5 3 Portal requirements ...... 7 3.1 Functional requirements ...... 7 3.2 Nonfunctional requirements ...... 7 3.2.1 Used technologies ...... 9 4 Architecture and implementation ...... 15 4.1 Authentication ...... 15 4.2 Meeting planning ...... 15 4.3 Meetings ...... 15 4.4 Architecture ...... 16 4.4.1 Routing ...... 16 4.4.2 Models ...... 19 4.4.3 WebSocket server ...... 20 4.4.4 WebRTC ...... 21 5 Deployment of the portal ...... 27 6 Conclusion ...... 31 6.1 Evaluation ...... 31 6.2 Possible extensions ...... 31 Bibliography ...... 33 A Attachment ...... 35

vii

List of Figures

3.1 Use case diagram for the portal 8 3.2 WebRTC architecture [12] 13 4.1 Classes representing application controllers 18 4.2 Sequence diagram for making WebRTC call 25 5.1 Deployment diagram for the portal 29

1 Introduction

1.1 Motivation

The Internet is everywhere in today’s society. It can be found in our homes, coffee shops, buses and even in our mobile phones. Internet has created a brand new way of communication between people in the whole world. It does not matter if you are in the Czech Republic, in the United States or in the Australia – there is still Internet connection available. And with that comes the opportunity to communicate with other people. The internet browser has become one of the most used application in almost all devices. It became an indispensable part of our life. Some of the computer users do not even use any other application than the browser. It became gate to their digital lives. Even though Internet originally served for publishing static content, Rich Internet Applications have begun to spread recently. These applications look like old fashioned desktop applications and provide web pages with interactivity – moving objects on the page, better graphics, asynchronous reloading of information on the web page, playing multimedia, etc. Also real-time applications have begun to ex- pand. These applications make communication from server to clients possible. Instead of just clients sending requests to the server, the server can now provide all connected clients with fresh information as soon as it is available. Real-time technologies made the creation of multimedia communication applications directly in the browser possible. They are also used mostly for applications like social media, or online games, where the freshness of the data is very important. In the past plugins were used for creating real-time applications. These plugins were needed to install in the browser in order for the page to work correctly. This solution is not ideal, because it forces users to become maintainers of their own browser. It also forces them to install and check for updates of these plugins for which some users may not have the necessary knowledge. Some of these plugins do not necessarily have to be safe and they open backdoors to user’s computer. Examples of these plugins are Flash and Silverlight. Because

1 1. Introduction of these shortcomings HTML51 and Javascript have been spreading more. These technologies provide way to create interactive applications without the need of using yet another modules. They are using native capabilities of the browser and therefore there is no need to install and maintain plugins.

1.2 Goal of the thesis

This bachelor thesis is concerned with creation of internet portal which will be used for making audio and video conferences. Most of today’s solutions for online conferences is in the form of desktop applications which forces users to download, install and maintain this installation on their own computers. Usage of these application may also not be free for larger group of people in simultaneous call. The portal is based on WebRTC2 technology. This technology provides interfaces for real- time communication directly between browsers. It contains functions for sending audio, video and also files. This interface is becoming part of almost all browsers. Therefore there is no need of any interference from user in order to use this portal. When WebRTC will be available in all browsers, the portal will be available to all users no matter what device they use. Management of the users participating in given conference is vital part of this portal. When creating a conference there is possibility to pick a list of users who will participate in this conference. Theoretical part of this thesis is researching applications that are currently used for online conferences. Next part contains the description of available technologies that can be used for creating Rich Internet Applications. Main content is the description of WebRTC technology and interfaces it provides for programmers. Practical part is describing the implementation of the portal and the resulting application. It sums the decisions made during the development of the portal including its deployment. In the next chapter of the practical part is the implementation evaluated and the problems and shortcomings that appeared during the development are mentioned. Possibilities of further extension are summarized in the conclusion.

1. HyperText Markup Language 2. Web Real-Time Communication – https://webrtc.org/

2 2 Online communication

With the development of the internet there has been a big expansion of communication over internet. Advantages of online communication are high availability and that this communication is mostly free of charge – included in the cost of internet connection. In the time of writing this thesis 72,97 percent of population of Czech Republic has Internet connection [3]. In the world it is 35 percent of all population [3]. This high percentage of availability makes internet great platform for everyday communication with family, friends, coworkers and also with clients. Online communication can be divided based on the type of trans- ferred messages. The most widely used form of communication nowa- days is text communication. Examples of this communication are email, social networks and chat portals. The main advantage of this form of communication is that the recipient of the message does not have to be online and can read the messages later. Another advantage is that it is easier to store the history of the communication. Next form of communication is multimedia communication. This communication transfers audio, video or combination of both between the participants in the real-time. The main advantage is the possibility of immediate reaction like in the personal communication. Disadvan- tages are bigger data flow and need of bigger storage in order to store the history of communication. This thesis is concerned with creating online portal for video conferences.

2.1 Real-time communication applications

This section describes various applications that can be used for any form of real-time communication. It lists both desktop and web applications. Web applications are easier to use because they do not usually need any setup. On the other hand desktop applications often offers richer functions and higher quality of audio and video transfer. It is up to the individual to select which solution suits his needs.

3 2. Online communication

2.1.1 Desktop applications ∙ Skype1 – communication application owned by Microsoft. It supports both chat messages and audio and video calls. It also supports calls to mobile phones and group calls.

∙ Pidgin2 – chat application that can use various chat networks such as ICQ, Google Talk, XMPP, IRC. It is also extensible with plugins, which can add support for other networks and protocols.

∙ ICQ3 – instant messaging software using OSCAR protocol. Some of it’s features are group chats, video chats and file transfers.

∙ Miranda4 – lightweight instant messaging software which supports multiple communication protocols. It is also extensible via plugins which can add support for other most used protocol that are not included in the base distributions.

2.1.2 Web applications ∙ Oracle Beehive Conferencing5 – web conferencing software used mostly by Oracle employees. It supports text and voice chats and also screen sharing.

∙ WebEx6 – developed by Cisco. Some of it’s features are video conferences, screen sharing and conference recording.

∙ GoToMeeting7 – online meeting application which supports voice and video calls, screen sharing, application sharing and also meeting recording .

1. http://www.skype.com 2. https://www.pidgin.im 3. https://www.icq.com 4. http://www.miranda-im.org 5. https://stbeehive.oracle.com/bcentral 6. https://webex.com 7. http://www.gotomeeting.com

4 2. Online communication

∙ Google Hangouts8 – application for chat and video calls developed by Google. It is also capable of calls to mobile phones and sending SMS messages.

∙ Join.me9 – offers audio and video conferencing for up to250 participants with the enterprise account. It also offers recording of the conferences, screen sharing and mobile and desktop versions of the application.

∙ AnyMeeting10 – software for audio and video conferences. Some of it’s features are screen sharing, file sharing, conference recording. It has prize plans supporting up to 1000 people in one conference.

2.2 WebRTC

Most of today’s solutions for video conferences is implemented using native applications or browser plugins. Disadvantage of these applications is that they need to be downloaded, installed and updated on the user’s computer. Because of this reasons new standard WebRTC was founded. WebRTC is open source project developed and maintained by Google. It implements standards for audio, video and file transfer in real-time without the need to install native application or browser plugin [4]. WebRTC is based on the peer-to-peer11 communication which enables data transfer directly between browsers without any intermediate server. The server is only responsible for transfer of the meta data which are used for initiating and managing peer-to-peer communication. This meta data transfer is called signaling. Signaling is not part of WebRTC standard and therefore any already existing protocol can be used. XMPP12 or SIP13 are examples of such protocols. Standard also enforces using encryption both for signaling and data

8. https://hangouts.google.com 9. https://www.join.me 10. https://www.anymeeting.com 11. Type of computer networks in which the communication is made directly between clients 12. Extensible Messaging and Presence Protocol 13. Session Initiation Protocol

5 2. Online communication transfer itself which leads to better security. Based upon the properties mentioned above and that this project is open source it is suitable for secure multimedia transfers in real-time. WebRTC provides interface in the Javascript programming language. This interface hides the direct access to the communication media, network and process of coding and decoding of audio and video data from the programmer. WebRTC API14 is still under active development which results in limited support in the browsers. As of time of writing this thesis only Chrome, Firefox and Opera browsers are supported [5]. As the time advances this situation gets better and in the future possibly all major browsers will be supported.

14. Application Programming Interface

6 3 Portal requirements

This chapter describes the requirements for the implementation of the portal.

3.1 Functional requirements

The main usage of this portal is to make conference calls with various customers and therefore there is huge emphasis on the security, authentication and authorization. The usage of the portal is restricted only to people that are registered. When the user is registered and logged in, he is able to schedule a new meeting. Upon scheduling a new meeting he can select group of people to which a link identifying the meeting will be sent. The user also has to select time and date of the meeting. To access the meeting user has to know it’s unique hyperlink. When the meeting has started, users can see all the participants that are connected. The primary form of meeting is video conference, but there is also possibility to exchange simple text messages. There are small previews of other users camera streams and user is able to select the one he is interested in and switch it to fullscreen mode by clicking on the preview. All of the requirements are summarized in the use case diagram in figure 3.1

3.2 Nonfunctional requirements

Since the main purpose of the portal is to be used for business meetings, it should be secure. All access and data transfer is performed via HTTPS connection. Users are logging in using their email and password which they have entered during the registration. Upon successful login server generates a unique token for the user which is then used for every request to the server he makes. This token is mainly used for authentication of the real-time communication.

7 3. Portal requirements

Figure 3.1: Use case diagram for the portal

8 3. Portal requirements

3.2.1 Used technologies Web development is becoming more and more complex. In order to create successful, reliable, secure, responsive and user friendly web application, web developers need to know handful of technologies. This chapter gives a list of these need to know technologies that are used in the implementation of the portal and describes the most important of them in greater detail. These particular technologies were chosen because they are widely used and very popular among developers when creating web applications. They are also very suitable for building rich, real-time web applications.

HTLM5 HTML5 is a fifth revision of the markup language used for structuring content on the Web. It was published on 28 October 2014 [6]. This new revision introduces a set of new elements and attributes that can be used when building modern websites. Some of these new elements are used for better, readable structure of the source code (nav, header, section, article). HTML5 also brings elements that can be used for displaying multimedia content on the webpage such as video and audio (video and audio tags). It also introduces new APIs for developers to use. These APIs are intended to be used with the cooperation of the Javascript language. Examples of these new APIs are canvas, drag and drop APIs, support for offline web applications, better history management and Web Storage.

CSS3 HTML5 is purposed for the structure of the content, so there is need for another language that would be used for graphical presentation of this content. Most used language for this purpose is CSS1. CSS is a style sheet language. CSS is designed primarily to enable separation of the document description and its graphical presentation. Specification of CSS3 is divided into several self-contained modules, each describing separate capabilities [7]. Examples of this modules are Media Queries,

1. Cascading Style Sheets

9 3. Portal requirements which provides developers with easier way to develop responsive applications, Namespaces, Selectors and Color modules.

Javascript JavaScript is scripting language most commonly used for Web pages. But it can also be used in non-browser environments. It is interpreted, object-oriented language. It mostly runs on the client side of the web, when it is used to program interactions on the web page and for manipulation of the Document Object Model. Javascript is prototype based language, which means that behavior reuse is made via cloning an existing objects and assigning them to the objects prototype. Javascript can also be used on the server. Example of such usage is Node.js2.

Node.js Node.js is an open-source JavaScript run-time used for developing server side applications.It is build on the Chrome’s V8 JavaScript en- gine. It is not JavaScript framework but rather environment in which JavaScript applications can run. It provides non-blocking I/O API. Non-blocking input/output or also asynchronous input/output per- mits processing of multiple files simultaneously which leads to better performance when processing multiple requests at once which is typi- cal for web applications. It is based on event-driven architecture. Event driven architecture is an architecture pattern in which applications are built around producing and reacting to events. Due to it’s performance benefits, Node.js is often used to build large, scalable network applications and applications where real-time response is needed.

WebSockets & socket.io Most of current web applications are using communication model client-server. That means that clients are sending request for the data to the server which then responds with the requested data. But this is not enough for the real-time applications. That led to the development of new protocol called WebSocket. WebSocket provides full-duplex

2. https://nodejs.org/en/

10 3. Portal requirements

communication channels over a single TCP3 connection [10]. It can be used in web applications and also in any other client application – desktop or mobile applications for example. It is capable of bi-directional communication between the server and the client meaning that the server can send data to client at any time. This protocol is currently supported in most major browsers. Socket.io4 is the most popular JavaScript library that implements bi-directional communication using WebSocket protocol.

Bootstrap Bootstrap5 is a one of the most popular front end frameworks. It is used for developing responsive web applications. It provides front end developers with CSS classes that can be applied to HTML markup to style the markup in a consistent style. It also contains a set of pre- defined components like modal dialogs, navigation elements, tabs and other different components that are widely used in today’s web development.

Package managers, build process Current web applications are built using many libraries, frameworks and utilities. It is vital part of development to manage these dependencies in a consistent manner. One way of managing libraries is to download them manually. But this can become unmanageable very quickly. For this purpose package manager software exists. These package managers contain databases of packages published by other developer which can be simply used in any project. Developer just have to declare which libraries he wants to use and then the package manager will take care of downloading and installing the right version of the library. Two of the most widely used package managers are Bower6 and NPM7. Bower is package manager for the front-end of the

3. Transmission Control Protocol 4. http://socket.io/ 5. http://getbootstrap.com 6. http://bower.io/ 7. https://www.npmjs.com/

11 3. Portal requirements web, whereas NPM is used for managing dependencies for Node.js applications. With the growing complexity of web applications there is need to minify the sources to serve them as compact as possible. Sources are often concatenated into as few as possible files, reducing the number of requests client needs to make to the server. These concatenated files can then be minified – unnecessary white spaces are removed, variables can be renamed to shorter names – all without changing the functionality of the application. Build tools can be used to automate this kind of tasks every time the sources are updated. They can also be used to moving resulting files to desired directories and they can even be used to automated deployment of the application. One of the most widely used build system tools is Gulp8.

MongoDB MongoDB9 is a document-oriented database. It is NoSQL database which means that data are not stored in tables as in traditional rela- tional databases, but in case of MongoDB in JSON-like schemas. It has drivers for multiple programming languages including Javascript and therefore it can be used to store data needed for web applications.

WebRTC WebRTC is a framework that enables developers with the APIs they can use to build browser applications that use real time communication. It is supported by Google, Mozilla and Opera and is developed jointly by W3C10 and IETF11. In the past integrating real-time communication in the browser applications was too complex and expensive. Therefore WebRTC has implemented standards for real-time, plugin-free video, audio and data transfer. It’s architecture is shown in figure 3.2[11]. The most interesting part for web developers are the Web APIs. They are implemented in Javascript language and hides the low level algorithms for media access, video/audio decoding and network transfer from

8. http://gulpjs.com/ 9. https://www.mongodb.org/ 10. World Wide Web Consortium 11. Internet Engineering Task Force

12 3. Portal requirements

Figure 3.2: WebRTC architecture [12]

the developers. The lower level exposes it’s APIs in C++ language and is targeted for web browser developers to help them with integrating support of WebRTC in their browser. It contains audio and video algorithms and transport algorithms as well. The most important API from WebRTC library is method called RTCPeerConnection. This method creates RTCPeerConnection [13] object which is used for managing the peer-to-peer communication between clients. It can be used as follows:

var pc = new RTCPeerConnection(config) where config is a variable containing configuration needed for successful connection. Mainly it contains an array of ICE12 servers which are used for determining client’s public IP13 address and open port

12. Interactive Connectivity Establishment 13. Internet Protocol

13 3. Portal requirements for communication even when the user is hidden behind NAT14 or firewall. Usage of WebRTC APIs is described in section 4.4.4.

ICE and NAT NAT is shortcut for Network Address Translation [15]. It is a method of translating IP addresses used on private local network to public IP address and also in the opposite direction. In order to reach resources beyond the local network a request has to be translated by NAT server. The source IP address of the request is changed to the public IP address of the NAT server and the server is then responsible for mapping this address back to the original server inside the private network. In order to initiate peer to peer communication using WebRTC peers need to know their public IP addresses. Therefore a technique called Interactive Connectivity Establishment is used. It provides NAT and firewall traversal capabilities for any type of session-oriented protocol [14]. It allows direct communication between peers even if they are in separate private networks. It works by gathering IP addresses and open ports of potential candidates through which can then the communication be routed. Security related side effect related to the ICE traversal is that the other peers can discover private IP addresses of each other. This can then be used for malicious acts against the user.

14. Network Address Translation

14 4 Architecture and implementation

This chapter describes architecture of the system. It shows and explains the most important parts of the implemented system.

4.1 Authentication

Authentication is done using session based method. That means that upon successful login user is issued a unique session identifier by the server. This identifier is than usually stored in a browser cookie. The server then processes this session identifier during every request to acknowledge the identity of the user. Users are authenticated to the portal using their email address and password. Both identifiers are chosen during registration. After successful registration user is also logged to the system so that he does not need to enter his credentials once again. A unique token is also generated for the user. This token is used for authentication to the socket.io server.

4.2 Meeting planning

The main page of the portal is used for planning new meetings. To plan a new meeting user has to enter its title, start and end date. A list of emails of participants can also be filled in. An email with link for the meeting will be sent to every email address in this field.

4.3 Meetings

This section describes the main piece of functionality of the portal - meeting itself. In order to join the meeting user has to be logged into the system. To join a specific meeting he need to know its link. Knowledge of the link serves as authorization mechanism for the meetings. Only people who knows the link are allowed to join the meeting. On the meeting page there are three tabs. Chat, video and participants.

15 4. Architecture and implementation

Chat tab serves for simple exchange of the text messages between connected users. Detailed description of how the chat is implemented can be found in the section 4.4.3. Video tab displays user’s local video and also video and audio stream of all connected users. Implementation is described in section 4.4.4. Participants tab shows who is connected to the meeting. It is a simple list of email addresses of all connected users. This also serves as a simple authorization mechanism for the leader of the meeting to see if the link to the meeting has not been leaked to somebody that should not know it.

4.4 Architecture

The portal is implemented using Model-View-Controller design pattern. MVC1 is a popular design pattern used when developing web applications. It separates the presentation of the data from the business logic of the implemented system. As the name suggests the main parts of this pattern are views, models and controllers. Models are used for managing data and business logic within the application. This also includes all operations performed on the data storage such as database. Views are used for displaying of the data. The views often are templates that specify how the data should be displayed. They do not include any logic. Controllers are the middle piece that puts it all together. Their purpose is to translate user’s request to model’s methods and then selecting the right view, supplying it with the data it needs and sending this resulting view back to the client.

4.4.1 Routing The concept of routing in context of the MVC architecture and in the web development in general is to map HTTP requests to calls of the server functions. Therefore routing is responsible for how the application reacts to user’s requests. Express2 framework provides

1. Model-View-Controller 2. http://expressjs.com/

16 4. Architecture and implementation developers with simple method of routing. Basic definition for routing functions can be described as follows: app .METHOD(PATH, HANDLER) ;

METHOD is one of the HTTP request methods, PATH is path on the server which runs the application and finally HANDLER is a function that will be executed when users makes requests for the PATH with given METHOD. The portal uses these routes:

∙ ’/’

– GET – displays main page of the portal which allows users to plan new meeting – POST – creates new meeting based on the data in the request

∙ ’/register’

– GET – displays a register form – POST – creates new user

∙ ’/login’

– GET – displays a login form – POST – logs user in

∙ ’/logout’

– GET – logs user out

∙ ’/meetings/:meetingId’

– GET – this route presents user with page that contains the meeting itself

17 4. Architecture and implementation

Figure 4.1: Classes representing application controllers

Controllers

The application uses two controllers. Meetings controller which is responsible for handling all interactions with the meeting and the Users controller which handles interactions with the users. Class diagram for the controllers is shown in figure 4.1. Users controller is responsible for presenting users with the login/register forms, user authentication and creating new users. Meetings controller is responsible for presenting users with the form to plan new meeting, displaying the page with the meeting and creating new meeting. There are there possible pages that are shown to users based on the state the meeting is in. First is shown before the meeting has started and displays information about the meeting such as its name, organizer, start and end date and also the list of participants that were selected by the organizer. This page also contains link for other users to join. Second is presented during the meeting. It contains various interfaces for chatting, viewing video streams from other users and a list of users who are attending the meeting. Third is shown after the meeting has ended. Its main purpose is to inform users that the meeting has ended and therefore they are not allowed to attend it anymore.

18 4. Architecture and implementation

4.4.2 Models

As was mentioned in one of previous chapters, Mongodb was chosen for storing all the needed data for the portal. For easy representation and manipulation with the data a Javascript library called mongoose3 was chosen. Mongoose is an object modeling library that provides schema-based ways to model application data. With this library developers can define the structure of the models used within their application using Javascript objects. First of all the portal needs to store data about users. All this data is stored in a single document with the following structure: { _id: ObjectId("randomUniqueId") , email: "[email protected]", password: "hashedPassword" }

With the mongoose library this data can be represented in the application using following object: var mongoose = require("mongoose") ;

var userSchema = new Schema({ email: { type: String, unique: true }, password: String });

The naming of the fields is self-explanatory – email field stores email of the user and the password field stores hash of user’s password._id field is auto generated by Mongodb and contains unique hash which serves for identifying the user record. Also email field is unique in the document. The portal also needs to store data about meetings. Such data include start date of the meeting, end date of the meeting, organizer of the meeting, list of participants. This data is stored in the following format:

3. http://mongoosejs.com/

19 4. Architecture and implementation

{ _id: ObjectId("randomUniqueId") , organizer: ObjectId("idOfTheOrganizer") , startDate: new Date() , endDate: new Date() , participants: [ { userId: ObjectId("idOfParticipant1") , }, { userId: ObjectId("idOfParticipant2") , } ], }

4.4.3 WebSocket server The vital piece of the application is also the WebSocket server. This server is written using the socket.io library and is responsible for both the real-time chat between users and the WebRTC signaling. In the context of WebSocket server each users is represented by a network socket. Network socket is an endpoint of a connection across a computer network. This socket is opened during the entire time user is connected to the server allowing the exchange of the messages between the user and the server.

Real-time chat In order to communicate only with people in the same meeting a concept of rooms is used. When the user connects to the meeting he is assigned to the specific room for the meeting. This room is identified by the id of the meeting. All messages are then exchanged only between users in the same room. When user enters a new message to the chat, the socket representing the user emits new event called ’chat message’. The payload of this event is the email of the user and the text of the chat message he

20 4. Architecture and implementation

entered. This message is then broadcasted from the WebSocket server to all other users in the same room.

WebRTC signaling The signaling is implemented using single event called ’webrtc.message’. The data being sent contains identifier of the user sending the message, identifier of the recipient of the message and type of the message. The type of the message is one of the ice, sdp-offer and sdp-answer strings. Message of type ice is used to exchange the ICE candidates between the users. sdp-offer type of message is used when sending the session description offer to the other peer and sdp-answer is used when responding to the session description offer.

4.4.4 WebRTC The most important part of the portal is the ability to do the video calls. This is implemented using peer to peer WebRTC API. The portal supports multiple users in one meeting and therefore each user has to create peer connection with other participants. When the user joins the meeting and starts the call, message is sent using the signaling Web- Socket server to all connected users indicating that new user has connected. Every user then creates an object of type RTCPeerConnection to create a peer to peer connection with the connected user. All the steps necessary to initiate the call are described in the figure 4.2. When the RTCPeerConnection object is created, the local stream is added to the connection and SDP4 offer is sent to the other peer. SDP is an internet protocol which purpose is to describe the transfer of the multimedia data. It is not used to transfer the data itself but instead it is used to negotiate the attributes of the medium. Some of the attributes are type of medium (audio, video) and supported audio and video codecs [16]. When the receiving user receives the SDP offer he creates an SDP answer which is in same format as the SDP offer and sends it through the signaling server back to the initiator of the connection. The peer connection is then established based on these SDP messages. An example of the SDP message is shown below. This message was generated when performing call to the same machine. It

4. Session Description Protocol 21 4. Architecture and implementation shows various parameters that are being negotiated before the start of the connection.

22 4. Architecture and implementation

Listing 4.1: Sample SDP offer

v=0 o=mozilla . . . THIS_IS_SDPARTA−46.0 ,→ 5159295319242568826 0 IN IP4 0.0.0.0 s=− t =0 0 a=fingerprint :sha −256 C5:84:35:36:E2:4B:5C:02:A8 ,→ :29:31:F1:98:17:40:69:7B:9B:5A:24:CE:90:C4 ,→ :15:90:02:E9:78:2D:98:64:37 a=group:BUNDLE sdparta_0 sdparta_1 a=ice−options: trickle a=msid−semantic :WMS * m=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8 c=IN IP4 0.0.0.0 a=sendrecv a=extmap:1 urn: ietf :params:rtp−hdrext: ssrc −audio− ,→ l e v e l a=fmtp:109 maxplaybackrate=48000;stereo=1 a=ice−pwd:3 cabb6a5723d9d2c338be7274a0891cf a=ice−ufrag :c881ac9b a=mid: sdparta_0 a=msid:{690d17c0−1fe3 −4b8f−b3ed−8763ebed0579} {50 ,→ d249df −20e2 −4015−889d−1816bdfd7cc4} a=rtcp−mux a=rtpmap:109 opus/48000/2 a=rtpmap:9 G722/8000/1 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=setup: actpass a=ssrc:649719515 cname:{ fe3561b6 −8d7c−46d6−bc34− ,→ c0343b3c3b33} m=video 9 UDP/TLS/RTP/SAVPF 120 126 97 c=IN IP4 0.0.0.0 a=sendrecva=fmtp:126 profile −level −id=42e01f ; level ,→− asymmetry−allowed=1;packetization −mode=1 a=fmtp:97 profile −level −id=42e01f ; level −asymmetry− ,→ allowed=1

23 4. Architecture and implementation a=fmtp:120 max−fs =12288;max−f r =60 a=ice−pwd:3 cabb6a5723d9d2c338be7274a0891cf a=ice−ufrag : c881ac9ba=mid: sdparta_1 a=msid:{690d17c0−1fe3 −4b8f−b3ed−8763ebed0579} {9 ,→ d442830−1fd1−4c22 −8075−89cc7047013f} a=rtcp−fb : 1 2 0 nack a=rtcp−fb:120 nack pli a=rtcp−fb:120 ccm fir a=rtcp−fb : 1 2 6 nack a=rtcp−fb:126 nack pli a=rtcp−fb:126 ccm fir a=rtcp−fb : 9 7 nack a=rtcp−fb:97 nack pli a=rtcp−fb:97 ccm fir a=rtcp−mux a=rtpmap:120 VP8/90000 a=rtpmap:126 H264/90000 a=rtpmap:97 H264/90000 a=setup: actpass a=ssrc:761680215 cname:{ fe3561b6 −8d7c−46d6−bc34− ,→ c0343b3c3b33 }"

24 4. Architecture and implementation

Figure 4.2: Sequence diagram for making WebRTC call

5 Deployment of the portal

This chapter describes one possible way how the portal can be deployed and brought to life. Steps mentioned in this chapter has been implemented to deploy sample application of this portal within the SDE1 company. The portal can be found on following url https:// mtg.sde.cz. All the components are also displayed in the deployment diagram in figure 5.1 For internal use in the SDE company, the portal is deployed to vir- tual machine running Debian2 operating system. On top of this system runs Nginx3 web server, that is configured to transfer all incoming requests to port 3000 on same machine. NodeJS server is then running on this port. Below is the configuration file for the Nginx web server.

Listing 5.1: /etc/nginx/sites-available/mtg server { l i s t e n 8 0 ; server_name mtg.sde.cz; return 301 https:// ,→ $server_name$request_uri ; }

server { listen 443 ssl; server_name mtg.sde.cz;

s s l on ; ssl_certificate /etc/ssl/mtg/mtg.sde.cz. ,→ c r t ; ssl_certificate_key /etc/ssl/mtg/mtg.sde. ,→ cz . key ; ssl_session_timeout 5m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

1. Software Development Europe, s.r.o 2. https://www.debian.org/ 3. http://nginx.org/

27 5. Deployment of the portal

s s l _ c i p h e r s ’EECDH+AESGCM:EDH+AESGCM: ,→ AES256+EECDH: AES256+EDH’ ; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m;

l o c a t i o n / { gzip o f f ; proxy_set_header X−Forwarded−S s l on ; client_max_body_size 500M; proxy_set_header Upgrade ,→ $http_upgrade ; proxy_set_header Connection " ,→ upgrade " ; proxy_set_header Host $http_host; proxy_set_header X−Real−IP ,→ $remote_addr ; proxy_set_header X−Forwarded−For ,→ $proxy_add_x_forwarded_for ; proxy_set_header X−Forwarded−Proto ,→ $scheme ; proxy_set_header X−Frame−Options ,→ SAMEORIGIN; proxy_pass https ,→ ://85.93.125.217:3000; } }

NodeJS server is managed using the PM24 tool. PM2 tool is com- mand line utility used for managing NodeJS applications. Applications managed by PM2 can be set up to start automatically after the machine start up. On the same machine also runs daemon for the MongoDB database.

4. http://pm2.keymetrics.io/

28 5. Deployment of the portal

Figure 5.1: Deployment diagram for the portal

6 Conclusion

6.1 Evaluation

The goal of this thesis was to design and implement a simple meeting portal that can be used for making video calls between multiple users. The work also mentions some of the already existing solutions for video conferences. The portal was successfuly implemented and is used for internal meetings in the SDE company. The implementation of this portal demonstrates capabilities of the WebRTC technology. It shows one of its primary way of use – real-time communication. WebRTC can also be used for data transfer between connected peers. The main limitation that was discovered during implementation of the portal is a quality degradation when a bigger amount of peers is connected. The cause for this is that in order to communicate with n users, each user has to establish n - 1 peer connections with other users. This network topology is called mesh topology. When peers are connected this way, each of them has to send his data stream to n - 1 users which results in huge requirements for user’s upload speed. One of possible solutions to this is to use MCU1 server. MCU server can be used to merge the multimedia streams into one. This server would then be responsible for accepting data streams from all the users and transferring them to the other connected peers. Without this special server, the portal is usable only for small amount of users depending on each users internet connection speed. Using the iftop2 UNIX utility it was discovered that one stream consumes approximately 1.6 Mb/s of bandwith.

6.2 Possible extensions

There are a lot of possible extensions to the implemented portal. Some of them include the possibility to mute the microphone, stop the camera stream. Also in the future screen sharing can be added so that the

1. Multiple Control Unit 2. http://www.ex-parrot.com/pdw/iftop/

31 6. Conclusion users can share their work directly from the browser. However screen sharing API is not yet widely adopted between browser vendors.

32 Bibliography

[1] Ian Hickson. WebRTC 1.0: Real-time Communication Between Browsers. Jan. 2016. url: https://www.w3.org/TR/webrtc/ (visited on 11/04/2015). [2] Erich Gamma et al. Design Patterns: Elements of Reusable Object- Oriented Software. Addison-Wesley, 1994. isbn: 0-201-63361-2. [3] List of countries by number of Internet users. Oct. 2015. url: https: //en.wikipedia.org/wiki/List_of_countries_by_number_ of_Internet_users (visited on 11/04/2015). [4] Sam Dutton. Getting Started with WebRTC. Feb. 2014. url: http:// www.html5rocks.com/en/tutorials/webrtc/basics/ (visited on 11/04/2015). [5] WebRTC Peer-to-peer connections. url: http : / / caniuse . com / #feat=rtcpeerconnection (visited on 11/04/2015). [6] HTML5. Oct. 2014. url: https://www.w3.org/TR/html5/ (visited on 02/20/2016). [7] CSS Current Status. url: https : / / www . w3 . org / standards / techs/css#w3c_all (visited on 02/20/2016). [8] JavaScript. url: https://developer.mozilla.org/en-US/docs/ Web/JavaScript (visited on 02/20/2016). [9] About Node.js. url: https://nodejs.org/en/about/ (visited on 02/20/2016). [10] WebSocket. Feb. 2016. url: https://en.wikipedia.org/wiki/ WebSocket (visited on 02/20/2016). [11] WebRTC Architecture. url: https://webrtc.org/architecture/ (visited on 02/20/2016). [12] WebRTC Architecture Diagram. url: https://webrtc.org/assets/ images/webrtc-public-diagram-for-website.png (visited on 02/20/2016). [13] RTCPeerConnection Interface. url: http : / / w3c . github . io / webrtc-pc/#rtcpeerconnection-interface (visited on 02/20/2016). [14] Jonathan Rosenberg. Interactive Connectivity Establishment. url: http://www.internetsociety.org/articles/interactive- connectivity-establishment (visited on 05/10/2016). [15] Network address translation. May 2016. url: https://en.wikipedia. org/wiki/Network_address_translation (visited on 05/10/2015).

33 BIBLIOGRAPHY

[16] M. Handley, V. Jacobson, and C. Perkins. SDP: Session Descrip- tion Protocol. July 2016. url: https://tools.ietf.org/html/ rfc4566 (visited on 05/10/2016).

34 A Attachment

The source code for the portal is available in the archive in the Infor- mation System of Masaryk University.