WebRTC DataChannel: Yahoo acquires PeerCDN. 2014 just got more interesting....

There were two disappointments for me from last week's WebRTC conference in Paris & recent ongoing news:

a) Still no major public WebRTC involvement from other big Web players beyond Google (unless you count Amazon Mayday which is still unconfirmed as WebRTC or not)
b) No really exciting new things happening in WebRTC DataChannel for the past 6 months

Both changed yesterday, with Yahoo! buying WebRTC startup PeerCDN. 

In my presentation at the Paris conference, I predicted that 2014 (see Slide 22 here) would see "major Internet players using WebRTC" and "Surprises, especially around data use of WebRTC". Looks like even I've been caught out by the speed of WebRTC evolution - they've both happened with 2 weeks of 2013 still left.

Silicon Valley jokes about Yahoo! acquisitions aside, this is a really interesting move. PeerCDN is one of a handful of startups trying to use WebRTC's browser-to-browser data communications ability, to reduce bandwidth/CDN costs for content companies - and ideally to reduce latency as well. Peer5 and StreamRoot (which was in Paris last week) are also in this space.

The idea is simple - rather than having all users download content from the company's own servers, or that of a commercial CDN like Akamai or Limelight, have some of it downloaded from each other. If two people are on the same site at the same time (or perhaps with cached content in their browsers), connect the two browsers together using WebRTC's less well-known DataChannel API, and deliver certain chunks of content like that instead.

There are various implications:

- Reduce the outbound bandwidth costs (or CDN delivery costs) of the content company
- Improves website response times, especially if the users concerned are geographically close to each other
- Indirectly increases uplink local-access bandwidth consumption, as the users transmit some of  their data back "upstream" to the other peers
- Represents a legal use-case for P2P data, as the content company is in control, and indeed in approval.
- Impacts the potential revenues and margins for traditional CDN players, and massively reduces entry barriers to that market
- Makes it harder for telcos to monetise on-net CDNs - although perhaps easier to launch them, if they white-label services such as StreamRoot's.
- It doesn't matter if only a % of browsers are WebRTC-capable. Where it's not supported by a given user's device, the content delivery reverts to Plan A - some reduction in bandwidth costs is definitely better than nothing.

Now, it's one thing doing all this on a small scale and demonstrating it at WebRTC conferences. It's quite another building it into a service that competes meaningfully with the likes of Akamai, which have global footprints, established salesforces and customer relationships, and many other value-added services - and also a fearsome army of IPR lawyers and an arsenal of patents. 

Yahoo!, for all its problems, is at least in the category of companies that can play those games - or else perhaps it may prefer to use the technology internally, rather than exposing it as a 3rd party service. Various commentators have suggested it might speed up its notoriously laggy webmail, but I don't think that's the key application here, as little content is shared between users. It's also possible that the CDN project will get lost in the background, with Yahoo! actually just buying the three engineering innovators behind the work, for more general development on WebRTC.

As for DataChannel, this is one more signal that it's perhaps even more important and disruptive than the voice and video bits of WebRTC. We've already seen it used for various types of screen-sharing, Google's Chromecast dongle and a few other early attempts. If the CDN use-case proves properly commercialisable by Yahoo/PeerCDN or others, then it's another landmark.

Other use-cases for DataChannel are also being widely talked about - certainly app/screen-sharing will be a major (if unspectacular) one, most likely bolted onto conferencing and UC solutions. But the real "fun stuff" will occur when it enables realtime data streaming for things like sensors, Internet-of-Things objects, health monitoring and so forth. Let's see what happens - but I have a feeling that we'll get a lot more than just yet another "Skype in the Browser" clone from DataChannel. 

This is also an area that telcos should pay attention to - well away from the ongoing IMS/WebRTC integration for VoLTE or anything else. I've said for a while that WebRTC needs to be dispersed across multiple business units in operators, and not just left to the voice/core-networks group. Opportunities for exploiting WebRTC DataChannel should be high on the priority lists of the CDN group, content/video optimisation, M2M, healthcare & other verticals, devices and numerous other telco business units. If operators don't get going on this immediately - at least in the labs or other skunkworks - then who knows what other 3-person startups will create independently.

Overall, I think this acquisition is a very interesting move. It marks the first overt buyout of a WebRTC player by a Silicon Valley behemoth (Telefonica/Tokbox was something else). That could trigger more VC attention, as well as focus attention on whether Google or Apple or Facebook or LinkedIn also start spending money on the next stage of the web. It's also a wakeup call for all those in the WebRTC community who forget that data is often at least as important as voice or video.


Interested in reading more analysis & comment about WebRTC? I am the only analyst who has done a full, cross-sector research report, covering all major use-cases, with conclusions and forecasts updated regularly. Click here for details of the Disruptive Analysis WebRTC report & update subscription.

The beginning of the end for IMS. WebRTC is the catalyst

I've been skeptical about IMS - especially in mobile - for a long time. But while I'm wary of confirmation bias, recent events mean that I am now confident the telecoms industry is internally recognising IMS's limits. Over time its relevance will dwindle, although conservatism and forced-need will give it some residual short-term momentum.

I started writing about IMS in 2005 and published a report in mid-2006 pointing out that nobody had bothered defining what an IMS-capable handset was, and that as a result it would be at least 2010 before commercial massmarket mobile IMS services were likely. Clearly, that was an over-optimistic view, as it's now the end of 2013, and probably less than 0.5% of handsets are properly IMS-capable, and a much smaller % of customers actually use the services.

Since 2006, my stance on the technology has hardened, especially with the ongoing farce that is RCS/joyn. While basic IMS platforms make some sense for replacing 40-year old fixed networks' switches with circuit telephony-equivalent VoIP for opex saving, the same does not apply in mobile, where new and cost-optimised circuit cores are a long way from the ends of their depreciation cycles.

There is not a single service that IMS can do that other platforms cannot - typically with greater flexibility, lower cost and much faster time-to-market. Furthermore, IMS's developer base is woefully small, while telco CFOs view investing in it - at absolute best - as a necessary evil. Its current role seems to be for operators that have painted themselves into a corner on VoLTE, where they can't spare the spectrum to maintain CSFB or SV-LTE any more. A few have drunk the RCS koolaid, but even there, outsourcing or cloud platforms means that little internal investment in IMS platforms is needed for a minor experimentation or deployment. A handful of stalwarts still seem evangelical, much to the skepticism of other operators - and often many of their own staff in other departments as well.

