RCS-e/joyn is not just only for mobile carriers.

From time to time we are being asked about if RCS-e/joyn is a technology only for mobile telcos. Our answer is a big NO.
Although RCS-e/joyn is a technology pushed and promoted by the GSMA whose full members are mobile carriers, we see RCS as an new standard IP messaging that could be used ubiquitously with the advantages of the interoperation and federation.
Solaiemes strongly believes in the potential of RCS for triple play telcos, as they can offer a common and global reach messaging experience (hope in the next future joyn we adopted by most of the carriers) in all devices/screens under different types of connectivity.
We believe in the power of the REST RCS Network API to offer RCS-e web and connected TV [soon new video-demo, be patient :-) ] clients.
DSL, Fix & Cable operators can provide then "a new communication service", a personal communication service in the same way they offered in the past a complementary or low fee email account. In the case of the TV, it offers huge possibilities of having the biggest screen of your home to receive pics from family and friends and see them directly there. Also to see incoming videosharing from mobile. Why not have your family on the couch watching TV and being prompted by you streaming live video while hiking when the summit gets closer?
Communications are about sharing experiences, and innovation can be delivered by all actors in the communication space.
It is very easy to integrate the RCS capabilities in softphones provided by fix carriers, or set-top-boxes by cable operators. Also, it you can deliver RCS as web or TV Widget easily. No reason for non mobile telcos to think that they have little choice to bring additional fun and business use cases for their customers.
From CAPEX perspective, if fix or cable telcos are investing in IMS and SBC to provide VoIP or IP media, the same infrastructure can be used to deliver RCS, increasing ROI from already decided and needed investments with the extra cases.
Users will costume to keep several RCS accounts (identities) in the same way that they are right now owning several email accounts or OTT messaging IDs. Value added services as "aggregating" those accounts and let the users set their own messaging policy/rules (IM-Box, auto-responses, filters, messaging divert, videoshare divert etc), we have the IMS AS to allow that, the RCS-e Personal Manager.

- Why not being the fix, cable or broadband carriers being the first ones to deliver those experiences o personal freedom to their users?
- Why not triple play telcos start thinking in "communication as a whole" and not a mere addition different revenue source branches?
- Why not starting to offer fix/TV RCS portable to mobile if the non MNO is also a MVNO?

Solaiemes is a rebel company :-) We like to destroy topics: pioneer technology can be created in a country with no telco equipment companies tradition, small tech start-ups can compete head-to-head with big ones of the telco infrastructure industry (our common challenge these days) and we want to help also non-mobile telcos destroying the industry feeling that fix or cable telcos are not the coolest.

Let's give a try!

Solaiemes to offer 1st commercial implementation of OMA compliant RCS network API

We are glad to announce that our products RCS-e Solution Gateway, RCS-e Thin Client Server and RCS-e LiveServe exposing RCS-e capabilities as REST API are now offering the OMA compliant Rest version.
Our views on the need of standardized telco APIs were explained in the former post and in this interesting debate in the Telecom APIs group in Linkedin.
We believe that the key factor of API success is the early availability and to be offered in the "developer language", in the way they like to work, and today it is REST and SOAP WS. Our platforms were offering two flavours, REST and SOAP WS (as some customers consider it better for back-end integrations as CRM systems).
Now, Solaiemes is adding the support of the Open Mobile Alliance RCS Network API flavour which is also REST based.
The same platforms will be exposing simoutaneusly the 3 API flavours and developers will have the freedom to choose the one which fits better with their needs.
Both, our initial REST implementation and the OMA one are REST but we decided to keep also our own version as it is covering some topics that the OMA spec is missing.

We look forward that this move will help telcos to launch RCS-e/Joyn as a platform. It means API for ubiquity, person to application and application to person cases to be offered at the same time that the RCS-e person to person enhanced messaging launch dates :-)