If you’re considering dipping your toe into the unknown waters of Voice over IP (VoIP), whether you’re looking at IP-enabling your existing PBX or going the whole way and installing a new IP softswitch, you’d better make sure your data network is capable of handling this new type of traffic. Voice has some pretty significantly different requirements to most data apps. If you don’t get it right, you’re not going to be popular if your users come out sounding like Daleks with hiccups.
First off, you need a switched infrastructure. Hubs — if you still have any — are out. But even then, your switches may not be up to scratch.
The biggest issue you’re going to have to face with voice is keeping end-to-end delays not just at a minimum, but also consistent. To give you acceptable voice quality, you need to ensure a maximum delay of 150ms from one phone to the other. But if that delay varies widely over time — i.e. you have jitter — the speech will become unrecognisable and the system useless. Voice-enabled network devices, such as routers, have jitter buffers to smooth out small variations, but they can’t cope with large ones. They also add delay, so are another factor you’ll need to take into account when figuring out delay budgets.
So you have to prioritise your voice traffic so that it doesn’t get held up by large, bursty data packets. And the only way to do this is to have switches (and routers) that have multiple queues, one of which can be prioritised above all others, so that your voice is never unduly delayed. You’re going to have to get to grips with QoS configuration — typically, it’s suggested that voice signalling and actual payload are treated separately, and are also separate from any video and of course your data.
It’s widely recommended that you use different VLANs for voice and data traffic — it’s easier to manage and control, and also helps keep the IP addressing schemes simple.
If you want to make use of the fact that you can power your IP phones over the LAN, you’ll need switches that support Power over Ethernet (see Power to your Access Points) for your wiring closets. If you’ve gone for fairly large, chassis-based switches, you may find you need pretty sizeable PSUs to drive all ports — watch how this affects both the air conditioning you need in your wiring closet, and UPS sizing, since you may now need to provide backup power to your closet switches that wasn’t required when it was just for data. Not all switch PSUs use standard three-pin plugs either — as the power rating goes up, you may find you have to get some serious re-wiring done.
And finally, of course, resilience. Where the business didn’t mind a 48-port switch line card failing and users having no network connectivity for a while for their PCs, this may not apply when it’s their phones too. If you have to add extra switches and uplinks, you may have a fairly major network overhaul to accommodate before you can plug in your first IP phone.
If you have multiple sites, even if you equip each with its own IP PBX (which isn’t really the best way to implement IP telephony, but we’ll look at the different deployment models in the next article), you’ll still need to pass voice calls between sites. The WAN is more of an issue in terms of creating latency and jitter problems since, typically, there’s a lot less bandwidth to play with.
The two main issues here are making sure you have enough bandwidth for your calls and then making sure they will get through with minimal delays. When you’re counting calls, remember that a G.729 call (8kbps voice) will require about 26kbps for a VoIP call over PPP (a lot more if you’re talking ATM). You shouldn’t provision your links to more than about 75 percent of the total bandwidth for all your voice and data, since you need to leave room for routing and management traffic. It’s recommended that only about a third of your available bandwidth is used by voice calls, since the prioritisation will cause resource overhead — and if most of the traffic is voice, then the strict prioritisation mechanisms lose their effectiveness anyway.
For slower links (typically sub 768k) you may be able to use compressed RTP to reduce bandwidth requirements on some types of links. You’ll also need to configure link fragmentation and interleave (LFI) to stop large data packet serialisation delaying the smaller voice packets.
You‘ll really need to do some monitoring at this stage to see what sort of delays you’re actually getting across your WAN, and you may need to discuss options with your service provider to provide a voice-capable service.
Remember that all this is before you start thinking about actually deploying any voice equipment. At that point you can look at redundancy, topologies, and how it all hangs together — not forgetting any extra network management you’ll need to monitor the voice traffic. First, find out how much it’s going to cost to get the basics in place — and make sure that they are factored into any project budgets.