| Tomorrow I'll be running the first of the Future of Voice Masterclasses I've been developing with Martin Geddes. We'll cover a broad array of topics around the value, business model and technology of voice communications, especially as we go beyond the basic telephony service we're so familiar with. I've spent the last couple of days at the wonderful eComm conference in San Francisco, listening to a challenging series of speakers cover everything from telecom regulation to wireless sensors to the psychology of motivation. One of the presentations that most struck me as surprising was one from Voxeo. It referred to the potential for running voice (specifically VoIP) inside HTML5 browsers and apps, rather than through standalone applications like a Skype client. This made me wake up, as I've previously been following the whole native-apps/web-apps debate without really being swayed by the web side of the argument. Indeed, I went to a Mobile Monday London event recently which did actually debate the issue formally, with two opposing teams. I asked a question about whether web applications would be suitable for demanding apps like VoIP - and even the web advocates said no, that was out of scope. The Voxeo presentation covered WebRTC and RTCWeb standards. (RTC=realtime communications). In a nutshell, there's basically a lot of work going on to enhance HTML5 so that it can deal with various codecs and streaming protocols, as well as Javascript APIs to control media - for example with access to the microphone and speaker. But the really interesting things are that: - Signalling is all done with web protocols like HTTP and XMPP, not SIP. - Google has donated a ton of its GIPS code to the project, which does clever acoustic stuff like dealing with echo and packet loss - Voxeo's platform called Phono.com has a variety of software functions which enable all this capability to bundled into useful formats - such as initiating a call. - Using something called Phonegap, web developers can create web apps for Apple IOS which incorporate voice connections and calls natively . So one web page (or browser) could make a voice connection with another server or browser. These are not phone calls. These are additional voice applications, which could theoretically connect to the public phone network, but don't need to. They might be voice-enabled game sites, or social networks, or whatever, where voice just works, Think about that for a moment. Voice communications becomes a feature of a web page, the same way that tables, or style sheets, or embedded images are. Voice as a feature, not a service. Now all of this is still some way away from being fully practical for mainstream phones. But over the next few years, it seems likely this going to get built into future browsers as part of the standard of HTML5. In other words, an HTML5-compliant mobile browser in 2013 may *have* to support this, although that may be dependent on whether a given device gives API access to all the relevant bits & pieces like microphone and speaker in the right way, without latency or other glitches. I'm still trying to get my head around the ramifications of this - but either way, it's deeply, deeply important and potentially represents more of an alternative for LTE Voice than even some OTT apps like Skype. Because this isn't voice as a separate OTT application - it's voice *in* the web itself. |
