What do you need to run a cloud-based telephony application?

What you need to run a cloud-based telephony application: The

 difference between traditional hardware-based and cloud-based

deployments

Ok, you’re sold on the benefits of cloud computing. You understand it means you can take advantage of computing resources that are owned and managed by someone else.  That’s great!  But you want to know what that means in relation to telecommunications, if you need any additional hardware or software, who takes care of the PSTN connection, how you can access the telephony resources in the cloud, how does it compare to the traditional deployment options. In short, you want to know what you need to know, in order to be able to develop and deploy your telephony-based application, whether it’s an IVR, voice-broadcast or conferencing system.  This post intends to answer your questions.

The application

To start with, let’s have a look at what your telephony application is going to be doing.  It is going to add telephony functionality to your workflow processes and, in telephony terms, the equivalent is call flow.  That is achieved by means of your application controlling the telephony resources via a menu of structured commands – an API. That, in turn, results in the call logic that is executed by the software program that makes, takes or interacts with a call (e.g., plays or records a message; presents a caller menu; transfers a call; creates a conference; or records a call).

The good news is that you do not need to purchase additional, specialist software to implement these telephony functions.  You will already have access to your programming language of choice – it’s what you’ve been using to write your business application. Apart from that, depending on the cloud telephony platform you use, there may be software to download, to help with the management of your application. Without doubt, your cloud provider should make any such software freely available to you. You shouldn’t have to buy anything extra in order to create the call logic.

The application server

To continue, let’s consider where your telephony application software is going to run. It’s probably going to run on the same servers you use for your business application. Yes, that means hardware. However, it doesn’t mean you have to purchase specialist machines. You can run the software alongside your other applications on your existing, premise-based servers or install dedicated ‘same spec.’ machines in your data centre. On the other hand, as discussed in my previous blog you could choose to run a virtual operation and run your application in the cloud; on Amazon or Rackspace, for example. Either way, it’s more good news.

The telephony resources

Moving on to the point where you have an application that can e.g., make an outbound call, transfer a call to an agent and record messages, let’s take a look at the telephony resources.  Where do those resources reside and how does the call logic that you have coded gain access to them? Here then, is some more good news to savour – you do not need to buy any dedicated telephony hardware or software. The primary function of any cloud-based telephony platform is to provide you with such resources, negating the need to buy specialist technology. Your cloud vendor’s purpose in life is to make available to you – in the cloud and on demand – a virtually [sic] inexhaustible bank of resources for your application to use.  And what makes things even better, is that you don’t have to pay for an over provision of capacity in order to cater for traffic peaks. You don’t have to pay for any volume of in house resources.

To use the cloud-based telephony resources, your application simply needs to be registered with the cloud platform, via a suitable Internet connection. Once that’s done, your call logic software executes on your server (as above) and exchanges information with the cloud platform when there is a call event to be handled.

The deployment

In terms of exploring the possibilities a cloud-based platform can offer you, it gets even better. You shouldn’t need to hand over any hard cash to set up a developer account. It’s only when you’re ready to roll out your application that you need to spend any money.  At that point, you will need to pay for inbound numbers and to be able to make outbound calls.  From that moment on, you can make and/or take as many calls as you need, and you don’t have to plan ahead for peaks. The cloud platform will scale automatically, depending on the traffic passing through, and it will handle innumerable, concurrent calls. You pay for what you use, rather than pay for hardware and software or specialist technology.

The connection to the PSTN network

When it comes to calls breaking out to the PSTN or when you have to receive calls originating in the PSTN, the good news prevails. You do not need to buy a gateway.  Once again, the functionality is managed by the cloud-based telephony platform vendor.  The cloud provider will have taken care of all necessary interconnect arrangements with its various service provider partners and any break out to the PSTN will be through those partners’ existing, established gateways.  Some providers, like Aculab Cloud, will even let you plug in your own service providers.  It’s simply a question of registering them to the telephony platform and it’s still the case that you don’t need to buy a gateway.

The data

And finally… data or, more specifically, data security, can be a very sensitive point.  In truth, there is no reason why data stored on premise is any more secure than that in the cloud.  Nevertheless, you (or your customers) may not be willing to place any or all of your data in the cloud at any time, if at all (although it’s important to add that you could, if you so wished).  If your application is data driven, your data can remain on premise; a connection simply needs to be made between it and your application. Most likely, that will be a pre-existing connection, which means you won’t have to add any costly, additional interfaces. 

Conclusion

A true cloud telephony platform should maintain the promise of cloud computing.  It should remove the need for you to purchase or maintain specialist telephony resources or gateways and it should allow you to invest in your application as your traffic volumes increase. It should enable you to ‘pay-as-you go’ and scale seamlessly, up or down, when you have the need.

My next blog will build on this subject, looking at migration strategies form traditional telephony deployments to cloud and will also consider some of the concerns rasied in relation to cloud.  Your thoughts and comments would be welcomed.