Building a Web Based Video Conference Framework

Transcription

1 1 Building a Web Based Vide Cnference Framewrk Brun Silva, Ricard Pret Ubiwhere Abstract Current dcument cntains the prpsal f a slutin that will allw building a Web Based Vide Cnference. It is prpsed that this framewrk uses HTML5, JavaScript and WebRTC t implement all its features. A Brker, TURN and STUN Server and Client Javascript Library are prpsed t be develped. Brker will be respnsible t prvide a public service that will receive and bradcast all peer s messages prir t the peer t peer cmmunicatin channel establishment. TURN and STUN Server will prvide als a public service that will allw peers t gather their public infrmatin and create a WebRTC cmmunicatin channel. Client Library will implement all cnnectin and stream management features that will allw any web based slutin t seamlessly add videcnference features. The prpsed framewrk was subjected f an implementatin and a videcnference web slutin was develped using this framewrk. The use f the framewrk was a success having prved that the prpsed slutin indeed wrks in a real case scenari. Pssible future implementatins are als presented in rder t add even mre value t the prpsed framewrk. V I. INTRODUCTION idecnference slutins are currently widely used t allw users t interact with each ther using an Internet cnnectin. Implementatin f these features hwever is still cmplex and time cnsuming mainly due t the many prprietary vide/audi prtcls and tls held by private cmpanies. Users demand fr these systems is increasing keeping up with the increasing quality f Internet cnnectins. Furthermre, users want access t these slutins using different devices such as smartphnes, tablets, desktps and smart TVs and maybe in a near future even using smart watches due t recent develpments in this area. This brad scpe f pssible devices brings even mre cmplexity. The different devices hardware and sftware pses different challenges and restrictins t the develpment f a videcnference slutin. Develping a versin f the slutin targeting each ne f the devices independently, althugh being lightly less cmplex will be incredibly time cnsuming and therefre substantially expensive. II. PROPOSED SOLUTION The current sectin will explain pssible prblems and slutins regarding the implementatin f a web based videcnference framewrk that will be used t enable videcnference features. It is purpse f the current dcument t define the slutin architecture, mdules and features t be implemented and technlgies t be used. Previusly it was stated that ne f the main prblems t be addressed when building a videcnference slutin is the fact that users will demand t access it using a wide spectrum f devices. In rder t reslve and minimize future prblems by supprting new devices used by users, a web-based apprach is prpsed. The evlutin f web brwsers has cme a lng way and nwadays it is pssible t prvide rich virtual envirnments using a web brwser regardless the device users are using. Mst web pages even adapt its cntent t a given device s screen size in rder t prvide all its features in an intuitive and appealing way. The develpment f a based web slutin allws taking advantage f the referenced evlutin withut having t develp a new versin f the applicatin fr each new device user s are demand using. Besides this, building an adaptive interface will allw with less effrt but withut discarding functinalities r usability t build an unique slutin that will target all available platfrms. The additin f a vide/audi element t a web page can be implemented using HTML5 media features. HTML5 intrduced built-in media supprt using <audi> and <vide> elements allwing t seamlessly embedding media elements t a web page. All mdern brwsers currently supprt these features being pssible t use these elements in smartphnes, tablets and desktps. Prpsed slutin will use WebRTC t implement its vide and audi sharing features. WebRTC cnsists f an API definitin being wrked by Wrld Wide Web Cnsrtium (W3C) as well as a set f prtcls specified by the Internet Engineering Task Frce s (IEFT). WebRTC aims t enable web brwsers t pen a direct peer-t-peer cnnectin channel between peers allwing these peers t exchange infrmatin directly. The API defines hw these peers will interact and share media streams as well as ther messages thrugh the channel created amng peers. Currently the fllwing brwsers have native supprt fr WebRTC: Desktp PC Ggle Chrme (v23 r higher) Mzilla Firefx (v22 r higher)

