How does a global corporation switch to IP Voice?
Step by step guide
Not so long ago I worked with a company that had more than a dozen offices around the world. Each had its own phone system – a total of five different makes – of which only two could handle IP telephony.
As a colleague once put it, we used to “spend a lot of time phoning ourselves”. International calls to our own staff, particularly in and out of our sizeable India installation, were frequent and costly.
Within the various offices, though, we used IP telephony extensively. Particularly where we had Cisco Call Manager or Mitel systems the handsets were all IP-based; it was just the trunk lines that used ISDN.
So the question was asked, could we hook the offices together via IP and avoid the public switched telephone network (PSTN)?
We had a head start. The company had a global WAN which, although slow in places and not designed with a focus on transporting voice, at least was in place and worked well.
We took various people’s advice on how to proceed. Should we take the plunge and pay real money to add quality of service (QoS) or class of service (CoS) controls to the network? Should we just take a punt and see if it worked?
In the end we decided to run a pilot between a couple of sites to see how hideous the voice quality would be without QoS or CoS on the WAN. Users were told: "You will be guinea pigs so please don't be surprised if there are issues and please tell us about every bad experience you have."
Before we started we knew that if our pilot was successful we would look to rolling out the service more widely and that we ought to think about how to implement the dial plans so that the service could apply globally without being undone.
We thought about simply configuring the phone systems to watch what the users were dialling and route our own calls through the IP WAN, but decided it would be preferable to implement some kind of short-code dialling.
I pulled together a list of extension ranges and discovered some handy gaps that allowed us to assign a two-digit prefix to each region. This would allow us to dial a remote user by entering their two-digit regional prefix followed by their three- or four-digit extension.
Once we had figured this out, I called in the service provider to configure the head-office end, which ran on Mitel kit, and my Indian Cisco guru to do his end.
The pilot sites were chosen primarily because they had the densest traffic, but by happy coincidence we had the opportunity to test dissimilar systems' SIP (Session Initiation Protocol) implementations instead of the easy option of hooking identical systems together with their own proprietary protocols. We told the pilot users they were good to go and let them play for a few days.
Sound of music
The feedback started to come in. With some trepidation I opened the first email, expecting a tale of staccato voice quality and random call drops. Instead the message was from a gushing accountant proclaiming that the quality was not just good but better than on the old ISDN connection.
Feedback over the next few days was almost entirely positive, except for a few complaints about call drops.
Encouraged, we decided to connect more sites. The Mitel systems were hooked together using Mitel's proprietary protocols, mainly because Mitel SIP trunk licences cost the thick end of £50 per channel and we would need several dozen channels, while Mitel-proprietary voice over IP (VoIP) trunks cost nothing.
Cisco-to-Cisco and Mitel-to-Cisco used SIP. We configured short-code dialling on each IP-connected site so that it could route to the non-IP-equipped countries, but routed the calls over the PSTN for the time being.
Importantly, we did a hefty promotion with posters in the various locations and stickers on everyone's phone listing the short-code dialling prefixes.
We soon realised these were cases of sudden silence on calls between two particular sites
Feedback was extremely positive, even though we had loads of sites and no QoS or CoS on the WAN. The only problem was the continuing handful of dropped calls.
We soon realised these were not in fact dropped calls but cases of sudden silence on calls between two particular sites, usually when the call had been going for a while.
Having analysed further, we realised that it happened on calls between Cisco and Mitel kit, and only in one direction. We called in our Mitel specialists (who also happened to deal in Cisco kit) and asked them to scratch their heads.
The answer lay in the way Mitel and Cisco did SIP: there is a keep-alive signal thrown out after a call has been going for some time and if a response is not received the sender will stop transmitting.
There is a nuance to this protocol that lets vendors implement it in slightly different ways, and our Mitels were doing it differently from our Ciscos. Log into the GUI, check a couple of radio buttons, hit Submit and problem solved (except on one Mitel which had an older software release; a quick upgrade was required to have that radio button available to be checked).
We ran with that setup smoothly for some months. We had an occasional voice quality problem but these were few and far between, and of course when we wrote the request for proposal for replacing the WAN it included CoS as part of the requirements.
When our non-IP phone systems came to the end of their useful lives they were replaced with Cisco or Mitel and brought into line with the global VoIP setup.
The whole project taught me a number of things about VoIP. First, you don't need a lot of bandwidth for it to work, and if you don't mind taking a punt you can try it out for minimal cost – a few hundred quid in my case.
Second, when you embark on a trial make sure you think about the eventual requirement so you don't paint yourself into a corner by configuring stuff you will have to undo later.
Third, remember that there is more to this stuff than technology. The reason we were so successful so quickly is that we engaged with the users for the pilot and then promoted the system while we were rolling it out.
Fourth, you don't have to have every location connected from day one. By implementing IP Voice where we could and making the short-code dialling work on the sites that were stuck with PSTN these still felt part of the global picture. When their systems were replaced with IP-capable ones users dialled the same numbers but had an even better experience thanks to faster call setup times.
Finally, watch the technology that is coming over the horizon. When I did this project it was not realistic to cluster Cisco or Mitel kit over the global distances involved; neither was Active Directory integration something we could do.
It didn't stop me badgering the vendors to try to understand when I could have the features that were not yet available so they would be on our roadmap for when the time came.
IP Voice technology, whether in a proprietary or open-standards form, continues to march on apace, so keep your eye on what might be coming. ®
Sponsored: Beyond the Data Frontier