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.
It does make you wonder whether OTT-style federation technologies like XMPP and Matrix.org can step up and provide a more pragmatic federation standard between the MNOs for communication app use cases. Layering things like distributed message history and federated group chat on top of SIP/IMS/IPX is not exactly a natural fit.
Good points Matt, I think there are many modern ways the aims of delivering a federated rich communications service can be delivered that allows service providers to experiment to meet the specific needs of different customer groups. WhatsApp and LINE try to be all things to all people. Wire is a great example of trying to make comms simple and easy. Today we have the complex social dance of remembering which platform someone is more responsive on. And its ever changing. For example, I get this excuses of “sorry I do not check Skype that often now as we’re using Slack these days.” As comms becomes increasingly embedded the need for closed silos (WhatsApp / LINE / Skype) will start to wane and federation will grow in importance – its about making it easy and successful for the user. Telcos can either lead in IP comms federation (as they led in circuit switched federation) or reactively follow.
I don’t buy this federation concept for the most part.
Three reasons for this:
a) The most advanced & innovative services have unique characteristics that don’t “federate” well – for example ephemeral messaging, pseudonyms and different identity-spaces, different forms of presence (online vs. last-seen) and so on. You can’t federate apples & oranges – there may well be no common denominators at all.
b) User behaviour will align with particular tools for specific intentions and contexts – as well as personal preferences. We’re much more likely to have the web as a “guest mode” if needed, as Libon already does. There’s no need to go down a layer, unless it’s all the way to email or SMS.
c) I think this whole idea of “richness” is absurd. It’s a classic case of bad analogy deceiving our brains – we look at the word “rich” and think it must mean “good” because it relates to money. Yet in a RCS context it comes with *poverty* not richness – the constraints of phone-number only identities, the interruption model of user-interaction and so on. True richness comes from adding features that convey purpose or improve effectiveness. Irrelevant video-calling in a messaging app isn’t “rich”, it’s “residue”.
Hi Dean,
a) Agree, federation would only be for a base level of functionality – basic presence (online), messaging and perhaps voice. Your communication likes and dislikes are well know 😉 So why can you not at least use your preferred client than have me try and fail to have you join a Hangout? Federation is only for those services that see some value in federation as the hook into me being their user is some other value.
An important trend is comms getting embedded into apps, services, and business processes. Currently the comms is very much process specific, but as it becomes general purpose you can imagine scenarios where I’m on Reddit and share with you a conversation on a topic, which we then take into a call to bitch about the other retards commenting. That reach out (single click) will benefit greatly from federation, as Reddit has people there because of the online discussion, our conversation enhances our experience only, Reddit has no winner-takes–all need for adding comms. I think as embedding comms grows, the case for federation grows. Its not universal – the silos will remain silos.
b) Guest mode is an option, not the most easiest for the user. Could it be slicker with federation?
c) Yes, Rich is a crap term. And does cause false assumptions. Telcos need action in communications, waiting for RCS is gross incompetence. Let diversity reign and let telcos federate as they do today without the millstones of QoS and charging.
It’s worth noting that well-designed federation can give you the highest-common denominator quality of experience between two silos – it doesn’t have to be the lowest-common denominator ‘core’ functionality. For instance, both XMPP and Matrix let you specify arbitrary extensible message types to pass around over federation. So if you have two platforms which support something like ephemeral messaging, then as long as they both use the same ephemeral messaging extension, it’d work fine.
That said, the more exotic a feature is, the less likelihood of an app exposing it for federation. So in practice the real value of federation ends up being ensuring a baseline feature set of communication. XMPP’s baseline is sadly a bit too minimal, whereas Matrix gives you federated group chat, full conversation history, voice/video, capability negotiation etc. in the baseline. Hopefully this is useful enough for the common generic use case of “i just want to talk or chat”. Meanwhile if you actually do want to start using fancy differentiating features from a specific app… then that’s a good time to switch over to your app (and rejoice in the fact that federation means that your conversation history and identity remain intact as you switch 🙂
To use the email analogy: 90% of the time I write an email I’m quite happy to send it in plaintext, and it might as well be from my iPhone or from PINE or Gmail or whatever. If I actually want to start embedding HTML tables and markup in it, then I’ll go break out Thunderbird or Outlook for support of those exotic extensions. At no point does federation break down on me.
I don’t think the problem of federation is specific to a protocol and for sure not to SIP. There is nothing xmpp (or other protocol) does with federation and SIP cannot do – at the end it can resume to DNS+TLS and you get all that is needed to federate. All the other things like API keys, etc, are just fancy elements that can be added in SIP header as they are usually now in HTTP packets.
The problem with federation is how Telcos are used to work, with closed agreements between each others rather than open peering. And I don’t expect that will change any time soon in the big telcos.
Otherwise, I do agree that SIP SIMPLE presence specs are a big failure for the authors, especially given the several layers to be considered, with OMA/GSMA extensions. The initial presence specs (end-to-end, similar to what xmpp or others like skype used to have), still works fine. Unfortunately those specs not continued by IETF and it is missing the specs for centralised storage of contacts (not necessary on the provider server, e.g., I can store it on dropbox), which should be easy to deal with as just store/fetch operations with a known document format (vcard, or some xml/json/…). The rest should be the client handling.
A revised version and quick to get would be end-to-end subscriptions+notifications, plus what I said with centralized storage specs.
For sake of clarification: the end-to-end subscriptions+notifications is what the free version of bria – xlite – does (or used to do, haven’t checked lately). Practically the SIP server only forwards back and forth, no states, no scalability issues at the core. Also, as further note, KPhone had it from like year 2000, worked as long as I could install it, because it was built with the QT version at that time and the version is no longer supported/available on major linux distros.
The missing piece: the contact are stored locally and sync’ing across devices is not straightforward – the only piece that needs to be specified as a ‘standard’ (here it can be used xcap format, but I would rather see something new and better (mainly expecting ‘simpler’) given its adoption so far is not significant.
Considering that SUBSCRIBE and NOTIFY use the same format as for SIMPLE specs, even those that went RCS path have it half done and actually they need to remove a lot and just add some small bits instead.
I’m not sure it’s accurate to say that there’s “nothing xmpp (or other protocol) does with federation that SIP cannot do”… Agreed that SIP and XMPP are fairly low-level building blocks for federated method invocation and federated message-passing (respectively). But if you’re wanting to federate today’s communication apps on top of this you need much more expressive higher-level semantics – you need to incrementally synchronise conversation history, not just pass messages. You need to sign the integrity of that history. You may want to encrypt the message end-to-end and perhaps obfuscate the metadata. And for this you need a much higher level protocol than baseline SIP and XMPP. There are some XEP options for doing this with XMPP; meanwhile Matrix has it baked in; but I know of nobody who has tried to layer this on top of SIP. Whilst you /could/ conceivably shoehorn these semantics on top of SIP (or even IMS), it would be quite ungainly to do so. In the end SIP was designed for initiating sessions, not synchronising data structures.
In terms of open federation… yes, telcos do closed federation – I guess in the end this is because it’s easier to bill users and charge people for interconnected traffic when you know who they are and you have a contract in place with them. This isn’t going to change anytime soon; the value of the PSTN’s physical ubiquity, universal namespace (E.164) and network QoS is huge. (As great as QoE is, it’s sometimes nice to know you have a guaranteed pipe and don’t have to fight against other traffic once you hit the copper).
However, this doesn’t stop open federation from existing on the internet. After all: email, the web, and even the internet itself are great examples of rich open federations which work staggeringly well. It’s a shame that XMPP and SIP haven’t taken over the world for VoIP/IM open federation, but I don’t think this is a problem with VoIP/IM itself. We should be looking to ways to make open federation work on the ‘net – and if we can build a healthy ecosystem there, perhaps it’s one that the telcos may adopt too (and provide the billing functions and bridge to the PSTN). [Disclaimer, I run matrix.org and so am a bit biased on this :)]
Finally, totally agreed that end-to-end RFC3265 pubsub is a fine foundation for basic presence. Meanwhile the fact RFC6914 has to exist at all makes me very sad (and it doesn’t even cover the OMA and GSMA stuff).
I haven’t really looked at matrix.org protocol, but I guess it is rather young and therefore hard for someone to express any viability on large deployments. On the other hand, even I do primarily SIP, I am fairly familiar with the core of xmpp protocol (wrote first sip-xmpp gateway for IM&P back in 2003, and keep using for various projects since then). It has benefits and but also drawbacks, but I don’t think that would be something to stress out here.
Anyhow, every day we can come up with better ideas, but really matters the effort to get something deployed and maintenance costs. Now that most of telcos have a SIP core (I won’t call that IMS, besides being more mobile oriented, there are many mobile operators with just SIP routing core), deploying a parallel system requires to integrate it with the core infrastructure to become a single product. That means development effort, no matter is has to be done for xmpp or other protocol. Then, for deployments, practically the infrastructure is doubled in terms of nodes (virtual or physical, one has to care of availability, redundancy, upgrades, etc…). There are specs for combining SIP+XMPP (CUSAX), but I haven’t seen any big movement towards, due to infrastructure costs. I even pushed for it myself at some point.
To resume on the above, either way there is development effort:
– integrate existing core with another platform (which would require eventual a standardisation as well)
– reset/revisit the specs and develop on top of what is at the core, reusing a substantial part
Now, not sure what you really expect from “incrementally synchronise conversation history”, but you have with sip from the very early days:
– store and forward (202 Accepted reply)
– expiration of messages (if you want something ephemeral – Expires header)
– sip was designed for end-to-end communications (only location discovery via a server, then directly between the users). That’s implicitly, not to do so requires extra things (e.g, add Record-Route headers). It is just the operators doing it with server in the middle always (for billing or legal requirements or nat traversal).
– there can be used a direct connection between two sip clients, without any server at any time in between, which is not in xmpp. OTR or the like work for IM with SIP. For end to end encryption I am not sure if any other protocol offers much more options.
Maybe a bit offtopic, but somehow related, I am not happy how IETF (not to say GSMA/OMA/…) ended up to work lately, where seem to be people just imaging things and writing specs. They must enforce a ‘write a reference implementation’ policy for anything that gets to RFC level. I like how XMPP managed to get many specs coming from community of developers, they are more realistic, being done mainly on needs, not dreams.
To conclude, I agree there is a need to reset SIP IM&Presence (or how some people refer as RCS/e) out there, but is more like ‘cut all the crap from the specs with server side presence agents aggregators’. RFC3265 is offering the (literal) simple layer for what 99% of people want/need for presence.
Yes, Matrix is very young (entered beta in December) and hasn’t been tested or deployed at scale yet, although it’s maturing fast. My point was more that the federation model in SIP and ‘traditional’ XMPP doesn’t support the requirements of modern communication apps. Whilst SIP/IMS may be fine for a telco core network made up of traditional phone calls and simple messaging, it fails badly for:
* Conversation history – especially if you want to federate and synchronise it between participants on different networks, or if persisting the conversation is its main purpose (e.g. gathering IOT data)
* Group communication (unless you force it to look like a voice conference)
* Synchronising arbitrary data between groups of federated users (e.g. whiteboarding, file synchronisation, extensible data you might want to store in a group chat, etc).
Whilst it would be lovely to build on top of SIP/IMS for use cases which need these features, I’m not convinced that shoehorning these semantics with additional layers on top of SIP or XMPP is the best choice – the stack of layers gets too tall, and the risk of impendance mismatches between the layers gets too large, and you may end up finding you’ve reinvented RCS. So whilst it would be great to be able to immediately layer this sort of thing on top of the carrier-grade SIP/IMS deployments out there, I think a more novel approach can be useful.
You asked: ‘not sure what you really expect from “incrementally synchronise conversation history”’ and mentioned store & forward, msg expiration, and p2p end-to-end sip as possibilities.
What I expect from “incrementally synchronise conversation history” is effectively an eventually consistent global distributed object database with pubsub semantics and federation. Communication is about synchronising state from A to B; SIP and XMPP do this by passing domain-specific messages and relying on B update its worldview as it best sees fit. If instead you consider a conversation as arbitrary data (including history) that needs to be synchronised between the participating members, then you end up passing state deltas between A and B which update a better defined common view of a conversation. This way you a) support group communication as a first class citizen; b) support conversation history as a first class citizen; c) support arbitrary data synchronisation of any kind between participants. The downside is that all participants are constrained to the same data model of the world, although if that model is sufficiently extensible and unconstraining this may not be a problem.
Obviously you /can/ just layer this on SIP (just use INFOs with state deltas in their bodies), or indeed on XMPP (like XEP-0289 and Buddycloud do), but you’re effectively just using SIP/XMPP as a transport layer then and entirely ignoring normal call/messaging flows. And it certainly doesn’t remotely match the IMS model. So when we implemented all this in Matrix, we just layered it on plain HTTP as a more agnostic baseline (with the option of using more efficient transports for those who need them), using HTTP as a relatively clean slate compared to SIP or XMPP’s baggage. This wasn’t due to ignorance of SIP or XMPP; we’d spent the last 10 years building out SIP-based solutions (SBCs, LBs, mediaservers, IVR, etc).
In terms of the importance of reference implementations – 100% agreed. It’s inexcusable to write a spec without showing it viable, working, useful and usable with a reference implementation. (That said, it’s also possible to swing too far the other way… currently the Matrix implementations are much more polished than the specification. Turns out writing RFCs can be harder than writing software :D)
Some of RCS features are still interesting such as Discovery Capabiliy, Content Sharing… if you have already VoLTE and ViLTE architecture and you want to add value on VoLTE and ViLTE. you don’t need RCS.
RCS API are interesting. RCS like app (or webRTC) is relevant if you speak about ViLTE as iPhonex will never support ViLTE (and it is relevant to have Visio available in all devices)…
Non silo Multi-device Rich Comm is relevant for operators with guaranteed QoE (and security)…
Would be interested to see what will happen in coming months regarding to Social Networks in severql countries with what has recently sadly happen in France. Start to speak about forbidding some OTT. For sure life of OTT will become less easy…
Warning: Very biased opinion ahead!
I have mixed feelings regarding this post, from “nice one”, to “been there, done that”.
While RCS seen from outside seems a complete mess done by crazy people, seen from inside it is even worst 😉
As I have spent almost 4 years participating in the RCS standardization process, I will try not to express personal opinions, or say what should be done instead (fortunately enough, I have left the Telco industry for now). I will not try to push RCS, neither, just try to put some rationale on the table about why things are like they are in RCS (and leave everyone else take their own conclusions).
First of all, I joined RCS task forces for release 4 specification. RCS was almost a dead end, no commercial deployments, not real MNO interest, and only some minor trials with quite bad results (both on the technology side and on customer experience). The specification process was lead by standards people, quite far away of reality and without any pressure of getting RCS to commercial deployments. The groups were well managed and process was very fluid, but veeery slow probably on the wrong directions.
Regarding the number of docs/endorsements, take note that the GSMA is not an SDOs, and can’t create new specs, but has to use the ones already available by others (mainly IETF/3GPP). And by the way, we did the HTTP REST spec for RCS also (with WebRTC support, which btw, I personally pushed for).
So, we did exactly what the post proposes, “resetting” RCS, that’s why RCS-e was born. Focusing on time to market, we were able to get some new (European) MNOs involved and committed for launching. In order to simplify, some functionality was removed (based on the trial results) mainly removing presence, and adding some missing basic functionality (come on, chat without store and forward??), moving the focus from presence/address book to chat/IM.
We needed to make some technical and political concessions in order to get to an agreement (“We need to be able to bill based on traffic type SIP vs RTP/MSRP, but we can charge for first message”, “Our IMS vendor provider don’t support GRUU, and won’t support it until next year, so we can’t do IM server forking”). All of that lead to some awful decisions that proved to be wrong, also we left some problems to be solved into the future (like S&F on GC) which we should have address better and earlier.
All of this was done outside of the area of influence of the GSMA, which got some vendors quite angry. IIRC we got even a lawsuit from the European commission of competence instantiated anonymously by some of the those angry vendors who thought we did it to favor to their competence. It was a quite intense work, and we did it in just two month, quite a record for RCS.. 😉
The good news was that RCS got some momentum, and we actually started to work on commercial deployments. I won’t explain much what was the pain of that.
First it was IMS deployment, which was either not deployed or deployed but optimized for VOIP (with very nasty shortcuts). There was no interconnection between MNOs and we had to start solving lots of problems that was not due to RCS, like DNS and ENUM integration (with national portability), MNO interworking (no interworking was in place at all), roaming, IPX, integration with VoLTE (I will come about that later).
Then, there was no IM server nor RCS client available, so we had to spend a lot of time and resources debugging and testing them. Also, we had to engage OEM for getting the native RCS implementations.
Last, was internal opposition from marketing departments and product managers, more worried of loosing their bonus due to SMS revenues loss than launching new service.
In the meanwhile, RCS-e initiative was adopted by the GSMA, and a new set of working groups was created,. Also, in the meanwhile, the North American operators started to make their own set of specs. We got the pressure to converge. That lead to caos.
We had different approach, different time lines and TTM, even different technologies (OMA CPM vs OMA IM). So that’s how RCS 5.0 was done, just a mix of two completely different standard (and incompatible btw) under same name.
Also, that lead to more problems, integration with VoLTE, which put a several architecture constrains in the table. Like avoiding two different registrations on the IMS core from the same device, dedicated APN for IMS, but not usable for MSRP, what do we do with WiFI? Also, we had a very strong push back of what I think was one of the most important features on RCS 5.0, voip calls over wifi.
And in the mean while, no important features was introduced, and main fixes (like store and forward and file transfer for GC) was left for 5.1.
So, not sure what is the right solution for Telcos, if RCS, an no IMS approach, an easy UNI/NNI solution, a pure “OTT” service, a non federated one, fortunately enough, I left the Telco industry before RCS 6.0 was started.. My personal opinion, is that any Telco initiative is doomed to failure, regardless of the model chosen.
Sergio
A beautiful, heart-felt, summary. Thank you Sergio 🙂 This captures the real history of RCS in a way Wikipedia could not allow to be told. The time for old-world, everyone and their pet cactus must agree telco initiatives is dead. Leadership is required. No nonsense, copy what’s already working (the Web), and start dumb with a MVP (Minimum Viable Product). The GSMA is the trade body for the industry – leadership not conference organizing is required. Its OK for GSMA people to have telcos demanding they be fired, their role is the future success of the industry not this quarter’s numbers or the end of year bonus, as long as they are moving the industry forward rather than in ever decreasing circles. Which is not the case today.
In my work with developers, tech vendors and telcos around the world, there are amazing successes. Just look at some of them described at TADSummit, http://www.tadsummit.com, and the amazing creativity displayed at TADHack, http://www.tadhack.com. I’m still very positive on the power of communications. Though I do agree that at present most telco initiative fail.
The problem of RCS was not the technical complexity, it was not easy but the technology was created anyway, the vendors created API for opennes and to make easy to access from non telco devices as SmartTV or plain web browsers.
What failed in the case of RCS was the real “aim/willingness” of telcos to be the first ones, take the risk of disrupting themselves and challenge their own SMS.
There is a lot of space to use the rich chat as platform for non person to person cases, the most popular chat apps as Whatsapp did not focus on that, and it was a nice space for telcos if properly were able to engage developers and create business models. It was the vision promoted by Solaiemes years ago, we see now how several of leading chat apps as Line and Wechat are creating that type of person to service interaction (even without a real public API for developers but it is the trend).
I disagree with Crutel above, about “it would be interesting what will happening” other year. Telcos seem happy seeing what happens even in the case is what is happening is that their value is being taken by other parties and they are doing little or nothing. I can not believe it!
If telcos want to make a serious try, they should deploy fast, and could be cloud based, the technology is ready and affordable, with focus on chat based service interactions and engaging the developers since day 1 with a web based self-service developer portal ot start filling RCS with content.
For us it is frustrating to be approached by banks, bus compaines, marketing companies interested in the chat based approach for services and the API to create easily services and discouraged by the lack of the availability of RCS yet and lack of availability of API in the available chat service as Whatsapp.
And fully agree about QoS is overated, and the QoE that users wants says “quality of experience = asap + let me know with feedback help you to improve the service”
Hi Juan,
I agree everything is there, but tier 2 telcos are being put off by crazy prices in RCS RFQs. This is a fact, and is leading to inaction. We need to find a way of breaking the impasse. Of making it easy, of removing most of the costs, so we can move forward. The industry is being held ransom by an out of date approach 🙁
I agree that RCS is moving slow….Consequently, we have not even bothered to update our 2013 – 2018 report to a 2014 version and may not for 2015 either !!
Fred, that straight forward commercial decision speaks volumes.
As you say, Juan, RCS is more an API enabler, allowing rich message support in Apps; with webRTC, there is an opportunity for providing voice/video/messaging capability available in Apps.
RCS as P2P solution does not make sense if it is just the same solution as WhatsApp…
If we can bring in any device (for example using webRTC), then there is some value-addition.
Juan: It’s always funny to hear about complaints against telcos. When I see the price of RCS vendors solutions, I would say that it does not always help the operators to make the choice (I saw a lot of vendors solution and a big average is not cheap … I would never say how it costs but it’s amazing.
You may not be able to say Patrice, but I can 😉 RCS RFQs are being halted as the costs presented make RCS inviable!
If one / the current problem of RCS is price (added on top of many others known from the beginning or discovered along time) , there are many Telco APIs available today from small vendors with nice and affordable business models that have already proved being competitive, effective and technically top of market. RCS is not needed from this point of view.
Problem is Carriers still find it hard to work with smaller vendors, but then they do they are positively surprised. It is time for a change of mind!
Hi Javier,
I think this is a key issue for telcos, how to work with smaller players yet not end up in a complex mess as smaller companies get bought, go bust, or pivot (fashionable term for change business). Telco MUST work with the smaller providers, innovation is not going to come from the vested interests of their strategic providers who are focused on $100M+ deals of IMS / SDP / RCS / etc. This is one of the reasons I think open source must play a much more significant role in the industry, the whole ecosystem then supports the code base. Axiata group is open sourcing MIFE (Mobile Internet Fulfillment Exchange) an interesting step in the right direction. Project Clearwater, Mobicents, Fairwaves, the list goes on of projects that are moving us in the right direction.
NEPS also see the value of this shift. The challenge is in my opinion not so much the marketing or strategy folks rather a complicity between certain product teams (IMS and SDP in particular) and the account management teams are blocking change. They’re behaving perfectly rationally, sell a $100M IMS project and make $2m bonus, and those product teams have big targets to fill so need all possible sales to remain employed. But it results in expensive projects that get trapped in a failure to launch. This is why telcos must take a firmer control over their future and work with smaller players and the risks and responsibilities that requires. BUT the timeline for the payback on such decisions is well over 1 year, which is a lifetime in the political games played within telcos. Hence leadership is required from the CEO and management team if telcos are to adapt to the web-centric world they find themselves in. It is a tall order and investors have clearly bet against this change happening, see telco multiples are now lower than utilities. But investors have a herd mentality, and are not always the best indicators of what the future can hold.
I see more and more projects surviving despite the best efforts of the establishment within NEPS and Telcos to kill them. Some are now generating good returned, e.g. Dialog’s IdeaMart. We just need many more successes and more determined individuals to force common sense through their organizations regardless of the toll that takes on them.
Alan
I find the call for a reset completely disconcerting. Especially since it is being called for on the basis of technical complexity, and pricing.
There are technically complete RCS solutions available, they implement every single aspect of the RCS 5.2 specification, they are accredited by the GSMA.
Pricing is always negotiable. However it takes two or more parties to negotiate. If operator’s want something they are going to have to pay for it. If they want something new, they have to be willing to be first (and therefore pay more for it) or wait for prices to decline.
Javier hit it on the head, the big vendors are unwilling to work with small companies with actual proven solutions. Many of the operators don’t realize the size of their competition — WhatsApp was ~40-50 people when it got noticed. Facebook’s own financial filings show it was only generating $15m in revenue and $2m in Cash on acquisition. The operators then put so many requirements on the small companies that the prices go up further.
Operators own internal roadblocks could have killed RCS, thankfully they haven’t yet. As someone working in the industry I will categorically say RCS is definitely not dead, there is significant activity, but it is well under the radar to casual analysts.
Hi Brent, long time no talk. Have a look at Genband’s announcement on the Fring Alliance (https://www.fringalliance.com) they’re doing what I recommended, a best effort interconnect for IP Communications. If they can get Libon and TU Go involved, it could be quite interesting, and break the ip communications log jam RCS has forced on the industry.
I did not say RCS is dead, I said it has failed (which is true based on my work and discussions with telcos that is far from casual). I called for a reset to get things moving (RCS started in 2007). Its nice to see Genband having a go with the Fring Alliance.
Alan,
Im not sure that RCS has created an “IP communications log jam”, but I agree that the technology selection (IMS, MSRP) created a need for specialized knowledge and that this is still causing issues (file transfer over MSRP vs HTTP). Thus the time taken to get everyone to a standard that interoperates globally is one of the reasons we are all frustrated.
The Fring alliance looks to me to be another attempt to combine the silo’s of proprietary messaging solutions that were never intended to federate in the first place. Federation (or ubiquity) is great topic for heated debate as it underlines the chasm in the ocean floor of telecommunications that has appeared in recent years. Ubiquity and Federation are pretty much dead or dieing terms, as users are more than happy to support multiple APPs to communicate in different methods to different SN.. Indeed the attraction of communication in this century is that you CAN communicate differently – the choice is pretty endless in ways to express yourself – contextual messaging is now king. We should stop trying to ‘fix’ this and thus I accept your reset request on those terms.
So where does that leave RCS? Potentially in 2 ways (1) it leaves it as a technology layer that operators can expose to the developer and M2M communities and (2) it becomes the natural progression for messaging as Telco operators move off CS and SS7 and deploy IP architectures to support HD voice. In (1), as Juan said, the underlying technology, when deployed and accessed using a simple 2 page REST API allows you to create different and powerful contextual communication tools that businesses and enterprises are asking for. In (2) Its worth noting that DT and Vf in Europe now have native RCS devices deployed, and they work really very well. RCS is now making great strides as the replacement for SMS and is available on SONY, SAMSUNG and LG handsets today. By the end of this year there will be very few handsets sold on those networks that don’t use RCS – If you haven’t used an RCS ‘blackbird’ device, then think of the native messaging app that operates on Android the same way iMessage does, with all the same features.
Brent is correct that there are many RCS solutions out there that are low cost and quick to deploy using cloud technologies. The cost of RCS isn’t really a barrier anymore, companies like his and mine are really helping Telco move away from big iron and into NFV’d cloud services, and prices are tumbling as a result.
The big question for the Telco CFO’s is whether ANY investment in messaging will make a return, given ubiquity isn’t valued and roaming dollars are gone. The answer sadly, is ‘not in the excel sheet you current use mr CFO’. The biggest reset needed IMO is how Telco delivers value to its customers for underlying services like chat, when the market value of those services is zero. Its really hard to beat free, but unless you deploy something, and have an advanced service layer capable of delivering contextual, relevant information, then you may as well pack up your bags and be happy to be the bit pipe of the future. We should reset our thinking of RCS in those terms.
Hi Neil,
Sorry its taken a week to publish your comment, its been a crazy couple of weeks for me.
I hope you agree: we’re agreed that something needs to change, waiting just another year is an inadequate strategy.
Telcos that are running RFQs which include your’s and Brent’s companies in the responses are complaining about costs. And as you know the total cost of deploying RCS is not just your costs, there are other vendors’ costs. And in the discussions on this weblog article a Telco has pointed out cost of RCS is a significant issue. I agree the way telcos make decisions today is anti-innovation, and I’ve discussed that in several articles on this weblog. So I hope we agree telcos need to change their processes on service innovation.
My only issue is on “proprietary messaging solutions that were never intended to federate.” Here I disagree, they can federate whether they were explicitly designed to is not a significant issue. You are going to see some interesting announcements through 2015 of services that federate the massive messaging silos created over the past couple of years.
Operators need to respond to what is happening in 2015, RCS can be part of that, but my recommendation is we need a lightweight best effort option to enable faster action. The Fring Alliance is something I think the RCS vendors could embrace, calling it OTT is dumbass (I’ve told Genband to stop calling Fring OTT), its best effort IP communications, and RCS (QoS-supported IP Communications) needs to find a way of accommodating it. As Doug pointed out in a similar Linkedin discussion kicked off by Quan of US Cellular – we need more ‘and’ than ‘or.’