WebRTC platforms & distribution partnerships: From evangelists to acolytes

Over the last month I've been to a number of WebRTC and related events - AdvancedComms Asia in Singapore & HK, WebRTC World Expo in Miami, and GenBand's Perspectives customer/analyst conference in Orlando, as well as numerous meetings and calls with WebRTC-related vendors, users, investors and clients.

A couple of themes that have emerged are mostly continuations of existing ones - the overall pendulum of WebRTC swinging towards enterprise "disunified comms", a broad recognition of the equal (or greater) importance of mobile WebRTC-embedded apps vs. browser experiences, and the continued steady growth in profile of telcos and other service providers. All of these I've covered recently on this blog, or in my regular WebRTC research report updates for clients.

But one additional trend really jumped out at me last week at the GenBand event: the importance of distribution and integration partnerships, for WebRTC PaaS players. It's something I'd started seeing signs of at Enterprise Connect in March, but some of the impressive activity that's been done by GenBand's Kandy "ecosystem" really threw it into stark relief, and brough a few separate things together for me.

The headline: Evangelism is not enough. 

Lots of WebRTC companies are out pounding the conference circuit, not just for the technology itself, but also at specialist events for healthcare, finance, general web-design and so on. They are running hackathons, providing developer out-reach via web forums and other avenues, and generally "getting the story out there", especially to the long tail of developers.

That is absolutely necessary. But it's not sufficient.

The WebRTC PaaS market needs not just evangelists, but acolytes too. These are third-parties who are "devotees", or "followers", or assorted other religiously-inspired terms that imply not just "belief" but also provision of active help in the priest in performing the rites.

Translating the metaphor to IT terminology, this means systems integrators, channel-partners, consultants and others who assist in the "go to market" for the PaaS providers and their SDKs. (A fairly similar argument also applies to WebRTC gateway vendors, although that's somewhat different given upfront costs and existing infrastructure. I'll cover it in another post/report).

This gives a multiplier effect, as various types of partner are able to reach out to their customer base, adding broader marketing and sales resouce, adding value through other products or software customisation, or giving an impression of greater credibility and stability.

I see at least important 4 go-to-market channels for PaaS providers, each with sub-divisions:

• Major software companies embedding PaaS (or components). Temasys' recent announcement with Citrix for its browser plug-ins is a good example, as is Kandy's expanding role within SAP's applications, and also as a basis for its own fring application. At Enterprise Connect, I liked CafeX's integration with Humanify for contextual-comms in B2C websites as well.
• Systems integrators. Acision announced last year that it was working with Capgemini, and Kandy is working with Tech Mahindra among others. I know from my own research sales and consulting that other major firms are interested in WebRTC, but it's less clear if they will "roll their own", work with established PaaS players, or pick-and-choose for particular projects.
• Telcos & SPs: While some telcos are developing their own PaaS offers, others are acting more as solution integrators, combining an existing platform with other elements. Tata Communications is using SightCall's PaaS, as well as various other vendors' products in its Click2RTC offer.
• Consultancies & agencies: There is a broad range of "general" web, comms and mobile-app professional services companies interested in WebRTC. They range from high-profile WebRTC specialists such as Quobis (which also has its own software products) through to "digital media agencies" that work with brands or B2C players on overall web/mobile strategy and design. Acision's work with Blacc Spot and Kandy's with Deloitte's Digital arm are examples.

The categorisation can never be perfect - various companies can exist in multiple roles, and sometimes the PaaS offer blends into the background, while sometimes it's more transparent as a "resell". But the general principle is the same - the PaaS provider gets the benefit of extra scale and reach, as their ecosystem is doing some of the heavy-lifting.

The relationships have to work two ways as well - the PaaS vendor needs to invest quite a lot of effort to turn a couple of isolated deals into a genuine "ecosystem", where there are genuine feedback effects. At the moment, I'd say Kandy is probably ahead in terms of brand-name partners, and seems to have invested quite a lot to get its message across, at least in North America. The heavily-branded tour bus is a nice touch.

There is also another spin on distribution here - some WebRTC PaaS providers have another ready-made channel: their own existing developer programme/community for other APIs. Twilio and AT&T are the two most obvious proponents of this approach, as well as Tropo although its acquisition by Cisco rather changes things.

