Solaiemes Q&A about our technology for RCS-e/Joyn

We are often asked by potential customers, potential partners and telco analysts which is exactly what we are doing and how it could match with complementary offerings or instead become competitors from other vendors. We had compiled the most relevant questions and use this post to explain in this Q&A format what we do, hope it helps :-)

When did you start your RCS technology development? In mid 2009 but with the base of our previous IMS VideoShare and Push To Talk SIP, MSRP and RTP/RTCP technology and IMS integration experience. At that time RCS appeared as unlikely possibility for future with many telcos still believing that SMS will never decline. Successful OTT alternatives and the need to fill LTE with services made finally telcos to make the move and speed up RCS-e/Joyn.

Are you developing an RCS-e Instant Messaging Server? No, we saw from the beginning that big players, the IMS vendors were also offering the IM Server, and it is difficult to compete with the giants in risk avoiding companies as telcos, our only chance was doing something that nobody else was doing at that moment and this "something" was key to solve "a problem".

Which "problem" did you try to solve with your RCS-e technology? We tried to solve the problem of amazing telco enablers not being used for creating cases on top due the lack of proper interfaces to engage the developers. It was done in the past with SMS, where SMS Gateways with REST APIs brought a lot of value on top of SMS, and lots of use cases could be created by 3rd parties. Unfortunately that model was not applied to next comms enablers as PTT, VideoCall, or IMS VideoShare. Also Parlay APIs are more a tool for professional services of infrastructure vendors than an effective way to attract the ecosystem to create services.

How did you that? We created infrastructure instancing "virtual RCS clients", managed by REST API, "user to network interface", fully IMS and Instant Messaging vendor independent, no lock-in.
Those "virtual clients" could be used with the API to create interactive services (as SMS short numbers in the past) or just to create RCS thin/web clients to put ubiquitously RCS in tablets, pc, TV, without the need of developing all telco protocol stuff. We named it RCS-e Open & Ubiquitous. We were awarded with the GSMA RCS DevChallenge Innovation Category.

This interactive services based on RCS-e interaction using your virtual clients are the alternative to apps? Well, this approach is good for telcos, as they can offer their "service stores" conterpartying the "app stores" where the key role belongs to the platform owner (manufacturers or OS providers). Each model has strengths and weaknesses, telcos may take profit of the mass market if they can put Joyn in every device as SMS is in every device. We would say that we help telcos to add value on top of the "connectivity".

Then, all of your products is UNI ? No, we have also 2 products that can not be considered UNI "user to network" interface. The RCS-e End User Confirmation Request Server is considered core

And do you have an IMS Application Server, core architecture to extend your portfolio?
Yes, RCS-e Personal Manager, our platform to allow users to customize their own messaging completion settings include Options & Invite AS, using standardized ISC interface with IMS.

Is your technology interoperated with different IMS and clients vendors? Yes, current customer projects, GSMA RCS tests fests in the last 2 years and particular interoperation conducted for partnership enablement. We could say that we are interoperated with the IMS, IM Server and client of a live network.

Are telcos already using your technology? Yes. Unfortunately tight NDAs do not allow us to disclose too much but currently the Solaiemes technology is being used to create services and new use cases based on RCS-e/Joyn interaction. Also, we are bidding in other telcos and conducting demos that make us confident in extend our customer in the next months.

What do you think about the "RCS too little too late" sentence? We totally disagree, we create technology to make RCS-e a platform to create cases on top (beyond the person to person messaging case being implemented by OTT) and also to put RCS-e in devices (with thin clients) with no HW/SW capabilities to run the OTT messaging apps. Services created with Solaiemes gateway are not offered by current OTTs.

Are you working with or receiving kinds of interes coming from non-telco companies? Yes, we are receiving info requests from companies developing apps for big brands interested in using our API to provide alternative channels to interact with users for their customers (retailers, transportation, banking). A few companies are also testing the API to create proof of concepts of interaction and CRM , they find it easy, as easy to develope with Twitter of Facebook API. The most important is that this is not a religious topic, the same companies offering Apps development is interested in offering also rich messaging interaction service. Channels are mutually complementary.

