Status of WebRTC across Asia by Alan Quayle +++

Let’s go back in time, to April 22nd 2013

WebRTC Workshop
The HTML5 Real-Time Web
April 22nd 2013
Pre-conference Workshop for the IMS World Forum
Alan Quayle
alan@alanquayle.com
www.alanquayle.com/blog
Jose de Castro
jdecastro@voxeolabs.com
www.voxeolabs.com
5/7/20 © 2013 Alan Quayle Business and Service Development 2

Objectives
• Bring together deep technical and deep business thought leadership on
WebRTC with Jose de Castro, Alan Quayle, and many of the audience to
providing attendees with a unique independent workshop.
• Provide a deep-dive quantified analysis of the WebRTC status, enabling
attendees to understand what is likely to emerge over the next 18
months to 2 years, in this complex rapidly emerging ecosystem and
what it will mean to their business.
• Provide attendees with a series of WebRTC demonstrations, to share
their experiences on implementing WebRTC, and provide ample
networking opportunities at the end of the workshop to discuss and
consolidate what has been learned through the day.
5/7/20 © 2013 Alan Quayle Business and Service Development 3

Structure (1 of 6)
• Registration
• 09:30 - Introduction to WebRTC and Initial Market Review
o What is it and what it is not,
o Cutting through the mis-information and hype
o Non-technical introduction
o Web browser implementation status
o Taxonomy of suppliers / service providers
o Codecs and devices - is certification necessary?
o What is Google's aim?
• 10:30 Standardization deep dive
o Standardization process
o Current status
o Battles and likely outcomes
o IETF and RTCWEB documents

Structure (2 of 6)
• 11:30Technology deep dive
o Peer connect API
o Setting up local media and media flow
o Protocols
o WebRTC triangle / trapezoid
o SIP, Jingle and the PSTN.
• 13:00-14:00 Lunch
• 14:00 What WebRTC means to Service Providers and IMS:
o Extending enhanced communications services to web browsers
o Impact on OTT (Over The Top) and existing voice, messaging, video and VAS
o Impact of device compliance
o Customer experiences and behaviors
o Revenue, churn and relevance impacts
• 14:30 What WebRTC means to enterprises:
o Impact on Unified Communication and the Contact Center
o Impact on company's website
o Security and operational issues
o Potential cost savings and innovations

Structure (3 of 6) DEMO TIME 15:00-17:00+
• Demo Time will be divided into 2 sessions, its aim is to be informal
and provide ample networking opportunities for attendees to
consolidate their learning from the workshop:
• Demo presentation to the group: each demo will be 5 minutes long,
and 5 minutes for questions; and
• Demo one-on-one: attendees can chat one-on-one with the demo
presenters, notionally 30 minutes but can run on into discussions at
the bar through the evening.

Structure (4 of 6) DEMO TIME 15:00-17:00
• Zingaya ('Call' button for websites)
o Embed a 'Call' button into the website. Visitors can click that button and the call is
forwarded to the website operator's preferred land-line or mobile phone. All that is
required is a website; all the visitors need is a browser and microphone.
• Voxeo Labs (Ameche (new IMS/Web services), Tropo (leading call control API),
Phono (Web comms innovation)). They will demo Phono’s three types of
identity:
o Anonymous Identity: user lands on web site and is able to call directly into the contact
center
o Web Identity: use your web identity (twitter, foursquare, etc) to call each other.
o Telco Identity: Phono sessions can attach to the telco network and assume the real
identity (phone number) of the subscriber, allowing calls to be routed to both the mobile
and the browser simultaneously.
• Telestax
o Provides a complete stack from the client-side with Javascript JAIN SIP JS and WebRTC
as well as the server side with our SIP Over WebSockets. The demo will be a WebRTC
video conferencing and IM.

• Solaiemes WebRTC to Rich Communication Suite demo
o Demonstration of RCS messaging and WebRTC to access to media
components of devices to revamp the value of PSTN (and also mobile) lines.
Shows how Unified Communications could be built just a mash-up of
standards and APIs.
• Quobis
o Their approach to WebRTC is based on QoffeeSIP, a complete open source
Javascript SIP stack that can be used in a website to exploit all the multimedia
capabilities of WebRTC technology. Thanks to QoffeeSIP they have developed
a corporate WebRTC webphone that can interop with different network
devices; this webphone is going to be released at IMS World Forum event.
• Huawei leading NEP
o WebRTC / RCS insurance application demo

