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.
What I'll do within a year
Within a year, perhaps a tad longer, I can see myself becoming willing to sign up for SIP-only connectivity in one or more regions – though probably not for the key offices whose up-time is mission-critical. There's a good chance that within that time the big telcos will have SIP services that I'm willing to put some faith in, and once my confidence builds to that level I'll be reasonably happy to recommend that approach.
What I'll do in the long term
In the long term, I'd love to be able to decide that when each of my in-house PBXs reaches the end of its useful/supported life, I'll throw it away and sign up for a cloud-based service instead. But what form will this take, I wonder?
Are we likely to find companies worldwide having their desktop phones registered with a remote device over the SIP trunk? Maybe, but I think that we're more likely to have some kind of concentrator on-premise, against which the handsets (and software-based telephony applications, of course) register themselves but which uses the core cloud service for its centralised management, login and call forwarding (think Cisco Survivable Remote Site operation, but using someone else's kit).
A likely scenario is a hybrid setup, though, where major locations have on-site intelligence that can survive disconnection from the central hub and to live without local equipment in smaller, less critical offices.
And I reckon that the big providers will be doing this with a product offering I'm willing to trust in the next 24 to 36 months.
Barriers to cloud telephony
It should be obvious at this point, then, that there's only really one barrier to implementing cloud telephony. The technology is pretty well understood, protocols such as SIP are supported by the vast majority of equipment, and it's actually a very simple technology to implement (although the underlying protocols are complex, the configuration on the average phone server or client is generally as simple as configuring some tick-boxes and IP addresses or hostnames).
The remaining barrier is, then, the basic lack of availability of services in the marketplace that one would trust for one's corporate telephony.
This isn't a criticism of those companies that are already offering SIP-based services and are dipping their toes in the water of a full cloud offering – on the contrary I'm delighted that companies are forging forward and offering products in this field. My problem is that like any telecoms manager in a medium or large company, I can't presently justify the risk of adopting such a new concept in a business that's used to its phones working seamlessly and flawlessly.
In short: don't be too quick to rush into signing up with a fledgling cloud telephony provider. But absolutely do watch the technology like a hawk and ask yourself how your plans for your telephony installation over the next three years might marry up with the inevitable development of cloud services.
Most importantly, take the opportunity to explore the technologies – primarily SIP – that will enable your cloud services to operate in that eventual scenario, and since the concepts are well established and rock solid in most local implementations, use them to your advantage while you wait for the providers to be able to sell you the services that let you throw away your ISDN and not replace your end-of-life PBX.