In 2009, I light-heartedly mused whether the mobile industry had essentially "nailed the dead parrot of IMS to the perch of LTE" - ie tried to tie the standards so closely together that operators would be forced to deploy IMS anyway, despite it being a dead & moribund platform for innovation. (If you're a Monty Python fan, have a laugh at my fairly notorious blog post closely referencing the famous sketch). 

It seems I may have been prescient. This weekend marked the 4th anniversary of the first LTE launch, and yet only a handful of operators have deployed VoLTE in the wild - conspicuously not including TeliaSonera, whose 2009 network set the 4G ball rolling (Norwegian VoLTE is as rare as Norwegian Blue parrots, it seems). 

The South Koreans have it running, as does MetroPCS in some areas, although its new owners T-Mobile are more equivocal about deployment schedules elsewhere. O2 Germany has it "at a few base stations" (ie a face-saving press release) and two HK operators have made announcements of imminent launch. Only this week, UK LTE operator EE said it would "trial" VoLTE in 2014. This fits with my oft-stated summary that:

"VoLTE was the right idea but 5 years too late; RCS was a stupid idea to begin with". 

VoLTE has been plagued by myriad complexities, such as the SR-VCC handover to 2G/3G, the need for full coverage (& often small cells and fibre backhaul) to support it, innumerable integration issues, and perhaps above all the basic economic costs of the IMS platform and devices/clients needed to make it work. In many countries, voice telephony revenues are already flat or declining - which makes investment in a complex new platform, for a potentially declining service, a difficult business case to justify. Add in uncertain support from Apple and the need for a Grade-A network including indoor coverage, and the argument looks weaker still.

Even in the fixed telecoms world, there is very little non-telephony use of IMS. Network-based videoconferencing, enterprise unified comms, IM and a handful of other services are deployed but little-used. In most instances, telcos resell non-IMS third-party conferencing or UC solutions instead, while far more have partnered with Internet/app companies like Whatsapp than have launched RCS.

IMS has increasingly been made obsolete - both for applications and as a control-plane solution - as a concept by:

• Widespread use by billions of people of the open Internet
• Wide availability of fast fixed and mobile broadband, allowing third-party VoIP and video services to emerge at low cost, offering free/cheap services
• User behaviour indicating that "quality of service" only matters some of the time, and that often quality is easily ignored if the price is right/zero
• User behaviour indicating that "islands" are often seen as more valuable than interoperable standardised services, for many use cases. "Walled gardens" are fine as long as the users are themselves willingly climbing in over the walls
• Smartphones, initially from Nokia but now Apple & Samsung have made it easy for alternative communications applications to be accessed and installed. Apple has some of its own, in particular.
• Hopeless timescales for IMS standards development, especially for applications. The committee-led bureacracy of RCS, with lengthy monthly/annual cycles, has to compete with app players that can make decisions on new features in an afternoon, and deploy them the week after.
• The most vibrant telecom service domains are largely outside of IMS's grasp - content, IPTV, cloud SaaS, hosting, vertical initiatives and so forth. Conversely, "session-type" communications such as telephony and SMS/IM are declining in revenue (and often, relevance).
• The low relevance (and or focus) placed on IMS by telcos' Digital Services groups - whether they are doing Telco-OTT VoIP, content/entertainment offers, or vertical services for healthcare, transport, energy and so forth.
• The need for telcos to accept multiple identity models rather than key everything to phone numbers and subscriptions
• Wide use of 3rd party WiFi on mobile devices, meaning that centralised policy-control is mostly irrelevant, while operator-managed services need to work over generic connections as well as "on-net". If services are used OTT-style some of the time, then why not all of the time?

Yet despite all this, there is still a huge part of the telco and vendor community that doggedly sticks to the view that IMS's time will come. That VoLTE and RCS, and maybe some lipstick-on-a-pig API exposure layered on top, will lead to its rightful and "ubiquitous" implementation across all operators. That fully-interoperable, QoS-managed, access-integrated communications services of the future will be based upon it.

The reason for this is simple: it is standardised, and "therefore" it is the only choice. A generation or two of telecoms engineers and architects have been brainwashed into believing that standardisation is essential, innovation is done by vendors/committees, and "interoperability" at a service level is paramount - and transcends "minor" issues like user preferences, wants and needs. Now clearly, certain aspects of interop are essential - notably in the radio network to make sure that device A works with network element B - but for actual end-user services, interop is only needed for basic lowest-common denominator offers. (See here for an earlier blog post on the limits of interoperability)

In other words, the reason that IMS has been grinding on for so long - despite its limitations being obvious, and numerous "refugees" publicly denouncing it - is because the telecoms establishment can't bring itself to admit that it got the last decade so spectacularly wrong. This is understandable - it's a well-known psychological syndrome called the Endowment Effect which means you tend to like what you already have, more than is reasonable or logical. People have invested a lot of time and money in IMS - careers, even - and are reluctant to acknowledge that it's been mostly wasted. 

We also tend to have another cognitive tendency to defend our own belief systems, in spite of overwhelming evidence that they're flawed. There is even a neuroscientific reason for pushing back against the blindingly obvious, to the extent of even lashing out at it - our brains are programmed not to change complete frameworks of perception.

Which is why last week's WebRTC conference marked a turning point for me. Parts of the "establishment" are now shifting. Most notably, the term "Post-IMS world" was used by a senior operator labs representative from Portugal Telecom, as well as another from Orange showing slides with IMS potentially being an add-on to a WebRTC-centric domain, and not vice-versa. IMS is still there, but it is relegated to the same sort of "legacy interop" category as the PSTN. In other words, IMS will be about for a while, but will decline in importance, and certainly will not be where the innovation or new revenue happens. (PT has been working with Deutsche Telekom on an experimental WebRTC platform called WONDER, standing for "Webrtc interOperability tested in coNtradictive DEployment scenaRios").  

Now at the moment, these noises are coming more from the Labs and CTO offices of operators, not the architects deploying today's infrastructure. I'm sure that all those operators have IMS loyalists as well, but open dissent is often necessary before a coup. These are experiments and ideas about the future. Nevertheless, they represent an important sign that the mindset is shifting. As per the title of this post - it's the beginning of the end, not the death knell quite yet.

Perhaps more significant was a vendor speaker who is also on the 3GPP project to integrate WebRTC and IMS. Some of this was about straightforward gateway specifications & timelines, but other aspects of it seemed similar to the WebRTC-first world-view espoused by PT and Orange. There is tacit recognition that services will often be anchored primarily on the web (or enterprises' IT), but will sometimes need to interact with PSTN/IMS as a secondary role. This is a first in my view - the 3GPP acknowledging that some communications services, deployed or sold by telcos, may not be IMS-based in the future. We all know it's true - many Telco-OTT propositions are built oustide the reach of IMS - but it's rare to get "official" statements recognising it.

One other thing was around authentication and access to telcos' WebRTC services. Obviously, many vendors and some operators want to re-use the phone number, SIM credentials and so on. This makes sense for certain use cases, although the phone number remains totally inappropriate for most such instances on the web, where users may be anonymous, temporary users, "guests" and so on, rather than "subscribers". One of the possible items for the second version of the 3GPP standard is called "large-scale 3rd party access". As the event chair, I challenged the speaker to define that more clearly - I asked "Is that a euphemism for 'log on with Facebook'?". The answer? An unequivocal, one-word response: "Yes". Again, that to me is a landmark of realism from 3GPP.

The brutal truth is that many telcos will keep banging their heads on the IMS wall, because they do not have the resources or vision to see beyond standards, even if they are clunky, expensive or obsolete. Then, they will complain about more-nimble Internet competition. Some will set up Digital Services groups to build their own equivalents, or partner with Internet/app winners. But others will continue down the blind alley regardless. Having the 3GPP at least acknowledge the existence of IMS alternatives is a good start, although not enough. More clear-thinkers willing to challenge entrenched legacy viewpoints in Labs and CTO Offices is also needed - perhaps a tough task in some of the more stubborn operators like Vodafone and AT&T, which are still doggedly trying to push legacy-IMS into the 21st century.

I'd say that there is a strong argument that investors, CEOs and boards need to fire those responsible for wasting time and money on an unworkable technology. Those who have abdicated the responsibility for platform innovation to vendors and standards groups have squandered 10 years, versus the Internet players. I can't recall the last time a telecoms CTO was fired for making a poor technology choice - because usually the "choice" isn't theirs to make - it's predefined by a group of people who never talk to end-customers or developers. I still meet people saying "Ah, but you can't send a message from Facebook to LinkedIn, or a make a video call from Skype to Facetime"

My view is that IMS is reaching its zenith. It still has some brief upward momentum left - but the rockets have run out of fuel, and gravity is starting to pull it back. Whether it has reached a stable orbit, or will break up on re-entry is unclear. Some more VoLTE deployments will probably keep vendors happy in 2014 and 2015, although it is abundantly clear that it will not be the "default" telephony solution of the future. I'd be surprised if VoLTE ever gets beyond 10% penetration of the global mobile user base, given everything else that is going on with communications and voice and the moment. RCS will struggle to gain active use by 2%, I'd expect, and most likely much lower. The API argument for IMS/VoLTE/RCS is also pretty ugly, especially as IMS-capable device penetration will never get to the "ubiquity" that evangelists are promising. Again, there may be some exceptions, but the bottom line remains that IMS is providing the wrong "raw ingredients" for many use-cases, so exposing them via APIs won't help, except for some niches. It's also possible that some countries will become "IMS islands" because of local specific issues - China, perhaps.

But I expect that many operators will simply decide to avoid IMS entirely, or deploy a bare minimum for roamers and a couple of point features. Even open-source efforts like Metaswitch's Project Clearwater won't change the end-game. Lower infrastructure costs are good news, but the lack of developer enthusiasm - and the dependence on the same tired legacy interop model - is a major limiting factor. That said, helping telcos to fail faster and more cheaply is at least in line with the Internet/app ethos they'll need to learn anyway.

Overall, we're now at the beginning of the end for IMS as an application platform, while its control-layer aspects are also a poor fit with coming network realities and user behaviour. It won't go quickly, but then neither did fax or telex. 

The parrot is still nailed to the perch. But it's still dead.

(If this topic is of interest, please contact information AT disruptive-analysis DOT com for details of workshops, speaking engagements, consulting projects & published research. Or click here for details of Disruptive Analysis' WebRTC report  & update subscriptions)

Many telcos' service innovation & partnering strategies are held back by internal processes

This year I've spent a lot of time with operators around the world. Some of this has been at public workshops such as those I co-run with Martin Geddes, while other engagements have been private strategy sessions about the future of voice, WebRTC or Telco-OTT/service innovation, either solo or with a range of other partners. In addition, I've also sold many operators my research reports and other services, and attended numerous exec-level telecom events like ITU World and ICIN.

Unlike a lot of larger consulting businesses, or major analyst houses, this exposes me directly to an important factor for future success:

How easy is it to do business with a telco, especially as a small company?

As I run most of Disruptive Analysis' administration myself, I am acutely aware of some of the practical issues that others don't see. Top of my list is how easy it is to get paid by a company - how procurement, invoicing and remittance of funds works. More on that below. I also get to see:

• How companies act in terms of internal silos and fiefdoms, with different groups either not communicating, or actively competing and undermining each other.
• How hard it is getting meetings set up - and whether they are useful, productive meetings or an exercise in politics
• Whether "not invented here" syndrome still exists, inhibiting new services and ideas
• The relative power of "conservative" groups vs. the innovators. (Try suggesting the phrase "open source" and watch what happens)
• The lack of willingness to take shots at "sacred cows" and question assumptions - the need for, and value of, QoS is a good one here.
• How few people are focused on the real needs and wants of consumers. Forget all the fancy stuff about having behavioural psychologists and UX specialists - many operators don't even have have product managers for voice telephony.
• Inability to think critically about vendor marketing and hype. I regularly get pitches regurgitated straight back at me.
• Institutionalised need for adding unnecessary process steps. I've recently been asked to write a short 2-page article on a topic I know well. No, it doesn't need a 5-stage effort submitting a draft of the "flow", having conference calls & iterating repeatedly.
• Omni-present shadow of (very slow) legal processes. Yes, telcos are big regulated companies and need to be aware of the fine print. But that doesn't mean that every tiny detail & contract needs to be re-written - often at an internal cost greater than the amount I'm actually getting paid. Be pragmatic, already.
• Technology-related issues such as vendor selection processes.

Often, operators want to talk to me about partnering, or developing new applications and services. Frequently, the conversation turns to attracting web or mobile developers, creating and marketing own-brand Telco-OTT apps, or partnering with existing Internet/OTT players.

But while all this is very worthy, it is often critically dependent on those operators interacting with small firms, often acting as suppliers. They might be individual web developers, small consultancies helping with user-interface design, startups with a cool product that could be added to a telco's bundle for certain segments and so forth.

Companies that telcos might want to do business with are getting smaller. Whatsapp - with 300m+ users - has about 50 employees. Many "established" WebRTC players have fewer than 10 staff. Tsahi Levent-Levi had a great post on this a couple of months ago - it needs about 4 developers to make a decent WebRTC service. That, for example, a telco might scout and decide was a really neat differentiator and cool to resell as an innovative option for their "enthusiast" users, perhaps. 

Same deal for various new forms of infrastructure equipment or software - NFV/SDN startups perhaps, or firms with a clever idea for a value-added voice app. Maybe a next-gen billing system suitable for digital services, based on users rather than subscribers.

You get the idea. While a lot of innovation does come out of big players like Ericsson & Huawei & NSN & Oracle & IBM and their peers, increasingly telcos need to go back to be able to deal with small companies too. Especially developers, both telco-centric specialists and "long tail" software houses for web and mobile.

Yet for most telcos, doing business with small companies is beneath their radar, because the COO and CFO don't really think about these issues - they are struggling with minimising internal costs, maximising internal process efficiency, and perhaps outsourcing "non-core" functions. The knock-on impacts of this on areas such as innovation capability, or business agility, or flexible partnering, don't see much influence.

A specific example is top-of-mind for me. For many operators, procurement is fundamentally broken. It is bureaucratic, slow, and based on the assumption that telcos have a few long-standing vendor partnerships, with companies with teams of lawyers and form-fillers.

I've now faced the following "process" several times:

a) Inquiry from an operator asking about Disruptive Analysis products/services
b) Have a conference call, write a proposal, negotiate, agree the work
c) Have a call/email about logistics & practicalities - travel, location & format, and whether I need to get started on any paperwork upfront. 
d) "Oh no, just send me the invoice, I'll make sure it gets paid promptly"
e) A month or so later, do the workshop or seminar or present the project's conclusions
f) Submit invoice/expenses
g) A week later get an email from purchasing/finance "You need to fill in this form to apply to be on the supplier database". Something that could have occurred a month earlier.
h) Look at form. It asks for every conceivable piece of information, from certificates of incorporation, to bank statements, to shareholder names & details. I've got one in front of me that wants to know full details of any overdraft or loan facilities offered by my bank to my company. And the square footage of my factories and offices. Oh, and it needs an official company stamp (What?) & to be submitted by mail/courier.
i) Read the covering email. I missed the other form asking for a registration fee. Yes, that's right - they want me to pay them money, so they can pay me. Somewhere between a joke and an insult. This has now happened several times.
j) I go back to my client and raise hell. Luckily, as a reasonably-visible analyst I can wield a little influence when necessary, even without having to descend to threats of naming-and-shaming
k) Maybe there's a back door somewhere. A way to expedite invoicing and payment for "exceptions" that just need to get sorted. Go up high enough in the organisation and you can pull some strings. This may still need a shorter form, and a still-onerous purchase-order registration process though.
l) Chase up for actual payment, or suffer 60/90/120-day payment cycles.