2 2 Andrid Opera (v18 r higher) Ggle Chrme (v28 r higher) Mzilla Firefx (v24 r higher) Opera Mbile (v12 r higher) Taking int cnsideratin previus supprt infrmatin, it is easy t see that nt all devices will be able t use the develped slutin. IOS based devices as well as Internet Explrer r Safari brwser s currently d nt have native supprt t a WebRTC based slutin and s will nt be able t be used by end users. Despite this, the fact that independent and imprtant cmmunities such as W3C and IEFT are respnsible fr the specificatin f WebRTC, will undubtedly in a near future encurage/frce ther brwsers and devices t implement its features. A. General View Bellw is displayed an image cntaining the general view f the slutin t implement. Figure 1 - General View Framewrk will cnsist n three independent entities that will interact with each ther in rder t establish and maintain a peer cnnectin between tw peers and that will be used t exchange media stream infrmatin. Client Library will be embedded at any web page slutin in rder t prvide all features assciated with the videcnference. Bth Brker and TURN and STUN entities will cnsist n standalne server applicatins that will prvide an endpint allwing Client Library t use each service s features. A detailed descriptin f each ne f the entities and mdules t be implemented is prvided bellw. 1) Brker Brker cnsists n an individual service that will allw peers t send private and public messages amng ther cnnected peers. Multiple clients using the Client library will cnnect t this service using a scket cnnectin allwing creating a bi-directinal channel used t send and receive messages. It is previusly said that applicatin will allw peers t interact with each ther withut using any third service. This implementatin wuld pse n difficulty if bth peers that wish t interact with each ther had public IPs. In this scenari it wuld be easy t create a cmmunicatin channel and start exchanging infrmatin between these tw peers. This scenari hwever is very rare because it is expected the majrity f clients t be behind distinct NAT netwrks. In this scenari it will be impssible t start a direct channel cmmunicatin withut first each ne f the clients discver and cmmunicate their current public IP address. In rder fr each ne f the peers t privately send their actual IP address t each ther, there has t be sme public available endpint that can receive and send messages between these peers. Brker Service will accept scket cnnectins and will allw bradcasting messages t all targeted peers. Brker will then allw peers t exchange vital infrmatin that will be used t create a direct cmmunicatin channel and use webrtc specificatin and brwser s native implementatin f WebRTC t exchange media streams. Previus image displays tw sub-mdules assciated with this service: a) Rm Management In rder t grup multiple users and bradcast ntificatin messages t all interested peers the cncept f rm is prpsed. Users will be able t either register r enter in a precreated rm being scheduled t receive all ntificatins and public messages assciated with the registered rm. Regarding rm management the fllwing features are prpsed: Register t Rm Check if Rm is created Discnnect frm Rm Return current users in a given Rm It is prpsed Brker t nt handle rm id generatin as well as permissin management. It is intended that this service prvides a quick respnse system withut prcessing/validating any infrmatin. By prviding a rm based apprach it is pssible fr users t bradcast t all cnnected peers a given infrmatin withut having t cmmunicate individually with each peer. Als, user s discnnect/cnnect infrmatin can be bradcasted in rder t each cnnected peer t discard the previus targeted peer cnnectin that was established with the leaving user. b) Message Bradcaster Like previusly said, Brker s main purpse is t bradcast public and private messages. It is prpsed that this mdule implements the fllwing features: Bradcast message Public messages will be sent t all user s currently in the targeted rm. It is expected that these feature will be mainly used t bradcast ntificatins f user s

