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

Agenda
Before you start
Front-end
Back-end
End-to-End
COMPANY CONFIDENTIAL © COPYRIGHT 2014 DIALOGIC INC. ALL RIGHTS RESERVED. 2

Many ways to work with WebRTC
Frameworks,
Tools, and
Level of effort
Low-level
source
SDKs
Cloud 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
Signaling
SIP Gateway
Bandwidth
Authentication
Push Notifications
Elasticity
Transcoding
STUN
TURN Servers
Low Latency
Recording
Geographic
redundancy
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
navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia ||
navigator.mozGetUserMedia || navigator.msGetUserMedia;
Browser differences are a manageable fact of life
Almost all cloud API vendors include some polyfill
Use the official Chrome/webrtc adapter.js
Will get worse, but community will adapt

Chrome Extensions for notifications & screen share
Building a Chrome extension is
not that difficult:
http://webrtchacks.com/chro
me-extension/
Use webrtc-experiment’s
generic one to start:
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 ratios
Don’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 good
rfc-5766-turn-server
Coturn
Can be integrated with other network
infrastructure
Media server +
co-resident
STUN/TURN server

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 Transcoding Interworking
Recording Stream processing Person-to-machine

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

Identity
Server
App
Server
App
Server
Legend
Web-Centric security model
Web
server
IMS
Network
SIP
WebMG
Firewall
API Manager
API Calls
H2S
Server
WSS
server
STUN/
TURN
Internal
REST APIs
Existing Web
Infrastructure
New WebRTC
Elements

How does Amazon’s WebRTC network work?

Deploying WebRTC successfully – A web developer perspective

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Deploying WebRTC successfully – A web developer perspective

Ähnlich wie Deploying WebRTC successfully – A web developer perspective (20)

Mehr von Dialogic Inc.

Mehr von Dialogic Inc. (7)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Deploying WebRTC successfully – A web developer perspective

Hinweis der Redaktion