Speaking Engagements & Private Workshops - Get Dean Bubley to present or chair your event

Need an experienced, provocative & influential telecoms keynote speaker, moderator/chair or workshop facilitator?
To discuss Dean Bubley's appearance at a specific event, contact information AT disruptive-analysis DOT com

Thursday, May 07, 2015

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.

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.

(As a good start, check out the upcoming Contextual Communications event I'm running with Martin Geddes, on June 15th in London. Details here)

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

4 comments:

Martin Geddes said...

It would be interesting to better understand the individual and organisational psychology that perpetuates this madness. At what point does the belief system that RCS has a viable future collapse? What are the incentives that keep it (seemingly) alive and animated?

Matthew Hodgson said...

In other news, Martin: reasons off the top of my head why RCS continues to stay alive:

1. The sheer number of people (GSMA, telco network teams and RCS vendors) who have invested too much time, reputation and money into it, and who would lose face and suffer if it failed.

2. Until recently RCS been the only available solution for federated rich communication (other than XMPP, which has an entirely different set of problems). RCS was sold to the telcos as the one true way to compete with OTTs, and this caused many telcos to sit back and ignore the OTT threat, trusting that RCS would solve all their woes. So right now, some telcos are still hoping against hope that RCS will save the day, as they see no other options on the table which provide the federation features they (reasonably, in my opinion) expect.

3. Enough RCS solutions have been sold and launched that there is the appearance of an active market, giving hope to the remaining faithful. SingTel's Wavee looks to be RCS from WIT; Sprint's Messaging Plus is RCS from Jive; AMX launched Joyn; the Spanish & Korean operators that Dean mentions above. The minor problem is that these services simply don't remotely compare in terms of uptake or usage to the likes of WhatsApp, Viber, Skype, Hangouts, Facebook etc. And RCS interworking is sufficiently hard that very few of them actually federate together, which was meant to be the whole point in the first place.

4. Technologically RCS appeals to the traditional carrier network mindset: it's highly layered, built on top of the GSM-inspired IMS core, and can feel like an extreme but logical extrapolation of traditional network standards. And this familiarity is reassuring (whilst also giving vendors a sufficiently complex standard that creates a barrier to entry for the market). The end result is that simply sending a text message over RCS involves a protocol stack spanning at least MSRP, XCAP, SIMPLE, IMS, SIP, SDP, TCP/UDP/IP. Whilst layering can be good in some scenarios, for this use case it simply fails to compete with the simplicity of just sending a message as HTTP+JSON+TCP/IP (for instance), as per your typical OTT app.

I feel bad about being so negative about RCS, but the fact is that it's holding back the industry. It's incredibly frustrating to try to encourage Telcos to participate in OTT-style ventures and not get left behind, only to be told that RCS is the only option on the table. In the end this was a main driver for creating Matrix.org: to provide a pragmatic alternative for modern federation, giving an entirely different way forwards for interoperable telco and internet services.

Matthew Hodgson said...

This is a great write-up of RCS's woes, alas. One can quibble over some of the specific complaints, but the overall picture is undeniable (and this is coming from someone who's been obliged to build an RCS 5.1 implementation).

However, I think the conclusions aren't quite so clear cut and there's a real risk of throwing the baby out with the bath water. Just because RCS isn't fit for purpose to provide interoperability between modern communication applications doesn't mean that federation has been obsoleted by "10-sec app downloads or 1-sec browser interactions". The current trend of fragmenting communication into a million different websites/apps is *incredibly* dangerous: users lose control of where their data is, who they trust with it, how they access it, and they lose control of selecting the user experience they prefer for typical day-to-day contextless communication. It encourages single companies to hoard data and mine, sell and otherwise exploit it. Obviously there are many scenarios where you /need/ context and to be sharing the same app... but there are also many scenarios where the only context of a conversation is shared mental state and the prior conversation history, and a modern means of federation is critical to support those scenarios with the best user experience for *both* parties.

I had a classic example of this tonight: Steve Sokol, myself and Richard Tworek needed to jump onto a call to sort out our agenda for the Open Source Options for WebRTC Development session at WebRTC Miami next week. Richard called the meeting, sending an calendar invite email linking to a plus.google.com URL for Hangouts. First problem was that the URL didn't show in the invite in Thunderbird at all - I had to manually base64-decode the raw email to view it. Meanwhile on my iPhone you have to tap on "Notes" to find the URL. Second problem is that Hangouts on Desktop refused to let me join the hangout as I'd been invited using my @matrix.org email address, which isn't yet associated with a Google account. Hangouts didn't tell me /why/ it wasn't letting me join; I was just stuck there - it occasionally failed to connect with a wonderfully cryptic "KL-DR Error" or similar. I think the same thing happened to Steve, so cue a flurry of email 5 minutes into the slot (complete with crossing and delayed mails) to discuss the problem. Meanwhile, I actually didn't want to be using VoIP in the first place for this - I was going to be running around the house after my kid whilst on the call and there's bad wifi/data coverage in some rooms: i'd much rather just use a plain old PSTN conference bridge for once. Luckily Richard suggested Uberconference, and we reconverged only having lost 10 minutes of the 30 minute slot trying to get on the same page.

The moral of the story here is not that Hangouts sucks: it can be great and it's just a simple matter of programming to fix the issues we hit. However, it *really* sucks that, as as user, I was forced into using *any* specific app for this purpose. We'd have been fine had I been able to just dial into the same conversation using a service I /know/ works for me which suits my particular hardware, network, locale, data privacy requirements, corporate IT infosec requirements, etc. etc. There was *NO* contextual data to this conversation short of the mail thread that triggered it, and certainly *NO* need for everyone to be forced to use the same app.

RCS is clearly not the answer, but it would be catastrophic if RCS's shortcomings causes us to swing even further towards assuming that all you need to communicate these days are a hundred fragmented parallel communication channels; splintering your conversations and contacts across this sea of incompatible apps and sites.

Dean Bubley said...

Belated feedback:

Martin - a lot of it relates to the dysfunctional way that standards are created. The people, politics, agendas etc. 3GPP and GSMA in particular seem to struggle to understand the role of user "agency" and choice. They come from an era when a committee had to create a "perfect" standard to impose, as it was too expensive to create alternatives. That mode of thinking is now obsolete, except in "heavy lifting" areas like radio technology.

Matthew (taking your 2nd post first)

Interesting comment about the enduring large amount of "contextless" comms. I agree that such standalone models will be around for some time - hence telephony, SMS and email staying around. RCS cannot be a 4th one, however as it is not up to the job - and won't be implemented or used widely.

I'd also suggest that in your example, building WebRTC apps directly into the email thread might have been the "answer".

I suspect we'll get some sort of helper-app, combined with personal experience, to work out the best way to connect with someone at a given instance. It's a bit like real life. I have a fair idea that we'll bump into each other today at the WebRTC event over coffee - but I know I can reach you via alternative channels (probably Twitter DM) with minimal friction. I think the Internet ends up like normal human interaction in real life - you have to understand & interpret the other person's preferences.

Also - huge thanks for the other set of reasons you posted for why RCS is still pseudo-alive