Abstract—Current document contains the proposal of a solution that will allow building a Web Based Video Conference. It is proposed that this framework uses HTML5, JavaScript and WebRTC to implement all its features. A Broker, TURN and STUN Server and Client Javascript Library are proposed to be developed. Broker will be responsible to provide a public service that will receive and broadcast all peer’s messages prior to the peer to peer communication channel establishment. TURN and STUN Server will provide also a public service that will allow peers to gather their public information and create a WebRTC communication channel. Client Library will implement all connection and stream management features that will allow any web based solution to seamlessly add videoconference features. The proposed framework was subjected of an implementation and a videoconference web solution was developed using this framework. The use of the framework was a success having proved that the proposed solution indeed works in a real case scenario. Possible future implementations are also presented in order to add even more value to the proposed framework.
I. INTRODUCTION
ideoconference solutions are currently widely used to allow users to interact with each other using an Internet connection. Implementation of these features however is still complex and time consuming mainly due to the many proprietary video/audio protocols and tools held by private companies. Users demand for these systems is increasing keeping up with the increasing quality of Internet connections. Furthermore, users want access to these solutions using different devices such as smartphones, tablets, desktops and smart TVs and maybe in a near future even using smart watches due to recent developments in this area. This broad scope of possible devices brings even more complexity. The different devices’ hardware and software poses different challenges and restrictions to the development of a videoconference solution. Developing a version of the solution targeting each one of the devices independently, although being lightly less complex will be incredibly time consuming and therefore substantially expensive.
II. PROPOSED SOLUTION
The current section will explain possible problems and solutions regarding the implementation of a web based videoconference framework that will be used to enable
videoconference features. It is purpose of the current document to define the solution architecture, modules and features to be implemented and technologies to be used.
Previously it was stated that one of the main problems to be addressed when building a videoconference solution is the fact that users will demand to access it using a wide spectrum of devices. In order to resolve and minimize future problems by supporting new devices used by users, a web-based approach is proposed. The evolution of web browsers has come a long way and nowadays it is possible to provide rich virtual environments using a web browser regardless the device users are using. Most web pages even adapt its content to a given device’s screen size in order to provide all its features in an intuitive and appealing way. The development of a based web solution allows taking advantage of the referenced evolution without having to develop a new version of the application for each new device user’s are demand using. Besides this, building an adaptive interface will allow with less effort but without discarding functionalities or usability to build an unique solution that will target all available platforms.
The addition of a video/audio element to a web page can be implemented using HTML5 media features. HTML5 introduced built-in media support using “<audio>” and “<video>” elements allowing to seamlessly embedding media elements to a web page. All modern browsers currently support these features being possible to use these elements in smartphones, tablets and desktops.
Proposed solution will use WebRTC to implement its video and audio sharing features. WebRTC consists of an API definition being worked by World Wide Web Consortium (W3C) as well as a set of protocols specified by the Internet Engineering Task Force’s (IEFT). WebRTC aims to enable web browsers to open a direct peer-to-peer connection channel between peers allowing these peers to exchange information directly. The API defines how these peers will interact and share media streams as well as other messages through the channel created among peers.
Currently the following browsers have native support for WebRTC:
• Desktop PC
o Google Chrome (v23 or higher) o Mozilla Firefox (v22 or higher)
Building a Web Based Video Conference
Framework
Bruno Silva, Ricardo Preto
Ubiwhere
o Opera (v18 or higher) • Android
o Google Chrome (v28 or higher) o Mozilla Firefox (v24 or higher) o Opera Mobile (v12 or higher)
Taking into consideration previous support information, it is easy to see that not all devices will be able to use the developed solution. IOS based devices as well as Internet Explorer or Safari browser’s currently do not have native support to a WebRTC based solution and so will not be able to be used by end users. Despite this, the fact that independent and important communities such as W3C and IEFT are responsible for the specification of WebRTC, will undoubtedly in a near future encourage/force other browsers and devices to implement its features.
A. General View
Bellow is displayed an image containing the general view of the solution to implement.
Framework will consist on three independent entities that will interact with each other in order to establish and maintain a peer connection between two peers and that will be used to exchange media stream information. Client Library will be embedded at any web page solution in order to provide all features associated with the videoconference. Both Broker and TURN and STUN entities will consist on standalone server applications that will provide an endpoint allowing Client Library to use each service’s features. A detailed description of each one of the entities and modules to be implemented is provided bellow.
1) Broker
Broker consists on an individual service that will allow peers to send private and public messages among other connected peers. Multiple clients using the Client library will connect to this service using a socket connection allowing creating a bi-directional channel used to send and receive messages.
It is previously said that application will allow peers to interact with each other without using any third service. This implementation would pose no difficulty if both peers that wish to interact with each other had public IPs. In this scenario it would be easy to create a communication channel and start exchanging information between these two peers. This
scenario however is very rare because it is expected the majority of clients to be behind distinct NAT networks. In this scenario it will be impossible to start a direct channel communication without first each one of the clients discover and communicate their current public IP address. In order for each one of the peers to privately send their actual IP address to each other, there has to be some public available endpoint that can receive and send messages between these peers. Broker Service will accept socket connections and will allow broadcasting messages to all targeted peers. Broker will then allow peers to exchange vital information that will be used to create a direct communication channel and use webrtc specification and browser’s native implementation of WebRTC to exchange media streams.
Previous image displays two sub-modules associated with this service:
a) Room Management
In order to group multiple users and broadcast notification messages to all interested peers the concept of room is proposed. Users will be able to either register or enter in a pre-created room being scheduled to receive all notifications and public messages associated with the registered room. Regarding room management the following features are proposed:
• Register to Room • Check if Room is created • Disconnect from Room
• Return current users in a given Room
It is proposed Broker to not handle room id generation as well as permission management. It is intended that this service provides a quick response system without processing/validating any information.
By providing a room based approach it is possible for users to broadcast to all connected peers a given information without having to communicate individually with each peer. Also, user’s disconnect/connect information can be broadcasted in order to each connected peer to discard the previous targeted peer connection that was established with the leaving user.
b) Message Broadcaster
Like previously said, Broker’s main purpose is to broadcast public and private messages. It is proposed that this module implements the following features:
• Broadcast message
Public messages will be sent to all user’s currently in the targeted room. It is expected that these feature will be mainly used to broadcast notifications of user’s Figure 1 - General View
registering and leaving events. • Send private message
The establishment of a peer connection between two peers will be promoted by private messages. Two peers will be able to exchange private information that will allow creating a peer connection directly between these two peers.
This module will only implement both a public and private broadcasting message system. All information sent and broadcasted will not be stored or validated by the broker.
In order to implement Broker, Node.js technology is proposed. Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices. Node.js has Socket.IO built in support and is specially targeted to real time web applications. Node.js is suited for applications that have a high number of concurrent connections having each request a low processing time associated with it. Previous description is a perfect match when considering the mission associated with the Broker service resulting that Node.js is a perfect fit to develop this module.
2) TURN and STUN Server
Like previously referred it is impossible to create a direct communication channel between two peers behind a NAT network without knowing each client’s public IP address. Current instance will provide a public endpoint and allow client’s to retrieve their public IP address, type of NAT and further information that will enable two clients to create a direct communication channel using WebRTC API and protocols.
The modules responsible for that are STUN (Session Transversal Utilities for NAT) and TURN (Transversal Using Relays around NAT). STUN server will reply to client requests with their public address and some additional information, like the type of NAT of their networks.
However, in some cases, obtaining public address through STUN doesn't solve the problem, as in cases of clients behind routers that employ a restriction called Symmetric NAT, once in this, cases for each connection, router also changes the source port, and thereby, the returned address from STUN server is only valid to the connection established between client and STUN server. In this cases is used the TURN server, wherewith client establish a connection and communicate through it with other peers.
The specification of this module is not in the context of the current document. There are both third party services as well open source implementations, that provide this service and so,
no new points or conclusions can be retrieved or accomplished in the development of a service that already is widely available and documented.
3) Client
Client will consist on a Javascript library that will enable the addition of videoconference features to any web based solution. It will be responsible to interact with TURN and STUN Server in order to find clients’ public IPs, use Broker to negotiate peer connections and streams with other peers. With the use of Client, third party web solutions will only have to display notifications received (if desired) and display active local and remote streams.
A description of each module displayed at Figure 1 is provided:
a) Local Stream Capture
This module will be responsible to capture and manage local stream to be shared with other users. It will be possible to share audio, video, audio/video and nothing. The following features will be provided:
• Enable local audio only • Enable local video only • Enable local audio and video • Disable all local streams
Third party applications will be able to set which local media streams the user desires to share. In order to implement these features, getUserMedia browser function will be used. All current scoped browsers (Opera, Chrome, Firefox) which support WebRTC features also provide getUserMedia functions which allows to seamlessly catch both local user webcam and microphone streams. Every time a user changes local sharing streams all user’s room active users will be notified of the change. For each peer connection that was currently used to share local stream, the re-negotiation peer connection routine will be restarted in order to re-create a new communication channel with the updated local media stream.
b) Broker Connection Management
Broker Connection Management will be responsible to manage connection with the Broker service. Notifications will be passed to the third party solution every time the connection is established or lost. Besides this, this module will provide the following features:
• Send public message • Send private message
c) Peer Connection Management
This module will be responsible to manage the peer connection with each peer. Every time a new peer connects/disconnects or a peer’s sharing streams are changed (local or remote) this module will be responsible to handle all the workflow needed to establish or re-establish the connection. It will interact directly with TURN/STUN Server in order to get local user’s session descriptor. It will be this module the one responsible to implement all the webrtc connection establishment workflow by using browser’s webrtc native features. This module will notify third party web solutions every time a peer connection with a given user is updated. In order to better understand the workflow followed by this peer the following image is presented:
Figure 2 - Peer connection establishment
Previous image explains the workflow that will take place when Client2 enters a room where Client1 is currently on. When Client2 successful registers the room (1), a broadcast to all users currently in the room will be sent by the Broker service (2). Client1 will receive the notification and will then interact with TURN and STUN server (3) to retrieve its information regarding its public IP. A new peer connection is created using this information and the session description will be sent privately to the Client2 using Broker private message feature (4). On receiving this information, Client2 will interact with TURN and STUN Server (5) in order for it also to retrieve its peer connection. It will use both information returned by TURN and STUN (5) Server as well as session information sent by Client (4) to create the webrtc based channel. After creating it, it will return its information to Client1 (4) that is waiting for this information to finish establishing the peer connection. After these process a peer connection is established between peers being possible to both Client1 and Client2 to directly send messages without relying on a third service.
d) Media Streams Management
Besides allowing catching and sharing local streams it will be also possible to manage remote streams. This module will be responsible to implement features regarding this management. Despite the fact that a user is responsible to define if it is currently sharing a local media stream, other users will choose if they want to receive each one of remote users’ available streams. In order to allow this management the following features will be provided by the client:
• Enable remote user’s stream reception • Disable remote user’s stream reception
The same process defined for the change of the sharing of a local stream will also be applied when changing the reception of a remote stream. When changing a given peer’s desired received streams, peer communication channel will be re-negotiated in order to change received media stream.
Client will consist in a JavaScript library that will enable the use of all previously defined features. In order to use Client, its source will have to be added to any web based solution. Besides this, an object will have to be passed to the client and will have to implement a set of functions in order to catch Client’s events. By using this approach it will be possible to use all Client’s public features as well as receive notifications from Client.
B. Development of the framework
In order to check if the proposed solution had the desired specification detail level an implementation attempt to build the framework was realized using the provided specification. The Broker was developed using Node.js and the defined features were added allowing users create/enter rooms and send private/public messages. An open source solution was used to provide the TURN and STUN Server just like proposed. Client library was developed using Javascript and all features associated with all modules were implemented sung browser native webrtc and user media features. Library provides an abstraction to all webrtc and stream management implementation using a notification system in order to provide both entrance/leaving notifications and local/remote streams to be displayed at the third party web page. By using this library, third party solution will only have to implement both notifications and HTML5 video/audio displays systems that will use streams provided by the Client library.
C. Third Party Application
In order to use the developed framework a third party application was developed on which videoconference features were to be added. The application was developed targeting smartphones, tablets and desktop devices adjusting layout to device’s dimensions. A real time collaborative whiteboard was added to the solution allowing users to collaborate by drawing on the keyboard while talking and viewing each other.
Figure 3 - Desktop View
Figure 4 - Tablet Landscape View
As can be seen by previous images, solution provides solution’s features taking into consideration not only device’s size but also device’s orientation. By using the developed framework, it was possible to focus solution’s implementation on the adaption of the layout on which to display streams without having to concern all the problems associated with creating, managing peer connections among users. Provided Client’s features allowed do implement all basic features associated with the establishment of a video-conference channel between users sharing a given room.
D. Future Work
Although specification and posterior implementation were a success on implementing a framework that enables videoconference features, there is still work that can be done and that will allow embedding important features to the framework adding even more value to the final solution. The proposed framework has the potential to be provided as a SaaS. In order to do this, some changes would have to be made allowing controlling and distributing resources among the different clients. The first changes would have to be in the room management. Room creation and management should filer its access to users using a given web based solution. User permissions should also be implemented in order to control which users have access to a given room. Also, the traffic associated with each web based solution would have to be monitored in order to be charged. A module responsible to do this would also have to be specified and implemented.
E. Conclusions
Proposed framework specification allowed building a generic framework that allows implementing videoconference features to web based solution without modifications to the framework. The degree of specification present at the document, proved to be a valid approach on building the proposed framework without needing any further specification and change.
The integration of the framework in a real case scenario was a success being the framework able to provide all intended features. It is therefore safe to say that the framework did meet all the initial expectation and if in a near future videoconference features are to be added to a given application, the use of the specified and developed framework will be almost certain.
REFERENCES
[1] Thomas Sandholm, Boris Magnusson, Bjorn A. Johnsson, “On-Demand WebRTC Tunneling in Restricted Networks”, 2014
[2] Max Jonas Werner, “WebRTC Security in the context of a DHT Implementation”, 2013
[3] Hitendra Patil, Amar Buchade, “Review and Study of Real Time Video Collaboration Framework WEBRTC”, 2014
[4] Justin Uberti, Cullen Jennings, “Javascript Session Establishment Protocol”, 2013
[5] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, “The Secure Real-time Transport Protocol (SRTP)”, 2004
[6] A. Bergkvist, D. Burnett, C. Jennings, A. Arayanan, “Webrtc 1.0: Real-time communication between browsers”, 2012
[7] D. Burnett, A. Bergkvist, C. Jennings, A. Narayanan, “Media capture and streams”, http://dev.w3.org/2011/webrtc/editor/getusermedia.html, 2012
[8] C. Perkins, M. Westerlund, J. Ott, “Web Real-Time Communication (WebRTC): Media Transport and Use of RTP”, 2012
[9] http://www.w3.org/Security/wiki/Same_Origin_Policy [10] http://www.w3.org/TR/html401/
[11] http://dev.w3.org/2011/webrtc/editor/getusermedia.html [12] http://tools.ietf.org/html/rfc5245