I'm going to keep a close eye on the evolving partnerships here. I suspect some don't get much further than a press release, while there are certainly others that have not (yet) been publicly announced. 

I'm also curious to see if any of the gateway-specific SDKs evolve into full PaaS platforms (eg Oracle's, Sonus', Broadsoft's), or indeed the UC-centric APIs from Unify or Avaya. A number of those companies - notably Avaya and Oracle - could also WebRTC-ify their own company's vertical market apps via their own platforms. Cisco+Tropo is an obvious candidate for that as well, while Tokbox could potentially be leveraged by other units of Telefonica.

The bottom line is that the various WebRTC platform providers are doing a better job in 2015 at promoting their role in the industry. But signing up third parties and ecosystems should have a multiplier effect.

More detail on the WebRTC market, PaaS, gateways, channels and vertical solutions is included in the Disruptive Analysis research report & updates. The next edition, due in early July, will consider the channel/ecosystem dynamics in greater detail. To order the report & updates, click here.

If you want to discuss a more specific research project, or brief me on your company, please contact information AT disruptive-analysis DOT com .

Ad-blocking: No, mobile operators won't be blocking adverts & charging Google to restore them

The last few days have seen a bunch of articles (see here [paid], here, here)  suggesting that some mobile network operators - notably in Europe - are considering deploying ad-blocking capabilities in the network, and potentially charging companies such as Google for the right to "unblock" them via some sort of revenue-share agreement. A company called Shine has been mentioned as a possible vendor - I've spoken to the firm in the past and was unconvinced.

That said, the idea that mobile operators might block ads in their networks, or charge for the traffic they use, is not new.

In fact, I believe invented the concept myself, 4.5 years ago. (See this post  - sorry to anyone trying to patent the idea!). I wasn't entirely serious, but I could see it was a possible future.

Another thing I’ve said before is that telcos often “take 4 years to spot a good idea, 4 years to implement it & another 4 years to realise they’re too late”.

And in this case, it’s already too late. While ad-blocking might be effective for stopping in-browser ads, the technology will struggle with other formats like in-app ads (except where they are from an obvious source, or in a hybrid "webview" page in the app). It also struggles with various forms of “native” advertising embedded into content, such as video pre-roll ads or sponsored-content promotions. 

In addition, the landscape has changed massively since 2010, in terms of the way that ads are delivered, dataplan size and the large role that Google/Android and other advertising-centric companies have on the overall mobile landscape. 

There are also many possible responses and workarounds to “block the blockers” – see below. My view is that these experiments will not just fail - they could backfire spectacularly.

Regulatory & policy context

As context, there is also much more awareness – and much less tolerance – of networks “messing about” with Internet traffic in 2015 than 2010, although parallel concerns over privacy and the power of a few web players perhaps make ads “fair game” despite that.

There is also a growing war in Europe especially, against US-based Internet companies being waged by some of the more shrill “public policy” teams at major telcos. Telefonica is among those advancing the most egregious and hypocritical arguments – with its blog putting up strawman after strawman, which I sometimes try to counter in the comments.

This fight is tacitly supported by the new European Commissioners Ansip & Oettinger, who seem less capable of forming independent and coherent opinions about telecoms than their "steely" predecessor Kroes.

In a nutshell, some European telcos feel they can “get away with” harassing Google and to a lesser degree Apple and Facebook, and get air-cover from their national regulators and the European Commission. While the current trials might have the convenient excuse of “protecting users’ dataplans”, the reality is much more duplicitous – they are jealous that Google has out-innovated and out-maneouvred them, in a similar fashion to their rhetoric about “OTTs”, when they have been asleep at the communications wheel for 20 years.

Minimising the data burden on users

The point in my original post was that one of the few forms of non-neutrality that regulators and the public might tolerate is that of dealing with mobile adverts. Perhaps that traffic could be paid for by the advertisers and their channels. Advertising is widely disliked - as evidenced by the growing number of (mostly PC-based) browser users downloading ad-blocking software themselves. A recent German lawsuit by publishers was defeated, but we can expect additional action to follow if telcos try to take the same path - as well as worsened relationships between the two groups of companies.

