A View to Our Future – Mobile Devices, WebRTC, HTML5, and the Webification of Communications
This post is based on a question from Marty Parker about the status of WebRTC. After writing the reply I decided it would be good to make it into a post. Specifically the question was as follows:
“Do current versions of WebRTC support mobile device browsers at the same level as the PC/MAC-based browsers? I’m thinking about the evolution of the industry and clearly apps on mobile devices is a major vector in the evolution. If WebRTC is as capable on mobile devices as on the computer-type devices, WebRTC may amplify that vector.”
My answer to this is a multi-faceted commentary on where we are and where we are going: in Devices, WebRTC, HTML5, and the general “webification” of communications. As I wrote it I realized that all of these factors are interrelated in the dramatic change in communications and collaboration that is coming. So, instead of a short answer on WebRTC, I took the opportunity to do a bit of crystal ball gazing about where it appears we are headed.
First, in response to the question, as far as whether other browsers will support WebRTC, this is a bit complicated. Natively today in Apple iOS Safari? – no, in WinMobile/IE? – no. However, there are active projects to create plug-ins for both environments, and these may extend to the mobile world. For iOS and Android, the Chrome browser supports WebRTC directly in some devices, generally the Moto/Google ones, less in the others as either the device vendor or the carrier can turn it off at this point. In some qualitative surveys I have done, I have found this to be spotty at this point. In addition, both Apple and Microsoft are active in the standards efforts and have indicated that they will support the standard someday.
Most of the mobile application development environments are supporting WebRTC as part of the app environment so you can use WebRTC, instead of SIP, in a native app. This is getting a lot of traction as most app developers at this point are developing native apps versus going HTML5. With this, the WebRTC code and APIs are not in the browser, but are coded directly in the mobile app that you download from the Apple or Google app store. As most apps, especially those done for enterprise use are developed in one of these development frameworks, adding WebRTC is easy. From an end user perspective, it is as easy as clicking an item to talk to an agent and the WebRTC is initiated. As Google open-sourced all of the WebRTC code for the media engine and the APIs are a W3C standard, this really simplifies development. In fact, many of these implementations can also choose which codec to use, eliminating the issues with Codec transcoding, such as the other end using an H.264 video codec. Interestingly, looking at the Amazon Mayday implementation shows that it is a mix of WebRTC and H.264 and a few other things.
Integrating WebRTC into an HTML5 application is the next generation of apps, but today performance is better on apps written directly to the Operating System APIs versus the more abstracted HTML5 APIs, and, of course, not all devices/browsers have full HTML5 support yet. This is especially true as the older versions of browsers in the field have a fairly long tail (anyone running Windows XP out there?). I think the long term (five-year) direction is for mobile to move to HTML5 apps cached on the device instead of bespoke native apps that are downloaded. I think we will see a proliferation of device OSs over time and that is the best way to do this – take advantage of the constant increase in processing power and network speed to further abstract the complexity so as to simplify deployment and support. If you click an icon and it is a HTML5 app, it looks like a native app and all works the same; as an end user, you probably don’t care.
In many ways, this is changing applications back into what they really are in most cases, a local display of a server-based application. Look on your smart device and see how many of the apps have real value if you are not network connected, especially over an extended period as the data becomes stale. Interestingly, this portends a radical change in devices over the next five years. If the device is running HTML5-based apps, then it becomes more of a very smart display with a cache. If we think about a 64GB cache, it is 30 days if you consume 2 GB per day. As 2 GB is about 2 hours of HD video content (or 24 hours of audio or a whack of emails), it is a very different model. If the device memory/cache is partitioned with an amount for music (say 10 GB), video (say 30 GB), Apps (20 GB for HTML5 code), and email (5 GB?), then the device has everything you need.
Instead of downloading music ahead of time and having a library, with the increase in bandwidth, many of us are now subscribing to a streaming service such as Spotify or Beats. However, if the network is not available, streaming will not work. With a cache, you can listen to music that is already in the device cache, perhaps automatically updated in the background based on your preferences or subscription settings. Or, the content can be sequenced and optimized based on your listening habits by the music app running as HTML5. The most interesting thing is that as our devices are connected more often and at higher bandwidth, the need for the cache is actually decreasing, while the available memory is increasing. And with Moore’s law, the power of the processor continues to go up, making HTML5 apps look equal to the OS-based versions. One wonders if the devices of the future will be bought less on the technology, and more on the brand, think sneakers or Beats headphones. When you buy a pair of sneakers, do you really analyze the technology of their manufacture or buy based on brand or price? Perhaps your smartphone five years from now will be an iBeats device or maybe a NikePhone.
Finally, from a communications perspective, all of these changes are adding up to the “Webification” of communications. In the web model, there is not just a single server or control point – it is called a web because it is a web of end points and servers and the overall user experience is a combination of numerous sessions with unique user experiences that last for relatively short periods. In fact, think about how many different web servers you visited in the last week/month/year; actually, you probably don’t know how many since a lot of them are connected into applications automatically, not under your direct control. In many cases, even if you had a direct connection to a specific server, Google may have found you the URL, but they do not take you there, they send you there. In other words, Google is a directory, not a portal.
With WebRTC, or whatever develops as the web communications technology moves forward, the same effect is going to happen in communications. In other words, if I have the URL to your server or your personal page, I go directly there with my device (may be a browser or may be an app or HTML5 in the device). I do not go through my server, but, in the web paradigm, go directly to your server and have a communications experience that is defined by your server. Similarly, when you want to interact with me, you come directly to my server, either an enterprise or personal, with different URLs. And communications can be added to the 30-40 million web servers and their applications or services, creating an explosion of innovation and new values. Over the next 5-10 years, I fully expect to see communications Webify, and the result is going to be transformational.
I hope these thoughts are useful and help illuminate some of the potential changes that are coming in our industry. I firmly believe the next 5-10 years will be more disruptive than the last 30, especially for communications. While VoIP changed how communications is transmitted and carried, to a great extent it did not change the basic value of the phone call. UC is adding new values, but in a constrained environment. With smart mobile devices, HTML5, WebRTC, and webification, the opportunities to create major value change is clear. While we are just now seeing companies beginning to exploit this model (see Uberconference, Voxbone, Lifesize, Oracle, etc.), the real change will be when you connect to LinkedIn (or Facebook or Twitter or eBay or…) and can simply click on a connection/friend/enemy to interact in a wide variety of modes.
In the end, the key question that comes out of this discussion is whether communications is a separate technology/discipline, or whether it will become part of the general fabric of our lives. If every application includes communications, how does that change applications that are communications only? Will there be applications that are communications only in the future? What makes the next few years so interesting is not the evolution of the telephony system, but the potential for something very different to emerge. While the Webified communications world will not displace the number-driven phone system immediately or in totality for an extended period, it is a certainly a new paradigm of communications. Ten years is a long time and a lot will happen in ten years. Ten years ago, there was no Facebook, no iPhones, no Android, no Tablets, no Twitter, no LinkedIn, etc. VoIP was in its infancy, while today VoIP is used in 95% of new communications installs. In the Internet/web world time moves fast and it actually appears to be accelerating, so we should expect big changes from the evolution of WebRTC and the Webification of communications.