Pages

Pages

Friday, October 11, 2013

For telcos, IMS integration should only be a small % of WebRTC effort

I've got numerous presentations and conferences coming up over the next couple of months, especially in Europe & SE Asia. Most of these touch on the themes of voice, WebRTC, unified communications and related areas. As a result, I've been giving some thought to my current views on WebRTC and its evolution so far in 2013 and critical angles for development in 2014 - especially where it intersects with the telecom service provider space.

My current thinking is that for many operators, their pace and breadth of innovation around WebRTC is too slow - and often (and ironically) confined to some of the more conservative-minded teams.

I don't want to pre-empt everything in my forthcoming presentations (and the new update for my WebRTC report subscribers) but there is one clear and critical message:

IMS interworking should account for no more than 30% of a telco's overall effort or investment into WebRTC. Further, the IMS/core network group MUST NOT have centralised control over a carrier's overall WebRTC strategy

For those operators that are pursuing IMS, either in fixed or mobile domains, yes it will be important to understand how to leverage WebRTC. It can potentially extend operator-branded VoIP to devices without apps or native support, for example - using a standard browser instead of a softphone or other dedicated client. 

This might be a help for VoLTE, by allowing users to use the same number/identity on (paradoxically) non-LTE devices such as WiFi tablets. It might reduce reliance on the still-clunky SR-VCC standard for switching from VoLTE to 2G/3G circuit telephony at the edge of coverage, if WiFi is available, too. Or allow innovation such as a "second telephony line", or even somehow enable non-telephony voice formats hook into an IMS platform. I'm not convinced this is the best way of doing any of this, and I'm also certain that not every operator will implement IMS anyway, but for those that do, WebRTC offers a way of making a legacy architecture a bit more 21st-century ready.

(WebRTC might also eventually help reduce the difficulty of rolling out RCS to some devices too - although the 17 or 26 other critical problems associated with that standard mean that it still has no chance of success).

But the important factor here is that even looking optimistically at IMS, it will not be the basis for the bulk of new services and revenue streams for operators. It has a role for some SPs in managing a more graceful decline of telephony from its historic peak, by lowing the cost base and maybe adding a couple of extra features. This has been seen with the fixed PSTN moving to NGN/IMS VoIP to replace creaky 30yr-old switches, and will likely be replicated in mobile with VoLTE. (Although here, the industry has been forced into VoIP by LTE not supporting CS voice, even though mobile CS infrastructure is often new and cost-optimised).

Either way, WebRTC-enabling VoLTE or other IMS services will not occur at "web speed". Although we're seeing a ton of gateway solutions emerge from all the big vendors (ALU, Ericsson, Genband, Huawei, Oracle etc), that's only part of the puzzle. There's still a ton of work to do around service creation, testing, regulatory compliance, market research, OSS/BSS integration and all the usual telco paraphernalia which extends launch cycles out to years rather than months. WebRTC might simplify development of device-side clients/apps, but it won't short-circuit the internal legal department's process of signing it off.

But most new services that telcos should be focusing on - whether they relate to content, IPTV, next-gen messaging, home automation, telco-OTT, banking, healthcare, corporate UC, videoconferencing and so on - will almost certainly not be anchored in IMS. They will run on separate platforms, often cloud-based, web-based and/or partner-based.

It is critical that all of the various telco business units and teams that are doing service development have their own views and autonomy when it comes to WebRTC. They should all be experimenting and prototyping using whichever tools and platforms make sense. WebRTC responsibility must be decentralised across a telco's portfolio of efforts. They should use 3rd-party APIs and SDKs, work with Internet companies, use pre-standard tools and platforms, create separate identity spaces and so forth. The same is true for internal processes at the operator - BSS/OSS, HR, field force automation, internal communications/collaboration and so on should all be looking at how WebRTC can enhance their activities.

