IP Telephony Goes Wide: Optimizing WAN Performance for Voice

Packetized voice over the wide area network isn’t that much more complex than a standalone implementation, if you follow some basic guidelines.

Sometime in the last 20 years, either an ivory-tower consultant or a very sleep-deprived IT manager observed that the nature of networks is to expand. We can parse that thesis endlessly—did she mean the number of users? Locations? Both?

No matter. Sooner or later, medium and large businesses will want to push at least some of their applications across the wide area network (WAN). Maybe an enterprise has grown organically or through a dizzying round of mergers with locations that straddle multiple time zones. Maybe the company needs closer ties with new partners in Australia. Or maybe it’s just time to extend IP telephony beyond headquarters to build on the savings and networking efficiencies already accrued.

Customers that want to extend IP telephony across the WAN have three basic adjustments to make to their network:

• A Quality-of-Service (QoS) mechanism so that all the routers in a connection give voice traffic top priority.
• Sufficient local and wide-area bandwidth to accommodate the needs of a real-time application like voice.
• A Service Level Agreement (SLA) with a fiber or long-haul service provider containing specific thresholds for packetized conducive for voice handling.

”In most cases, these aren’t going to be major new additions for customers or their networks,” says Richard Winslow, a senior sales engineer with ShoreTel. “And none of these pieces are going to stump any reputable service provider, since wide-area IP telephony is hardly a technical novelty.”

Find Out What’s There First
Before undertaking any upgrade like this—especially one that involves a service as critical to any organization as voice is—some inventory taking is in order. ShoreTel is not alone in requiring customers to do some kind of measurement of traffic and performance before deploying IP telephony across the WAN.

For ShoreTel customers, this takes the form of a Network Assessment, which can be done by the vendor or its multitude of partners. It’s a pretty simple process: Software probes are installed at every site where IP telephony will be extended. The probes simulate traffic for at least seven days. Then as part of the assessment, a report is generated on any discovered performance issues and on the anticipated call-handling capacity of the link and site.

This process can often prove informational for customers, who may not have realized they had that many private lines between San Francisco and Chicago, or thought they were T3 lines (45 megabits per second), not T1s (1.5 Mbps).

More frequently what customers discover is the widespread use of IP virtual private networks (IP VPNs), which create secure, virtual circuits between a desktop or remote location and the company remote access server, using the Internet as its WAN. Unlike an internal LAN or virtual LAN (VLAN), the Internet was designed as a best-effort network—no packet is more valuable than any other. All that means is that routers associated with VPNs need to be mindful of voice’s higher priority going forward.

The other common issue that arises with network assessments, according to Winslow, is that the WAN service provider isn’t living up to the terms of an SLA. Documentation like a ShoreTel Network Assessment can usually rectify that pretty quickly.

“By doing a network assessment ahead of time, you can identify problems and take corrective action before the installation,” Winslow says.

Quality Touches
The need for QoS isn’t unique to IP-based applications or the public Internet—it’s been a WAN mainstay for more than 10 years. In the last five years, Multiprotocol Label Switching (MPLS) has become the QoS mechanism of choice and is typically the way service providers like Global Crossing Ltd. enable traffic prioritization for their customers.

“We think MPLS is the best way to approach IP-based services—we support other IP based access methods, but for us it’s the best way for handling IP telephony,” says Anthony Cimorelli, a product marketing manager at Global Crossing. “QoS helps ensure that a premium service like voice doesn’t get disrupted by some massive file transfer going on in parallel, or that a company site that is growing doesn’t bump against any bottlenecks or service degradations,” Cimorelli adds.

The Global Crossing MPLS IP-VPN service is a private IP network offering and is built on three classes of service: premium, enhanced and basic. For customers that want VoIP as an application on their IP-VPN, they would put voice on premium class so it gets the priority it requires. “It’s also important to note that through our VoIP core, Global Crossing only uses the highest CoS—or premium class—for voice traffic,” notes Cimorelli.

ShoreTel supports both MPLS and diffserv—or, differentiated services, an older, less granular method for handling classes of service—for wide area QoS.

Regardless of the QoS mechanism they choose, Cimorelli and Winslow both urge organizations to be mindful that they have sufficient WAN bandwidth to handle packetized voice. “It’s not that voice is not going to hit the data network hard—it’s only about 8- to 20 Kbps of bandwidth,” Winslow says. “It’s just that voice is very unforgiving. You can’t drop too many packets and latency must lower. But it’s more of a real-time application issue than IP telephony being any kind of bandwidth hog.”

Again, your equipment vendor or service provider can help you understand how much bandwidth you’ll need with some sort of network assessment.

Getting an SLA or re-negotiating an existing one is also key to successful wide-area IP telephony deployment. Here are the critical details to include in any SLA governing wide-area IP telephony, according to Winslow:

• Less than 1 percent packet loss.
• Less than 150 milliseconds of latency and jitter.
• Use of a G.729 codec, which compresses voice to 8 Kbps.

Winslow points to another change that customers need to make when pushing IP telephony across the WAN: their network management mindset. “Customers need to treat the network differently—they have to realize they’re carrying a mission-critical application on the network,” he says. “They can’t unplug an Ethernet link in the closet, add a new blade, or do upgrades anytime they want. All that creates an issue between end points that’s different for voice than it is for data.”

None of these steps for optimizing the WAN for IP telephony will be radical for any organization that already has some kind of WAN connectivity. And none of these additions or adjustments applies to or benefits only the part of the network handling IP telephony. It’s just what customers have to keep in mind as their networks expand to handle new applications and new requirements.