WebRTC Summit (June 2014) - WebRTC Interoperability (and why it is important)

Interoperable WebRTC…
… and why it is important
Email: peter.dunkley@acision.com
Twitter: @pdunkley
10/3/2014 Title Version No: 0.1/ Status: DRAFT 1

Evolution on the Web
Sir Tim Berners-Lee
creates HTML. Web
-pages are static
W3C produces the
DOM1 specification
1990 1996 1998 2004 2011
Microsoft and Netscape
introduce different
mechanisms for DHTML
Google uses Ajax
in Gmail (W3C
releases 1st draft in
2006) – the dawn
of web-apps
WebSocket and
WebRTC
implementations
become available

Revolution in Telecoms
The revolution
Before today the operators (big and small)
had full control over real-time
communications because it was hard to do
and substantial infrastructure investment
Claude Chappe was required.
invented the optical
telegraph
Alexander
Graham
Bell patents
the telephone
From the 1960s
onwards digital
exchanges start to
appear
From the 1990s onwards
voice started to be carried
on technologies developed
for data networks such as
ATM and IP
1792 1837 1876 1919 1960s > 1990s > 2011
WebSocket and
WebRTC
implementations
become
available
Rotary dial
enters
service
First commercial
electrical telegraph
created by
Cooke and
Wheatstone
1963: DTMF
enters service

Four kinds of interoperability on two levels
• Level one (generic)
– Interoperable media
• Different devices can understand each other’s media streams
• This is what the IETF RTCWeb working group is doing
– Interoperable platforms
• Applications written for one platform (for example, a browser) can run on another
platform (for example, another browser)
• This is what the W3C Web Real-Time Communications working group is doing
• Level two (use case specific)
– Interoperable applications
• For example, a native mobile shopping application that can communicate with a
web-based CRM platform
– Interoperable services
• For example, a web-based CRM platform that can receive calls from the PSTN

RTCWeb
There are a number of proprietary implementations that
provide direct interactive rich communication using audio,
video, collaboration, games, etc. between two peers' web-browsers.
These are not interoperable, as they require
non-standard extensions or plugins to work. There is a
desire to standardize the basis for such communication so
that interoperable communication can be established
between any compatible browsers.
Real-Time Communication in WEB-Browsers
(rtcweb) 2013-03-13 charter

Real-time communication is hard
10/3/2014
Title Version No: 0.1/ Status: DRAFT
6
• VoIP has always suffered from a lack of standard profile
– What QoS/feedback mechanisms should be supported
– What codecs should be supported
– What security mechanisms should be supported
• This means that VoIP end-point vendors can all follow the
specifications to the letter and still produce devices that do not
interoperate
• This makes the job of developing a VoIP end-point far harder than it
should be
• This makes large scale consumer use of VoIP difficult
– You can’t just add real-time communications to your service - you have
to really, really, need it for it to be worth doing
RTCWeb provides this standard profile

WebRTC
The mission of the Web Real-Time Communications
Working Group, part of the Ubiquitous Web Applications
Activity, is to define client-side APIs to enable Real-Time
Communications in Web browsers.
These APIs should enable building applications that can be
run inside a browser, requiring no extra downloads or
plugins, that allow communication between parties using
audio, video and supplementary real-time communication,
without having to use intervening servers (unless needed for
firewall traversal, or for providing intermediary services).
Web Real-Time Communications
Working Group Charter

RTCWeb/WebRTC Architecture
Your web
app #1
RTCWeb
Voice Engine
. . .
WebRTC API
Your web
app #2
WebRTC C++ API (PeerConnection)
Session management / Abstract signalling (Session)
G.711/OPUS Codec
NetEQ for Voice
Echo Canceller /
Noise Reduction
Video Engine
H.264/VP8 Codec
Video Jitter Buffer
Image enhancements
Transport
Your web
app #3
SRTP
Multiplexing
P2P
STUN + TURN + ICE
Audio Capture/Render Video Capture Network I/O
The web
Your browser
Based on the diagram from http://www.webrtc.org/reference/architecture

Interoperable media and platforms are not enough
• To establish a media session you need to:
1. Locate the other end-point – it is probably on another network behind a
NAT device
2. Negotiate the media connection
• This means you need some form of signalling
– Even the simplest, proprietary, exchange between end-points is a form
of signalling
– Standardised signalling is required for interoperable applications and
services
Not all applications and services need to interoperate

