A presentation by Peter Dunkley (Technical Director, Acision). Presentation date 09-Jul-2014.

1. DevCon5 (July 2014): Intro to WebRTC
Peter Dunkley, Technical Director, Acision
Email: peter.dunkley@acision.com
Twitter: @pdunkley
10/3/2014 Title Version No: 0.1/ Status: DRAFT 1

2. 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
10/3/2014 Title Version No: 0.1/ Status: DRAFT 2

3. 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
10/3/2014 Title Version No: 0.1/ Status: DRAFT 3

4. 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
10/3/2014 Title Version No: 0.1/ Status: DRAFT 4

5. Real-time communication is hard
10/3/2014
Title Version No: 0.1/ Status: DRAFT
5
• 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

6. 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
10/3/2014 Title Version No: 0.1/ Status: DRAFT 6

7. 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
10/3/2014 Title Version No: 0.1/ Status: DRAFT 7

8. The signalling triangle (non-interoperable)
Server
UA Media
UA
10/3/2014 Title Version No: 0.1/ Status: DRAFT 8

9. The signalling trapezoid (interoperable)
Server
Signalling Server
UA Media
UA
The fact that something can interoperate does
not mean it must, or will, interoperate
10/3/2014 Title Version No: 0.1/ Status: DRAFT 9

10. 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…
10/3/2014 Title Version No: 0.1/ Status: DRAFT 10

11. 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
10/3/2014 Title Version No: 0.1/ Status: DRAFT 11

12. Thank you
Email: peter.dunkley@acision.com
Twitter: @pdunkley
10/3/2014 Title Version No: 0.1/ Status: DRAFT 12