Evaluation and Purchase

Prev don't be afraid of buying books Next

At this stage of your VoIP deployment, you begin to act on the information you collected during planning, analysis, and assessment. First, you rectify any problems that were identified; in particular, you make the network improvements necessary for good call quality and upgrade the equipment gaps. Second, you set up a pilot deployment, to gain firsthand experience taking the steps necessary to perform a full-blown deployment. During the pilot deployment, you evaluate and purchase your first round of new VoIP equipment.

Start with a realistic budget. Make some initial estimates about what the deployment and its ongoing management will cost. What devices and services do you need to purchase and how much will they probably cost? Are these estimates close to what you expect to spend?

Table 3-4 shows another chart from The Tolly Group, Inc., with their estimate of the cost of completing the planning and evaluation stages of a major VoIP deployment. Its numbers include the purchase of equipment for a small pilot deployment and the related test equipment and personnel training. The Tolly Group estimates that the process costs at least $250,000 when done in a structured manner. The chart is part of an advertisement promoting The Tolly Group's services. It is a good itemization, although the costs have changed somewhat since it was originally created.

Table 3-4. Estimates to Get Through the Planning and Evaluation Stages for a VoIP Deployment

Equipment Description

Estimated Cost in 2000

IP PBXs (2)

$80,000

IP Telephony Gateways (2)

$16,000

IP Phones

$3,000 to $6,000

Fast Ethernet/Gigabit Ethernet Switches

$3,000 to $30,000

Test Bed Wiring Infrastructure

$2,000 to $4,000

PCs and Servers

$30,000 to $50,000

Voice Quality Tester

$39,000

Data Traffic Simulator

$12,000 to $20,000

Application Traffic Simulator

$14,000

WAN Simulators

$20,000

QoS Appliances

$15,000 to $30,000

VPN/Firewall Appliances

$1,500 to $5,000

Fast Ethernet/Gigabit Ethernet Analyzers

$1,500 to $5,000

Training

$10,000 to $20,000

Test Racks

$2,000 to $4,000

Total

$252,500 to $343,000

From The Tolly Group, Inc. ITclarity ad, 2000.




Working on the Problem Areas

Before you begin the pilot deployment, resolve any problems identified during planning, analysis, and assessment. The changes to the network that you will make at this stage fall into two main categories:

  • Upgrading the network for good call quality

  • Eliminating the equipment gaps

The sections that follow offer some pointers for making the necessary adjustments.

Upgrading the Data Network for Good Call Quality

By now, you have presumably completed an initial VoIP readiness assessment, from a single call to the maximum number of expected calls at peak network usage, and you understand the mean opinion scores you have seen. You have also compared call quality across a range of locations.

If the call quality is good and the other traffic is relatively unaffected, that is a great start—your next tasks are simpler. Move to the next step of eliminating equipment gaps, as discussed in the upcoming section "Eliminating Equipment Gaps."

If the call quality is not acceptable, determine what the problems are and where they are located. What factor influenced the poor quality the most: end-to-end delay, jitter, lost data, or a combination of all three? Can a simple change in the VoIP configuration options, such as the choice of codec, improve the call quality sufficiently? Where are the most likely bottlenecks?

Begin remedying poor call quality by cleaning up the existing network traffic. It has been estimated that 20 to 50 percent of network traffic is unnecessary traffic that is produced by unneeded network services that are turned on by the default settings of modern operating systems. End users and even administrators are usually unaware that this traffic even exists.[14] A good way to detect this traffic is with a network protocol analyzer. Sometimes, older systems still generate unused traffic. Common examples are the NetBEUI and IPX protocols. Reducing network traffic not only frees up bandwidth, it also reduces processor and memory utilization on your PCs and servers.[14]

Now, look at the costs of making the required network improvements. Choices include adding more bandwidth, upgrading or replacing existing network equipment, laying out your network architecture in a more efficient configuration, reconfiguring or tuning the network for QoS, or a combination of these.

These choices are only the start of a decision tree for a network administrator, because the costs of these different choices are not equal. For example, adding more bandwidth may be a recurring expense if bandwidth is leased; upgrading the hardware may be a capital expense; and QoS tuning may appear to be free, but it usually has a high cost in personnel time.

Analyze the costs in as much depth as you can and decide whether you want to proceed with network changes. Readying the network is an iterative process of making the most cost-effective improvements a step at a time, then repeating the VoIP-readiness assessment to see if you are reaching your call-quality goals.

