Your first steps in implementing cloud-based telephony

It's really very easy to implement a corporate telephone system.

First you select a telephone system (Cisco if you want a multi-device setup with a billion more features than you need, Asterisk if you're an Open Source geek, or Mitel if you're me). Then you call the phone company, order the appropriate line (probably some flavour of ISDN), wait for a period that always feels longer than it should, and then connect your PBX to the spanky new box on the wall once it's arrived.

The thing is, though, you then ask yourself whether the approach you've taken is in fact the right one.

The first obvious question is one of resilience: how do you protect against, say, the ISDN30 in your London office developing a fault? Two ISDN30s into separate devices, preferably from separate exchanges and through separate street ducts? Maybe, but what if you lose the office completely – is there an easy way to direct the traffic to a different office's connection? You might be able to arrange forwarding with the phone company, but this can be tedious and slow.

The second common musing is why you actually had to buy or build a phone system in the first place. It's a piece (or several pieces) of tin that you have to power, maintain, upgrade, fix when it breaks and replace when it becomes end-of-life in what feels like the blink of an eye. Why not at least virtualise it? And if you can virtualise it, why not put it in the cloud?

Intra-organisation IP telephony has reached a level of maturity in the last five years or so that makes it the default choice in the vast majority of cases.

Even if you don't have Class of Service (CoS) or Quality of Service (QoS) controls on your LAN or WAN you can often rely on the “headroom” on your connections to get the traffic through in one piece.

For instance, all nine of the sites I'm responsible for use IP telephony except for the stuff that has to be analogue-connected (out-of-band management modems and fax machines, primarily) and it works a treat. All the sites also hang together via IP trunks, and historically the headroom has been sufficient to keep everything working (though we're presently implementing CoS so we can guarantee the service).

Virtualised telephony
Most of the systems I manage are Mitel 3300 platforms. One of the things you can do with these is to run them as virtual appliances on your ESX virtualised world – no more need for the big physical box in the cabinet.

The trouble is, though, that this is all very well until you need to connect something non-IP into it. Want ISDN30? Well, you'll need an ISDN to IP box for that. Connecting analogue devices in? That'll be another box then. So by throwing away your single metal box, you've presented yourself with the need for two new ones to do the conversion between IP and traditional protocols.

Why, though, do we still need to use ISDN for delivering phone calls? Why can't we get our telephone company to supply an IP trunk instead of an ISDN? The answer to this question is, of course: “Actually, you can”. While you're unlikely to throw away the requirement for IP to analogue any time soon, more and more providers are able to supply PSTN trunks using SIP (an IP-based, standard protocol) instead of ISDN.

The benefits of SIP are huge – the primary one being that the phone numbers become divorced from any geographical constraint you may previously have had. Remember all those times when you've had to change your phone number just because you happened to move your office that little bit too far from the exchange you're on? That's no longer an issue.

In addition, this geographical independence lets you consider resilience options you'd never previously dreamed of – so if, say, your Washington DC service provider pops a line card in its main exchange, you can have a secondary route land the calls in your Minneapolis office (and if you've clustered your PBXs, the Washington DC staff still get their calls and see no difference).

About that clustering …
That's a big advantage with SIP presentation from the PSTN, then. But in that last paragraph I did chuck in a little caveat – if you've clustered your PBXs. All modern PBXs worth their salt can be clustered to provide just this kind of resilience, but there are usually constraints with regard to the interconnects between them. Particularly over a WAN, you can soon fall foul of the round-trip-time constraints of your choice of phone system, which means you can often only cluster them within regions, not globally. So you'll get failover, but you won't get a globally transparent service.

The obvious alternative
If you're not going to be able to cluster your phone systems, you're not going to gain the benefits you'd like. Yes, you can probably do some resilience via SIP but without clustering you're unlikely, for instance, to be able to get to the utopia of any user walking up to any phone in any of your offices and logging in as himself/herself, with calls and voicemail following them seamlessly. (And if you're wondering: yes, this is one of the things on my wish-list for the next three years).

Think laterally, though. If you can't get your devices to cluster, why not see if there's someone out there who's dealt with it already, using carrier-grade kit that is able to deal with the latency issues but which you could never afford to buy for yourself in your wildest dreams, and can give you telephony as a service?

Having given this a great deal of thought for my own setup (which is actually pretty typical – decent-size company with a global presence in a dozen or so countries and a phone bill we'd always like to reduce) here are my recommendations.

When my fairly intense project schedule calms down, I'll most definitely be signing up in one or two countries for PSTN SIP trials – but only on condition that they augment, not replace, the existing ISDN connectivity I have. The old cliché remains valid, and will do for years to come: users expect data networks to break from time to time, but they always expect a dialtone when they pick up the phone.

More and more providers are offering SIP trunks, but it's worth noticing that not many of the big telcos are yet doing so. Remember also that there are different types of trunk: having it presented over an Internet connection is a world different, SLA-wise, than having it presented as a dedicated piece of string that connects directly into the exchange just like an ISDN link.