This nonsense needs to stop. In the words of one of my colleagues/partners, "Someone in procurement needs to be fired".

Not just because it's a pain for me, but because it's even more of a pain for the companies that operators NEED to work with, if they're going to innovate and partner/develop new services. Honestly - the process tends to be worse for those telcos that don't have in-house resources like software development, and that critically need to work with small and flexible external shops to get things done.

The sad thing is that I'm seeing telcos who are doing the right things - setting up innovation teams, building digital or OTT services, going out and meeting Internet players or content firms to cut deals. But all that risks being window-dressing, if those same "partners" get as far as the internal business processes, take one look and walk away. Or worse, do work, fail to get paid easily and promptly, and suffer cashflow problems as a result. They won't be working with that operator ever again.

(Incidentally, I'd say that some vendors are almost as bad as the operators. But they often do have multiple systems because they're more used to dealing with local contractors, software specialists and so forth).

So if you're a CFO/COO/strategy head - put yourself in the shoes of a small company trying to do business with your organisation, and see how bad or easy it is. Then try the same, signing up to become an Amazon Affiliate, or eBay Seller, or using Google Adsense. Getting paid by Internet companies (or indeed, paying them) is easy. This is why I now prefer to sell reports by credit-card online. I mentally wince whenever someone says "you need to be on the supplier system" just to buy a report.