Many applications don’t need interoperability
• Online dating – you’d only expect to interact with people on the
same site
• Online gambling – you’d only expect to interact with people on the
same site
• Online gaming – you’d only expect to interact with people in the
same game
• Collaboration within Google Docs or Office 365
Most interactive, browser-only, applications don’t
need to interoperate

Many applications do need interoperability
• Conferencing – do you really want to exclude the guy travelling who
can’t get (or afford) a mobile data connection?
• Online education – why shouldn’t I be able to listen to lectures
through other routes?
• Telemedicine – a huge boon for people living in remote areas (aren’t
those the ones who struggle to get online?)
• Call centres – can I afford to exclude customers who can’t (or don’t
want to) use WebRTC?
Many of the applications that need to interoperate
are high-value

Interoperability example: Call Centres
• WebRTC can make call centres run more efficiently
– No need for separate computers and hard-phones
– No need for complex soft-phone and web-UI integration
– Give everyone an inexpensive computer that boots into the browser and
have a fully integrated web-app
• WebRTC can make calling a call centre less unpleasant
– Web-form or mobile app instead of IVR
– Context based calling
• No need to re-identify yourself
• No need to explain why you are calling
– Callers can be entertained while in the queue
• Let them play games and watch YouTube videos
• Recommend games and videos based on information from social networks

The signalling triangle (non-interoperable)
Server
UA Media
UA

The signalling trapezoid (interoperable)
Server
Signalling Server
UA Media
UA
The fact that something can interoperate does
not mean it must, or will, interoperate

Interoperability could be bad for business
• Good for consumers doesn’t always mean good
for business
– Why would, for example, Microsoft want Office 365
users to easily collaborate with Google Docs users?
• In other situations…
It’s the API, stupid…

Picking the right API is the most important thing
Personally, I’ve come around (the hard way) to a fairly pragmatic stance
on this point, and I hesitate from declaring “it has to be” one approach
for signaling protocol, or another. Let me explain: Initially, I must admit I
used to obsess about what protocol the library was doing under the
hood. In fact, full disclosure: when I first started looking into JavaScript
WebRTC signaling, I thought SIP over WebSockets was a bad idea…
However, after I did a few projects… I started to have a change of heart.
I found that in using the library, I was able to accomplish the goals of my
projects, and the JavaScript interface to the library could be just as
simple and powerful as all the others. I couldn’t find the fatal flaw I was
expecting, and it just worked. In all this I started to care less and less
about what was happening on the wire between the library and the
service, and more about what features of the service I could access
through the API.
… Most importantly, the best one for you is flexible enough to meet your
security, architecture, and functional requirements (no matter what
protocol it uses).
webrtcH4cKS: What’s in a WebRTC JavaScript Library,
Reid Stidolph

There are many interoperable signalling options
• SIP
– Widely used today
– If you have to connect to legacy networks and
equipment this is probably what you need
• XMPP jingle over WebSockets
– It’s a standard but it isn’t as widely used as SIP
• OpenPeer
– This is great for interoperable WebRTC, but has little
to no support in existing devices.

Using SIP with WebRTC
• You have two choices
– Use SIP end-to-end (SIP over WebSockets)
– Use a REST (or another protocol) to SIP gateway
• It is better if you do not need gateways
– Gateways are expensive
• You typically have to deploy more equipment
• Resilience and scaling is harder

With a gateway
REST
and RTP
SIP and
RTP
Browser Gateway UA
Single point of failure
(unless complex and
expensive dialog
replication is used)

Without a gateway
SIP Proxy
Resilience without
replication (transaction
stateful proxy as per
RFC 3261)
UA RTP
UA

SIP gives you the widest choice today
• There are many open-source server implementations of
SIP over WebSockets
– Asterisk, FreeSwitch, Kamailio, OverSIP, reSIProcate
• There are many open-source client (JavaScript)
implementations of SIP over WebSockets
– JAIN-SIP-Javascript, JsSIP, QoffessSIP, sipml5
• There are SDK and network vendors who are packaging
this stuff to make it easy for you to use
It’s the API, stupid

Interoperable WebRTC Demos…

Questions?
Email: peter.dunkley@acision.com
Twitter: @pdunkley

WebRTC Summit (June 2014) - WebRTC Interoperability (and why it is important)

More Related Content

What's hot (20)

Similar to WebRTC Summit (June 2014) - WebRTC Interoperability (and why it is important) (20)

More from Crocodile WebRTC SDK and Cloud Signalling Network (8)

Recently uploaded (20)

WebRTC Summit (June 2014) - WebRTC Interoperability (and why it is important)