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.
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.
4 comments:
Dean,
Google also added video support to WebRTC via WebM video codec (not H.264).
This means you can get the same functionality for both voice AND video calls.
It can change the industry as we know it, but only time will tell if this technology will be embedded in browsers.
Nice insights, Dean. Latency would be a concern of mine as well. I hope the apps developers don't proceed too far without connecting with the radio folks.
... and add two lines of code from http://www.tokbox.com/opentok/api and you have video conferencing many-to-many on your site (soon in HTML5 instead of flash - prototype looks great!)
You can add two lines of code to voice-enable any website with Tawk. tawkalot.com. It utilizes HTML5 Speech Input. Looking forward to a whole host of other innovative applications.
Post a Comment