Misconceptions About Communication Platform as a Service (CPaaS)

Recently, I was asked to speak about Public Cloud Services, and specifically, CPaaS (Communication Platform as a Service) during a training call. It was actually really good timing, because this has been a hot topic with vendors, partners, and customers. In those discussions, I find that there’s a lot of misconceptions about what CPaaS actually is. As mentioned, CPaaS stands for Communication Platform as a Service, but even that term can mislead you into thinking that it’s a much broader and more inclusive thing than it actually is.

At its most basic level, CPaaS is simply an API-based model for accessing carrier services and the media processing resources associated with those carrier services. Traditionally, PSTN-type carriers offered their carrier services via trunks. In the old days, there were CO trunks, DID trunks, DIOD trucks, etc. They were analog in nature. Then came digital trunks that came in the form of T1/DS1s (or bigger versions such as DS3, DS4, DS5, etc.), or even ISDN-PRI. But the introduction of SIP trunks is what really started to change things. They used VoIP (Voice over IP) in a very flexible and software-based way. They were able to transport the voice using regular IP-based data networks, like those found in the enterprise AND on the Internet.

It became obvious to some companies that leveraging this new SIP model could let them sell to a new type of customer. All they had to do was become a regulated carrier (if they weren’t already) and sell their services not in the form of regular trunks, but as API-based web services. This would let software developers create completely new types of applications that could leverage the PSTN as well as provide enhanced voice management and manipulation capabilities without needing a PBX to access traditional PSTN trunking. And like most “as a Service” models, the goal is to provide those capabilities with flexible and granular consumption models. So, instead of charging the customer hundreds/thousands of dollars for a trunk circuit, and requiring the customer to buy thousands or millions of dollars for a PBX to connect to those trunks, developers could now pay for the usage of these carrier services in “micro” transactions: just pay as you use it, and if you don’t use it, you don’t get charged.

These CPaaS Service Providers also generally offer SMS/MMS texting services. So, same as with voice, there’s no longer a need to buy an expensive SMS/MMS gateway anymore. You can send/receive text messages for pennies per transaction. Interestingly, Avaya is actually one of the few traditional Unified Communications (UC)/Contact Center (CC) manufacturers that is also a developer-agnostic CPaaS provider. They charge $1 per phone number per month, and charge $0.005 for each text you send, and for every text you receive is free. When you consider much we use SMS for things like chatbots, you can see how critical of a component CPaaS is to those applications.

While CPaaS providers focus their services mostly on Voice and SMS/MMS channels, the capabilities they provide for those channels are incredibly feature-rich. They’ll typically offer recording services, transcription, carrier lookups, fraud control, notifications, and usage monitoring/reporting. To give you an idea of what could be built using these services, look no further than to the apps that these CPaaS providers have created themselves, using their own CPaaS APIs. A great example of this for Avaya is Spaces. Their entire Workstream Collaboration platform is written leveraging their own CPaaS APIs. Amazon Web Services does the same thing with Amazon Connect.

But more importantly, it lets developers such as ConvergeOne build advanced applications using these CPaaS APIs. Most notably, C1 Conversations is a framework of its own microservice architecture that allows us to add Voice and SMS/MMS capabilities with CPaaS that can be agnostic and independent to an existing UC/CC solution. If fact, this is one of C1 Conversations’s biggest advantages. It becomes an integration “easy button” for UC/CC platforms, such as Avaya and Cisco, for contextual data mining, workflow, and user interfaces. It allows us to provide layered innovation to legacy platforms where the addition digital channels might not have been possible.

I like to use the analogy of Legos when it comes to understanding CPaaS. As a kid, you generally would fall into one of two groups when it came to Legos. Some of you LOVED buying the boxed kit (which is the group I belonged to), such as the Pirates of the Caribbean ship or maybe the Millennium Falcon, and you loved following the exact instructions to put it together. Maybe you even glued the pieces together so that your project wouldn’t fall apart. But the other group of you (which is the group my wife belonged to) loved sitting down with a huge tub of loose Lego pieces and putting something together from your own imagination. You knew that while you might have to go get some additional pieces that weren’t in your tub, with the right creativity you could build something amazing. BOTH groups of kids were right. It just depended on your creativity, skills, and preferences.

APIs are like Legos. Those API providers might have built their own kits using their APIs for you to just buy as-is, but these APIs are also available for application developers to consume in their own way to build something bigger, more unique, and more relevant. Since the APIs tend to be pretty specific in what they do, application developers must usually leverage APIs from a number of different providers. That’s why you’ll often see references to UCaaS (Unified Communications as a Service) and CCaaS (Contact Center as a Service), and so many more, right along with CPaaS.

Remember, CPaaS can enable you to build some really powerful apps, in very cost-effective ways. However, CPaaS specifically just provides API-driven carrier services—REALLY advanced functionality of carrier services, but still mostly just carrier services. You can see that without platforms like C1 Conversations, building those applications around APIs could be beyond a company’s internal skill sets. With C1 Conversations, we get the best of both worlds. We can create very robust customized solutions, made from standard integrations provided by these “as a Service” APIs, and get them to work together in an agile, cloud-based consumption model.