But these activities should happen independently of whatever is going on in IMS, the Labs & the Core Network. The peripheral innovative business units must "distintermediate" their own core network if necessary - and be must given C-level "air support" when they do it. If they don't, they will lose relevance and opportunity, waiting for the slowly-grinding wheels of IMS/WebRTC integration to catch up. Which they probably won't for some time, if ever.

If and when the telco's IMS/WebRTC platform is equal to other choices in terms of flexibility, performance and planned future evolution speed, it should be considered for migration. But not before - it is not a "special flower" from the perspective of the group thinking about enterprise videoconferencing, or turning next-gen music streaming into karaoke, or considering adding realtime sensor data-collection to home-automation propositions.

The bottom line is that for telcos, WebRTC is a lot more important for IMS, than IMS is important for WebRTC. By all means pursue the extension of VoLTE or whatever - but telco CTOs (and, frankly CEOs and CFOs) must make absolutely certain that the bulk of WebRTC initiatives and investment are made outside of the stifling conservatism of the IMS mindset.


Thursday, October 10, 2013

Amazon's Mayday may signal its long-awaited WebRTC strategy

One of the things I've been waiting for is Amazon's foray into the world of WebRTC.

I've been wondering whether it would be simply adding the ability to speak to a customer support rep on the main website, to other users about product reviews - or perhaps the other way, as a competitor to APIs from TokBox & Twilio & Tropo, or as a hosted media/TURN server offer as part of Amazon EC2 or its other cloud services.

We still don't have a full story. But we might have a hint, with the new "Mayday" button on the Kindle Fire HDX (article here) which offers live tech support including one-way voice & video. You can see the Tech guy, but he can't see you. However, the data streams are two-way so the support agent can do diagnostics and so on.

At the moment, it's a little unclear what technology is being used either between the Kindle and the Amazon data centres, or internally within the contact centre facing the agent. It might be WebRTC or a close relative, but nobody's saying one way or the other yet.

However, there are three interesting angles to this:

a) It's a great idea from Amazon which will improve customer convenience, and potentially increase sales (albeit with extra costs of employing agents)
b) It further "democratises" the idea of embedding voice and video capabilities directly into applications and devices, for purposes other than a "phone call". This is a good thing for the WebRTC community, as it opens more eyes to what's possible - and, specifically, that embedded/contextualised comms is going to gradually steal share from "standalone" models of speech or video.
c) Amazon tends to "platformise" its internal technology. It designs and builds its systems in a way that it offer them externally as well, gaining both external revenues and reducing its own unit-costs by spreading them over greater volumes. That's what's driven EC2 and AWS business models, as well as numerous lesser-know platforms that Amazon provides for e-commerce, web-hosting and even physical logistics/warehousing. I remember hearing the CTO give a speech where he talked about building things "inside out".

So... I wonder if Amazon's big WebRTC play *isn't* going to be around technology, such as hosted virtualised gateways on AWS (although that might happen with partners, as it has historically with Flash media servers). Perhaps it isn't going to compete in the contested WebRTC API/SDK space with AddLive & TokBox and the growing range of other cloud players either.

Perhaps it's going to be a more generic "Video customer service & diagnostics"-as-as-service player. (MDaaS or Mayday-as-a-service is probably a snappier name). If this works well on the Kindle, imagine what other devices or applications could benefit from an Amazon-powered Mayday button. Certainly makes a bit of a difference from a generic "call me" button that is a mainstay of WebRTC today.

Just as LiveNinja has used WebRTC to build a generic "consult with an expert" platform, maybe Amazon will be the leader in WebRTC-enabled "interactive tech support". Or, perhaps "almost WebRTC" if they decide they can do better than the official standard for this specific use-case. The nice thing here is that nobody has to be purist about WebRTC, especially for "silo" applications. It's not like something like Mayday needs to interop with legacy SIP services - so its creator is free to use whatever works best, and the user will neither know nor care if it's WebRTC, Flash or magic pixies making it all happen.

Also worth noting that Amazon is doing a lot of stuff around voice recognition and virtual assistance as well, so maybe they'll front-end it with a new flavour of IVR, but with the V standing for video, not voice.