The API, is really REST? so easy? Yes, it was our aim, devs can not te engaged with Parlay type APIs. Our API is offered with 2 flavours REST and SOAP WS.

What do you think about OTT messaging companies? We think they are great alternatives and did an incredible work, Whatsapp, BBM, iMessage, Huddle, etc... Their success finally evangelized telcos about users like the enhanced messaging experience and speed up RCS initiative that was walking too slowly :-). Thanks to OTTs Joyn is in the market right now and almost anybody may understand the basics.

What do you think about #TelcoOTT strategies? We think it is a great approach, telcos may have two souls, two business, the "lines and data" and the "services on top" that could even reach their not "line & data" customers. Our technology allows telco to make their TelcoOTT offering, as can provide communications services beyond their data, i.e: put Joyn in a TV connected to a DSL provider.

Are you intending to certify your virtual clients officially?  Yes, we already sent test traces to GSMA following the procedure.

What about RCS release 5? We started with RCS release 2, once the RCS-e spec was released it took only 3 weeks to have our RCS virtual client ported to the new spec and new API calls added to support RCS-e different features. Our aim is to be also compatible with RCS 5, mainly due the interest of american carriers in this release, and we are involved in the UNI API for this release. Our API will support all live in the market RCS-e client specs.

Last but not less, do you think Joyn will succeed? Yes, obviously we are partial in this, but the common brand/logo (Joyn), the kinds of interest received, and that finally telcos should decide pipe or added value on top, time is gold :-)

And Solaiemes future? Well, we are positive, we are extending our customer base and new prospects are coming, also we are negotiating partnerships to resell our technology, we expect to grow. We have the best team on board to achieve it and hopefully the resources to increase our company size to attend all the opportunities we can be involved :-)

Finally, if you have a question, we can complete this post with your question!

Questions from comments

[Alan Quayle, analyst] Where's the money in RCSe/5? We think person to person mobile messaging is commoditized, and the money can come from:
- Using Joyn in basic devices / feature phones, serving the underserved and extending the adoption of entrly level data plans to most of the subscribers.
- Using Joyn/RCS-e as a platform to create services on top, A2P and P2A use cases with revenue share with developers (as SMS in the past, but hopefully at more affordable pricing addressing the long tail)
- Revenue from 3rd parties using Joyn an additional channel to reach their customers and also to secure transaction with special features (EUC), i.e: banks.
- TelcoOTT strategy, charging a bit for communications services (RCS-e) customer that is not a "telco customer", it means, offering the communications services to non "connectivity" customers.

[Dean Bubley, analyst] What is going to change user behaviour & make existing OTT users switch from using WhatsApp, FB, BBM, FaceTime etc to using Joyn? Well, firstly there are a big mass of underserved users of rich messaging, event smartphone penetration is growing fastly, today, more than 70% of users still can not use OTT alternatives.
In the other hand, if properly integrated in the phonebook (as many OTT) to start a Joyn chat or file transfer may be a natural act, as it was SMS or call. We think it is not about one alternative killing others, it is about complementing. Our aim to increase early Joyn adoption is its use as enabler, something that today is not being offered by OTT.

[Dean Bubley, analyst] What developer use cases might the RCS API support that other ecosystems' APIs cannot? Firstly, we can differentiate 2 types of complementary APIs, the device API (pioneered by Jibe Mobile) to allow apps developers to use internally RCS for their comms (saving time avoiding reinvent the wheel and also making arrive in example your score playing a game to a non-game user) and the network UNI API (the one we are pioneering) enabling to create interactive services without specific apps, just rich interaction with a phone contact. CRM boots are being used in the internet space (Voxeo-Imfied) and studies confirmed young people like texting, and the young people is the coming heavy user generation. As in the previous question it is not about one API killing others, is about talented developers combining all APIs (from internet services and from communication enablers) and creating compelling mash-ups bringing lots of use cases to all type of users in whatever device they need to use it.
Carriers and infrastructure vendors may be realistic about that they can not imagine and create all possible services/use cases people would enjoy, then, the proper approach it make easy for those talented 3rd parties to create on top of your communication enablers and find a fair way to share the possible revenue.