It's not just the procurement aspects either - it's the long list above.

This is why telcos seriously need to consider setting up fully autonomous new business units to deal with digital and Internet services. And executives need to empower them to ignore all the stupid forms and rules that the mothership clings to. Just as right-thinking "vanguard" telco units are disintermediating their own core network platforms, they need to bin as many of the useless, innovation-inhibiting processes too and start from the ground-up, with agility and flexibility in mind. 

Never mind a decade of MBA-addled nonsense from big-name so-called "strategy consultants"  about how telcos should reducing their number of suppliers. That might be true if you're building huge radio networks (& even then I'd argue it's flawed). It's certainly not applicable to service creation, developer engagement and true innovation in a fragmented, fast-paced Internet world. There, having more and smaller partners and suppliers is essential to survival. Make sure you're not putting them off.

Telcos' digital services/OTT businesses make Net Neutrality more important than ever

Telcos actually need Net Neutrality to survive & thrive, even though some don't realise it.

The current US & European softening of regulatory stance about "managed services" and Net Neutrality potentially hands suicide pills to operators, who mistake them for candy.

The problem is that some telco executives - and most of their lobbyists and industry associations - are still living in the past, and haven't actually caught up with the realities of creating and delivering new services, working with customers' preferred behaviour, and interacting with the innovators and developers of tomorrow's propositions. 

In addition, many are being influenced by vendors still pushing an assortment of unworkable plans around "personalisation", "smart pipes", "differentiated QoS", "1-800 models", "sender-pays content delivery" and assorted other policy paraphernalia and "useless-cases". I've been in meetings listening to telco network folk regurgitate tired marketing slogans about "turbo boosts" and "monetising OTT services" recently and had to do urgent remedial re-education on the realities of what's actually feasible.

Until now, Net Neutrality (in some markets) or at least the threat of regulatory intervention, has acted as a safety valve protecting telcos from themselves. 

The problem is that some of the regulators are also living in the past, and there is a danger that they'll buy into some of the nonsense. Part of the issue is that many of the advocates of Net Neutrality are also from another planet, arguing from silly positions like free speech and sinister conspiracies. 

There's a new commissioner at the FCC, while the EU position espoused by Neelie Kroes is seen by many to have caved-in to the requests of the telecoms incumbents wanting to provide managed services. The FCC chair appears to have read a 2008-era report on two-sided business models (yes, I know I wrote about it around then too - one of my worse calls) and seems to think they can be workably applied to broadband. The usual "Netflix will pay for a fast lane" wishful thinking is being wheeled out again. The Devil is in the details, but this article from TelecomTV suggests that the cut-and-dried Neutrality stance is unlikely to succeed. (And that's even before the baffling US legal system finishes its wrangling with the previous FCC rules).

The truth is that almost all non-Neutral Internet models are unworkable. Rather than abdicating their role as consumer advocates and saying "no rules should stand in the way of new business models", regulatory authorities should treat telcos pitching non-neutrality as if they were exhibiting suicidal tendencies, and take measures to prevent them from harming themselves their customers, and cherished national broadband/economic objectives.

