04/13/2023 Title Version No: 0.1/ Status: DRAFT 1
Interoperable WebRTC…
… and why it is important
Email: [email protected]: @pdunkley
04/13/2023 Title Version No: 0.1/ Status: DRAFT 2
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 3
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 4
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 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
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 8
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 9
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 10
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 11
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 12
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 13
The signalling triangle (non-interoperable)
UA UA
ServerSig
nallin
g Signalling
Media
04/13/2023 Title Version No: 0.1/ Status: DRAFT 14
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 15
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…
04/13/2023 Title Version No: 0.1/ Status: DRAFT 16
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 17
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.
04/13/2023 Title Version No: 0.1/ Status: DRAFT 18
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 19
With a gateway
Browser UAGatewayREST
and RTPSIP and
RTP
Single point of failure(unless complex andexpensive dialogreplication is used)
04/13/2023 Title Version No: 0.1/ Status: DRAFT 20
Without a gateway
UA UA
SIP Proxy
SIP
SIP
RTP
Resilience withoutreplication (transactionstateful proxy as perRFC 3261)
04/13/2023 Title Version No: 0.1/ Status: DRAFT 21
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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 22
Interoperable WebRTC Demos…