• Drum by NetDev (conference calls and online meetings)
o Allows providers of fixed, mobile and next generation VoIP services to deliver audio
conferencing as a direct, branded service. Hosted within your IP network on your
servers, Drum audio conferencing is a standalone software solution with an integrated
media server.
• Bistri (Social Video)
o Video chat with fun video effects, take screenshots of calls, share them with friends or
social networks. Bistri runs in the browser, so there's no need to install additional
software or plugins.
• apidaze.io
o Is a cloud communications API for developers with tools for building web or mobile
communication services, with a special focus on WebRTC. The demo will show how a
web developer can easily use the regular WebRTC API to place calls to external numbers
and audio conference rooms accessible from the PSTN too, using a simple raw
WebSocket connection that carries JSON text.

Introduction to WebRTC and
Initial Market Review

What The Geeks Say
Open, Nothing Proprietary
No Plugs-Ins
Multi Platform / Device

Real-time stuff for your
browser with no plug-ins

Embedding Communications
Everywhere!

Warning we’re
about to do
quite a bit of
time travel

Travelling thru’
time to 2020

Jumping to 2020 for a slide
Massively oversimplifies the political landscape, as most vendors are in both
standards bodies, but it shows the general bias.
Browser
vendors
dominate
Consensus oriented so
browser vendors can not
dominate

Travelling thru’
time to 2013

Codec Wars
Opus,
VP8
G.711,
AMR-
WB,
EVS,
H.264

Codec Wars
VP9AV1

Browser GetUserMedia PeerConnection DataChannel
Chrome Yes Yes Q2 ‘13
Chrome for mobile Yes (March ‘13) Yes (March ‘13) Q2 ‘13
Firefox (desktop) Yes Yes Yes (first one)
Firefox (mobile) Yes Yes Yes (first one)
Opera Yes H2 ‘13 2014
Opera Mini H2 ‘13 2014 2014
IE (desktop) Chrome Frame /
2014
Chrome Frame /
2014
Chrome Frame /
2014
IE (mobile) 2014/2015 2014/2015 2014/2015
Safari (desktop) 2014/2015 2014/2015 2014/2015
Safari (mobile) 2014/2015 2014/2015 2014/2015
WebRTC is NOT Everywhere

https://wpt.fyi/interop/webrtc?label=master&lab
el=stable&aligned

Lies, Damned Lies, and Statistics

Jumping back to 2020 for a slide

Mobile is Even More Complex
Native browser Natively in OS 2nd browser 3rd party SDK

80% 20%

Are you feeling travel sick yet?

In The Limit Which Browser Gives you the Best
Experience?

WebRTC is a car without wheels!

WebRTC Triangle
• Both browsers running the same web application from web server
• Peer Connection media session is established between them
• Signaling is not standardized, could be SIP, Jingle, MQTT,
proprietary. Uses HTTP or WebSockets for transport
Web Server
(Application)
Browser M
(Running HTML5 Application
from Web Server)
Browser L
(Running HTML5 Application
from Web Server)
Peer Connection (Audio, Video, and/or Data)
47Intro to WebRTC February 2013
The wheels!

We’re back in the 2020 from now on

But, but, but…….
• Back in 2013 it seemed pretty baked, you showed all those cool
demos running and working in multiple browsers
• And in November 2017, the WebRTC 1.0 specification transitioned
from Working Draft to Candidate Recommendation. Why hasn't it
moved onto a Proposed Recommendation (PR) and final
endorsement and a W3C Recommendation (REC)?

WebRTC is Trapped in Interoperability Pareto Jail:
5% of the features are taking 95% of the time to
complete interoperability testing

WebRTC is Trapped in Interoperability Pareto Jail
• WebRTC set the success criteria – it MUST BE INTEROPERABLE
https://www.w3.org/2018/07/webrtc-charter.html
o To advance to PR, each spec is expected to have two independent implementations of each feature
defined in the specification.
o To advance to PR, interoperability between the independent implementations (that is, bidirectional
audio and video communication as well as data transfer between the implementations) should be
demonstrated.
• WebRTC 1.0 only “matters” to to a niche of governments or bodies that need standards for
purchasing
• But key features are still far from being interoperable. Server side needs to work hard at
interoperability while browsers change (“enhance”) implementations all the time.
• We’re still playing whack-a-mole on interop: SFU developers (Selective Forwarding Unit
(WebRTC Uber geeks)) are always chasing after the latest browser or libwebrtc version,
sometimes finding the changes only because something stops working.