Yes, I know there are some isolated non-neutral examples like zero-rating, throttling of P2P, or national blocks on specific services, but by and large these remain in the spirit of the general perceived openness of the Internet. There are also a handful of emerging-market prepaid mobile data plans that try to offer app-by-app/site-by-site pricing, which are often aimed at featurephone users with very low ARPUs and equally low expectations of what the Internet offers.

But the oft-repeated "Internet fast lane" falls down on many grounds, much of which will end up with telcos ending up worse off than before, rather than foiling the dastardly customer-driven succss of Internet application and service companies.

The most obvious gotcha here is that the majority of non-neutral models (and proposed rules) are completely in contradiction to the recent, welcome trend of telcos to develop their own OTT/Internet-style applications, services, enhancements and enablers. Numerous telcos now have OTT communications or content units, offering everything from video streaming to VoIP to developer platforms. Several now have Telco-OTT messaging apps, cloud propositions and so on, as I predicted in my 2012 report. Sometimes these are "standalone OTT", while others are extensions of existing on-net services for users wanting access via WiFi, or devices running on other providers' connections. Even standardised failures like RCS/joyn now have OTT-extension capabilities over generic Internet access.

Ending Net Neutrality would kill these and many other promising service initiatives stone dead. In discussions with these groups, I have come across nobody who has even considered asking other telcos or ISPs for help in prioritising traffic. Most haven't even looked into QoS/priority for the times when users are actually their own access subscribers, on their own networks. There are numerous reasons for this, but chief among them is that these separate units or product people are usually staffed by Internet people, for whom this entire thing is an alien prospect.

There's a broad set of other reasons to consider sweeping changes to Net Neutrality law being actively suicidal for telecom operators. Potential unintended consequences include:

• Lots of expenditure on DPI/policy infrastructure & use-cases that don't actually work as well as vendors make out, given the constant shapeshifting of the application space
• Loss of focus on things that customers actually want (cool new services, whether in-house or re-sold/partnered) vs. stuff they don't (attempts to sell them half the Internet rather than the whole thing)
• Probability that regulators will insist that non-neutral offers are made on a non-discriminatory basis, ie to anyone who requests them. Should be fun when Skype, competing telcos or adult content firms get in touch.
• Hideous nightmare of OSS/BSS integration to put in systems to monitor all of the new non-neutral stuff, bill for it, support it and so forth.
• Numerous ways to game the system, either legitimately or fraudulently. I can think of plenty just off the top of my head (feel free to ask for a workshop for ideas!)
• Probability that non-neutrality will cut both ways, with powerful companies like Netflix, Google and Facebook instead charging telcos for access to their servers/features rather than money flow going to the ISPs. Want your subscriber to get HD? How about avoiding the 10 second delay on search that gets implemented on your new shiny non-neutral network? Pay up. It'll soon be obvious who wields the real consumer power to force churn.
• Likelihood of new OS's moving to default-on hard encryption for all IP traffic. Good luck picking out and prioritising traffic when that happens.
• Web mashups making a mockery of what gets accelerated / prioritised
• All sorts of entertaining corner-cases with radio networks, eg working out how to balance the needs of a Gold customer with a Platinum application at the edge of a cell's coverage, versus a 100 Bronze users using a Gold application next to the base station.
• Proliferation of "how neutral is your ISP?" traffic-light reporting schemes. Some regulators already offer these.
• Incentivising application developers and device/OS supplies to push users to open, 3rd-party WiFi wherever possible
• Embarrassing and easy comparisons between "prioritised" traffic on-net, versus potentially better performance on other unmanaged networks. Will a refund mechanism be in place for unnecessarily paid QoS?
• Huge scope for cost and lousy execution around the sales and marketing of non-Neutral Internet services.
• The risk that lots of money gets spent, lots of time & management effort wasted and diverted from real value-added services, and then any (massively politicised) laws get changed 15 minutes after the next set of elections.

Yes, there are some isolated examples where this might work. Enterprise cloud services for home-workers on fixed broadband. In fact in general, it's easier to see non-Neutrality apply to the fixed/cable network where there's a much clearer distinction between Internet and non-Internet broadband services anyway - plus it's possible to use a second physical or logical connection to ringfence the two. But these are small niches, which don't warrant the huge moral hazards of risking the general "open Internet" principle which is the only thing driving 2+ billion people to buy data access. 

It would probably be worth governments sponsoring second broadband lines to support some of the other services, rather than caving in to the illogical and dangerous "multi-service" rhetoric from some pundits who spend too much time perfecting mathematics, rather than customer and economic needs.

Overall, the current swing back away from Net Neutrality looks as if years of lobbying has born fruit. Unfortunately, the lobbyists' and protagonists arguments are now years out of date with reality. Most non-neutral business models are not just irrelevant, they are actively harmful to the telecoms industry at precisely the point it needs to focus on service innovation, not pointless network tinkering. It will lead to greater loss of money for operators, and ultimately faster consolidation and poor outcomes for the consumer.

You get the picture. Basically, out in non-Neutral Internetland there are lots of bear-traps. And lots of bears. Be careful what you wish for. Regulators should be acting as rangers, rather than encouraging naive telcos to go blundering about in the "polyservice" forest.

Updated WebRTC forecasts + new analysis of browser vs. non-browser uptake

I saw someone on Twitter post the other day that we are currently at "Peak Telco Conference". Last week & next week have an extraordinary number of clashing events, around the world. One interesting thing I'm noticing is how many seem to be adding in a session or couple of presenters on WebRTC, which is fast becoming the "topic du jour" across telecoms overall.

Unfortunately, these clashes mean I won't be with my familiar crew at the WebRTC Conference in Santa Clara, for their 3rd event, although I'll be watching the Twitter feed with avid interest! Instead I am at the ITU World & TADS Summit conferences in Bangkok in Thailand. 

I'm doing a workshop at ITU on Future of Voice (notably WebRTC & Hypervoice) along with regular conspirator Martin Geddes, as well as moderating what should be a lively panel on Telcos vs. OTT, in front of an audience of telecoms ministers & regulators. Friend Andy Abramson is on the panel, and is threatening to be even more disruptive then me.

At TADS, I'm doing a session on WebRTC (unsurprisingly), and then joining a panel of luminaries (including Martin again) about the Future of Voice.

So, in order to keep afloat in the inevitable media storm about WebRTC and telecoms over the next week, I thought I'd put out a quantitative blog post, updating some headline numbers and drilling down on how the WebRTC marketplace may evolve over the next few years. The figures come from the most recent update of my WebRTC research - subscribers got their 30 pages of new analysis about a month ago. (I know that quite a lot of people use my already in their presentations & press releases - feel free to ping me if you need updates).

