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.