While the morality of overall ad-blocking is dubious (it’s how useful free content is paid for), on mobile data-plans with low usage caps it may indeed be an onerous burden. Websites have a right to advertise at me, but don’t have a right to make me incur substantial extra costs for the “privilege” of being “advertised at”. Auto-playing video or audio adverts alongside static content are especially disproportionate. Various forms of pop-up or other intrusive formats are also occurring in mobile, as browsers get more capable – and there is justifiable resentment at some of these. 

Paying for ads’ data usage while roaming is especially awful, and is perhaps where the operators genuinely could offer user benefit and value by blocking them. Unsurprisingly, this will probably be the last use-case considered, given the perennial and profitable rip-off prices charged for data-roaming.

Sidenote: A compromise I’d suggest from the mobile advertising industry: ensure that ads take up no more than 10% of the total traffic needed for a given website or app when accessed over cellular networs. This would neutralise the bulk of the arguments being advanced here.

I actually believe that traffic for ads is one of the very few categories that might be viable as a source of “sponsored data” – although this will be in the form of discretionary promotions (eg bulky movie trailers downloaded for free) rather than some sort of across-the-board tollgate. I estimated the future market size of sponsored traffic for advertising in my recent report on new monetisation business models - it may reach $2bn by 2019 (see here). But the model suggested here – block ads unless the companies pay up or agree a revenue share – is the wrong one entirely.

Extortion only works against the weak.

Deploy counter-measures!

And in this case, the advertising machinery is anything but weak. The ridiculous thing about this concept is the ease with which such measures can be mitigated. I can think of 5-10 possible workarounds straight away. The most obvious group of approaches is to blend apps with content so they cannot be teased-apart, and another set involves using methods to avoid the filters in some way. There are plenty of other possibilities too.

Encryption of content is the most obvious. It is already widespread in mobile, and is growing fast – in some networks, more than 50% is encrypted. There are multiple styles, ranging from SSL built-in to HTTPS traffic, SRTP for WebRTC traffic, through to using compression and proxy servers. Some of these are still theoretically “blockable” based on IP address, but the risk of false positives increases hugely. The inclusion of Google’s SPDY technology into the HTTP2 standard has pretty much ensured this is a one-way ratchet for web traffic in future. 

Belated efforts by the telco industry such as the “Open Web Alliance” to limit crypto usage or propose “trusted proxies” for traffic management are already failing and, ironically, are undermined by “untrustworthy” actions such as this.

Google is already offering a VPN option in its new Fi service, intended to secure traffic over 3^rd-party WiFi. It doesn’t take much imagination to see that this could become a ubiquitous feature for Chrome – or even Android OS – over any connection. All the operator would see would be a single stream of encrypted traffic to and from Mountain View or a local Google node – perhaps even inside its own network.

The other obvious fly in the ointment is WiFi. Most smartphone users already spend 50-90% connected to 3^rd-party WiFi access in homes, offices, cafes, hotels and other places. Advertising will work normally in those places. Ignore the “seamless” carrier-WiFi hype – mobile operators’ own hotspots are a tiny fraction of the total in most countries, and will stay that way. We won’t see fixed ISPs and every WiFi operator pursuing a similar strategy of ad-blocking either – there is no rationale for it. This means that (a) Google and other advertisers will further assist users in finding WiFi, perhaps even subsidising it; and (b) Tools will be built into OS’s or 3^rd-party SDKs to allow developers and advertisers to download and pre-cache advertising via WiFi, serving it up locally as-needed.

Indeed, we would likely see various new ad-related APIs, or delivery services, being rolled out in Android and iOS, plus browsers, to help work around the blockages. These developments will not have come as a surprise to many, and it is foolish to believe that countermeasures are not already being worked on. 

Of course, Fi also means that Google now has a very good view of the wholesale costs of mobile data provision, and this will impact the ridiculous "revenue share" concept still further. At absolute worse-case, it will be asked to pay fees much lower than the consumers' retail price of mobile data. There will also be no justification for "double-charging" consumers for the same data paid for by advertisers.

Actions have consequences

The mobile industry is playing with fire here. The countermeasures available to Google, Facebook and others are powerful. There is a very significant risk that rather than increasing revenues, that instead these moves will actually decrease revenues, as well as increase costs and have assorted other unintended consequences – especially more encryption, and more use of 3^rd-party WiFi. 