3 3 registering and leaving events. Send private message The establishment f a peer cnnectin between tw peers will be prmted by private messages. Tw peers will be able t exchange private infrmatin that will allw creating a peer cnnectin directly between these tw peers. This mdule will nly implement bth a public and private bradcasting message system. All infrmatin sent and bradcasted will nt be stred r validated by the brker. In rder t implement Brker, Nde.js technlgy is prpsed. Nde.js is a platfrm built n Chrme's JavaScript runtime fr easily building fast, scalable netwrk applicatins. Nde.js uses an event-driven, nn-blcking I/O mdel that makes it lightweight and efficient, perfect fr data-intensive real-time applicatins that run acrss distributed devices. Nde.js has Scket.IO built in supprt and is specially targeted t real time web applicatins. Nde.js is suited fr applicatins that have a high number f cncurrent cnnectins having each request a lw prcessing time assciated with it. Previus descriptin is a perfect match when cnsidering the missin assciated with the Brker service resulting that Nde.js is a perfect fit t develp this mdule. 2) TURN and STUN Server Like previusly referred it is impssible t create a direct cmmunicatin channel between tw peers behind a NAT netwrk withut knwing each client s public IP address. Current instance will prvide a public endpint and allw client s t retrieve their public IP address, type f NAT and further infrmatin that will enable tw clients t create a direct cmmunicatin channel using WebRTC API and prtcls. The mdules respnsible fr that are STUN (Sessin Transversal Utilities fr NAT) and TURN (Transversal Using Relays arund NAT). STUN server will reply t client requests with their public address and sme additinal infrmatin, like the type f NAT f their netwrks. Hwever, in sme cases, btaining public address thrugh STUN desn't slve the prblem, as in cases f clients behind ruters that emply a restrictin called Symmetric NAT, nce in this, cases fr each cnnectin, ruter als changes the surce prt, and thereby, the returned address frm STUN server is nly valid t the cnnectin established between client and STUN server. In this cases is used the TURN server, wherewith client establish a cnnectin and cmmunicate thrugh it with ther peers. The specificatin f this mdule is nt in the cntext f the current dcument. There are bth third party services as well pen surce implementatins, that prvide this service and s, n new pints r cnclusins can be retrieved r accmplished in the develpment f a service that already is widely available and dcumented. 3) Client Client will cnsist n a Javascript library that will enable the additin f videcnference features t any web based slutin. It will be respnsible t interact with TURN and STUN Server in rder t find clients public IPs, use Brker t negtiate peer cnnectins and streams with ther peers. With the use f Client, third party web slutins will nly have t display ntificatins received (if desired) and display active lcal and remte streams. A descriptin f each mdule displayed at Figure 1 is prvided: a) Lcal Stream Capture This mdule will be respnsible t capture and manage lcal stream t be shared with ther users. It will be pssible t share audi, vide, audi/vide and nthing. The fllwing features will be prvided: Enable lcal audi nly Enable lcal vide nly Enable lcal audi and vide Disable all lcal streams Third party applicatins will be able t set which lcal media streams the user desires t share. In rder t implement these features, getusermedia brwser functin will be used. All current scped brwsers (Opera, Chrme, Firefx) which supprt WebRTC features als prvide getusermedia functins which allws t seamlessly catch bth lcal user webcam and micrphne streams. Every time a user changes lcal sharing streams all user s rm active users will be ntified f the change. Fr each peer cnnectin that was currently used t share lcal stream, the re-negtiatin peer cnnectin rutine will be restarted in rder t re-create a new cmmunicatin channel with the updated lcal media stream. b) Brker Cnnectin Management Brker Cnnectin Management will be respnsible t manage cnnectin with the Brker service. Ntificatins will be passed t the third party slutin every time the cnnectin is established r lst. Besides this, this mdule will prvide the fllwing features: Send public message Send private message

4 4 c) Peer Cnnectin Management This mdule will be respnsible t manage the peer cnnectin with each peer. Every time a new peer cnnects/discnnects r a peer s sharing streams are changed (lcal r remte) this mdule will be respnsible t handle all the wrkflw needed t establish r re-establish the cnnectin. It will interact directly with TURN/STUN Server in rder t get lcal user s sessin descriptr. It will be this mdule the ne respnsible t implement all the webrtc cnnectin establishment wrkflw by using brwser s webrtc native features. This mdule will ntify third party web slutins every time a peer cnnectin with a given user is updated. In rder t better understand the wrkflw fllwed by this peer the fllwing image is presented: Besides allwing catching and sharing lcal streams it will be als pssible t manage remte streams. This mdule will be respnsible t implement features regarding this management. Despite the fact that a user is respnsible t define if it is currently sharing a lcal media stream, ther users will chse if they want t receive each ne f remte users available streams. In rder t allw this management the fllwing features will be prvided by the client: Enable remte user s stream receptin Disable remte user s stream receptin The same prcess defined fr the change f the sharing f a lcal stream will als be applied when changing the receptin f a remte stream. When changing a given peer s desired received streams, peer cmmunicatin channel will be renegtiated in rder t change received media stream. Client will cnsist in a JavaScript library that will enable the use f all previusly defined features. In rder t use Client, its surce will have t be added t any web based slutin. Besides this, an bject will have t be passed t the client and will have t implement a set f functins in rder t catch Client s events. By using this apprach it will be pssible t use all Client s public features as well as receive ntificatins frm Client. Figure 2 - Peer cnnectin establishment Previus image explains the wrkflw that will take place when Client2 enters a rm where Client1 is currently n. When Client2 successful registers the rm (1), a bradcast t all users currently in the rm will be sent by the Brker service (2). Client1 will receive the ntificatin and will then interact with TURN and STUN server (3) t retrieve its infrmatin regarding its public IP. A new peer cnnectin is created using this infrmatin and the sessin descriptin will be sent privately t the Client2 using Brker private message feature (4). On receiving this infrmatin, Client2 will interact with TURN and STUN Server (5) in rder fr it als t retrieve its peer cnnectin. It will use bth infrmatin returned by TURN and STUN (5) Server as well as sessin infrmatin sent by Client (4) t create the webrtc based channel. After creating it, it will return its infrmatin t Client1 (4) that is waiting fr this infrmatin t finish establishing the peer cnnectin. After these prcess a peer cnnectin is established between peers being pssible t bth Client1 and Client2 t directly send messages withut relying n a third service. d) Media Streams Management B. Develpment f the framewrk In rder t check if the prpsed slutin had the desired specificatin detail level an implementatin attempt t build the framewrk was realized using the prvided specificatin. The Brker was develped using Nde.js and the defined features were added allwing users create/enter rms and send private/public messages. An pen surce slutin was used t prvide the TURN and STUN Server just like prpsed. Client library was develped using Javascript and all features assciated with all mdules were implemented sung brwser native webrtc and user media features. Library prvides an abstractin t all webrtc and stream management implementatin using a ntificatin system in rder t prvide bth entrance/leaving ntificatins and lcal/remte streams t be displayed at the third party web page. By using this library, third party slutin will nly have t implement bth ntificatins and HTML5 vide/audi displays systems that will use streams prvided by the Client library. C. Third Party Applicatin In rder t use the develped framewrk a third party applicatin was develped n which videcnference features were t be added. The applicatin was develped targeting smartphnes, tablets and desktp devices adjusting layut t device s dimensins. A real time cllabrative whitebard was added t the slutin allwing users t cllabrate by drawing n the keybard while talking and viewing each ther.

