How Standards Define Themselves to Death

Steve Austin, The Six Million Dollar Man, was – Better…Stronger…Faster… That was the hope of RCS (Rich Communication Services).

RCS started its journey at the GSMA in 2008 with the promise to allow service providers to deliver “OTT like” services with interoperability across service providers and managed quality of service as it is provided by those that own the network. By being better than what OTT can offer, users would vote for those services of the service provider.

Where was the market back then?
 

Looking at OTT on mobile at that time, things were still kind of preliminary.

Skype – Mainly used on desktops, Skype for mobile was in its infancy

WeChat – didn’t exist, launched in 2011

WhatsApp – Didn’t exist, launched in 2009

Facebook Messaging – Project Titan for user to user messaging was launch in 2010 and mobile messenger app was launched in 2011

Viber – Didn’t exist, launched in 2010

You get the point…

The important things to conclude from this data are:

• Back then, when RCS started, there was still plenty of market share for it to capture
   
• The OTTs listed above took the market by storm working vertically (a specific service) and not horizontally (many services for a specific segment/region)
   
• They are all islands…didn’t wait for any standards
   
• Oh…and they are all free

Why RCS lost to OTTs?

RCS has standardised itself to death in 2 ways.

It has insisted on trying to define and standardise everything possible rather than sticking to the bare minimum. Due to this, it lost a lot of time and left little room for flexibility to those who wanted to deploy it. RCS and the brand “Joyn” defined everything all the way up to the user experience, what the address book should look like and what the user would see on each and every screen.

On top of that, RCS standardization tries to capture requirements from 2 camps, what was known previously as RCS and RCSe, later to be unified under the Blackbird standard version. This move sounds great but Blackbird still includes different options for doing pretty much the same thing. When you define multiple ways to send a message and to implement presence-based features, the life of the developer becomes more complex.

The promise of RCS was valid
 

The promise of RCS was, and even today still is a valid one. It has been proven to be valid through the success of OTT players such as WhatsApp that provide some of the RCS services but in a proprietary way.

Different from VoLTE, that has good technical and business reasons to replace Circuit Switched voice, RCS doesn’t enjoy the network ownership advantage, OPEX savings and enhanced user experience compared to using an OTT service for the same purpose.

The major benefit of RCS could have been cross service provider interoperability.

Other assumed benefits, such as a unified user experience, are not more than a pipe dream as not all device vendors will vote for what join has defined (i.e. Apple). Given that, we are left with an application, at least on some of the devices, and not a pre-integrated experience that comes pre-loaded on the device.

The enhanced address book and integration with the phone’s address book has come to the OTT applications user experience a long time ago. Given the ubiquitous nature of some of them (who of my friends doesn’t have WhatsApp? None!), the benefit of RCS interoperability is losing its advantage.

There was another option

The other option was to put time-to-service at a higher priority than top to bottom standardization work.

Time-to-service as priority #1 doesn’t translate to zero standards, it translates to standardizing only what really needs to be standardized as was done in WebRTC, while leaving the rest for the implementers.

In context of RCS that would mean APIs (e.g. send message, get contact…) for applications to use the RCS service for launching innovative services and things related to payload (e.g. how a file is transferred between clients).

Service providers and RCS server vendors would provide client SDKs based on which the service provider could launch its own services. Additionally, they would provide them to developers to build services with and integrate them into other applications.

Conclusion
 

Reality has proven that even in places where standards exist, once communication crosses between services and networks, it goes through mediation servers. We see more coupling between clients and servers today, something that contradicts the goal of standards, to enable zero vendor lock. This reality is apparent today in every type of real-time communication – UC, IP-PBX, VoLTE and WebRTC. There is no reason why it will be different in RCS and therefore waiting runs the risk of missing the opportunity.