If your cost estimates for preparing the data network for VoIP appear to be too high, it is a good time to take another look at your VoIP deployment plan. By this point, you understand better what the deployment will require, so you have some choices:

  • You can decide how to budget costs intelligently at the right time in the future.

  • You can increase your current budget and proceed—considering this a suitable long-term investment.

  • You can approach VoIP as a staged deployment, taking some steps now and saving some steps for later.

Obtaining More Bandwidth

Here are four tuning techniques worth exploring to conserve and ration bandwidth:

  • RTP header compression— Saves bandwidth by reducing the number of bytes in RTP datagrams. VoIP traffic uses RTP to encapsulate the speech frames. RTP header compression (called cRTP) is used among IP routers in the network backbone. It can reduce the 40-byte RTP headers to a tenth of their original size, halving the bandwidth consumed when using low-speed codec. In streaming video, by contrast, the payload is often 10 times the size of the header, so compression may not be noticeable. Enable it when there is a link along the route with bandwidth lower than 500 kbps. So, why not always use cRTP? It adds latency, increasing the transport delay component of the end-to-end delay.

  • Silence suppression— Saves bandwidth by making the payload smaller. In most telephone conversations, there are times when one speaker or the other (or both) are silent. During silence, it is not necessary to send full packets; a much smaller packet can be sent, indicating silence during the period. Enabling silence suppression at each end of the conversation can typically reduce overall payloads by 50 percent, although call quality may be affected.

  • RTP multiplexing— Can save bandwidth by putting multiple packets of audio information into one datagram. This means that only one IP/UDP/RTP header is necessary, instead of one for each audio packet. Delay is increased, though, because the datagram can't be sent until multiple packets have been generated. Another downside is that the loss of a single datagram can mean the loss of multiple audio packets, further eroding the call quality.

  • Call admission control— Lets you avoid having too many concurrent VoIP conversations. If your WAN bandwidth only supports two VoIP calls well, you want to avoid a third call. VoIP server software can limit the number of concurrent conversations to a predefined number, to avoid overloading slow links. Excess calls can then be automatically routed to the PSTN.

These four techniques may help, but ultimately you may need bigger pipes. Look for the slowest links, or the links where the contention for bandwidth is greatest. Many delay and data-loss problems can be solved by having lots of available bandwidth to accommodate the VoIP conversations and the other concurrent network transactions effortlessly.

Upgrading or Replacing Existing Equipment

Upgrading or replacing your data-network equipment may give you the boost you need, without buying additional bandwidth from your service provider. The latest, fastest equipment often can increase bandwidth, decrease latency, and increase capacity. Here are some upgrades to consider:

  • Hubs often create bottlenecks in a heavily used LAN— Consider replacing hubs with Layer 3 switches. Recent switches are also much better at handling IP multicast traffic than those of a few years ago; check to see if the combination of old switches and IP multicast is massively throttling your available LAN capacity. Also, aside from being orders of magnitude faster than traditional IP routers, high-speed switches have become more reasonable in price. Purchasing these is an especially good move if your older routers don't support the QoS schemes that you plan to implement, because you have to replace them anyway.

  • Routers operate using queues for the arriving and departing traffic— Routers always seem to function better with lots of RAM. Doubling or tripling a router's RAM is frequently a cost-effective upgrade.

  • Modern hardware-based firewalls have much higher capacities than some older, software-based models— Firewalls are often bottlenecks, greatly increasing transport delay as they reach their limits.

  • In the WAN, look for ways to reduce delay— A change from satellite links to terrestrial links for VoIP traffic flows can significantly reduce the fixed propagation delay.

  • Network backbones can become the bottlenecks over time— Is the backbone now the place where traffic slows down during peak usage periods? Is it time to consider gigabit switches and routers?

Changing the Network Design