5 5 As can be seen by previus images, slutin prvides slutin s features taking int cnsideratin nt nly device s size but als device s rientatin. By using the develped framewrk, it was pssible t fcus slutin s implementatin n the adaptin f the layut n which t display streams withut having t cncern all the prblems assciated with creating, managing peer cnnectins amng users. Prvided Client s features allwed d implement all basic features assciated with the establishment f a vide-cnference channel between users sharing a given rm. D. Future Wrk Figure 3 - Desktp View Figure 4 - Tablet Landscape View Althugh specificatin and psterir implementatin were a success n implementing a framewrk that enables videcnference features, there is still wrk that can be dne and that will allw embedding imprtant features t the framewrk adding even mre value t the final slutin. The prpsed framewrk has the ptential t be prvided as a SaaS. In rder t d this, sme changes wuld have t be made allwing cntrlling and distributing resurces amng the different clients. The first changes wuld have t be in the rm management. Rm creatin and management shuld filer its access t users using a given web based slutin. User permissins shuld als be implemented in rder t cntrl which users have access t a given rm. Als, the traffic assciated with each web based slutin wuld have t be mnitred in rder t be charged. A mdule respnsible t d this wuld als have t be specified and implemented. E. Cnclusins Prpsed framewrk specificatin allwed building a generic framewrk that allws implementing videcnference features t web based slutin withut mdificatins t the framewrk. The degree f specificatin present at the dcument, prved t be a valid apprach n building the prpsed framewrk withut needing any further specificatin and change. The integratin f the framewrk in a real case scenari was a success being the framewrk able t prvide all intended features. It is therefre safe t say that the framewrk did meet all the initial expectatin and if in a near future videcnference features are t be added t a given applicatin, the use f the specified and develped framewrk will be almst certain. REFERENCES [1] [2] [3] [4] [5] Figure 5 - Mbile Prtrait View Thmas Sandhlm, Bris Magnussn, Bjrn A. Jhnssn, On-Demand WebRTC Tunneling in Restricted Netwrks, 2014 Max Jnas Werner, WebRTC Security in the cntext f a DHT Implementatin, 2013 Hitendra Patil, Amar Buchade, Review and Study f Real Time Vide Cllabratin Framewrk WEBRTC, 2014 Justin Uberti, Cullen Jennings, Javascript Sessin Establishment Prtcl, 2013 M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Nrrman, The Secure Real-time Transprt Prtcl (SRTP), 2004

6 [6] A. Bergkvist, D. Burnett, C. Jennings, A. Arayanan, Webrtc 1.0: Realtime cmmunicatin between brwsers, 2012 [7] D. Burnett, A. Bergkvist, C. Jennings, A. Narayanan, Media capture and streams, [8] C. Perkins, M. Westerlund, J. Ott, Web Real-Time Cmmunicatin (WebRTC): Media Transprt and Use f RTP, 2012 [9] [10] [11] [12] [13] 6