Roger Jones's customer had a problem. The firm had Cisco implement one part of its voice over internet protocol (VoIP) system and Avaya do the other. Sound quality was suffering, and callers were hearing jittery audio.
"There had been mismatch between Cisco and Avaya QoS," says the business development director within Avaya's technology and consulting group. There were supposed to be three streams of traffic in the VoIP system - one for voice, and two sets of signalling traffic (one for the gateway and another for handset signalling).
"The customer had only set up two," he says. "That was a classic example where a network readiness test had been done but they needed to do one extra test.
As more companies' traditional PBX systems reach end of life and they decide to move to VoIP, situations like these will continue to crop up, but VoIP needn't be such a trial. Implementing the technology can be relatively painless as long as you follow some basic guidelines.
Dan Davies, consultant manager at specialist unified communications integrator Unified Group, says that any VoIP implementation should start with a formal requirements gathering phase, so designers know what the business wants to do with the system.
"Users really don't know what their call patterns look like, which makes it very difficult. The answer to 'how much bandwidth do you need?' is 'how many calls [will be made], and how compressed do you want them to be?'"
Victor von Schlegell, president of Michigan-based VoIP services firm Appia Communications, says that customers often don't know what systems can do and set out to save money without considering loftier goals.
"Before they buy, they should understand what convergence really is and how it can help them," he says. For example, receptionists may be used to telling callers to redial another number to find someone working in another location. VoIP makes inter-office routing possible - but does the customer know that?
When the customers are ready, the designer has to be sure the network is ready. A network readiness assessment is crucial, says Davies.
He will put network probes on a system for around a week, to emulate VoIP calls between themselves and other nodes. This gives the design team an understanding of issues such as packet latency, and enables it to produce a summary of recommendations.
Security measures should be a part of those recommendations. Putting voice and data across the same network makes the infrastructure an even more critical attack vector. Those who don't secure their VoIP implementation could potentially look forward to unauthorised access to PBX systems, call tapping, and denial of service attacks.
There are some ways to avoid these dangers. Encrypting the voice content is important to avoid eavesdropping, says Jones. "We're using standards-based SIP phones and we want to encrypt the voice to that phone. We do it on a per-call basis," he says.
Avaya uses certificates sent to the phones, which means that it is also important to encrypt the signalling data. The Session Initiation Protocol normally used to control calls is a verbose, human-readable language, which is often sent in cleartext. Using TLS encryption protects both that, and the certificates used to encrypt the voice.
Other measures include using endpoint security technologies such as 802.1x, to verify devices connecting to the network. IP phones should also be logged out by default, and default passwords in their embedded web server software should be configured to be more secure.
The Unified Group recommends using a virtual Lan to segregate VoIP traffic for security purposes. However, Davies points out that it isn't quite that simple. Many companies must consider softphone users, who will be calling from PCs on the regular data Lan rather than from IP handsets that are easy to connect with the VLan.
VLans can also be useful for quality of service (QoS), which is a crucial attribute in networks serving low-latency applications like VoIP. QoS is a particular concern across Wans where bandwidth is often constrained. VoIP solutions can be implemented across the open internet if you have a high-speed broadband connection (the higher the speed, the better), but it can be ropey. Von Schlegell doesn't recommend that any office with more than three phones attempts an open internet VoIP setup.
Ideally, customers will have a dedicated Wan service provider, which a VoIP implementer would talk with to find out how Wan systems have been configured. Many such companies are moving to the to DiffServ model for QoS, where bits are set in a certain area of the packet header to signify different levels of service.
DiffServ is becoming particularly important as VoIP solutions spread across multiple sites, Davies says. "802.1p is a layer two QoS mechanism, but as soon as a packet needs to traverse between subnets, through a router or layer 3 switch, 802.1p is useless," he warns. "Then you have to use a layer 3 QoS mechanism and DiffServ is becoming a standard there."
Following guidelines such as these could keep your VoIP signals crisp. Ignoring them could create a 'London Bus' syndrome in your network, where VoIP packets arrive too late, all at once, or not at all. And unfortunately, unlike public transport, you can't shrug your shoulders and assume that there'll be another packet along in a minute.
This was first published in June 2008