WebRTC

Two emerging approaches

* peer-to-peer... "with a little help from my servers"

HTTP

STUN

Web Application Server

This is where browsers retrieve the application logic and user interface

JavaScript

HTML, css, images...

Minimum load:

• Few one-shot transactions in a client lifetime
• 1 box for ~10^5 clients

TURN

The protocol of IP communication services

SIP

over

WebSocket

Internet Co's

• VoIP telephony
• Video Conferencing / Telepresence

+ easy to make existing communication services accessible from browsers

Natively interpreted by browsers

The language of the web

Adding support for WebSocket transport to SIP

(already available for UDP, TCP, SCTP)

JSON

over

WebSocket (+ BOSH + COMET)

Vendors love this!

- no WebSocket, no party

Fall-back, if something goes wrong

- slow, often

Network info for establishing peer-to-peer media connections

No Trickle ICE!

- poor flexibility

• no custom signalling
• imposes SIP identity scheme

+ WebRTC- and application-specific signaling on the same channel

Telco equipment vendors

+ enables fast connection setup

Trickle ICE!

+ does not impose any identity scheme on the application

+ easy reliability in "broken-network" scenarios

Using popular hack-wrapping libraries (e.g. socket.io)

Web Signaling Server

Detail #1:

Detail #2:

Signaling needs to be bi-directional and MUST happen over HTTP(S)

• but HTTP is inherently mono-directional!

Two options:

• Well-established BOSH/COMET "hacks"
• Immature* WebSocket standard

Signaling is fully delegated to the application

The application logic (i.e. the JavaScript code) implements the signaling protocol

• According to its very specific needs

* Deployed in browsers, but not in proxies**

It's a feature!

** Incl. transparent proxies, common in mobile networks

details

(signaling)

The

in

devil's

Clients stay connected here to send and receive event notifications

E.g.:

• "place a call to..."
• "user hit button X"

E.g.:

• "someone is calling"
• "change UI layout"
• "display a notification"

Interactive Connectivity Establishment

Medium load:

• A live connection for each active client
• 1 box for ~10^4 clients

(OPTIONAL)

Web Signaling Gateway

Translates the web app signaling into other communication services lingo

SIP, possibly XMPP

• VoIP telephony
• Video Conferencing / Telepresence

Easy job if web apps speak SIP over WebSocket

Medium load:

• A live connection for each active session
• 1 box for ~10^4 sessions

ICE servers for NAT and Firewall traversal

(OPTIONAL)

Web Media Gateway

Translate WebRTC media toward other communication services

Simple, plain RTP

ICE + SRTP

And possibly transcoding

This is complicated!

This is VERY complicated!

High load:

• (En+de)cryption and (poss.) transcoding for each active session
• 1 box for ~10-10^3 sessions

Web server(s) implementing the application logic

blah

"WebRTC" as in

"Peer-to-peer* realtime communications

between web browsers**"

blah

"Web" as in ... errr ... "The Web"

"RTC" as in

"Realtime Communications"

Enabled by default in Chrome and Firefox since June 2013

blah

"Web" as in "App"

blah

a ah b lah

blxh bxxh

blah blah

... because the Internet is a mess!

but also...

Software libraries for building WebRTC-compatible apps on major mobile platforms

blah

"Web" as in "Embedded"

blah

"Web" as in

"The sky's the limit"

blah

** and mobile apps, embedded devices...