DevCon5 (July 2014) - Intro to WebRTC
Download as pptx, pdf0 likes464 views
WebRTC provides a standardized profile for real-time communication that enables interoperability between browsers without plugins. It defines client-side APIs for audio and video calling as well as other real-time communication capabilities. The WebRTC architecture includes the API, codecs, transport mechanisms like STUN and TURN, and network I/O that allow real-time apps to run directly in browsers. Signaling is required to establish connections between users, and the standardization of WebRTC aims to improve interoperability compared to proprietary solutions. However, interoperability is not always in the best interests of businesses. Ultimately, the API is more important than the underlying protocols it uses.
DevCon5 (July 2014) - Intro to WebRTC
- 1. DevCon5 (July 2014): Intro to WebRTC Peter Dunkley, Technical Director, Acision Email: [email protected] Twitter: @pdunkley 10/3/2014 Title Version No: 0.1/ Status: DRAFT 1
- 2. 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 2
- 3. 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 3
- 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 10/3/2014 Title Version No: 0.1/ Status: DRAFT 4
- 5. Real-time communication is hard 10/3/2014 Title Version No: 0.1/ Status: DRAFT 5 • 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
- 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 10/3/2014 Title Version No: 0.1/ Status: DRAFT 6
- 7. 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 7
- 8. The signalling triangle (non-interoperable) Server UA Media UA 10/3/2014 Title Version No: 0.1/ Status: DRAFT 8
- 9. 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 9
- 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… 10/3/2014 Title Version No: 0.1/ Status: DRAFT 10
- 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 10/3/2014 Title Version No: 0.1/ Status: DRAFT 11
- 12. Thank you Email: [email protected] Twitter: @pdunkley 10/3/2014 Title Version No: 0.1/ Status: DRAFT 12