RCS (Rich Communication Suite) has failed, we need an RCS reset, according to Dean Bubley its been a Zombie Technology for several years. My conversations with telcos over the past year on RCS have recurrent themes of it being too expensive, too complex, increasingly detached from the market reality, and most importantly has lost the confidence of many telcos. Within the ‘leading’ telcos on RCS implementation, there are a few execs who have nailed their careers to RCS and are pushing on regardless of what the rest of the organization thinks. Simply, RCS customer numbers speak for themselves.
Telcos must not give up on voice and messaging, watching SMS and E.164 (voice) continue their decline into being increasingly the communication path of last resort is grossly incompetent. But that is what is happening as the industry waits for RCS. RCS started in 2007, 8 years ago! And we’re seeing RFQs on RCS being halted for the above reasons – that is why it has failed. And waiting for WebRTC to magically solve all the above problems is equally as bad.
Digging into the standards documentation can only be described as purposefully obscure. Here is a partial list of what someone must go through to understand RCS:
- RCS specifications and amendments (not only the version you are implemented, but also previous ones)
- OMA SIMPLE IM standard and the specs it refers to
- RCS profile spec for OMA SIMPLE IM
- RFCs for SIP, MSRP, XCAP, and others
- RCS test cases
- 3GPP IMS specs
This is over 2000 pages of telecom protocol specifications generally written in a way that only makes sense to the people involved NOT to general engineers. This is NOT a 2 page RESTful API spec, written so any web developer can understand. A common refrain from my discussions and own personal experience in working with telecom standards is time its consuming: no clear reading path; repeatedly going back and forth between all these docs to “get” the picture; small details can be critical. This is a standard NOT designed to be open, but only accessible to the people involved in the standards definition.
Then on development and testing, some of the challenges include:
- SIP: selecting a platform and framework to develop on, IMS compatibility, features
- Developing directly from a barebones SIP stack time consuming, reinventing the wheel, IMS extensions are rather exotic even to SIP experts, effort is greater than one man year with an expert
- MSRP: not much used outside RCS, expertise scarce, no good quality open source stack, most commercial stacks are client-side based (not focused on scalability). Limited sources
- RCS client: implementing state machines (registration, capability exchange, chat sessions, FT sessions) and interactions between them
- This is not a stateless API definition like REST this is a stateful protocol
- Very scarce development expertise on RCS and IMS
- Hiring would be bottleneck, either direct staff or finding competent outsourcing.
- Beware that RCS outsourcers have exclusively worked on client side not on the network.
- Testing requires being part of the ecosystem: established players resist new entrants
- Relying on operator arm twisting to complain?
- Possible but time consuming and relation straining: scarce resource excuse will always be at hand (and probably true)
- Even more scarce integration/deployment expertise to face 3rd party testing issues
- Setting up and maintaining an internal development lab is a non-trivial effort – half a man year
- Tasks like analyzing logs require deep knowledge of standards AND nuances/idiosyncrasies of current system (some of them non-standard complaint) – deep expertise
All this is done on purpose to keep RCS an exclusive club, which of course raises prices. Some of the technology choices such as MSRP and XCAP make doing simple things like sending the message “Hi” incredibly inefficient, 20KB versus <1KB for WhatsApp due to all of the overheads of the various protocol layers (MSRP, SDP, SIP).
The GSMA needs to be honest with its members; no BS like we saw with WAC in ‘joining forces’. An RCS reset is urgently required, I’ve called for this in the past, but urgent corrective action is well overdue. If MWC 2015 takes place and the same “wait for it” RCS drivel is played out, the GSMA demonstrates it is completely out of touch with the market and common sense.
Drop all the UNI stuff, get a vastly simplified NNI (Network Network Interface) spec out so operator comms clients; whether it is Libon, or IMS, or CounterPath, or Kandy, or Damaka, or one of the close to 1000 clients out there; can federate simply without all the gross complexity and cost built into RCS. To the telcos: stop accepting failure from the GSMA, stop them wasting time on conference organizing, get them focused on doing what is right for the telcos, their customers. RCS in its current form has failed, reset the program and focus on a vastly simplified NNI that reflects market realities.
A good point raised when I bring up the need for a reset is “Well how are you to do this with QoS? The RCS NNI has to be built on IMS if you’re to bill for it using IPX, at which point you’ll end up with something that looks almost identical to RCS anyway.” Those 2 legacy assumptions of the need to bill per event and the need for QoS keep killing progress. Let’s get a best effort NNI that assumes there is no need for billing as its just subscription services. Its where your customers are today. Then a lightweight, quick, and easy NNI is possible. Those that believe that bit of QoS matters and customers want to be nickel and dimed for every roaming transaction can then spend another 8 years arguing. While the rest of the industry can move forward in remaining relevant to their customers.