Some of the ads that may get blocked will no doubt cause embarrassment or even legal action – I can’t imagine competition authorities being amused if TelcoA blocks ads for TelcoB, for example. There’s also a strong risk that TelcoA blocks some of its own advertising, given the typical distant and disconnected silos within a large operator. That should make for some lively boardroom discussions. The publishers vs. telcos fight won't be pretty either.

I also envision the system lacking “discrimination”. Unless there is a laborious "white list" process, it will probably block ads for charity appeals, or stop government-paid ads for voting registration or impending tax-return deadlines. That should cause much amusement in policy circles, I’m sure. There will inevitably be a host of “false positives” and “false negatives”, as you can expect companies to use the same distribution channels and “signatures” for both ads and “legitimate” content.

The biggest irony is that all this will just encourage continued advancement of native apps and OS’s vs. more-powerful browsers – the exact opposite of what many telcos would like to see happen. In-app advertising will inevitable be more block-proof than web-based versions.

It’s even possible that Google will start tiering or limiting its own services on “hostile” networks, to encourage users to churn to “friendly” ones. And in extremis you could even imagine MNOs being made to pay for subscribers’ access to certain apps or services. Most people would more happily switch telco, than switch Internet ecosystem.

My prediction is that these ad-blocking services will never see the light of day - and if they do sneak out, will cause untold amounts of pain. The idea the MNOs will get a signficant revenue-share of a business to which they add zero value is laughable.

Overall, trying to extort protection money “in case something nasty happens to your ads” is a silly and unnecessary risk. Never mind the old cliché about bringing a knife to a gunfight – the mobile industry is trying to act like a racketeer here, but is only packing a rusty spoon in its belt.

RCS is still a zombie technology, "28 Quarters Later"

In February 2008, a number of major telcos and technology vendors announced the "Rich Communications Suite Initiative" (see here).  I first saw the details a couple of months later, at the April 2008 IMS World Forum conference in Paris. 

****NOTE: NEW FEB 2017 POST ON RCS & GOOGLE - CLICK HERE ***

It is now 7 years, 2 billion smartphones, and 800m WhatsApp users later.

Or to put it another way, 28 Quarters Later*.

However, unlike Danny Boyle's scary, fast-moving monsters in the 28 Days and 28 Weeks Later movies, RCS is not infected with the "Rage Virus", but is more of a traditional zombie: dead, but still shambling slowly about and trying to eat your brains. It's infected with bureaucracy, complexity and irrelevance.

To remind you: April 2008 was also a few months after the launch of the first iPhone, and a few months before the launch of the AppStore. It was also when Facebook Chat, now Messenger, was switched on in my browser for the first time - while I was waiting on the podium, to start chairing the IMS event. The world of mobile devices, apps and - above all - communications has moved on incredibly far since then.

But not for RCS.

The last 7 years have seen multiple iterations of RCS versions 1.0-5.2, RCSe as a short-lived spin-off, Joyn as the GSMA-sponsored brand, and more recently an attempt to piggy-back onto the deployment of VoLTE, as well as an attempt to reposition RCS as either "SMS 2.0" or some sort of API platform for developers.

Yet the active RCS user base is never quoted - I suspect it has fewer than 20m monthly users worldwide, and probably fewer than 5m active daily users. And by "active" usage, we should really focus on the "rich" aspect (see also below) with video or file-sharing, not just SMS-in-zombie's-clothing text. 

