WebRTC, standing for Web Real-time Communication, will gain some well-deserved attention in the months to come for a number of reasons: It may turn out to be disruptive, to drive some fights in the industry, to fuel innovation and to delight software developers and consumers alike. Less well known is RTCWEB, its sort of companion, the engine that works in the background for real-time peer-to-peer communication between browsers.
Web technology and browsers have improved dramatically over the past years. More and richer features have received direct support in Web browsers (e.g. graphics). With WebRTC, browsers can do things that before would have required a plugin or a dedicated client to be downloaded and installed by a user (e.g. as with Skype). WebRTC makes browsers support phone calls, video calls, conferencing, sharing of nearly everything (audio, files, screens), gaming and of course all sorts of messaging. All this without the need to handle pop-up blockers, to install plugins or 3rd party software. WebRTC is the German Autobahn for real-time communication straight out of the browser: fast and smooth.
Main elements of this technology are being standardised by two organisations: The World Wide Web Consortium W3C and the Internet Engineering Task Force IETF. W3C defines what web developers will need to know (WebRTC). IETF defines what browser implementers and infrastructure vendors will need to know (RTCWEB).
What are the claimed benefits?
- Free, standardised communications technology built directly into web browsers.
- No need for download of plugins, no issues with their update, smoother user experience.
- Web developers can deploy real-time-related services more easily and more universally across devices around the Globe.
What about the industry support?
First, there is the support which is needed directly in web browsers. Several browser implementers have shown early implementations of WebRTC, including Google, Mozilla and Opera. As usual, the browser companies still put their innovations into desktop browsers first, before they bring the same features to browsers on smartphones. In the meantime, we find WebRTC support e.g. in Google Chrome and Mozilla Firefox Nightly. Solutions (by 3rd parties) for Apple’s iPhone operating system iOS and Google’s Android smartphone operating system have already been shown too. Support in browsers is generally mixed. Typically not all aspects of the specifications agreed in standards are implemented in equal measures across browsers today, though solutions will become more complete over time. Good news is that WebRTC calls have already been demonstrated between the Chrome and the Firefox browser in Feb 2013 . For a YouTube video about this, see .
Second, there are the companies which use WebRTC as a new enabler. They experiment with new types of communication services using WebRTC as a nice browser-built-in feature. Some of those companies are Voxeo Labs, Twilio and Solaiemes.
As WebRTC is the talking point these days when it comes to real-time communication on the Web, no wonder that telecommunication service providers including mobile network operators have started to take notice and some jumped into action. Partnering is overdue then: Deutsche Telekom announced a partnership with Voxeo, KDDI with Twilio and so did AT&T. Telefonica showed greater appetite and simply acquired a company knowledgeable in WebRTC, namely TokBox.
No doubt, Google and Mozilla with a community of companies in W3C and IETF have been driving WebRTC (and RTCWEB) pretty successfully so far. There will be others whose existing services will be impacted, including Microsoft/Skype. Not surprising that Microsoft has taken a different route through their proposal called Cu-RTC-Web which apparently got first announced in Aug 2012 .
As Peter Bright argues in , Microsoft appears to dislike the use of SDP (the Session Description Protocol) made mandatory, whereas others would argue it eases interoperability with SIP-based systems. Mind, SDP is also used by mobile network operators in the so-called 3GPP IMS system for IP-based multimedia, which may well ease interworking of WebRTC with the network operators’ IMS-based services. Reportedly neither Skype nor Microsoft Lync use SDP in their core. On the other hand, as Peter argues, Microsoft’s concern over SDP may be justified, in particular if WebRTC / RTCWEB required the current SDP to be extended to support W3C use cases and if greater demand arose for browser to non-browser communication.
Thus, we need to see, whether some of the issues surrounding SDP turn out to be show-stoppers in the future or not. Though Microsoft’s proposal was voted down by WebRTC folks, it doesn’t mean the issues Microsoft pointed out have been automatically resolved.
And Apple? Well, shrouded in secrecy so far.
On the computing infrastructure side possibly some kind of WebRTC Platform as a Service (PaaS) propositions may get traction (Chad Hart calls it WebRTCaaS ). There, WebRTC technology features and services are used by websites in a PaaS/cloud model. As companies active in this space he lists Twilio, Voxeo, Hookflash, AddLive, TenHands, and VidTel.
To which extent will WebRTC cause some headache for telecommunications companies?
AT&T positioned themselves with regard to WebRTC already at their Developer Summit in Las Vegas in early 2013. It seems that a typical carrier’s strategy won’t be fighting WebRTC. Instead, it will most often be about embracing the new technology and limiting damage to existing telco business models through enriching any WebRTC-enabled services with telco ingredients of value. Interworking with ‘legacy’ audio/video services or existing VoIP services is one area where value-add can be created. This is also picked up by telco infrastructure vendors like Ericsson. As they say, their solutions will not only support web-to-web communication but also web-to-IMS interworking.
Who does the standards?
The Internet Engineering Task Force IETF has defined an enabling protocol specification in its working group called RTCWEB .
Both standardisation efforts are not fully completed yet as of the date of this writing.
Overall, W3C and IETF have somehow managed to agree on a beneficial work split.
The “over wire” or “on-the-wire” protocols from IETF run between supporting servers (for signalling) and between browsers (for the media path).
Some hot debates centred in the past around the type of mandatory video codec to choose for browsers (VP8 versus H.264). Ideally it should be first class and royalty free. The “first call” between Google Chrome and the Mozilla Firefox browser has been made using VP8 in Feb 2013.
Fair to say that IETF go even further: RTCWEB is of course the great companion of WebRTC, but not limited to it. “From RTCWEB protocol point of view, the endpoint can also be something different from a browser”. Thus, it could be for instance some native application (say in iOS or Android) or a machine-to-machine terminal software that collects sensor data and transmits it via the RTCWEB protocol suite.
What are the bits and pieces needed for a good WebRTC service implementation?
We need mighty functions inside the browsers that handle everything related to real-time services like voice and video: Audio/video engines that include e.g. codecs like Opus for wideband music quality audio (what a new phone conversation quality we can expect now via the browser!) and VP8 (or H.264) for video (stunning video full-screen on my 24’’ monitor), jitter buffers, image enhancers, noise reduction etc.
Then we need a protocol that handles real-time communication including data framing, loss detection, lip synchronization, error recovery (RTP) and one that provides statistics about that (RTCP). On top, security (confidentiality and integrity) is catered for by encrypting data and signalling and by shipping keys. For this secure protocols are used (SRTP for symmetric key cryptography, DTLS over UDP to exchange session keys). To support generic data streaming between peers e.g. for gaming, additional protocols like SCTP are needed. Finally the browser will support mechanisms to deal with NAT/firewall traversal.
Second, we need server support for various reasons (despite WebRTC enabling peer-to-peer real-time data streaming): To enable signalling between the remote browsers, to support NAT/firewall traversal using the ICE framework with protocols like STUN and TURN involved to connect peers directly or via a relay server, and to discover real-time service users around the Globe (who is out there ready to be communicated with!).
Finally, WebRTC-enabled services may need to tap into identity solutions in order to allow communicating users to verify each other’s identity.
Looking under the hood: How does it actually work?
1) First, the web page’s code gets streaming audio, video or other data from the desktop, laptop, tablet or smartphone or any other gadget that runs a Web browser. For this purpose, the web page developer will use the MediaStream API which uses a method unsurprisingly called getUserMedia(). The captured media stream will be typically passed on to an HTML 5 element of the same page to output this local audio/video via the user’s browser. The same media stream will be passed to the other party via the RTCPeerConnection API.
2) Second, some signalling happens between the local web application and the remote peer application via a server in-between.
- Network configuration: The local web application gets its own network information (IP address and TCP/UDP port), and exchanges this with other WebRTC clients via signalling to enable a connection.
- Session control: It then coordinates signaling communication to initiate or close a session.
Importantly, signaling methods and protocols are not specified by WebRTC. This means, a WebRTC service developer can choose any suitable messaging protocol for signalling purposes (e.g. SIP, XMPP, WebSocket or others).
3) Once the signalling has successfully completed, the browser can ignore the in-between server and send streaming audio, video or generic data (e.g. for screen or file sharing, gaming…) directly to the peer browser at the far end (thus peer-to-peer). For this, it uses the RTCPeerConnection API for audio and video (RTCDataChannel API for generic data like screen sharing or gaming).
Where is the money flowing and what products can we expect?
WebRTC in Web browsers constitutes an enabler, the one on consumer devices and usable by web and web apps developers. Other products emerge like gateways to support WebRTC communication with the good old telephony service and equally with the now classic Voice over IP services. Finally, there is no limit to building real-time service support (be it voice, video, or screen sharing) into all sorts of consumer-facing web applications. This could be related to customer care and service assistance (e.g. in a medical scenario, for patients or elderly people). More generally, voice/video/data sharing capabilities can be added to existing business, enterprise and collaboration software where it makes sense (e.g. for on-line instant advice) with low hurdles for deployment. Finally, as mentioned above, companies will enter the market with cloud-based solutions that assist service developers in bolting together a new WebRTC-enabled web application.
Is it really new?
VoIP and video conferencing over the Internet have been here for a while, and so related services like Skype, Cisco’s WebEx or Citrix’s GoToMeeting. Equally, as pointed out in  things like Real-Time Messaging Protocol (RTMP) as available in Adobe Flash may be regarded as existing predecessors. WebRTC in browsers, however, eliminates some of the complexities and inconveniences enterprise users and consumers had to face so far: downloading a Skype client (and downloading it again when it says a new version is available), handling pop-up windows and security alerts when starting WebEx or simply needing to wait several minutes until the web conferencing tool is ready to go. With WebRTC that should be a matter of the past.
Overall, WebRTC and RTCWEB (worthwhile to mention both) constitute a major development. It’s still early days as the first WebRTC call between Google and Mozilla teams showed in Feb 2013 . More needs to be done and will be done. And more news will hit the web about companies like Voxeo  or AddLive  innovating in this space.
 Sam Shead, Chrome and Firefox showcase video chat via WebRTC. http://www.zdnet.com/chrome-and-firefox-showcase-video-chat-via-webrtc-7000010915/ 6 Feb 2013.
 WebRTC conversation between Google Chrome’s director of product management, Hugh Finnan, and Mozilla’s chief of innovation, Todd Simpson. http://www.youtube.com/watch?feature=player_embedded&v=MsAWR_rJ5n8 3 Feb 2013.
 Microsoft’s proposal for WebRTC. http://html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm
 Peter Bright, Microsoft goes its own way with Web audio/video spec, despite W3C rebuff. http://arstechnica.com/information-technology/2013/01/microsoft-goes-its-own-way-with-web-audiovideo-spec-despite-w3c-rebuff/. 19 Jan 2013.
 Chad Hart, Is there a WebRTC ecosystem? http://lphs.acmepacket.com/blog/bid/168799/Is-there-a-WebRTC-ecosystem, Jan 2013.
 Ian Elliot, First Contact – Firefox & Chrome WebRTC. http://www.i-programmer.info/news/86-browsers/5421-first-contact-firefox-a-chrome-webrtc.html, 5 Feb 2013.
 Voxeo Labs’s Phono: http://phono.com/webrtc. Demonstrating phone calls between Web browser and old legacy phone network.
 Some WebRTC service inspiration: http://www.addlive.com
 Documents on webRTC at W3C: http://www.w3.org/2011/04/webrtc/
 Documents on RTCWEB at IETF: http://tools.ietf.org/wg/rtcweb/
Download this paper in pdf format here.