deploying webrtc successfully – a web developer perspective

COMPANY CONFIDENTIAL © COPYRIGHT 2014 DIALOGIC INC. ALL RIGHTS RESERVED.

D1-2 Deploying WebRTC Successfully –

Web Developer Perspective

Chad Hart

COMPANY CONFIDENTIAL © COPYRIGHT 2014 DIALOGIC INC. ALL RIGHTS RESERVED. 2

Agenda

Before you start

Front-end

Back-end

End-to-End


Many ways to work with WebRTC

Level of effort

Low-level source

Frameworks, Tools, and

SDKsCloud API’s

Amount of control

Website Plug-ins & widgets


Plug-ins for your web admin


WebRTC plug-ins – super simple

Advantages Disadvantages

Only works on your website/CMS

Limited functionality

Limited control

Does not have your branding

Easy for a web-admin to use

Often integrated with your CMS


Consuming WebRTC API’s from the cloud

SignalingAuthentication

Push Notifications

SIP Gateway

Transcoding

STUN

TURN Servers

Low Latency

Elasticity

Recording

Geographic redundancy

Bandwidth

Service monitoring


WebRTC Cloud-API’s – easy but inflexible


Usually most expensive

Vendor longevity risk

Vendor dependency

Feature evolution risk – may not always have what you need

Platform lock-in on advanced features

Designing to control costs

Rapid setup

Often very easy prototyping

Good platforms have most of you need

Often easy to swap with other Cloud-API vendors for basic calling


Building WebRTC from scratch – 2 options

Official Build by Google Ericsson Lab’s OpenWebRTC


Building from scratch is not for the faint of heart


Steep learning curve

Big on-going commitment to maintain

Standards not done & codebase continually in flux

Project was not designed for your application

Abiding by license terms

Full control

Many application-specific optimization opportunities

Native mobile support

Ability to incorporate select components

Active community support


Happy medium - develop with tools

Open Source

Commercial

Server-side libraries

JavaScript libraries

Mobile SDK’s

Cross-platform frameworks

Infrastructure elements


Building with tools – many, many options


Figuring out which option is best

Interworking various toolsets

Inconsistent feature evolution

Potential platform lock-in

Many options to choose from

Ability to choose best-of-breed components

Optimized selections based on application needs & team skills


http://upliketoast.blogspot.com/2011/01/search-results-vintage-women-boxing.html


Web vs. native – not an easy debate

Web arguments

Less expensive to develop

Most users per development hour

WebRTC inside web views will happen soon (on Android at least)

You need a website anyway

Native arguments

iOS support

iOS support

Better push notifications for improved battery life

Better camera controls

You need a native mobile app anyway

http://upliketoast.blogspot.com/2011/01/search-results-vintage-women-boxing.html


Hybrid apps for WebRTC


Front-end considerations


Design for telephony people


getUserMedia browser permissions


Remind your users to share their media


Use HTTPS to cache permissions in Chrome


Use a polyfill to adjust for browser differences

Almost all cloud API vendors include some polyfill

Use the official Chrome/webrtc adapter.js

Will get worse, but community will adapt

navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia || navigator.msGetUserMedia;

Browser differences are a manageable fact of life

https://github.com/GoogleChrome/webrtc/blob/master/samples/web/js/adapter.js


Chrome Extensions for notifications & screen share

Building a Chrome extension is not that difficult: http://webrtchacks.com/chrome-extension/

Use webrtc-experiment’s generic one to start: https://www.webrtc-experiment.com/getScreenId/

http://webrtchacks.com/chrome-extension/

https://www.webrtc-experiment.com/getScreenId/


Mobile considerations - bandwidth & battery

Video resolution

Video framerate

Number of streams

Audio quality

HTML canvas processing

vs.


Telephony people: use responsive web design!


Remember aspect ratiosDon’t overstretch a low resolution image


Mobile rotation matters


Mobile rotation matters

Manage empty space

Manage empty space


Back-end Considerations


Deploying STUN & TURN servers

Almost every WebRTC deployment should have a TURN server

Included with most cloud-API providers

Plenty of quasi-public STUN server available for prototyping

The open source ones are very goodrfc-5766-turn-server

Coturn

Can be integrated with other network infrastructure

Media server + co-resident

STUN/TURN server

https://code.google.com/p/rfc5766-turn-server/

https://code.google.com/p/coturn/


What do you care more about?


Bandwidth is not always ubiquitous or free

Client-side Server-side


CPU & processing power is expensive

Client view Provider View


Server-side media processing use cases

Multi-party conferencing InterworkingTranscoding

Stream processing Person-to-machineRecording


Networking: Points of presence & latency

Inherent VoIP latency: 100-150 ms

÷ 2 for one-way

AWS round-trip latencies

Transcoding latency:0-200 ms


What about Signaling?

Image source: Flickr user Tuomo Tammenpää – http://www.flickr.com/photos/misuser/5846728262/


Web & telephony test tactics


Legend

Web-Centric security model

Web server

IMS Network

SIP

WebMGFirewall

AP

I Man

ager

API Calls

H2S Server

Identity Server

App Server

App Server

WSS server

STUN/ TURN

Internal REST APIs

Existing Web Infrastructure

New WebRTCElements


How does Amazon’s WebRTC network work?

deploying webrtc successfully – a web developer perspective

Technology