A Practical Look at CPaaS for Over-the-Top Applications

“Great strategy is consummately practical.”

- Salam Al Shereida

 

Anyone who has followed my writing over the past several years knows that I am a practical, nuts and bolts kind of guy. While there is nothing wrong with high-level discussions, I like to get my hands dirty by working with the technology I write about. Sometimes, that means sitting down with a protocol analyzer and watch packets fly across the Internet, but often, it involves writing software that exercises whatever it is that has captured my attention.

 

My latest interest is communications platform as a service (CPaaS). Given the number of articles written about CPaaS, many others in my field are also interested in it. I’ve learned quite a bit from my fellow bloggers, but most take the big picture approach and pontificate on the benefits of CPaaS without ever sitting down and playing with it. Personally, I need more than that and expect that there others out there who feel the same. So, to help quench that thirst for a deeper understanding, allow me to unpeel the CPaaS onion and take you on a deeper journey into what it can do for you.

 

It all begins with application programming interfaces (APIs). As a born in the cloud technology, CPaaS exposes its features and functionality through a series of RESTful interfaces, which allows developers to pick and choose what they want to use from a CPaaS platform. If SMS text features are all that is needed, the developer sticks to those APIs. If only voice is needed, the developer will spend their time working with the inbound and/or outbound voice APIs and ignore the SMS APIs. It’s like going to a grocery store and only putting the things you want into your shopping cart.

 

For the remainder of this article, I will show some of what the Avaya and Twilio CPaaS platforms deliver and how their APIs can help build over-the-top applications.

 

It wasn’t all that long ago that programmatic access to text messaging was an expensive and complicated process. With CPaaS, sending a text message can be accomplished with a few lines of code and can cost as little as $.0075 for Twilio and $.005 for Avaya. Receiving a text message is still $.0075 for Twilio, and Avaya gives it away for free.

 

For both platforms, sending a text message is accomplished by making a RESTful POST where the message body contains the sender, the recipient, and the message. For example, an Avaya call looks like this:

https://api.avayacloud.com/v2/Accounts/{account SID}/SMS/Messages.json

 

On Twilio you would do this:

https://api.twilio.com/2010-04-01/Accounts/{Account SID}/Messages.json

 

By design or accident, the APIs look nearly identical and are as simple to use.

 

The use cases for outbound SMS are nearly endless. Imagine a situation that requires some form of outbound notification, anything from emergency notification to process monitoring. With APIs as easy as these, programmers without an ounce of communications experience can quickly add SMS text without understanding what Twilio and Avaya are doing to make it possible.

 

Contrary to what you may have heard, voice is not dead. Granted, while other forms of communication have significantly gained in popularity, they have yet to kill off the old-fashioned telephone call. I would rather send an email than dial a number, but I still rely on voice when I need immediate attention. However, I have little to no use for a physical telephone connected to a “brick-and-mortar” telephone system. I use cloud telephony on both my PC and mobile devices when I want to talk with someone or something.

 

Voice is one of the areas where CPaaS offers the biggest bang for the buck. Unlike legacy telephone systems connected to legacy carriers, CPaaS excels at scaling up and down. This is true for both the number of simultaneous voice connections and the resources used to access those connections. For instance, I can acquire a new CPaaS telephone number in a matter of seconds. That same process can take days or even weeks with legacy systems.

 

As with SMS text, making an outbound phone call with Twilio or Avaya CPaaS is trivial. You start by acquiring a telephone number. You then use that number in your application.

 

In my previous examples, I showed you how to send a text message with a RESTful API call. Both platforms also supply SDKs (Software Development Kits) for the most common programming languages. Making a telephone call from a node.js application using Twilio is as simple as:

client.calls.create({telephony-parameters})

 

Doing the same with Avaya looks like this:

connector.makeCall({telephony-parameters})

 

Both platforms support playing announcements, answering machine detection, sending DTMF, etc. for outgoing calls.

 

As before, the use cases are limitless. Personally, I’ve used CPaaS voice to spin-up voice notification applications in just a few minutes. This includes the time it took to log into my CPaaS account and purchase a new telephone number.

 

Outgoing voice is exciting but processing incoming voice calls is typically far more important to enterprises. To support this, Avaya and Twilio allow applications to register webhooks against a number. When a call arrives, the webhook is invoked, and the application returns instructions on what to do next. These instructions include:

The application can request that CPaaS invoke the webhook again after each instruction has been carried out. This allows an application to remain in the call flow for as long as necessary.

 

If you aren’t thinking technologies like IVR, then you aren’t paying attention. In fact, I have spun up highly functional cloud IVRs in a few hours. Better yet, I have connected my applications to other cloud platforms such as Google Dialogflow and ServiceNow to create AI-powered helpdesks that dynamically scaled up and down depending on the call volume.

 

Beyond SMS and voice, Avaya and Twilio CPaaS support functions to manage recordings and transcriptions, perform carrier lookups on telephone numbers, configure SIP trunks, implement fraud control, acquire and release telephone numbers, create and manage conference calls, etc. Each functional area is supported by both RESTful web services and traditional language SDKs. And as you’ve already seen, if you learn one platform, it’s trivial to learn the other.

 

CPaaS is reshaping the way that many enterprises are looking at communications. While some may move everything to the cloud, others are more interested in creating over-the-top solutions that augment and happily coexist with their existing communications platforms. CPaaS’ by-the-drink pricing allows you to choose how much you want and how quickly you want it. I wasn’t exaggerating when I said that powerful solutions could be developed in minutes. As an old-school telephony guy, I know how difficult those same things were with legacy platforms. And as a practical guy, I would rather spend my time and money developing CPaaS solutions.