3. 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 3
4. 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 4
5. 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 5
6. 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
7. 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 7
8. 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 8
9. The signalling triangle (non-interoperable)
Server
UA Media
UA
10/3/2014 Title Version No: 0.1/ Status: DRAFT 9
10. 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 10
11. 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 11
12. 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 12
13. Acision SDK v1.0 for Android, iOS, and JavaScript
3rd Party
Identity
Provider
Single point-of-access:
sdk.acision.com:44
3
Note: different identity
providers work in different
ways, some may require
specific handling in the app
itself (for example, show a
Facebook login screen)
Application
Servers
Amazon AWS
Contact
Management
Library
Auth/Bootstra
p Library
Messaging
Library
Presence
Library
WebRTC
Library
SMS In/Out through Acision Forge
SuperNode
REST over HTTPS (port 443)
REST over HTTPS (port 443)
HTTP Proxy
and
Load Balancer
REST over HTTPS (port 443)
Secure WebSockets (port 443)
REST over HTTPS (port 443)
Secure WebSockets (port 443)
SIP over Secure WebSockets (port 443)
TURN server
SDK Wrapper
Audio/video calls
SIP trunk(s)
TURN over
TCP/UDP (port
3478) and TLS (port
Acision S5D34K9)
10/3/2014 Title Version No: 0.1/ Status: DRAFT 13
14. AcisionSDK Example: Android
AcisionSdkConfiguration config =
new AcisionSdkConfiguration("MYAPIKEY ", "user", "password");
config.setApplicationActivity(this);
AcisionSdk acisionSdk = new AcisionSdk(config, new AcisionSdkCallbacks() {
@Override
public void onConnected(AcisionSdk acisionSdk) {
session = acisionSdk.getWebrtc().connectTo("+441632960000",
new WebrtcSessionCallbacks() {
@Override
public void onConnected() {
session.setLocalView(localVideoView);
session.setRemoteView(remoteVideoView);
}
}, new WebrtcOptions());
}
});
10/3/2014 Title Version No: 0.1/ Status: DRAFT 14