Will laying out the network and arranging the users differently help improve the key VoIP measurements? Network redesign is obviously a big step. Consider changing the layout of your data network with alternatives like these:

  • Could VoIP conversations take shorter, more direct routes, reducing their propagation and transport delays? For example, do you have traffic going from New York City through San Diego back to Florida?

  • Fewer hops can reduce the cumulative transport delay. VoIP traffic is much more sensitive to the number of hops than traditional TCP transactions. Do some VoIP flows take 30 or 40 hops from end to end? Could the number of hops be reduced by re-engineering the network?

  • Clustering of traffic patterns means finding out which users are using which network applications, and where they are located. Does unnecessary data traffic flow on the same links as critical VoIP traffic? Could servers be positioned closer to clients, reducing backbone traffic? Could firewalls be placed differently?

  • Look for bottlenecks or other congestion points. If they can't be eliminated, can the voice traffic be routed around them?

  • Consider a layered architecture. QoS increases the load on your network devices. A layered architecture means that you push CPU-intensive work, such as classifying packets with access-control lists, out to the edge of your network. This lets the core of the network focus on high-speed switching, which is critical to delay-sensitive voice traffic.

Reconfiguring or Tuning the Network for QoS

Network devices and applications have powerful techniques available for dealing with the sharing of network resources, collectively referred to as QoS. QoS is most useful in VoIP deployments to help with consistency. At times when overall congestion rises, you would like VoIP traffic to maintain consistently low levels of delay, jitter, and packet loss. As with having lots of available bandwidth, QoS also can give you breathing room.

QoS is a large topic with lots of technical details, so tuning choices are discussed in detail Chapter 5, "Quality of Service and Tuning." At this point, though, plan on using QoS to make a good situation better—don't plan on using it to move you from a marginal situation to "good enough." QoS is most useful to mitigate the effects of occasional congestion; it is not designed to alleviate chronic congestion. If a link is frequently congested, additional bandwidth is probably the right solution, rather than a QoS strategy.

Eliminating Equipment Gaps

An outline of equipment configuration items to analyze was supplied earlier in the chapter, in the section "Configuration Assessment." Begin making the upgrades, starting with those that are the most cost effective. Make changes or upgrades one device at a time to start with, verifying proper operation after each change. Do all of this before adding any VoIP traffic to the mix; your intention is to make sure that you are doing what is necessary for VoIP without degrading the existing data-network traffic.

For example, before updating the operating system of an IP router, build a small acceptance test, in which a variety of representative traffic is generated among several places in a network, to see that it is routed correctly. For example, the test should contain flows consisting of TCP, UDP, ICMP, IP multicast, and router-table-update traffic. Run the acceptance test before making the upgrade, noting both proper operation and the traffic's performance. (An application-traffic generator can be especially helpful for this type of testing.[15]) Make the equipment changes, then run the acceptance test again, checking to see that everything is operating as before and that performance meets or exceeds the previous measurements.

Building a Pilot Deployment

A pilot deployment is the place for your entire team to get firsthand experience with VoIP systems and their behavior. And, during the pilot deployment, you evaluate and purchase your first round of new VoIP equipment.

Learning New Lessons Well

The reason to perform a pilot deployment is to learn. Your test lab is the place for everyone on your team to get their hands dirty with VoIP configuration details. Schedule times for unstructured use of the new equipment. Connect the equipment in many different combinations. Make mistakes; get into situations where nothing seems to work, and spend the time required to debug the situation. Start printing pages for your notebook of troubleshooting guides and hex-dump decodes. For example, see "Troubleshooting and Debugging VoIP Call Basics" for the Cisco basic guide to troubleshooting and debugging VoIP calls.[16]

Your test lab is where the whole team needs to get very comfortable with how VoIP behaves, including how it mixes with other traffic and how it behaves when something is wrong, how to debug VoIP, and how to isolate and fix a problem.

Take equipment out of the boxes, get it up and running, read the manual, and play with all the configuration choices. Do benchmark testing. Build a mini-representation of your data-network traffic, such as a mix of e-mail, ERP, web browsing, streaming video, database queries, and so on. How does the application traffic perform with no VoIP? How does it perform when VoIP is added?

Be sure to include representative firewalls, DNS and DHCP servers, VPN servers, traffic shapers, and other specialized networking gear in the test lab. Configure the firewalls to mimic the settings in your production firewalls, then make sure all the VoIP traffic—both setup and call traffic—passes through the firewalls and traffic shapers as intended. These devices are most likely to be sources of configuration errors or omissions. Learn all you can in the test lab, and learn more in the pilot to assure it is right when you do the full deployment.

Interoperability of equipment is a topic to tackle thoroughly during a pilot. If you are using equipment from multiple vendors, does it work together as expected? Can your management system (which is probably built by yet a different vendor than your other VoIP equipment) see deeply enough into the data collected by each component?