• Overall device support for WebRTC at end-2016 now predicted at 4.2bn, up from 3.9bn in previous forecasts
• Addition of new category of devices (beyond PCs, smartphones & tablets) to account for embedded-WebRTC products such as TV dongles, in-vehicle systems, M2M etc
• Active individual user-base of 1.6bn people, with around an average of 2 devices each, using WebRTC by end-2016. This equates to roughly 50% of the expected Internet user base at that time.
• Over 3bn devices will support the use of WebRTC outside the browser by end-2016. This is a critical understanding, as it fundamentally alters the way the technology will be perceived.
• WebRTC is already live in a variety of commercial use-cases, ranging from contact centres to online interviews.
• Sudden adoption of WebRTC by a major OTT player such as Twitter, LinkedIn or Facebook could lead to a rapid (almost overnight) acceleration of adoption beyond the forecasts. Thus far, we haven't seen this happen, but it could be a major catalyst, especially in conjunction with non-browser mobile WebRTC (see below). A "background" use of realtime data-streaming (eg for CDNs) could do the same, especially if hooked into one or more of the major browsers without user intervention.

Various new services are employing WebRTC "in spirit" even if the technology is not 100% identical to the (proposed) standards. This doesn't matter in many ways - innovations like Amazon Mayday (customer support) or Google Helpouts (expert interview platform), point to the underlying democratisation of voice and video outside the traditional "phone call" model. In many ways the strict technology enablers are irrelevant except academically - the bottom line is more forms of communication, developed more easily and cheaply by web, corporate, mobile & telco app developers.

Perhaps the most important output of the new analysis is this: overall from late-2015 onwards, the number of non-browser WebRTC-supporting devices will grow above 50% of the total across all device categories (ie including PCs). The majority will have both access mechanisms. For smartphones, browsers will not be the main way that users discover and use WebRTC.

It is important to explain what "non-browser WebRTC" consists of, as it is only really starting to be discussed now. There is growing evidence that WebRTC is moving (on mobile) from browser towards app implementations, either though:

•  “Hardcore” development by specialists, directly using the RTCWeb and so-called "RAI2.0" stack of protocols and codecs which underpin WebRTC, built directly into apps. The forecasts include use of the media engine & firewall traversal & encryption components, even where there the “official” WebRTC Javascript APIs aren’t used. An early example is Vonage's mobile app, which incorporates a lot of WebRTC's underlying nuts & bolts.
• Use of 3^rd-party client APIs and SDKs, which give a more rounded and accessible set of capabilities to developers than “raw” WebRTC JS APIs, especially when applied to standalone apps. Examples here include Tokbox, Crocodile, Twilio, Tropo and many others. There may well be extra server-side APIs used for various functions as well. 
• As yet, we haven’t seen WebRTC APIs appear directly in device OS’s, although there are rumours that Android may soon start to support them, while Firefox OS is clearly on a similar trajectory. Disruptive Analysis expects this model of WebRTC to become a reality over the next 1-2 years - and we may even see Apple joining in at some point. (Sidenote: Facetime appears to use a lot of the same underlying technologies as WebRTC)
• Devices such as Google Chromecast do not have screens, and therefore do not have normal browsers. They may still enable some form of WebRTC capability (even if just data-streaming) however. 

Overall, these trends have much more impact on the WebRTC market than the wrangling over codecs, or even the offer-answer/SDP debate. What is happening is that there is now sufficient critical mass of effective, open-source or commercial enablers, that WebRTC or WebRTC-like development is taking on a life of its own. If the official, browser-based standard still faces a lot of arguments..... well, the dirty secret is that it doesn't matter, unless you're someone form whom native apps vs. web is a religious argument you feel evangelical about.

If you would like to get access to the new forecasts, and indeed the original Disruptive Analysis WebRTC report, details about purchase are available on this page. (Note: my travel schedule may mean it takes slightly longer to get content out to customers).

I'll also be at the December WebRTC event in Paris, so I hope to catch up with everyone there.

Mobile data traffic - some quick thoughts on Ericsson's latest update

Ericsson has just published the November edition of its Mobility Report.

I'm just going through a couple of stand-out items, especially about mobile data traffic. There's some good stuff about subscription growth, "app coverage" and small cells, but that's for another post.

Ericsson reckons that global mobile data traffic grew 10% quarterly between Q2 and Q3 2013, and 80% from Q3'12 to  Q3'13. The chart seems to suggest the beginnings of an S-curve tail-off in growth - the previous June report suggested 19% growth quarterly Q4'12-Q1'13, and the chart suggests c15% for Q1-Q2. The February report cited 28% quarterly growth for Q3-Q4'12. That said, the growth rates are quite "lumpy", although the last quarter showed the slowest growth in 2 years by a considerable margin.

Quarterly Mobile data traffic growth from previous Ericsson Mobility reports
Q4'11-Q1'12 = 19%
Q1'12-Q2'12 = 14%
Q2'12-Q3'12 = c20% (read from chart)
Q3'12-Q4'12 = 28%
Q4'12-Q1'13 = 19%
Q1'13-Q2'13 = c15% (read from chart)
Q2'13-Q3'13 = 10%

Overall, the global forecast is for a CAGR of 45% mobile data traffic growth between 2013 and 2019, with much greater traffic growth from smartphones, and comparative stagnation of mobile PC dongles, MiFis and the like. That's a slightly more realistic forecast than others have predicted, but I still think it's a too top-heavy, given the S-curve effect (ie quarterly growth has fallen from 28% to 10% in less than a year).

This forecast compares with Ericsson's earlier 50% CAGR for 2012-2018 - but in the June report, it said it expected 2012-13 growth to "continue doubling", which when calculated through implied the remaining 2013-2018 period to have CAGR of only 41%. It's possible that the shift to LTE (which often comes with bigger data buckets in plans) might drive a "double-S", but there's limited evidence of that so far.

My main problem with the analysis, is that the chart on page 11 suggests that smartphone mobile data subscriptions will triple between 2013 and 2019, and that average usage will simultaneously grow about 3.5x. I think that is unsupportable, as the next 3 billion smartphone users will be late adopters, often in low-ARPU markets with parsimonious data plans (or more likely, sporadic prepay top-ups). It suggests that smartphone user #5 billion, coming online in 2018, will instantly be using gigabytes per month from Day 1, unless user #1 billion is using about 20GB/month by then to skew the averages. In almost all maturing sectors, the laggards & late-adopters tends to be low, casual users. This suggests that Ericsson's forecasts are over-cooking things substantially.

Ericsson puts 2013 mobile data traffic as 35% video, and is predicting that to go to 50% in 2019. But interestingly, Cisco VNI had video at 50% in 2012 and forecast 66% by 2017. To my mind, that's partly because "video" is a useless concept bundling in hundreds of arbitrary and different elements - streaming, downloads, uploads, 2-way communications and so on, not to mention mashups (is Vine a video application, or social? How about sharing videos on Facebook?)