When will WebRTC 1.0 be released from Pareto Jail?
Maybe H2 2021, maybe…. Definitely 2022!

• Why are WebRTC companies like Vidyo being sold at valuations
below revenue? The recent CallStats.io acquisition is considered to
contribute negligible revenue to 8X8.

Endurance Hunting: WebRTC by itself is difficult to
make money, but its critical to the Future of
Communications. You have to be in it to win it.

• Why is WebRTC so complex?
o Just look at https://www.w3.org/2011/04/webrtc/

Real Time Communications in the real world is complex
AND Time has moved on, almost a decade
• Original idea was to take pieces that were working in other services and reuse: SDP,
DTLS, RTP, ICE, … This led to a very complex protocol layer and architecture.
• Some of those existing pieces were quite immature and are being battle tested
only with WebRTC. Others were simply a bad idea (SDP).
• WebRTC required other standard bodies to develop specific pieces for it, such as
how to use RTP for simulcast, etc.
o It has taken a very long time and opens another field for political infighting, the companies
that could not influence W3C had a field day at IETF.
• Specs were not closed fast enough, so it took too many features that make
components like SFUs brittle, hard to debug and test; and browsers even worse.
• And it’s getting more complex:
o RIPT, QUIC, AV1 codec,
o End to end encryption: will Apple and Google for example agree on a common API so a
platform can set that up for Chrome, Safari and a native iOS app? Not a WebRTC issue per se,
but it will need to be resolved to deliver on the vision.

Yep, WebRTC is going to get even more complex

There are some great open source projects to help
abstract some of that complexity

WOW! So what should I do?
1. Develop your own WebRTC-like system;
2. Build on your own using open source pieces and developing your
own orchestration and management;
3. System integrators using open source and proprietary extensions
and management platforms;
4. CPaaS with no professional services;
5. CPaaS partner;
6. Use one of the few vertically integrated specialized solutions
fitting your use case.

1. Develop your own WebRTC-like system
• Example Zoom
o Speculation: WebAssembly for their current web implementation, likely native application uses C/C++
optimized code.
o Speculation: not only has customized encoder optimizing for specific screen sharing and camera
resolutions. BUT MOST IMPORTANTLY: very tight feedback loop so encoder closely follows network
changing conditions.
o I know there are many Zoom-haters, I remain impressed how their video just works given my experience of
many other services.
• Pros
o Control
o Differentiated experience, e.g. video call continues to work, when other services would have stalled.
Recorded sessions look surprisingly good.
o Deliver built for purpose experiences
o Avoids libwebrtc dependence - libwebrtc is the de facto standard implementation for WebRTC compliant
clients, its behind Chrome, Firefox, Safari, Edge, etc.
• Cons
o Requires rare expertise – a few hundreds of people in the world can do this
o May not be able to take advantage of device hardware acceleration (web implementation only)
o Significant maintenance burned
o Needs strong company culture: product discipline, fighting feature creep, and execution focus

1. Seeing more more projects to avoid the libwebrtc
dependency
• There are a few independent implementations, personal projects,
in languages like Python, Go. Can be used for custom applications,
IoT, etc.
o https://github.com/pion/webrtc
o https://github.com/aiortc/aiortc
o Tim Panton’s |pipe| stack now shares no code with libwebrtc, since they
moved to a pure java opus implementation
• https://twitter.com/steely_glint/status/1247442124385202177
• We are witnessing some breaking the dependency from libwebrtc
o Especially for projects using data channels, and those not needing a
browser.
o Definitely potential for embedding inside applications on focused use
cases.

2. Build on your own using open source pieces and
developing your own orchestration and management
• Example: Building your own conference system using Janus or Jitsi server. Simwood have just launched
their conferencing app with some customizations.
• Pros
o Jitsi and Janus are excellent open source projects, with smart teams
o Jitsi – video conferencing with end to end encryption, funded by 8X8
o Janus – general purpose WebRTC Server developed by Meetecho (in Napoli)
o Leverage expertise of Jitsu and Janus teams
o Lots of other open source projects including for recording, whiteboarding, integration with PBX/PSTN, etc
o If successful, it can make your organization target for M&A as reservoir for rare skills
• Cons
o Have to build own redundancy and scaling – which if the service is used internationally gets complex fast. High
availability for real time communication services (very small hiring universe) is very different of high availability for
web apps (larger expertise pool to hire from)
o Relationship with the Janus and Jitsi teams is critical. Jitsi is funded by 8X8, so may need to have the capacity to fork
the project.
o Product culture and specific expertise on real time end-to-end communications, product, and UI/UX
o Still dependent on WebRTC in the browser needs to be tracking Chrome and libwebrtc main bugs, features
continuously – rare skills
o Dependency on open source projects for tracking and fixing. They detect most of the high-risk issues, but their
bandwidth is limited. What do you do if a high impact bug requires a Jitsi or Janus change but they take longer to fix
than your service can afford?