(Some vendors/operators are trying to replace native SMS apps on phones with RCS, to force people to "adopt" it. Most will just assume it's still SMS for text-messaging and avoid the other so-called "capabilities". Be wary of puffed-up future stats). 

The issue is that RCS has a large number of unfixable structural problems that guarantee its perpetual failure:

• It is "engineered" not "designed". Nobody sat down to ask what human problems RCS is intended to fix. It's a random grab-bag of technical features designed to be "interoperable" rather than "be useful for a purpose". There were no psychologists, designers or behavioural specialists involved in its creation.
• It has a bunch of expensive and complex "moving parts", using obscure and inaccessible protocols. Alan Quayle has a good run-down on its failings here. 
• Nobody needs expensively-engineered network cellular "QoS" for messaging, especially when 50-90% of use will be over 3rd-party WiFi anyway.
• It comes from an era where standardised app-level interop and federation was seen as a major benefit ("SMS only took off when networks interoperated") without recognising that 10-sec app downloads or 1-sec browser interactions now make this irrelevant. Popularity, design and purpose are keys to success - you can always interoperate later if needed, via the web.
• It's very slow-moving, as it's standardised by a committee process and hundreds of pages of labyrinthine documentation. It can't rapidly respond to new developments - messaging as a platform, stickers, "last seen online", likes, filters, disappearing messages etc. While it is a bit more extensible today, with operators' own features, it is still hamstrung by the lowest-common denominator interop specs and unnecessary QoS and per-message charging machinery
• RCS is often pitched as "competing against OTTs", but no reason is ever given why users should switch away from WhatsApp, LINE or WeChat, and for which use-cases. I have never seen a case-study interview of a teenager saying "I used to use SnapChat, but now all my friends have switched to Telco Messenger X"
• There is no obvious business model, except giving it away for free and hoping it adds value to a service bundle. Given that VoLTE is already an expensive investment in a declining market, it seems unlikely that many telco CFOs are keen on throwing yet more money down the drain for zero/negative ROI.
• Blending RCS with VoLTE overlooks the fact that VoLTE will not become "ubiquitous" for at least 10 years, and maybe never. I'm forecasting just 27% of LTE users to have VoLTE by end-2019  or in other words, less than 10% of overall mobile users. Limiting RCS to the niche of VoLTE users guarantees its irrelevance, given they're exactly the people most likely to use other apps on high-end devices.
• There is (AFAIK) no free international interconnect model for RCS - yet an important use-case for Skype, WhatsApp, WeChat and others is chatting to friends abroad.
• It is "any-to-any" rather than driven by buddy lists or whitelists, and so prone to spam and unsolicited marketing messages. Conversely, WhatsApp remains almost totally spam-free (helped by lack of an external spammable API, as well)
• RCS needs an IMS, which no mobile operator really wants to deploy, unless/until they're forced into it by VoLTE. While some RCS-aaS cloud solutions exist and help manage the costs, they still require client solutions on devices
• It's not supported by Apple and only half-heartedly by Google/Android and Microsoft, as they all have their own (better) communications products that tie into their own ecoystems (and their better understanding of user behaviour and design)
• It's not widely supported in retail-market "unlocked" handsets, used by most of the world's majority of prepay mobile users.
• It doesn't work very well with dual-SIM phones, or for people who have multiple SIMs and accounts.  
• It's unclear how it will work for people who don't have data plans. It might be zero-rated, but that has its own complexities and risks. For example, are file-transfers zero'd as well? It would be ironic if RCS got pressed into service as a free way to download other messaging apps from appstores.
• It is being pitched as a "platform" before it is a successful "product". That's not the way the technology industry works. Developers and enterprises will only sit up and listen when it has already got widespread adoption among the audience.
• Ubiquity is earned. Whatsapp, WeChat, Facebook and others have achieved viral adoption by giving people what they want, being differentiated in some way and having them recommend it. RCS has attempted to force itself on people, with telcos assuming a sense of "network privilege and entitlement".
• Users like fragmented communications experiences for many reasons - we see people happy with 5, 10 or more "messaging" or social apps, plus an increasing tendency to embed messaging capabilities as a feature into other apps. (Voice & video will follow suit, courtesy of WebRTC)
• There is no relevance of RCS to the enterprise. It doesn't fit with the way businesses or their employees use mobile devices and corporate applications. (Yes, I'm baffled by the Mitel/Mavenir acquisition, too)

Perhaps the most obvious indicator of failure is the name. Nobody actually wants "richness". Users want the right tool for the job, not an overloaded Swiss Army knife made "rich" with useless gizmos. The name - much like the term "multimedia" in IMS and MMS - epitomises the muddle-headed thinking that went into its conception.  It's rooted in engineers wanting to throw in as much as possible, not designers actually considering how people might behave, and what purposes/contexts they might pursue.

It is notable that WhatsApp added voice (& features like photo-sharing) only after it was already popular for text messages, and its owners could examine user-behaviour, how they used it (and for what), and only then determined what secondary features they might want. Almost all the most successful Internet applications have started out with something simple, and then added on top of it. They are also able to roll back changes, and do large-scale A/B testing on a live audience.