There is little mention in the report of the increasing use of (non-operator) WiFi on smartphones, which is up to 80% of total device use in some countries, even excluding WiFi-only tablets. There are a couple of mentions of "WiFi offload" being excluded, but as offload is probably (at most) 20% of total smartphone WiFi compared to private incremental non-offloaded use, that suggests that the numbers have very significant downside sensitivity, as free amenity WiFi proliferates around the world. Even in developing markets, it is common to have free WiFi in various public locations such as cafes, and savvy price-conscious users can be expected to exploit this, rather than paying for dataplans or prepay data credit where possible. In some countries, WiFi use is also increased by the risk of smartphone theft if the devices are used openly in the street - instead, people use their phones mostly indoors, in more secure (and WiFi-rich) environments.

Taken together, I'd say that Ericsson's numbers are starting to fall into the realm of sanity (unlike the continued breathless "exponential" hyperbole I heat in many presentations), but the forecasts are still too optimistic, given what we're seeing with both typical data allowances, and WiFi use. I haven't done a full analysis, but I suspect that a global mobile data traffic CAGR in the range 35-40% for 2013-2019 would be much more realistic, translating to perhaps 30-35% in developed markets and 40-50% in developing.

VP8 acceleration hits the mobile phone in time for IETF88

Following on from Cisco's open-sourcing pitch for promoting H.264 in the big WebRTC codec debate, it's now Google's turn to turn up the dial on VP8. [My take on Cisco's move is here]

One of the biggest stumbling-blocks cited for VP8 so far has been the lack of any mobile optimisations - specifically hardware acceleration in smartphones or tablets, necessary to avoid battery-sapping processing for VP8 video done in software.

But with what surely cannot be coincidental timing, Google has announced that its new LG-made Nexus 5 phone comes with - drum roll - hardware encoding/decoding for VP8.

According to this chart, it's a native feature of the chipset in the Nexus 5, which is based around a spanking-new 2.3GHz Qualcomm Snapdragon 800 as a CPU, and Adreno 330 GPU. This marks the first time that Qualcomm has appeared as clear enabler of WebRTC & VP8, as far as I'm aware.

The chart also points out that as well as the Snapdragon 800, there are also VP8-supporting chips that do encoding & decoding from nVidia, ST-Ericsson and Rockchip. But given its share of high-end phone chips, I've long believed that Qualcomm is something of a potential "kingmaker" when it comes to codecs and, ultimately, the ways in which WebRTC will manifest on mobile. If this is what it seems, then it is highly significant.


Other phones/tablets announced with the 800 include:
- Samsung W2014 dual-screen flip phone
- Samsung Note 12.2 tablet
- Samsung Galaxy S4 LTE+
- Sony Experia Z1S
- Asus Padfone Infinity

Overall, it looks like the usual mantra of "phones only support H.264" is now obsolete - especially as Apple is pretty stingy with providing access to its video acceleration APIs anyway.

WebRTC codecs & Cisco open-sourcing H.264

It's gearing up to be a busy week in WebRTC-land. In particular there's the 88th IETF meeting in Vancouver, and up for discussion and hopefully finalisation is the thorny issue of WebRTC mandatory video codec(s), with the main candidates being H.264 and VP8 this time around, but with H.265 and VP9 hoving into view in the near future as well.

Quite a lot has already been written on this topic, including by me in the October 2013 report update which has recently gone out to subscription clients, plus numerous other blogs and pundits, such as the guys at WebRTChacks who came out with a great post listing the various options last week.

But then a few days ago, Cisco Systems set the cat among the pigeons with its announcement it was open-sourcing its H.264 codec and paying the MPEG-LA royalties for anyone else who wants to use it, as long as it uses it in the form of Cisco's binary distribution. For those that want to use the Cisco source code to build their own binary however, there will remain a royalty liability. 

There's a ton of great analytical blog posts around already on Cisco's move, including by Tsahi, Chris Koehnke,  Dave Michels, WebRTCHacks and assorted great comments from Lawrence Byrd. 

I'm hoping to make some different points, especially about mobile WebRTC and non-browser implementations.

In my view WebRTC is inevitably going to divide along an important dimension:

• Use-cases that need interoperability with “other stuff” (eg existing videoconferencing, enterprise UC systems, telco SS7/IMS etc)
• Use-cases that are perfectly fine as standalone islands (eg a karaoke app, business walkie-talkie apps, or a customised video-chat service). Some of these will be P2P, but many will be server-based as well.

At present, it is hard to determine whether the future balance of importance & value is 20/80, 50/50 or 80/20 around interoperability vs standalone use-cases for WebRTC. It could go either way, and will be influenced partly by the way the industry and standards are set up in the near future. My view is that standalone uses will generally be more innovative (as is already being see with datachannel uses for WebRTC), but interoperable ones probably have easier near-term revenue pathways.

Clearly, Cisco would like to tip the balance of WebRTC towards the interop-rich use-cases, especially given its large installed base of H.264 (and also SIP) end-points. Cisco's open-sourcing move improves the ease of creating interoperability-based use cases, for example corporate videoconferencing systems extending out to browsers as additional end-points. It should be noted, however, that interoperability needs more than just codec similarity - a ton of other signalling and security issues will likely mean that gateways and SBCs are still essential, even if the theoretical transcoding burden is reduced.

However, interop is not the sole motivation, important though it is - and neither, really, is the financial benefit of H.264 royalties for the patent holders. What is also important to them is restricting the growth of new, competitive greenfield services and apps, which work best as low-cost islands - based around open-source software and (ideally) completely unencumbered codecs. Because H.264 works best with the current status-quo endpoints, it also favours current status-quo vendors and business models. It also helps to lock in H.265 as the future codec of choice, rather than VP9 or Mozilla's Dalla.

This is one reason why, in Disruptive Analysis' view, IETF should not go with H.264-only as the MTI codec, but should also add VP8. Just as there are two audio codecs (G.711 and Opus), there should also be two video options, to enable a level playing field between old and new participants. And to assure a "fair fight" between VP9 and H.265 - something which again, may skew the world between open/unencumbered and royalty-bearing. 

This is especially true as the MPEG-LA licencing regime is aimed very much at the traditional media industry in terms of streamed video, rather than application developers using new forms of communication. The 100k user threshold at which H.264 royalties become payable typically means a quite successful content or web company - but 100k users for a free mobile app is almost trivial - and almost certainly not profitable. The current licencing regime is heavily stacked against the small developer, and free/freemium models.

Consequently, next-generation developers will need an unencumbered video codec of one form or another - both for the desktop web, and for mobile apps.

Indeed, all the discussion about Cisco's H.264 move assumes that WebRTC remains a single, web-based standard. But the other, little-discussed dimension here is whether WebRTC use-cases will be primarily based in the browser or not. My view is that on the desktop, WebRTC will indeed be predominantly browser-based, although we'll also see it appear in some standalone applications.

