Janus: back to the future of WebRTC!

Transcription

1 : back to the future of! Alessandro Amirante Tobia Castaldi Lorenzo Miniero Simon Pietro Romano January 14, 2015

2 Outline 1 Some context and standardization activities 2 Writing a gateway from scratch Programmable Real-time Media Components 3 : a general purpose gateway architecture 4

3 Real-time media in browsers No standard solution! No interoperability Plugins need to be installed anyway = Joint standardization efforts Internet Engineering Task Force (IETF) World Wide Web Consortium (W3C) RTCWEB (IETF) Real-Time Communication in WEB browsers WG Defines protocols and formats to use WEBRTC (W3C) Web Real-Time Communications WG Defines UI and API to access devices

4 reference architecture

5 Involving a gateway (and applications)

6 Involving different technologies as well

7 Do we really need a gateway? Several reasons for a YES, here Relieve full-meshes (heavy on the client side) Leveraging widespread technologies (e.g., SIP infrastructures) Fixing things between implementations Reason for a NO? You won t go beyond 1-1 communication You don t want an infrastructure You don t care about legacy stuff What is a Gateway anyway?

8 The protocol suite Signalling (well, sort of) and Negotiation Javascript Session Establishment Protocol (JSEP) Session Description Protocol (SDP) adaptation Connection Establishment and NAT Traversal Session Traversal Utilities for NAT (STUN) Traversal Using Relay NAT (TURN) Interactive Connectivity Establishment (ICE) Media Transport and Control Real-time Transport (and Control) Protocol (RTP/RTCP) Secure Extensions to RTP (SRTP) Datagram Transport Layer Security (DTLS) Media Transport and Control Opus audio codec (MTI, Mandatory-to-implement) VP8 (and/or H264!) video codec (MTI candidates) Generic Data Data Channels (SCTP)

9 : a general purpose gateway In ancient Roman religion and myth, [..] is the god of beginnings and transitions, and thereby of gates, doors, passages, endings and time. He is usually depicted as having two faces, since he looks to the future and to the past.

10 : a general purpose gateway A door between the communications past and future Legacy technologies (the past ) (the future ) General purpose, open source gateway Demos and documentation: Design and implementation of the gateway suite re-implemented (core) architecture rewritten from scratch

11 architecture The core only implements the stack JSEP/SDP, ICE, DTLS-SRTP, Data Channels,... Integrated web-server for communication with browsers Application logic implemented in server side plugins Users attach to plugins via the gateway core The gateway handles the stuff Plugins route/manipulate the media/data Some proof of concept plugins implemented Echo Test Streaming Conferencing ( Meetecho!) SIP Gateway ( Tiscali Indoona!)...

12 Extensible Architecture and API

13 Extensible Architecture and API

14 Plugins as bricks Each plugin is a feature, not an application Application can be composed out of different features Features as bricks for a complex scenario A few examples... Screensharing with Q&A Video MCU (screen) + Video MCU (speakers) + Audio Bridge (questions) Video communication in social networks SIP plugin (calls) + Echo Test (diagnostics) + Voice Mail (messaging) Social TV Streaming (TV channel) + Video MCU (interaction)

15 Screen Sharing with Q/A

16 Social TV

17 Benchmarking Measuring performance is not trivial... Different plugins have different behaviors Different technologies have different impact Need to focus on a single application Video MCU is a typical use case See, e.g., conferencing.

18 Benchmark configuration Stress testing done in lab: A single instance running on a server equipped with: 16-core Intel(R) Xeon(R) CPU E GHz; 32GB of RAM; Ubuntu LTS OS. One machine hosting browsers acting as publishers; controlled through the Selenium web browser automation framework. Three machines hosting browsers acting as viewers (also controlled through Selenium).

19 Preliminary results rocking figures 10 publishers (i.e., active users) # of server-side PeerConnections = nx(n 1) = passive viewers # of server-side PeerConnections = mxn = 30x10 = 300 A single instance was able to handle 390 Peer Connections flawlessly! CPU utilization does not go beyond 17% Did not (yet) push that limit further due to the lack of physical resources on the client side... Bandwidth, OTOH, may become an issue: Up to 80Mbit/s uplink bandwidth required (server-side) in the depicted scenario!

20 Video MCU performance

21 Video MCU performance

22 What to do next? Finalize the implementation SSRC multiplexing Integrate in our -related projects Meetecho (web conferencing) SOLEIL (large scale streaming) Mobile access Implementation for Android basically done, to be refined Improve the pluggable architecture Plugins as filters, not only sinks (e.g., transcoders) Plugins in series and/or in parallel Test test test! More numbers are important Hoping the community can help there Several people/companies already trying it in the field

23 Questions? Comments?