By contrast, RCS has been developed as a rigid, all-singing, all-dancing application with minutely-specified details.

What the industry should have done was take SMS, and make continuous minor tweaks to the application. A better (& cheaper) SMS could have battled its rivals. Context-specific versions of SMS would have made sense, too. Trying to just swap out SMS for RCS will likely make the experience worse, and accelerate the move of users (and developers) to alternative products.

There are dozens of ways to improve the utility and value of SMS. Adding video-sharing isn't one of them. RCS is emphatically NOT the new SMS2.0, despite desperate marketeers trying to suggest it.

A couple of operators' own messaging apps allegedly have RCS as an external interface for others to connect to - but I suspect that's mostly just to tick a box and keep the GSMA's enforcers quiet. I'm not aware that Orange Libon has any active "federation" use, for example. I also think Genband's "fring alliance" attempt to white-label messaging apps to multiple telcos and then allow them to "federate" is an exercise in futility. 

RCS-based app federation is just a way to create a "coalition of the losers".

The way that RCS has been positioned and marketed has been woeful as well.

RCS has had slogans such as "It's just there, it's just works" which have been laughably false, while early deployments - including by multiple operators in some countries (eg South Korea & Spain) have faded rapidly from sight. I wrote a research report in September 2010 about its continued failure.

About 3 years ago, I heard a Metro PCS radio ad while driving in the US saying "try Joyn, the messaging service taking Europe by storm!". I assume that someone subsequently rescued the teacup suffering from bad weather.

I meet virtually nobody in the industry who thinks that RCS anything other than a joke, apart from a couple of tired-looking vendor representatives. Yet most won't say so in public, scared of pointing out the GSMA Emperor's nudity. A few bloggers occasionally put up half-baked "Will RCS finally allow telcos to beat the OTTs?" articles, but that's just as click-bait, and probably half of them hope I'll jump in personally, and start a fight in the comments. 

I see a few vendors still trying to pitch RCS as an API for developers, or adding WebRTC to it in the hope to "extend" it to the browser or other devices. Both are attempts to put lipstick on the pig zombie. The use of RCS for A2P messaging will not happen until there are sufficient users adopting it for P2P. It's doubtful anyone will want to "engage" via a medium their customers are unfamiliar with, or that they think is uncool or clunky.

In my view, the industry needs to stop messing around with RCS, and kill it loudly and clearly. It needs to die with a bang, not a whimper. Someone needs to drive a wooden stake through its heart, then we can "go to the Winchester, have a nice cold pint, and wait for all of this to blow over"

The "reset" can only come with 5G. Rather than wasting yet more time and money with the GSMA's "2020" vision and perpetuating legacy IMS, VoLTE & RCS, the industry needs to start again with a clean sheet. It needs to move towards contextualised communications, where voice/messaging/video is a feature of apps, websites and devices, not just a standalone service. It needs to decouple basic useful protocols from signalling, as in WebRTC. It needs to stop trying to define application behaviour, but leave that to the market.

Operators should pull the plug on all RCS investments now. Stop throwing good money after bad. Put the teams to work on thinking about what future communications could be - not trying to protect the obsolete "interop" models of the past, with clunky, expensive and unwanted new services. Operators needs to work individually - with vendors as and where appropriate, or with Internet/app providers if that makes more sense. They need to understand how and why their customers communicate, and predict how that will change.

The future of communications is about:

• Context and purpose - help people achieve what they really want
• Fragmentation & multiplicity
• Flexibility & agility
• Design & behaviour
• Interop & federation only where it makes sense, not by default
• QoS only where it makes sense, not by default
• Differentiation
• Multiple identity domains
• Security, privacy & control

RCS was already dead in 2008. It's still dead now. Ignore the occasional twitches of its corpse. Instead, focus on the growing seeds of new sources of value in communications.

***For a Feb 2017 update on RCS, GSMA & Google, click here ***

And if you want to know what is genuinely innovative & an opportunity in voice/messaging for carriers, contact me at information at disruptive-analysis dot com

* OK yes, it's 29 quarters since the original announcement, but 28 since I discovered the details. Who's counting.