devcon5 (july 2014) - intro to webrtc
DESCRIPTION
A presentation by Peter Dunkley (Technical Director, Acision). Presentation date 09-Jul-2014.TRANSCRIPT
04/13/2023 Title Version No: 0.1/ Status: DRAFT 1
DevCon5 (July 2014): Intro to WebRTCPeter Dunkley, Technical Director, Acision
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
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 5
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 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
04/13/2023 Title Version No: 0.1/ Status: DRAFT 7
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 8
The signalling triangle (non-interoperable)
UA UA
ServerSig
nallin
g Signalling
Media
04/13/2023 Title Version No: 0.1/ Status: DRAFT 9
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 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…
04/13/2023 Title Version No: 0.1/ Status: DRAFT 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