3. System integrators using open source and
proprietary extensions and management platforms
• Example: Quobis (remember them from 2013?)
• Pros
o Integrator tracks and manages open source projects, libwebrtc and
browser
o WebRTC and related complexity hidden (somewhat) behind a SDK
o Integrator ready made components used as building blocks, tested
and supported. Faster time to deployment and reduced risk.
• Cons
o Scaling concern reduced, partially relying on integrator, but still
need a DevOps team and high availability expertise
o Product culture and specific expertise on real time end-to-end
communications, product, and UI/UX
o Dependency on integrator, it could be a strategic or business
concern. Likely M&A of rare skills providers (acquihire / endurance
hunting)
o Limited by custom components feature set and roadmap

4. CPaaS with no professional services
• Example: Uber with multiple CPaaS providers
• Pros
o CPaaS responsible for working around bugs and keeping compatibility between browsers and
libwebrtc versions
o CPaaS provide additional services: recording, integration with other services, etc
o CPaaS provide certifications (HiPAA), critical for some verticals
o Rely on the CPaaS provider to implement redundancy and scaling
o Use a couple of CPaaS providers given abstraction, dual-source to reduce risk from CPaaS
acquisition, like Uber
• Cons
o Cost of CPaaS
o Dependency on CPaaS team and likely M&A of CPaaS providers (also on the roadmap and delay on
implementing features)
o Prioritizing your issues/wishes vs rest of customers in a large CPaaS can be difficult

5. CPaaS partner
• Example: Customers of Twilio, Nexmo (Vonage), VoIP Innovations (Apidaze), Simwood, etc.
• Pros
o CPaaS responsible for working around bugs and keeping compatibility between browsers and libwebrtc versions
o CPaaS provide additional services: recording, integration with other services, etc
o CPaaS provide certifications (HiPAA), critical for some verticals
o Rely on the CPaaS provider to implement redundancy and scaling
o Use a couple of CPaaS providers given abstraction, dual-source to reduce risk from CPaaS acquisition, like Uber
o Partner can help with specific expertise on real time end-to-end communications, product, regulation, and UI/UX
• Cons
o Cost of CPaaS
o Dependency on CPaaS team and likely M&A of CPaaS providers (also on the roadmap and delay on implementing
features)
o Prioritizing your issues/wishes vs rest of customers in a large CPaaS can be difficult
o Very strong dependency on partner, if the service is critical for the company, the partner would become one of the
strategic partners
o Likely M&A of rare skills providers (acquihire / endurance hunting)
o They can do a ‘Twilio’ on you and become a global competitor, ask Talkdesk

6. Use one of the few vertically integrated specialized
solutions fitting your use case.
• Example: Zoom SDK, GoToMeeting API, etc
• Pros
o Ready-to-use service
o Focus on customer experience
o Removes need to rare skills
• Cons
o Vertical services are, by far, not as flexible as the other options. Very limited
customization and differentiation within the RTC service.
o Business proposition must be strong enough to differentiate from the
vertical service itself (otherwise would be customers will directly use Zoom,
or GoToMeeting)
o Expensive based on cost per session or per minute. However, removes all
the costs and risks associated to the previous options

Is WebRTC the right choice for my RTC project?

Any Questions?
• Go to the TADSummit weblog on this presentation for a public
discussion: http://blog.tadsummit.com/2020/05/20/status-of-
webrtc-across-asia/
• Contact me directly alan@alanquayle.com

Status of WebRTC across Asia by Alan Quayle +++

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Status of WebRTC across Asia by Alan Quayle +++

Semelhante a Status of WebRTC across Asia by Alan Quayle +++ (20)

Mais de Alan Quayle

Mais de Alan Quayle (20)

Último

Último (20)

Status of WebRTC across Asia by Alan Quayle +++