Presented at the WebRTC Paris Conference from 16-18 December. Sharing the challenges faced by developers in using WebRTC, as well as a survey of developers aware but not developing with WebRTC to understand their experiences. Also reviews a model (analogy to America history) of how WebRTC will develop, as I consider Moore's crossing the chasm inaccuracy for this embedded technology rather than product. We need to focus on helping not hyping developers in 2015.

1. Non-Telecom Developers’
Experiences with
WebRTC

2. Let’s all go back to 2010

3. 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

4. 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

5. 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

6. The secret sauce of this start-up.
(which never came to pass as it was
painfully too early to market)

16. 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

17. Lesson 1: History of WebRTC
camera mic network speaker screen
WebRTC
Your app
your signalling
your
server

18. Lesson 1: History of WebRTC
5 years ago
Large gap
Innovation slow
Now
Small gap
Innovation faster

20. Lesson 2: WebRTC is Powerful
Takes care of
ICE, 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)

21. Lesson 2: WebRTC is Powerful
A B
Hello?
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

22. Lesson 4: How to use WebRTC
Your Job:
1. Exchange "bootstrap" info
2. Choose transport parameters
3. Choose media to send/recv, and when
4. Debug, debug, debug
(Don't let legacy "signalling" confuse you)
Debugging??? WTF!

23. Debug, debug, debug
RTC bugs can be really tough
high 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

24. Lesson 5: How to do RTC Well
1. Logging!
2. Stats
3. 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 usage
6. 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

26. 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

27. 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. 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%
Telecomappservers(incall
services)
TelecomAPIs
Communications(calling
andmessaging)
TelecomAPIsPayments
TelecomAPIsProfile
(Location,deviceinfo,
subscriptioninfo)
FOSS(FreeandOpen
SourceSoftware)
WebRTC
Developmenttools
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

29. 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.

30. 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

36. 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!