In yesterday's post about RCS, I mentioned in passing that VoLTE and RCS must be 100% separated if either is to stand a chance of success. At present, attempts to combine them in RCS5 are, depending on your viewpoint, either: (a) a rather Machiavellian attempt to force deployment of RCS even among skeptical carriers, or (b) because a few use-cases of IM/chat benefit from being integrated with voice communications. There is also the vendor bundling argument of "Get 2 apps for the price of 1 on our IMS platform".
The net effect is shackling the already-hobbling VoLTE to the corpse of RCS, making it drag its deceased counterpart along for the entire distance of a marathon. Not a strategy for success, for either (a) or (b) scnearios. To mix my metaphors - just because you share IMS DNA with your sibling, you should still remember that incestuous marriage is banned for good reasons: your offspring will likely have undesirable genetic traits. Far better to look for fresh genes elsewhere and cross-breed with Internet species, for example.
That led to me to a broader set of thoughts about voice/messaging integration, and also fragmentation of the voice experience. I've often used this chart (or variations) for the past few years, and it encapsulates what is happening as voice goes "beyond telephony":
In a nutshell, voice communications is changing from standalone telephony, to a more complex and dynamic market in which voice gets embedded into many applications and contexts, often in forms that don't look like traditional "phone calls". WebRTC accelerates this, although it is already happening via apps and APIs in any case.
This also means that typical phones and PCs will have multiple "voice apps" in future, besides the dialler. Obviously this is already becoming true for many users today, who have VoIP capabilities from Skype, Google, Telco-OTT apps, corporate UC systems, embedded voice in games or Facebook and so forth. With the advent of WebRTC we'll see even more fragmentation of the voice experience, with websites and mobile apps featuring voice functions internally. Often, the experience of voice will often be nothing like a phone conversation - no "Hello, is that Dean?" or the normal interruptions, ringing, stilted etiquette and other bits of 130-year old furniture that make up this thing we recognise as a "call".
While we already see cloud providers and operators provide telephony APIs to developers (some do already), many of those still have the same "raw ingredient" as the basic phone call, using the same voice engine and numbering as the handset's main dialler. That's not good enough.
There needs to be much greater flexibility and imagination. For example, if I'm calling from a call-centre there needs to be Grade-A background noise suppression so you can't hear the inane chatter of my colleagues, while I try to sell you double-glazing. But if I'm on a beach making a "wish you were here!" call to a friend, it would be nice to have the gentle sound of waves in the background, not deathly silence. There are many other parameters and interaction models for developers to tune too - that's just a simple example.
For video, there are actually more options, because firms like AddLive, Plivo, Telefonica/TokBox and others are offering video APIs and back-end cloud services, based either on WebRTC or proprietary alternatives. But as far as I know, there aren't many easy APIs for non-telephony forms of voice communication yet, although Twilio, Rebtel, Voxeo Labs and others enable in-app voice with some control over interaction logic.
Coming back to the RCS/VoLTE debacle, this points to an uncomfortable conclusion - rigid, standard phone calls are precisely the wrong sort of voice to include in RCS-type use cases anyway. Even if RCS miraculously became a success, developers would probably want to mash it up with non-VoLTE voice a lot of the time. You'd want stereo for a karaoke app, and the capability to deal with a lousy external microphone, for example. Some might want to trigger a traditional phone call, but others would not. Even then, developers will want a choice of 3rd-party telephony/VoIP APIs and not just the carrier's, for example if they want to use different phone numbers.
So if telcos and their vendors decide to put voice capabilities into RCS anyway, they need to start from square one, and think "Why are we putting voice here? Is it for phone-type calls similar to Skype? or is it for other use-cases? What do users and developers actually want to do?". As with my post on messaging, they need to think about Intent & Purpose, and not just get blind-sided because they can get both sets of (independent) capability from the same platform.
A similar argument applies to VoLTE adding RCS. If LTE phone calls can benefit from associated messaging, presence or other features, is RCS really the right/only product to deliver that, for the specific use-cases that carrier feels are important?
Operators should be looking more at mashup / orchestrated approaches. And they need to be happy to have multiple voice experiences on their customers devices - and not only that, but they ought to be developing multiple voice apps/services/APIs, not just clunky old telephony warmed-over in VoLTE guise.
So if you want voice in RCS, then there's a big choice out there. Bolting it to VoLTE makes no sense whatsoever - it would even be better to have a second, different VoIP app-server on the same IMS and use that instead, especially as half the time it's likely to be running over 3G or 3rd-party uncontrolled WiFi anyway.
The net effect is shackling the already-hobbling VoLTE to the corpse of RCS, making it drag its deceased counterpart along for the entire distance of a marathon. Not a strategy for success, for either (a) or (b) scnearios. To mix my metaphors - just because you share IMS DNA with your sibling, you should still remember that incestuous marriage is banned for good reasons: your offspring will likely have undesirable genetic traits. Far better to look for fresh genes elsewhere and cross-breed with Internet species, for example.
That led to me to a broader set of thoughts about voice/messaging integration, and also fragmentation of the voice experience. I've often used this chart (or variations) for the past few years, and it encapsulates what is happening as voice goes "beyond telephony":
In a nutshell, voice communications is changing from standalone telephony, to a more complex and dynamic market in which voice gets embedded into many applications and contexts, often in forms that don't look like traditional "phone calls". WebRTC accelerates this, although it is already happening via apps and APIs in any case.
This also means that typical phones and PCs will have multiple "voice apps" in future, besides the dialler. Obviously this is already becoming true for many users today, who have VoIP capabilities from Skype, Google, Telco-OTT apps, corporate UC systems, embedded voice in games or Facebook and so forth. With the advent of WebRTC we'll see even more fragmentation of the voice experience, with websites and mobile apps featuring voice functions internally. Often, the experience of voice will often be nothing like a phone conversation - no "Hello, is that Dean?" or the normal interruptions, ringing, stilted etiquette and other bits of 130-year old furniture that make up this thing we recognise as a "call".
While we already see cloud providers and operators provide telephony APIs to developers (some do already), many of those still have the same "raw ingredient" as the basic phone call, using the same voice engine and numbering as the handset's main dialler. That's not good enough.
There needs to be much greater flexibility and imagination. For example, if I'm calling from a call-centre there needs to be Grade-A background noise suppression so you can't hear the inane chatter of my colleagues, while I try to sell you double-glazing. But if I'm on a beach making a "wish you were here!" call to a friend, it would be nice to have the gentle sound of waves in the background, not deathly silence. There are many other parameters and interaction models for developers to tune too - that's just a simple example.
For video, there are actually more options, because firms like AddLive, Plivo, Telefonica/TokBox and others are offering video APIs and back-end cloud services, based either on WebRTC or proprietary alternatives. But as far as I know, there aren't many easy APIs for non-telephony forms of voice communication yet, although Twilio, Rebtel, Voxeo Labs and others enable in-app voice with some control over interaction logic.
Coming back to the RCS/VoLTE debacle, this points to an uncomfortable conclusion - rigid, standard phone calls are precisely the wrong sort of voice to include in RCS-type use cases anyway. Even if RCS miraculously became a success, developers would probably want to mash it up with non-VoLTE voice a lot of the time. You'd want stereo for a karaoke app, and the capability to deal with a lousy external microphone, for example. Some might want to trigger a traditional phone call, but others would not. Even then, developers will want a choice of 3rd-party telephony/VoIP APIs and not just the carrier's, for example if they want to use different phone numbers.
So if telcos and their vendors decide to put voice capabilities into RCS anyway, they need to start from square one, and think "Why are we putting voice here? Is it for phone-type calls similar to Skype? or is it for other use-cases? What do users and developers actually want to do?". As with my post on messaging, they need to think about Intent & Purpose, and not just get blind-sided because they can get both sets of (independent) capability from the same platform.
A similar argument applies to VoLTE adding RCS. If LTE phone calls can benefit from associated messaging, presence or other features, is RCS really the right/only product to deliver that, for the specific use-cases that carrier feels are important?
Operators should be looking more at mashup / orchestrated approaches. And they need to be happy to have multiple voice experiences on their customers devices - and not only that, but they ought to be developing multiple voice apps/services/APIs, not just clunky old telephony warmed-over in VoLTE guise.
So if you want voice in RCS, then there's a big choice out there. Bolting it to VoLTE makes no sense whatsoever - it would even be better to have a second, different VoIP app-server on the same IMS and use that instead, especially as half the time it's likely to be running over 3G or 3rd-party uncontrolled WiFi anyway.
1 comment:
Dean, very imaginitive. However. The investment in ims for volte dwarfs the integration of rcs on a 100:1 scale. They will be combined, and must be if the road on which they run is to become stable enough, and go to enough places to make the technology pervasive and cheap enough to enable what you describe.
Post a Comment