The pilot also is the time to work through a range of tuning choices. For example, some QoS techniques require that the devices at each of the hops through the IP network be reconfigured. Making these changes may be tedious when done by hand, but you will find that by doing things manually, you learn where great productivity gains can be made. Your team members need to be experts at tuning data networks for VoIP—such tuning is done not just once (at the initial deployment), but whenever a new device is added or topology changes are made.

Extensive education of the IT and support teams should take place during the pilot. To many people who are experienced in the data-networking community, the VoIP concepts discussed so far may be new, alien, and confusing. Send them to classes, let them read detailed articles on the web, devour the documentation from the vendors, read the weekly and monthly journals, and let them play in the lab.

How much should you spend on VoIP education? About US$10,000 for each technical staff member is a rough estimate. This includes salary time; those in the lower end of the salary range probably require more training than those at the higher end, so this estimate holds across a range of job titles.

Finally, your team needs to become experts at monitoring and managing the VoIP system. Install the server and agent management components and start gathering reports. You need to learn which events in your environment should be routed to you as alerts, and which should be handled automatically. What does it look like at the management console when a break occurs in the network? What does congestion look like? What happens when call quality declines?

Starting the Pilot

The locations where you choose to roll out VoIP for a pilot program have a noticeable influence on what you can learn from the pilot. First of all, pick places where the ROI is high, the potential for disruption is low, and the users' cooperation and feedback level is high. Refer to Chapter 2 for some good candidates.

You want to pick two locations so that you can run VoIP both within a single location and between a pair of locations. One of the best places to start a VoIP pilot is between a pair of branch offices. This is true for several reasons:

  • From a cost perspective, it is usually prohibitively expensive to put full-featured telephony equipment in small branch offices, even though the users in these offices may need the same features as the central office.

  • From a project-management standpoint, it is much simpler to coordinate the roll out of a new technology in small groups. Because branch offices conveniently organize small groups geographically (where they share the same infrastructure), but are separate from other groups, a branch office is an ideal place to start with VoIP.

  • Starting with small groups of users means less risk. Even though IP telephony products are maturing rapidly, few businesses have the confidence to forklift the rock-solid equipment they have been using the past 20 years and replace it with "converged" equipment.

  • To get deployments started, VoIP vendors have some nice "branch office" packages with fairly attractive pricing.

Evaluating Equipment and Systems

Your test lab and your pilot deployment are the places to evaluate the new VoIP hardware and software equipment you plan to acquire. The question you are attempting to answer in an evaluation is whether the components and their vendors meet your expectations.

Review how you make evaluation and purchase decisions. Presumably, your goal is to obtain equipment that gets you where you are headed. You would like your purchases to be cost effective, scalable, and reliable. VoIP equipment may have a range of expected lifetimes; do the purchases satisfy the life cycle expectations that you have for them?

New purchases are commonly evaluated in a setting that represents typical usage in your environment. When measurements and comparisons are done by professional testing labs or at shows, they are sometimes known as bake-offs or shoot-outs. A representative bake-off requires some planning, though, to make sure that you are testing what is important for your environment. Effective analysis skills and thorough testing tools are not necessarily common, which is why many people rely on the evaluations and comparisons done by professional testing labs. So, you face a trade-off: Do a bake-off in house, tailored to your environment, or depend on the results done by professional testing labs.

Network performance questions are easy to pursue as you evaluate network equipment for VoIP:

  • What is the user throughput through the device for one application session?

  • How many sessions can you run concurrently? When you reach that number, what is the user throughput?

  • What is a recommended maximum number of sessions to configure, by CPU or RAM?

  • How many locations (address pairs) can you have in concurrent sessions?

  • Ask the same questions as the preceding four, but with regard to response time rather than throughput—what is the latency through the device with one session? When you reach the maximum, how bad does the latency get? What is the recommended maximum?

  • Ask similar questions, but in the context of end-to-end delay, packet loss, and jitter—what are the key network performance metrics for VoIP and multimedia traffic?

  • What happens as you add IP multicast traffic?

  • Put together a realistic traffic mix in the test lab. Suppose your network is 60 percent TCP, 30 percent RTP, and 10 percent UDP, with a mix of transactions, file transfers, and streaming. What are the representative throughput, response time, delay, lost data, and jitter values for the corresponding application traffic?

  • What happens when you leave traffic mixes like this going for days or weeks at a time?

