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

04/13/2023 Title Version No: 0.1/ Status: DRAFT 1

Interoperable WebRTC…

… and why it is important

Email: [email protected]: @pdunkley


Evolution on the Web

1990 1996 1998 2004 2011

Sir Tim Berners-Leecreates HTML. Web-pages are static

Microsoft and Netscapeintroduce differentmechanisms for DHTML

W3C produces theDOM1 specification

Google uses Ajaxin Gmail (W3Creleases 1st draft in2006) – the dawnof web-apps

WebSocket andWebRTCimplementationsbecome available


Revolution in Telecoms

1792 1837 1876 1919 1960s > 1990s > 2011WebSocket andWebRTCimplementationsbecomeavailable

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 was required.Claude Chappe

invented the opticaltelegraph

First commercialelectrical telegraphcreated byCooke andWheatstone

AlexanderGrahamBell patentsthe telephone

Rotary dialentersservice

From the 1960sonwards digitalexchanges start toappear

1963: DTMFenters service

From the 1990s onwardsvoice started to be carriedon technologies developedfor data networks such asATM and IP


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

04/13/2023 6

Real-time communication is hard

Title Version No: 0.1/ Status: DRAFT

• 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

RTCWeb/WebRTC Architecture

G.711/OPUS Codec

NetEQ for Voice

Echo Canceller /Noise Reduction

Voice Engine

H.264/VP8 Codec

Video Jitter Buffer

Image enhancements

Video Engine

SRTP

Multiplexing

P2PSTUN + TURN + ICE

Transport

Audio Capture/Render Video Capture Network I/O

Session management / Abstract signalling (Session)

WebRTC C++ API (PeerConnection)

WebRTC API

Your w

ebapp #1

Your w

ebapp #2

Your w

ebapp #3. . .

The web

Your browser

Based on the diagram from http://www.webrtc.org/reference/architecture

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’tneed 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 interoperateare 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)

UA UA

ServerSig

nallin

g Signalling

Media


The signalling trapezoid (interoperable)

UA UA

ServerSig

nallin

g Signalling

Media

ServerSignalling

The fact that something can interoperate doesnot 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

Browser UAGatewayREST

and RTPSIP and

RTP

Single point of failure(unless complex andexpensive dialogreplication is used)


Without a gateway

UA UA

SIP Proxy

SIP

SIP

RTP

Resilience withoutreplication (transactionstateful proxy as perRFC 3261)


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: [email protected]: @pdunkley

Technology

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