Non-Telecom Developers’ Experiences with

WebRTC

Let’s all go back to 2010

ENTERPRISE COMMUNICATION PROBLEM #1: THE DESKTOP PHONE IS A DINOSAUR

Why is it still around? •  Call quality •  Conference calling

•  Incumbency of

vendors •  Transfers/internal

call routing

What will kill the desktop phone? •  Expensive $50 per month?

•  People are increasingly not at their desks. •  Mobile phones are with people all

day and now have the potential to kill the desktop phone with

XYZ’s help.

Most communication (56%) happens when people are

NOT at their desk – source XYZ market research

ENTERPRISE COMMUNICATION PROBLEM #2: USERS ARE PRISONERS OF CHOICE

Desktop Phone call

Mobile Phone

call

SMS

EMS

MMS Desktop

IM

Mobile IM

Mobile Voicemail

Desktop Voicemail

Video Call

Desktop Email

Mobile Email

Fax

Push to Talk

Push to X

MeetMe Conference

Colleague’s Phone

Business or Personal Numbers

Web Conference

VoIP Client

Skype

Yahoo! IM

MSN IM

Calling isn’t working: 70 percent of calls are forwarded to voicemail, less than 16% leave

a message and less than 5% are returned

Unified Communications has made the problem worse: Human latency is now costing the US economy $1T per year

XYZ solves this problem and improves productivity by 45 mins per day

– source XYZ market research

ENTERPRISE COMMUNICATION PROBLEM #3: GROUP MANAGEMENT

“At the moment it takes time to get groups setup for contacting members of ad-hoc teams, plus typically there is little integration so you get a voicemail group, an email group etc. If you are working across multiple organizations, i.e. integrating people from external companies (such as consultants), it is even worse, often having to create accounts for the minority in the majority used system etc - all in all it is a slow and frustrating process for agile working teams.”   Rob Nurick Global IT Services - GHD Manager - Asia Pacific McKinsey & Company, Sydney

The secret sauce of this start-up. (which never came to pass as it was

painfully too early to market)

Lesson 1: History of WebRTC

camera mic network speaker screen

Vidyo/On2 GIPS GIPS O3D

libjingle

Google Talk/Hangouts

signalling

raw

low-level libraries

high-level library

app

server

Lesson 1: History of WebRTC

camera mic network speaker screen

WebRTC

Your appyour signalling

your server

Lesson 1: History of WebRTC

5 years agoLarge gap

Innovation slow

NowSmall gap

Innovation faster

Lesson 2: WebRTC is Powerful

Takes care ofICE, STUN, TURN, IPv6, DTLS, DTLS-SRTP, RTP, audio codecs, video codecs, RTCP, BWE, AGC, AEC, jitter, error concealment, audio levels, FEC, RTX, SCTP, SDP, and lots more I can't remember right now...

So you don't have to

(as much)

Lesson 2: WebRTC is Powerful

A BHello?

Hello

Magic!

A B

Bootstrap To secure, robust, low-latency, p2p audio, video, and data

Anything and everything

This is the F@$&ing Cool Bit everyone gets

Lesson 4: How to use WebRTC

Your Job:1. Exchange "bootstrap" info2. Choose transport parameters3. Choose media to send/recv, and when4. Debug, debug, debug

(Don't let legacy "signalling" confuse you)

Debugging??? WTF!

Debug, debug, debug

RTC bugs can be really toughhigh expectations, low reproducibility, highly variable conditions, hardware failures, lots and lots of complexity, user misunderstandings .... get blamed for ISP problems :).

Very common bug report "They can't hear me"

Put on your detective hat :)

This is were you loose people

Lesson 5: How to do RTC Well1. Logging!2. Stats3. Learn the stack (so you can debug)4. Handle events (error, state changes)5. Don't forget: TURN, ICE restarts, device selection, mute state,

resolution changes, audio-only mode, bandwidth usage6. Watch stats: connect rate, "call" length, time to connect, time to

first audio, time to first video, estimated bandwidth, sent bandwidth, received bandwidth, sent resolution, recieved resolution

So what you’re saying is I need to understand the guts to be able to debug L

Spain, 49

Sri Lanka, 35

Mexico, 15 USA, 14

Hungary, 5 Slovakia, 2

Netherlands, 5

Belgium, 7

India, 6

Russia, 3

Philippines, 17

Nigeria, 2

Germany, 3 Tunisia, 2 UK, 5

Singapore, 2

Pakistan, 2 Japan, 3 Italy, 2

Brasil, 2

Canada, 2 Malaysia, 5

26

TADHack Survey (June) Country based

We used the TADHack Survey respondents from June to better understand what people other than the choir thought about WebRTC

TADHack Survey (June) What’s their Business?

35

75

16

4

16

18

24

Student

App Developer

Telco

Consulting

Platform Provider

System Integrator

Tech Vendor

Total of 188 Responses

App developers and Students were the top 2 targets for TADHack. We engaged with the Illinois Institute of Technology Real Time Communications Lab as well as the Universidad Rey Juan Carlos ICT Department which bumped up student developer numbers.

28

42.6%

68.1%

44.7% 53.2% 48.9%

55.3% 51.1%

0.0% 10.0% 20.0% 30.0% 40.0% 50.0% 60.0% 70.0% 80.0%

Tele

com

app

serv

ers (

in c

all

serv

ices

)

Tele

com

API

s Co

mm

unic

atio

ns (c

allin

g an

d m

essa

ging

)

Tele

com

API

s Pay

men

ts

Tele

com

API

s Pro

file

(Loc

atio

n, d

evic

e in

fo,

subs

crip

tion

info

)

FOSS

(Fre

e an

d O

pen

Sour

ce S

oftw

are)

Web

RTC

Dev

elop

men

t too

ls

Pre-Event Results: What Tech are of most interest to your projects?

Then we did some unscientific analysis – we asked the people who are NOT interested in WebRTC what they thought about it – because lets face it all telecom application developers should be interested in WebRTC

So we asked them (60) some questions

•  Have you played with WebRTC? o  Yes 50 o  No 10

•  What did you think? – just a few of the quotes… o  Outside of Chrome to Chrome we could not get it to work most of the time, so gave up o  Using WebRTC video on mobile phones seriously eats the battery life, we love it, but for

our application its not viable with WebRTC

o  Isn’t WebRTC still in development? o  Its much more complex than just the browser specification, there are many WebRTC API

providers, other service vendors, and SDK vendors that you have to be an expert to even understand their offer never mind comparing the offers

o  We use WebRTC data channel in two of our experimental applications, its good, it does

requires constant maintenance as browsers get updated, so we’ve not included it in any of our commercial offers yet. Once things get more stabilized we’ll think about it.

Early Explorers Wild West Civil War Progressive Era Modern Era

My view on where we are with WebRTC. We’re entering the wild west after the early explorers have mapped some of the landscape, with the privacy and security

issues better managed, we’ll see the big guys war it out, and with the market deciding we’ll enter a progressive era where the dominant innovations from the

war are consolidated into standards. All ending in the modern era where WebRTC is ubiquitous and no longer really mentioned, its just there.

A view on where we are with WebRTC

Summing Up

•  The Gap is still too big because WebRTC is being pitched too broadly o  The explorers need to guide / focus industry on where it makes sense in

2015 NOT 2020

•  The Vested interests have just got started o  But through economics it can be beaten back

o  Stop preaching to the choir and get focused on building the market

successes that stop the vested interests

•  Else in 2020 we’ll be still talking about the WebRTC Civil War!