In the end, you may determine that the devices you are evaluating have similar measurements. But the process of purchasing and using the equipment has brought you closer to what is probably the most important element of the evaluation: your relationship with the vendor.

A common question when converting telephones to VoIP is which vendor to choose. It is best to consider 3 or 4 vendors, and to build pilots with a size of about 10 IP phones each. The vendors will know you have your eye on a larger rollout than just 10—how do they treat you during the pilot? How is their product reliability? How is their technical support?

The quality of the relationship you build with the equipment vendors, and the quality and price of their products, should guide you in deciding what to buy. It takes performing a pilot to give you the confidence to know what to select.

Watching for VoIP Gotchas

Tom Lancaster, in his excellent VoIP tips on searchNetworking.com, has called attention to some gotchas you are likely to encounter in your pilot: echo[17] and full-duplex capability[18] in softphones. This advice is supplied in the following sections.

Dealing with Echo Problems

Echo sounds like a speaker's words are being repeated as soon as they reach the receiving end of a call. As long as the echo is reasonably quiet and short, most people can tolerate it, if they notice it at all. However, as the time between your speech and the echo grows, the echo becomes irritating.

The first step in getting rid of echo is to isolate its source. Usually only one party hears the echo. If that is the case, the echo source is on the far end. This is fairly logical if you think about standing in a canyon shouting "echo echo echo." If you stand right next to a wall and shout "echo," you are not going to hear one. To hear the echo, you have to stand far enough away that the sound has time to travel from you to the reflection and bounce back to you. When you shout "echo" into a nearby wall, more sound bounces back to you, but the delay is so short that you can't hear it. For this reason, if your local gateway is causing an echo, you won't hear it because you are too close.

After you figure out which end of the circuit is causing the echo, look for the usual suspects. The easy bet is cheap headsets or conference phones. These devices are notorious for allowing the output from the speaker back into the input (the microphone). In this case, an echo problem is easy to diagnose because you can swap out the equipment immediately and note whether the echo disappears. If it does not, the next guess is any place where different telephony technologies meet. For instance, a two-wire to four-wire conversion and a digital-to-analog gateway are common causes of noticeable echo. Troubleshooting these components takes a little more effort, and usually some testing instruments are needed to measure things such as decibel loss and impedance.

Determining Full-Duplex Capability in Softphones

The audio hardware in PCs that are being used as softphones needs to be able to record and play back at the same time. This is called full-duplex audio; without it, you can speak or listen, but not both at the same time. Unfortunately, many PCs have hardware that does not support full-duplex audio. For these computers, you may have to use an external device, such as an IP phone, instead of your PC's sound card and microphone. Upgrading sound cards in a few PCs in a small office may be pretty annoying, but it can be a budget-buster if you order 200 softphones for your corporation and find out your desktops all require upgrades before you can use them.

Checking whether your PCs support full-duplex audio is a fairly simple matter. Start by making sure your microphone and speakers are plugged in and turned on. Open a program that you can use to record and play back sound from your microphone. Microsoft Sound Recorder is a free package that ships with Windows (Accessories/Entertainment/Sound Recorder). If you don't already have a favorite third-party application, use the Microsoft program.

Next, make a recording. Do this by clicking the Record icon and speaking into your microphone for a minute. After you have finished, open a second instance of Sound Recorder (or your favorite application). On the first Sound Recorder, rewind your recording and play it back. After it starts to play back, quickly switch to the second instance of Sound Recorder. On the second instance, begin recording again for a few seconds. If you can play back the second recording, you know the PC supports full-duplex audio.

Transcoding

Transcoding is the process that converts between different codecs. Transcoding can be problematic for VoIP, but you never had to worry about it in the PSTN. In a VoIP deployment, you may be using a mix of different codecs such as G.711, G.726, and G.729. All PSTN calls use the G.711 encoding. Consider the example where a call originates from an IP phone using the G.729 codec. The destination is a phone in the PSTN. The VoIP gateway must transcode the G.729 data stream to G.711 and vice versa.

The conversion process between codecs is costly. It increases delay and lowers the call quality. Try to avoid data conversions between codecs whenever possible.

Amazon


Taking Charge of Your VoIP Project
Taking Charge of Your VoIP Project
ISBN: 1587200929
EAN: 2147483647
Year: 2004
Pages: 90

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net