The W3C/IETF plan to support real time communication in the browser, WebRTC, is moving from high-flown concept to somewhat messy, but useful, reality. Generally, I am a fan. WebRTC offers new opportunities to both indie developers and the established players. It will undoubtedly accelerate the adoption of new conversational services at the expense of traditional fixed and mobile telephony. There are a lot of interesting and important topics to explore related to WebRTC but I want to start by talking about what kind of ecosystem will be involved in successful WebRTC services. A lot of the technically focussed analysis of WebRTC has not highlighted the extent to which WebRTC services will require multiple components and company inputs to be integrated.
- RTCPeerConnection which allows connections that send and receive media to be made with peer devices running WebRTC; and
- RTCDataChannel which allows generic non-media data to be sent over an RTCPeerConnection channel.
In this discussion I am just going to focus on RTCPeerConnection. RTCDataChannel is a really interesting initiative with a lot of implications but it’s probably the least mature part of WebRTC and not really central to the point I want to make about ecosystems. Mediastream is the most mature element but it doesn’t feature majorly in my thoughts on the value chain.
WebRTC – Simplified service architecture
Lastly, we should not forget about the (not really) “dumb” pipes that all this flows over. WebRTC changes browser behaviour quite profoundly by creating the potential for a lot of traffic on new protocols and new IP ports. To some extent the support of web sockets have already opened up the use of multiple protocols on the browser but WebRTC will make this much more common. All this will have impacts on local personal firewalls, home gateways and ISPs but that is a discussion for another day.