Tuesday, May 29, 2012

Solaiemes RCS-e API technology compatible with Newpace RCS-e core solution

We are glad to announce the compatibility between our RCS-e 3rd party REST API Exposure technology with the Newpace RCS-e Core.

The Solaiemes RCS-e 3rd party REST API Exposure technology was tested with the Newpace RCS as a Service product core. When combined, these two products provide operators’ an RCS-e in the Box solution with an RCS REST API exposure that allows our customers to create third party services and web access clients on top of NewPace’s hosted RCS-e/joyn services seamlessly.

Newpace RCS-e as a Service (hosted) allows telcos to deploy RCS-e/Joyn minimizing the CAPEX investment. Solaiemes platforms can be also offered "as a Service"(link), making feasible for MNOs to deploy in a very short time RCS-e service with additional services as web access and 3rd party services on top of the basic Joyn services created with REST API.

We are putting the each one innovation overcoming the issues (or myths) that stopped RCS-e deployments:

- No need of a full IMS draining CAPEX budget.
- Having from the beginning a platform for innovations by 3rd parties (CRM services, internet mashup, user generated content in social media using Joyn features from your phonebook, etc).
- Affordable alternative for MVNO's and non tier-1 MNOs to launch RCS-e with a minimum investment and no risk.

For us it is important proving that vendors are cooperating to help telcos to deliver the next big thing in messaging and add value to the telco enablers.
(read the post by Newpace).


Thursday, May 24, 2012

Is "Solaiemes RCS-e REST API" Cloud based?

We are being asked whether the way we expose RCS-e capabilities as REST API is "cloud". Well, our platforms are instancing RCS-e Virtual Clients, behaving as "clients" and exposed to internet. In previous post we explain how our platforms installed in the MNO premises become an "extra mile" of their infrastructure, following the SBC. But it is not the only one possible way of using our infrastrucute. We may also install it directly in internet and the virtual RCS-e Virtual Clients (services or web clients) will be registering to the telco RCS-e via internet as device client does.

Even the MNOs are preferring to have "all what they consider infrastructure" in their datacenters, this Cloud based RCS-e API exposure is the way that we are currently providing remote demos and engagement/try&buy pilots, and the interoperation is very easy to the telco core, only need to know the IP Address of SBC or P-CSCF. Yes, it works. Also it has additional advantadges as RCS-e Solution Gateway and RCS-e Thin Client Server are multitenant and can instance RCS-e Virtual Clients in different MNOs/cores/domains. Yes, we need to be flexible and it allows to offer the RCS-e REST API exposure as a Service :-)


Right now, there are appearing vendors with a RCS-e Core as a Service solution (or RCS-e in a Box cloud based) as Newpace. Then it is possible partnering to create a bundle of RCS-e as a Service offering plus our Value Added Services and Thin/Web Client access on top of RCS-e enabling platforms. You can see the chart. It becomes a nice way to deliver #telcoOTT RCS-e with no CAPEX investment.
From the point of view of where our platform can run it is possible both, in dedicated servers, or in public cloud virtual machines, all combinations tested and working fine :-) Then, we can say that Solaiemes is a cloud communications infrastructure/service provider. Feedback welcomed.


Monday, May 14, 2012

Our views on CTIA Wireless 2012.

Last week we were in New Orleans exhibiting at CTIA and it was great. Perhaps it is true that CTIA is loosing some big exhibitors once NA & LATAM are opting for UMTS as 3G and LTE as 4G and then the MWC is becoming the main marketing event for big players.
Instead, CTIA had a lot of vibrant companies showcasing pure innovations, small companies delivering high end innovation to help carriers and delight users.
We focus our presence in evangelizing and explain why messaging (RCS, RCS-e, Joyn) must become a platform, not only a person to person messaging alternative to the existing ones.
We had very positive feedback about our Friendly Telco Border concept and how we apply it to RCS case by delivering REST API (easy to use for whatever non-telco aware developer) to create both: services and web/thin clients.
Several telcos agreed that they way to compete is exposing the telco enablers in the way it could be used by third parties and Parlay and face to face interoperations with core infrastructure are not the way. Several MNOs are waiting for first RCS-e live deployments and the availability or out of the box enabled device to start the proccess of launching: RFI, trial, etc but expecting that time to market will be less than 6 months as they will be deploying already interoperated technology and native clients. Crossing fingers then.
Finally we talk with other core vendors to partner in areas where we are clearly not overlapped but complementing and creating a powerful end-to-end.
Hope to tell you news about this point in the next weeks.


Wednesday, May 2, 2012

The way our RCS-e/Joyn REST API exposure works.

Solaiemes approach to the need of exposing carriers communication capabilities to 3rd parties was radically different to the previous ones. In the past, the attempts to expose capabilities to create services were based in OSA, Parlay, etc, more thought to offer professional services the own infrastructure vendors than a proper exposure to the vast ecosystem of developers. Our approach is simple, expose not directly from the core infrastructure but as "clients". We instance virtual clients (telco protocols of the clients being kept at carrier cloud) and in the case of our web-clients strategy. In this case the RCS-e Virtual Client API is not used to create an alternative UI in a device but to create a service based on messaging interaction (as it was done with SMS to create A2P and P2A cases).
The chart.

(click to enlarge)

We were awarded by this approach. As you can see, the 3rd party API is core vendor independent (no lock-in then), as it behaves as "client", we can say we are interoperated with the main vendors of IMS, Instant Messaging Server and the SBC leader. What we provide is that "extra mile" for telcos to create a new frontier, the one we name FTB (Friendly Telco Border). With our approach "plug & play" whatever RCS-e core can have integrated a 3rd party REST and SOAP WS exposure in less than a week and RCS-e automatically becomes a platform to create value added services (application to person and person to application) complementing the person to person messaging (initial use case). You can see in the chart how device clients interact with "service clients" representing services (i.e: CRM). Those "service identities" (additional contacts in the user phonebook) will be a new revenue stream for carriers, and if they are defined as SIP URI, also a new business model appears: the domaining based on the names of the services to be deployed. If we see how amazing companies as Voxeo, Twilio etc are succeeding "selling" communication capabilities, we see that they approach the developers/customers offering the interface they know how to use and needing none/minimum support: internet style APIs (REST & SOAP). Time for telcos to make their try in the way developers can embrace it :-)