Cloud Telephony - What's the Big Deal?

Posted by: Mahesh Paolini-Subramanya

Let's say you want to set up a cloud-based telephony service. In this day and age, it should really be pretty simple, or so you think: build a datacenter (or use Amazon EC2), download your choice of FOSS platform (e.g. FreeSwitch or Asterisk), write some code and you are done! Oh wait, there is that little pesky bit I kind of glossed over - the bit about writing some code. I mean, how hard can it be, right?

Start simple - all you want to do is have people make and receive calls. That's about as easy as it gets, assuming you have one instance of FS up and running. If you want to get really daring, you could implement a couple of different FS instances. With a little experimentation with mod_event_socket and mod_xml_curl you can have a nice distributed infrastructure that randomly distributes calls across all your FS instances. From there, it's really just a small step to your own 5ESS replacement (ok, maybe not, but you can dream, right?).

Now you decide to get a bit more complicated by adding conferencing into the mix. The thing about conferencing is that all the participants, for some absurd reason, want to be able to talk to each other. Which means you have to make sure that all conference participants are on the same FS node when they dial in to the conference. Oh no! More code you need to write involving knowing which node a conference is calling, call routing to make sure that calls end up on the correct node, etc. Let's say you somehow manage to pull even that one off.

Then, for extra credit, imagine the scenario where Alice calls Bob, and Bob now decides to transfer Alice into a conference. It is quite possible that the FS node that the first call was on (Alice to Bob) is not the same as the node that the conference is on. Yikes! Now you need even more code to move calls between nodes when the call is already in progress. Again, not impossible, but it means that you have to deal with more complexity. And we haven't even gotten to the point where you want a fancy GUI that shows you what's happening to your call, other people's calls, to the conference, etc.

There is a bit of a pattern to everything we've described above. When you get right down to it, Cloud Telephony is no different from Cloud Anything. It really is pretty easy to build up a cloud infrastructure to support atomic events, (i.e., events which are largely disconnected from each other). It is only when you want the infrastructure to deal with events that interact with each other that the complexity sets in, and as somebody famous has probably said, Complexity Is Never Easy. People think of telephony as the simple act of two people talking (on phones, of course), which is right up there with thinking of baseball as people throwing a ball around - true enough, but somewhat missing out on the nuance. The world of telephony is so much more - IVRs, blinky lights on phones, find-me/follow-me, monitoring calls in a call-center, etc. Highly complex stuff, admittedly built up from simple components, but complex nevertheless.

We do need to be clear here, you could do all the above pretty easily by just having one Humonogous (technical term) server, but then this is an article about Cloud Telephony, not Humongous Server Telephony. Quite a few "Cloud" (quotes intentional) providers out there actually do practice Humongous Server Telephony - a triumph of marketing. More power to them, but we prefer to do it correctly. We have Erlang handling the communications between all our FS nodes, CouchDB handling all the persistence, and a *lot* of code handling the edge cases (because believe me, that is where all the hard work is).

Its big, and its complicated, but it is stable, it is reliable, and it just works.

So yes, Cloud Telephony *is* a big deal!