But on smartphones, tablets and other devices, WebRTC will primarily be embedded into native apps, or the underlying device OS, and not necessarily the browser. That is *especially* true on iOS, unless Apple suddenly changes its mind on WebRTC support in mobile Safari.

Let me reiterate that: on mobile devices, the bulk of WebRTC will NOT appear in-browser, but instead it will be in-app, with either the developer directly integrating the various WebRTC code modules (such as codecs, DTLS, SRTP etc) into an app, or being provided with a 3rd-party API and code libraries by cloud-comms player like TokBox or Tropo.

In my newest forecasts, from the middle of 2015, there will be MORE non-browser mobile implementations of WebRTC than mobile browser devices. There will be 2.3bn mobile devices with non-browser support of WebRTC by end-2016.

That means that WebRTC on mobile (especially iOS) probably cannot easily exploit Cisco’s H.264 offer. There needs to be a way for either standalone app developers to get access to iOS’ existing H264 (and iPhone hardware acceleration is not currently allowed under present APIs) or else there needs to be “BYOcodec” with the app. In other words, either a separate (and potentially royalty-bearing) implementation of H.264, or else VP8. My expectation is that future mobile chipsets will likely support hardware acceleration of both H.264/5 and VP8/9 - although whether the OEMs like Apple provide API access is another matter.

In other words, Cisco's kind offer will be irrelevant for most mobile implementations of WebRTC. That doesn't mean Cisco is being duplicitous here - just that it cannot, by itself, influence those forms of distribution and use of H.264, especially on iOS.
For this reason, Disruptive Analysis believes that in order of preference, the IETF should choose as MTI video codec:

1) [Best] H.264 + VP8, with a clear statement of intent on H.265 + VP9 for the future
2) An old, out-of-patent codec so that there's a minimum fallback option, but each app chooses its preferred codec as it needs to
3) No mandatory video codecs at all. Fallback is voice-only, unless an app specifically negotiates video.
4) [worst] Either VP8-only or H.264-only.

[Also - I've seen a couple of mentions on Twitter about  the idea of a mandatory codec selection API, rather than a codec itself. Also sounds like a good idea, but not exactly sure how it would work in practice. I'll keep an eye out]

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.

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.

True personalisation for broadband & Internet access: The "Insurance" business model

I drive an unusual car. I live in central London, but unusually have a garage. I've never had a speeding ticket or major accident. I'm male, in my 40s, and work as a telecoms consultant. I drive less than 6000 miles a year. I can be considered an "enthusiast".

All of these are risk factors that insurance companies number-crunch each year, before offering me their annual premium. Some companies decline to offer cover. Some companies specialise in assessing various of the risk factors above, and can price keenly. Some have "live" agents & underwriters involved while others just use an online form and a big computer. They have different tweaks and tunes, such as levels of cover and varying excess (deductible) fees if you claim. If you have an accident/claim-free year, they will probably offer you a discount next year and beyond.

And that's the insurance industry's approach to pricing. It uses something similar for home insurance, health insurance and so on. The details of what and how prices are calculated vary by country, based on culture and law (eg in Europe they're not supposed to discriminate prices based on gender despite women generally being lower risks).

Telecoms, on the other hand, prefers the subscription-based model, with published price plans and perhaps a few add-ons, as well as overage and so-called value added ("out-of-bundle") charges like roaming.

Yet at the moment, much of the telecoms world is:

a) Suffering from a decline of the services which lend themselves best to plans (calls, SMS etc)
b) Trying to work out how to price broadband, given rising usage and declining costs of infrastructure, and a messy relationship between the two.
c) Trying to work out how to balance broadband and Internet access value, perhaps with additional services such as IPTV or new "managed services" completely separate from vanilla, Neutral Internet access (as I wrote about yesterday).

Also, as my colleague & erstwhile debating partner Martin Geddes points out, certain network behaviours (and applications) are worse "citizens" than others, creating problems and congestion. "Greedy" applications can almost be thought of as denial-of-service attacks on other users, consuming excess resource and causing "stationarity" problems. Something similar is true for mobile devices with poor transcievers, or even location - if you live in a basement, you probably consume more of your "fair share" of radio resource than someone on the second floor of a building with big windows. Then there's consideration of signalling (eg on/off applications always ppinging the network) as well as traffic volumes, and so on.

So maybe the telecoms industry should take a leaf out of the insurance companies' book.

Instead of getting a monthly subscription, you get quoted an annual "broadband premium". Watch lots of YouTube over LTE? Access Facebook 74 times a day from your smartphone? Drive a knackered old phone with a lousy radio chip? Download 20MB of emails at 9am in Kings Cross Station? Then sorry, but you're a poor broadband risk, and your premium is going to be really high.

The interesting thing is that if there's enough competition at a retail level (eg with MVNOs or new forms of wholesale), there ceases to be a need for full "transparency" on pricing. Each operator collects its own set of variables, crunches it through its own algorithm, and comes up with a personalised quotation. It also analyses your real usage and "risky online behaviour" to refine its premium next year. Maybe we see the emergence of companies similar to credit-scoring that rank your broadband social/anti-social scores.

Yes, there would need to be a whole range of safeguards put in place. It wouldn't be a direct copy of the insurance business. But it would certainly be a more interesting - and perhaps fairer - way to price broadband and Internet access services. (There would probably need to be assorted regulatory changes too, I know, as well as privacy challenges).

My general view is that business models - and revenues - are driven by the OSS/BSS function in telecoms. Network innovation and network-resident policy functions there to enforce certain things, manage/optimise some others, and monitor and measure statistics - but is not at the core of business model innovation. You only need to look at the years of futile and failed attempts to use DPI and PCRFs to create so-called "application-based" plans. By all means instill more intelligence in the control-layer of the IP core to manage costs and aspects of customer experience - but that's not where the revenue side of profitability will stem from.

And from the OSS/BSS side? You've been talking about "personalisation" for years, and more recently "big data". The problem has been that personalisation hasn't really been personal ("what bolt-ons do you want to buy, based on a central core plan?"). The insurance approach would need very big data to be effective, and would by definition deliver completely personalised prices.

Now yes, I know all this is a bit of a straw-man. It would be hellishly difficult to do, especially with legacy networks and legacy charging/billing systems. But I'm really curious about whether people could actually see it working, if we started from a green-field situation.

Sidenote: this is the type of properly "out of the box" thinking you get if you employ Disruptive Analysis as a consultant or business advisor. You might not agree with all the ideas - but the point is to stimulate *real* business-model and technology innovation, not just a warmed-over iteration of the last century's ideas. Contact information AT disruptive-analysis DOT com. Don't Assume.