"The definitive guide to Successful deployment of VOIP and IP Telephony"

If you receive errors when attempting to view this white paper, please install the latest version of Adobe Reader.

"Successful VoIP deployment relies on careful planning, thoughtful infrastructure preparation, and a management platform designed for IP telephony's unique real-time performance requirements. Network assessment is a key component of this, but is not enough on its own to ensure VoIP success. "
Source : Prognosis

Resources Related to Deployment of VoIP and IP Telephony :

• VoIP (Wikipedia)

The definitive guide to Successful deployment of VOIP and IP Telephony

VOIP and IP Telephony is also known as : IP Telephony, Understand IP Telephony, Free IP PBX Guide, Choose a Business VOIP Solution, On-demand PBX Flexible, Business Telephone System, Small Office IP Phones, Voice Over Internet Protocol, IP Telephony Resources, IP Telephony Definition, Services IP Telephony, IP Telephony Systems, IP Telephony Solutions, IP Telephony Overview, IP Telephony Extends, IP Telephony Internet, IP Telephony Basics, Internet Telephony, IP Telephony Definition, Portfolio of Telephony, Converged IP Telephony, Installing IP Telephony, Protocol Telephony General, Benefits of IP Telephony, Replace Your Hosted PBX, Compare Business VOIP Providers, Convergence IP Telephony, IP Telephony Service, IP Telephony Packet-based, IP Telecommunications Portal, IP Telephony Connectivity, IP Telephony Availability, IP Telephony Connections.

Chapter 3: Planning and Assessment

At a professional car race, the cars are powerful, fast, and full of muscle, zipping around the track at amazing speeds; the drivers defy death and beat physics at every turn. What only the true racing fanatic realizes, though, is that there is more to this feat than the power of the car and skill of the driver. Considerations such as the preparation of the track, the track surface, the inflation of the tires, the bank of the turns, the surface temperature of the track, minor variations in the fuel mix, and other seemingly arcane considerations contribute in a very real way to the outcome of the race.

This chapter talks as much about the track-the high-speed broadband surface over which telephony and other multimedia content races-as it does about the vehicles-traditional and multimedia phone calls. This chapter will also delve into some of the seemingly arcane aspects of both, making good on the promise in the first chapter to educate phone people about IP networks and IP people about telephony systems.

The first two chapters introduced some of the principles driving the change to VoIP and IPT and noted that this guide will challenge the market "buzz" that has been generated by emerging and evolving packet telephony technologies. This chapter will continue exploring both the pros and cons of this technological shift, which should be more of an evolution than a revolution.

Planning and assessment must begin with a careful identification of the business drivers for change, which will, in turn, provide objectives that will guide the project and allow the measurement of the outcome. This evaluation must include thoughtful analysis of the current methods of voice communications and both the voluntary and involuntary drivers. Voluntary drivers include the desire to reduce cost and increase productivity as well as advances in business applications that require the integration of new technologies. Involuntary drivers can be factors such as manufacturer discontinuation of existing systems and an enterprise's lack of desire to continue investing in hardware that is rapidly becoming obsolete.

Planning and assessment also includes setting proper expectations with both users and management. Expectation setting includes defining proper design and ongoing operational criteria, such as technical requirements and acceptable operational thresholds. Important metrics for all telephony applications are identified, whether for simple two-party telephone calls, voice and/or multimedia conferencing, voicemail and presence applications. Methods for translating those metrics into a measurable and actionable Service Level Agreement (SLA) for internal or external service providers are also provided-whether those providers are carriers and service providers who supply the track or service providers, systems integrators, and inside entities who provide the vehicles that run on the track.

This chapter will also include a unique, comprehensive capabilities inventory that is designed to ensure that every capability used in the current/old system is at least considered for inclusion in the new system.

Business Drivers for Change

When companies explore Internet Protocol Telephony (IPT) solutions, the focus must be on key business areas because it is business applications and needs that will drive change, and the meeting of business needs that will define the project and make the project successful in a business context. As different as it may often seem an IPT project is no different than any other project that impacts the way in which every member of an organization does their day-to-day job. In fact, the IPT project touches the lives of every member of the organization and the way in which they communicate with each other and with those outside the organization.

When evaluating the full range of business needs it is vital to the success of an IPT implementation that management and user requirements are assessed and proper expectations set. It is also important to fully understand all the business drivers behind the shift to IPT. If cost reduction is the primary driver, there will be different factors to consider than if the primary driver is deploying new, converged applications. Understanding the key drivers for the project helps maintain focus on those factors that ensure success. Communicating the objectives clearly with everyone involved, including suppliers and service providers, helps maintain a clear view of the expected results and allows all parties to weigh in on the viability of the objectives.

When the migration from traditional telephony to VoIP and IPT began in 1995, businesses and industry pundits alike projected incredible cost savings. These savings were primarily seen as a natural outgrowth of consolidation. The consolidation to a single physical network and single cable plant also led companies to envision a consolidation of staff, reducing the support requirements for a single converged network. Much of the punditry surrounding convergence neglected the inherent complexity of telephony itself-for years the market had been lulled into a false sense of simplicity by the fact that anyone could lift the receiver on any phone, press the correct series of digits, and-voila-a person anywhere in the world would lift the receiver and answer!

Over time actual experience with VoIP has made a mockery of most claims of deep savings vs. traditional telephony, unless, of course, users are willing to abandon most features of traditional telephony, which is hardly a fair comparison, and use the nearly free PC-based systems. Although the savings of VoIP circa 2007 are substantial compared with the cost of traditional telephony circa 1995, VoIP today often demands a premium as older, depreciated gear with a service life in the range of two decades is replaced with an unknown or 18-month to 5-year expected service life. And one must also consider that purveyors of traditional telephony have reduced the prices for use of their reliable, high-quality traditional systems. This leaves issues such as manufacturer discontinuation, including both the discontinuation of lines of traditional equipment as well as the discontinuation of the manufacturers themselves, and the desire for new, integrated, multimedia applications in the forefront of reasons to purchase the new, often more expensive, VoIP and IPT systems.

As networks converge, new integrated services can provide unique, new business processes. In a fully integrated network, the tighter relationships between data systems, telephony services and video lead to new opportunities. Take customer service as an example. Customer data, collected over both telephone and computer systems, can enable new methods in providing customer service, possibly at a lower cost, but more importantly in a manner that directly increases customer satisfaction, and indirectly increases revenues, enhances an organization's reputation, and raises the bar for customer service within the industry; thus, putting pressure on competitors to meet the new challenges or lose market share.

Call center functionality, for instance, can easily be dispersed geographically, and not just through low-cost VoIP-driven off-shore call centers but also through distributed, call-center-free call takers working part time at home on a demand-driven basis at a lower total cost but a higher rate per hour. It's the technology that makes it easy to integrate teleworkers at remote locations, at lower costs and providing higher levels of service while better meeting the personal needs of the workers. An integrated, Web-based customer service application can handle both telephone calls and provide Web services such as interactive online and TTY for the deaf. Those users who would prefer to communicate via their browsers can explore a business Web site and click a button for customer support that places a VoIP phone call to a company representative who is working at home or in a centralized call center. With IPT in a fully integrated environment, computer telephony integration (CTI) tools can provide the customer support representative with comprehensive information to assist the customer. This information might include not just customer contact and account information but also a screenshot Web page that the customer last visited and a complete history of what this customer has been looking at on the Web site.

For example, consider the scenario that Figure 3.1 shows-an insurance service center. What sort of reaction would this company get if, when the customer clicked "help," a service rep were to come online via IPT linked to a Customer Relationship Management (CRM) front end and speak directly to the customer? "Good morning, my name is Mary. It looks like you're trying to find information about our new policy options for your automobile coverage. I'm sorry the Web information wasn't more helpful. How can I help you?"

Figure 3.1: Customer service and CRM in the integrated IPT environment.

The call center can just as easily support Internet users as PSTN callers. Computer telephony integration at its finest and most developed can provide a powerful competitive edge to customer service organizations. This evolution in the network and change to the corporate culture require both time and focused effort. They evolve continually as new behaviors are learned. Although no company can jump from legacy telephone systems to a fully integrated voice and data network overnight, IPT might provide a point of entry for your company to begin moving into a competitive converged network.

Lower Costs

As mentioned earlier, lowering cost was seen as an early driver for migration to VoIP. Cost reduction was seen as coming from multiple fronts. First, the consolidation in infrastructure to a singe network was viewed as a source of cost savings. The problem with this logic is that most businesses standardized on a single, high-grade Category 5 or Category 6 twisted pair wiring scheme years ago that can handle the needs of all forms of multimedia information. The old dual-mode cabling of twisted pair for telephones and other types of cable for data workstations has been replaced with a standard, unified wiring scheme. Bottom line: there is not significant cost savings today in the physical plant.

A second area of cost savings was the reduction or elimination of telephone costs through the use of the IP network to replace the old phone network. Organizations that started with this idea often find that their existing IP networks are usually not large enough or robust enough to handle the new load of telephony and multimedia demand without being enlarged and made more redundant, and that the cost for VoIP-based outside phone services is about on par with today's cost of traditional services.

A third area where substantial cost savings were envisioned was personnel costs. The general thinking was that because voice is just another IP application, it could be put on the IP network and managed by the data team so that all the traditional telephony people could be terminated, thereby creating a substantial ongoing cost savings for the organization. This logic is faulty, as organizations that do a wholesale purge of their old telephony departments go without key services. There is just no way to replace the knowledge and expertise.

What happens is that organizations often use the migration to a new IPT system as an opportunity to sort out their data and telephony personnel, keeping the best and brightest from each department. What emerges, however, are single super-techs with multimedia capabilities that are well-suited to work in any company and cost more in training, salary, and benefits. It is a whole new era and a proper program must be developed to ensure that the needed skills are available, and this must also include the consideration of service providers and system integrators who will have the hiring headaches and share the cost and availability of their stables of skilled multimedia workers over all clients.

The Myth of Bandwidth Savings

There was a widespread myth associated with early VoIP services that all you have to do is add VoIP to your network and it will work just fine. Vendors said it will fit in between the unused spaces in your data network. Don't believe it! Voice service is mission critical to the operation of any business. Anything you add to your network-whether it's an application, new software, or new devices-will impact performance. If your equipment vendor tells you to add their product and your "voice will ride free," be very skeptical. You will get what you pay for, and it's crucial that you protect all your business network services, whether they are voice or data.

One early driver behind packet telephony migration was to move voice traffic off the more expensive PSTN onto a cheaper network, like the Internet. This was purely driven as a costreduction measure. Although this method presents an intriguing argument, it also presents a true "apples to oranges" comparison. The PSTN and Internet are regulated, managed, and priced under completely different methods. The PSTN is a highly regulated environment, while the Internet still remains, for the most part, an unregulated data service.

One approach to providing quality to a network has been to exponentially increase the carrying capacity or bandwidth of the network. This has historically been referred to as gigabandwidth. With advances in LAN switching technology, Gigabit Ethernet is now fairly common in the backbones of corporate networks. 100Mbps to the desktop is commonplace. Many pundits and technologists have argued that with the exponential increases in optical networking, we have achieved a glut of bandwidth. Some have even proclaimed that "bandwidth is free," although we all seem to be paying a higher price that we would like to pay. Certainly any IT manager who pays for WAN circuits will tell you bandwidth is not free.

Bandwidth is a finite resource in your network. CPU processing cycles are finite too. All your business network services are additive, each consuming available resources.

An opposing argument is that providing a user with gigabandwidth is merely a temporary patch or workaround. The Internet has done more to encourage consumption of data than the early designers ever imagined. End users always find creative uses of technology that the inventors or designers never dreamed of. Today, the idea of a gigabit data stream to the desktop seems to eliminate any need for QoS mechanisms.

The question becomes whether some traffic is more critical than other traffic. For many businesses, telephone traffic is the most mission-critical application there is. A call center that takes catalog orders or makes airline reservations cannot function without telephony. Assigning a lower priority to email and Web traffic is a sound business decision for such a company. In order to do that, some prioritization scheme is necessary, whether it's one reviewed here or some entirely new approach.

The best solution to QoS issues involves the well-being of the entire network. Processing power must improve. Bandwidth must increase. Traffic engineering techniques must evolve. Prioritization for mission-critical traffic must be implemented. There is not one single "silver bullet" solution that can placate all the demands placed on IP and the Internet today, because the problem is not one single problem. Only a complex solution will effectively address the myriad performance concerns in today's networks.

Access Charge/Local

Local access charges have been challenging for many businesses. Large enterprises might have a distributed PBX architecture with a comprehensive "least cost routing" methodology implemented across the corporation. These local access lines, typically T1, E1, or J1 lines, were at one point, an incredible cost burden. The cost was offset by routing calls inside the private voice network of a large company and dropping them off to the local telephone network as close to the destination as possible. In essence, companies replicated the routing of the PSTN within their own private telephone network, providing the lowest cost access based on their own infrastructure.

Although this approach still works in the packet telephony world, the use of the ubiquitous Internet and the lower cost of high-speed packet interfaces often require a rethinking of how calls are routed. Many companies, however, will develop one strategy to get them through the migration period and another strategy for the post-migration period. Any multi-national organization must also consider the legality of packet telephony, or at least a bypass of the national Postal, Telephone and Telegraph (PTT) authority in any country in which they work- as well as the legality of encryption if that technique will be used to keep the packet voice secure.

Long Distance

Long distance access was reduced for many companies through the local access trunks provided at each remote office. Companies used creativity in trunking PBXs and key systems in smaller offices to make the absolute best use of expensive carrier resources at the cheapest possible rate. Many large enterprise companies built telephone networks that rivaled those of small telephone companies.

PBXs were linked or meshed together using point-to-point circuits and proprietary protocols, establishing a telephony network that allowed the customer to create routing priorities. Although this setup has helped reduce the cost of long distance calling in many cases, it has added complexity to the customer voice network and put the onus on the customer for making path determinations about call routing.

Intra-Company

Intra-company voice traffic has been solved as a problem for many years. Companies have established a combination of voice trunks and voice channels on the corporate data network that allow hauling internal telephone calls from coast to coast and around the world. PBX vendors provided IP interface cards to simplify inter-PBX trunking over IP networks, and in many cases, a company simply carved voice trunking capacity out of the data network bandwidth to connect voice systems.

This approach was often presented by vendors as "free VoIP" on the data network, however, as Chapter 2 explored, this is a fallacy. More accurately, this was sales and marketing hype that caught the attention of some customers. What companies did find is a financial savings in using the same carrier network infrastructure to transport both voice and data traffic. Nothing rides free, but the savings of a single infrastructure and single billing system has proven quite significant.

Extra Company

Telephone calls to the outside world are the lifeblood of many businesses. We call customers, vendors, and business partners every day. As companies scrutinize expenses for inbound and outbound telephone calls, close financial management motivates business managers to find creative new ways to reduces costs.

Support Costs

In addition to the engineering resources addressed earlier, many organizations look to cost savings in other support areas. Just as in the network engineering area, don't divest yourself of other critical support resources such as the service desk and the technicians who handle moves/adds/changes. Instead, team your voice and data specialists together as a new unified communications team, extracting the valuable knowledge from every resource at your disposal. Don't let the knowledge of your services, your network, and your requirements slip out the door through some misguided effort to reduce costs. The cost reductions must be won over time. They aren't necessarily real for every business and they don't come immediately.

Help Desk/Support

Help desk support for telephones is generally simple. Everyone knows how to use a telephone. Many companies conducted user training at the time a new PBX was implemented and handed out basic feature guides from their equipment vendor that explained how to use voicemail systems and the various features of the system. In the integrated environment of VoIP/IPT, these features may be delivered to telephone sets that can be treated like traditional telephones. More often, integrated system introduce some element of data workstation feature management. For example, users can often manage their own telephone set button configuration and speed dial lists from a Web interface via their workstations.

It's critical to remember that as the services converge onto a single infrastructure, your corporate Help desk will be getting calls about new services and question about things they too will be unfamiliar with. It's vital that the Help desk and support teams be involved in the migration process and participate in early training efforts it order to effectively support ongoing daily business operations.

Moves/Adds/Changes

When implementing an integrated services project, moves/adds/changes must be taken into consideration. This is hugely important in a traditional telephone environment but even in an IP telephony environment there are still many potential problems. Employees often move his or her workstation, which retrieves an address from the network using Dynamic Host Configuration Protocol (DHCP). Telephones, on the other hand, often had to be moved by the telephony administrator, reprogramming the PBX to deliver extension number and features to a new physical wire in the new work area. With integrated services, this process may be simplified but it cannot be overlooked. For instance, many systems allow the users to make all needed changes but often the users lack the technical sophistication to make the needed changes and even the most savvy users are rarely given access to firewall and security systems that often stand in the way of completely transparent moves adds and changes.

In many cases, the $12 per hour telephone technician-whose primary skills involved being able to read a floor plan, locate wire pairs, and use a punch-down tool-is being replaced with an $80-to-$120K per year IP engineer with knowledge of fire walls, IP router configuration, subnet address masks, and an entirely new set of skills possessed by a limited number of workers.

Remote/Nomadic/Mobile Workers

Integrating voice services with VoIP solutions provides an excellent tool for augmenting remote worker resources. Your call centers can now be staffed with people working from anywhere. For some call centers, this provides an opportunity to hire new, less costly staff that would have previously been unreachable. For example, stay at home mothers can now provide telephone support with full access to corporate resources. The widespread availability of broadband Internet, coupled with VPN technologies, provides a data linkage virtually anywhere. VoIP and IPT solutions do the same thing for voice services.

Enabling New Strategic Applications

Strategic new business applications are many and varied. Your company might have industryspecific applications that don't apply to other industries. Inventory and supply chain management, for example, is crucial in the manufacturing sector but plays a much smaller role in the financial services sector.

Business drivers, market shifts, and process re-engineering all play a role in determining what strategic new applications a business might deploy. CRM systems are permeating many new businesses. Enterprise resource planning (ERP) solutions are another factor for many organizations.

It doesn't matter whether you're deploying Oracle, SAP, or a Web application; the odds are high that any strategic change in your data services applications will ripple into telephony services in some way. In many cases, integrating telephony services will be a key business change enabler in and of itself.

Worker Productivity

Worker productivity will go up. Worker productivity will go down. There will be iterative cycles of improvement. Although your staff may be provided with new tools and new options that can enable them to work more effectively, don't overlook the learning curve. Most people learned basic telephone usage at a young age and have spent most of their lives dealing with telephones. Shifting that process to a softphone running on a PC, connected to a wireless network, integrated with a CRM application presents a new way of working.

Integrating unified communications into the corporate environment introduces the potential for a large cultural change. It's absolutely vital that workers be involved in understanding the changes and how their work will be impacted each step along the way. The more engaged workers are, they more quickly they will find ways to use the new environment to increase productivity. Most workers are driven to get things done, but they also need to understand what the tools they have to work with can do-and how those tools work.

Road warriors can use these technologies to enhance accessibility. Traveling executives can use their office number remotely from a hotel room. Engineers can still work while in training or away on a project. Integrated voice services provide the opportunity for not only enabling this work flow but doing it all transparently. A customer calling a salesperson doesn't need to know that the sales rep is halfway across the country in a hotel. The office telephone number can become truly portable. And the coming advancements in fixed mobile convergence and IP multimedia subsystems (IMS) will couple service more tightly to the remote worker than was ever before possible.

When evaluating systems, it's easy to fall into the "feature/function trap." Vendor selections are often made based on features and functions, with cost comparisons driving final decisions. For your workers, it isn't just about the features that exist, but how they are used. A worker who is used to having a 32-button telephone set that shows eight coworkers' phone lines with status indicators will have to change work habits to effectively use a softphone. Engage workers throughout the entire migration process from planning to production to maximize their productivity on day 1, day 10, and day 100 after deployment.

Obsolescence of Older System

Older systems become obsolete. Traditional Time Division Multiplexed (TDM) PBX systems once had a practical lifetime of 10 years. Many outlived that, but many were also obsoleted early because of technological advances.

Data networks have tended to be re-architected in a shorter life cycle. Data networks are often redesigned every 3 to 5 years. Switching and routing technologies have advanced quickly, making complete redesign of data networks cost effective in a shorter life-span than older PBXs. Consider not just the obsolescence of a legacy telephone system but also the data network life cycle when developing migration strategies to move to VoIP or IPT solutions.

No Longer Want to Invest in Old Technology

Obsolescence is one driver, but for many companies, especially market leaders, there are compelling business reasons to migrate to newer technology. It's not uncommon for an enterprise to move to new technology, not when older systems are at end of life, but when the end is visible on the horizon.

Manufacturer Discontinuation of Product and/or Support

Manufacturers discontinue support for older products every day. In some cases, the parts become scarce, making hardware repairs a challenge. In many cases, manufacturers will consciously choose to end the life of a product in an attempt to encourage customers to move to newer systems. In the history of business telephony, this was often called a "forklift upgrade." The analogy being that a forklift was needed to remove the old equipment to make room for a complete new system.

If your equipment manufacturer has put your company in a "forklift upgrade" situation, it may be important to consider how firm your relationship is with the manufacturer. Vendors play a dangerous game with this strategy, as customers are presented a perfect opportunity to take a system design back out to competition on the open market. This technique has backfired on many vendors, costing them key customers.

Increased Support and Maintenance Costs

As systems age, they become more expensive to support and maintain. Parts may be less available for hardware replacement. Technical skills to support older systems will naturally decline as these systems phase out of useful life. If you continue to use a 10-year-old system when much of the market has moved to other technology, the support costs to maintain an effective staff can easily rise. What it costs to support and maintain a telephony system today may be 30 percent more than it was when that system was a widely deployed standard implementation.

Another cost factor might simply be technology related. Newer hardware and software often introduce new patching and upgrade methodologies that are more cost effective than techniques used in the past. That can drive down support/maintenance costs for new systems in comparison. Make sure you review all the data and factor in the ongoing overhead in dollars, time, and skill set to support each of the options you consider.

Lack of Expansion Capability of Old System

Hardware and software solutions have practical limitations. Telephony systems are introduced to the market at a price point to ensure widespread adoption. As time passes, technology advances, and businesses advance too. A key system designed to support a 10-person office 5 years ago may well be stretched to capacity today, as that office may have 30 people. Hardware could be utilized to the max already. Expansion capability isn't just hardware. Older hardware solutions might not be able to support newer features your business requires. Expansion in software can only be supported to the capability of the hardware.

In your evaluation process, you can't just look at the requirements of today. The investment of technology a business makes is a strategic investment. It has to support the operational needs to the moment, today, as well as growth and evolution to support the strategic needs of the business for some foreseeable future. For some companies, that might be 7 to 8 years, and for others it might only be 3 to 4 years. Incorporate your strategic direction plans for the business with your strategic plans for technology. The technology won't do you any good if you don't build it to support your business.

Setting Proper Expectations

The bottom line for the success of any project is setting proper expectations. The executive management team may have very clearly defined expectations based on ROI and the size of the investment. Users may have an entirely different set of expectations based on workflows and operations processes. If you build your entire ROI case around the technology but implement an integrated service in a way that increases the labor effort of your staff, the overall result may be counterproductive. Everyone needs to know what to expect and what is expected of them. The only way to really be successful in any large project is to clearly define and communicate expectations. Like the network, the telephony system, and your business as a whole, the life cycle of an implementation project is a repeating pattern of setting and reviewing expectations.

Management Expectations

The executive management team focuses on key strategic factors. Capital expenditures (CAPEX) address the investment, and are often tied to ROI. Operational expenditures (OPEX) take into account the cost of operations and support; they're tied more to the total cost of ownership (TCO). Technology can often drive process re-engineering that changes workflows. Technology is often molded to fit business needs, but just as often, business processes are modified to leverage some feature of the chosen technology. You must also consider the return on effort and factor the work effort involved into the total cost of implementation and ownership.

Implementing VoIP or IPT comes with a broad general set of management expectations that vary widely, yet are all accurate. One view is that IPT will save money. This view generally assumes a modest CAPEX spread across all users of the service. Using cost recovery as a lens through which to view CAPEX helps balance the total CAPEX against the true investment and determine how quickly a solution might pay for itself. The money saving view often sees that OPEX can be reduced by saving on recurring cost. For many companies, this is based on a shift from a provider-managed service such as Centrex to a self-managed-IPT service.

Another view is that VoIP may cost more. One migration can lead to another. Some VoIP deployments have been plagued with network upgrade upon upgrade, but this is often because a comprehensive readiness assessment wasn't completed on the front end. Many business managers find that in their environment, CAPEX is as high as it would be to continue using traditional TDM-based PBXs. OPEX can be variable and particularly difficult to measure when you broaden the scope of the IT staff's role. The impact of requiring a new key competency or technical skill in a networking staff can inflate OPEX for the first year or two as the staff climbs up the learning curve. There still may be tremendous value in integrating strategic business or multi-media applications.

A third view is that it doesn't matter. It could be a cost-neutral decision either way. This is why some companies take cost reduction off the table in their strategic planning of technology. It's important to know your core competency and focus on that. The business you're in is the business you have to support. The technology choice needs to be driven to support the strategic direction of the business. Don't let the technology drive your business. Leverage the technology to strengthen your business.

Integrating voice and data is a complex project, filled with potential pitfalls. Comprehensive planning, network readiness assessment, and project oversight is absolutely vital to the success of an IPT implementation.

Every step should be documented. Every test plan should be thoroughly reviewed by multiple team members. As you begin the implementation, you'll face a series of potentially service impacting events. Circuits might be upgraded. Routers and switches might be replaced, and firewalls might be reconfigured. At every step along the way, thoroughly test the new environment. And for each of these steps, document a fallback plan to ensure business operations aren't disrupted if unexpected problems arise. Build a comprehensive plan for success with full management buy-in.

End-User Expectations

It's essential that end users be included in the process from planning to implementation. They are invested in the success of unifying communications services. They need to know that although things will be different, different isn't bad. During needs analysis, you'll need to understand their requirements. As the project progresses, setting expectations about how things work, voice call quality, and new features are important to them.

Collaborating with users makes them part of the process and part of the project and gives them an investment in the success. Treat them as advisors and partners whose business needs you're supporting. Training is often available through the vendors whose solutions you'll buy. Take full advantage of vendor training opportunities. Train the trainer sessions with key users is an approach that's proven very effective.

Even the final cutover implementation needs to actively engage end users. They will be your primary system testers. Use them to help develop test plans, and they'll feel their needs are being addressed. Be proactive and responsive. Another very effective technique is to activate a special cutover Help desk for several days before and after the "go live" date for your new system. This approach builds confidence and makes for satisfied users. When the users are satisfied that they're getting what they need and understand how to use the system, your project is well on its way to being successful.

Inventory of Existing Capabilities

As you begin the assessment part of the project, you must perform an audit of the capabilities of your current telephony system. Such an audit provides key insight into potential problem areas. What you know about your operating environment provides the foundation on which you build your assumptions. The more you know, the more accurate your assumptions will be. There are some specific areas to audit that help increase your chances of success:

• Network infrastructure
• Identify circuits used for wide area networking and Internet connectivity
• Inventory the network hardware-routers, switches, cabling.
• Document software such as router OS versions; this is a good time to get your routed network all on a common foundation
• Current business data applications
• What servers are in place today?
• What is changing or evolving in parallel?
• Identify any linkages between your existing business applications and voice services
• Security
• Inventory/audit your security environment
• Ensure that firewalls and other security systems will allow VoIP traffic
• Determine capabilities for moves/adds/changes allowed by your security system
• Assess legal issues regarding security and encryption for the areas in which you will be operating
• Management tools
• What network management tools are being used in your data center?
• What server/application management tools are you using in your data center?
• Current voice services and equipment
• List all PBXs and key systems in your organization. For each, include its "End Of Life" date and/or date at which it will be fully depreciated
• Document any inbound and outbound call center environments
• Document expected telephony performance
• Inventory all existing telephony features, determine their importance, and decide whether they will be available in the new telephony environment; this audit is covered in the next section
• Measure your current busy hour calling patterns
• Intra-office
• Intra-company (between offices)
• Offnet for each office (incoming and outgoing calls [local, long distance, international]-not to other offices)
• Fax machines
• PSTN channels/lines for each office

Existing Telephony Performance Expectations Audit

Ideally, you should quantify TDM service quality aspects that you want to carry over into IPT, either to ensure you build a system that meets user expectations or so that you have defined criteria to which to hold your systems integrator accountable.

Quantify and define requirements around:

• What is a reasonable length of time to wait for dial tone? At what point do you start jiggling the hookflash or start punching in the number anyway?
• Once you've finished dialing a number, how long do you wait for a ringback tone before hanging up and trying again?
• For every 100 calls you make where you correctly dial the number, how many of the 100 do you expect to succeed?

Based on responses to these questions, define a set of SLA requirements against which the IP telephony environment will be measured, to evaluate its success and ensure that it meets customer expectations. These SLAs should include:

• Availability expectations-This is usually expressed in uptime percentage of the telephony service from an end-user perspective.
• Throughput-Stated as successful call completions as a percentage of call attempts. You might want to provide different throughput requirements for different call types. For example, you might require a 99.9% successful call completion rate for all incoming calls to a call center, while requiring that only 97% of all internal calls complete successfully.
• Call setup and teardown boundaries; for example:
• 95% of all call attempts get dial-tone within 2 seconds while the remaining 5% get dial-tone within 4 seconds
• 90% of all call attempts get ringback tone within 6 seconds while the remaining 10% get ringback tone or congestion tone within 9 seconds
• Voice quality expectations, usually expressed in Mean Opinion Score (MOS) bands of 0.2 range-For example:
• 85% of calls must have a MOS score of 4.2 or higher
• 95% of calls must have a MOS score of 4.0 or higher
• 4% of calls must have a MOS score of 3.8 or higher

You might also want to consider defining different voice quality requirements for interoffice (that is, calls that cross the WAN) than you do for calls within a local office.

Existing Telephony Budgeting, Relationships and Tools Audit

Also worth considering as part of planning your IPT rollout are the potential changes in responsibility for paying phone bills and impacts on business processes:

• Prior to IPT, each region/office may have had their own interconnect and telephony budget.
• After IPT rollout, who will pay the telephone bills? Same as before? Or maybe the NOC team charges each department for their telephony service and holds the entire budget for telephone bills?

Consider existing service provider relationships-telephony, network, and desktop management. Also consider existing management tools-event manager, network management, and server/application management tools. Which (if any) of these existing relationships and tools should be integrated into your new converged environment?

Existing Capabilities Audit

A logical approach to auditing the capabilities of the existing system would seem to be to go to the documentation for the existing system, check to see which features have been paid for and/or implemented, and use that as a guideline for the new system. This approach only gets you part of the way there. What is really needed, beyond knowing what features are available, is knowing what features are actually used. This second requirement needs a great deal more research but can help you ensure that your new IPT system will provide every feature your organization needs, while avoiding the unnecessary effort, complexity, and cost of acquiring an IPT system that provides features that your organization simply does not need.

There are two general approaches to determining which phone features are used and which need to be replicated in any new system. One is network-centric and one is user-centric. The networkcentric approach involves gathering network traffic, such as signaling traffic, to ascertain which features are being used. Although this approach makes perfect sense to an engineer, it often neglects features that are local to specific phone sets. Another network-centric approach is to check the PBX or Centrex configuration information for the features that are available for each line and to use those as a basis for the new system design. Although this option comes closer to understanding the user's needs, it is still, at best, an indirect method. The best way, actually, is to ask the users! The users will be able to explain not only the features that they use but also the relative value of each.

One must also consider that certain phone features that may be unimportant and replaceable in one industry are critical to others. "Wake-Up Call," for instance, is a feature absent from most business telephony systems but one that is critical for the hospitality industry. "Skills Based Routing," the ability to route a call based on the skills of a particular individual call taker or class of call-taker, might not be important in a hospital environment but may be of the utmost importance in an insurance company. These are some of the reasons to ask the users rather than make assumptions.

The user-centric approach begins with the network-centric approach, but instead of jumping right to the inventory and analysis, the list of features is translated into a survey tool to be used by the phone user to indicate features that they employ. Figure 3.2 shows a list of many of the most common features.

Figure 3.2: Traditional telephony features.

Once a comprehensive list of potential features is developed, a suitable user survey approach must be created. Once again, the obvious approach is not the most suitable. The obvious approach is to provide a list of all possible features and ask the user, at the very least, to check off which features they use and, at the very best, to rate the features in terms of their importance on a 1-to-3 or 1-to-5 scale. The problem with this approach is that the users often don't understand the technical name for a feature. The obvious solution is to provide descriptions of the features, but that still leaves the problem that not all users use all features all the time and that they might leave off an important feature.

Another approach is to provide some type of card with the features listed so that when a user uses a particular feature, they can simply "tick off" the feature. Although this approach works well and provides a more-or-less accurate audit over a period of time, it generates a lot of cards. The total number of cards can be reduced by having the user check off the feature the first time they use it and use hash marks to indicate how many times they use the feature during the study period. This reduces the number of cards, but analysis is still problematic. A further simplification can be achieved by choosing representative users for each department, job function, or operational area. Doing so assumes that each executive secretary will use the same set of functions and features-not always an accurate assumption-and that each call center operator will use the same set of features and functions-more likely to be true within a job category. Entry-level operators will likely use the same subset of functions; supervisors will likely use the same set, and so on.

Once a cross-section of users is identified, one more simplification step can be achieved. Through the use of a specially designed survey card, which is drilled at specific points around the periphery to align with audit questions, it is possible to greatly ease the survey and audit process and quickly analyze results. The creation and use of cards of the kind shown in Figure 3.3 can greatly enhance and speed information collection and analysis.

Figure 3.3: Sample telephony capabilities audit card.

It is also not required to print capabilities on a card that will not be used by a specific audit group. "Wake-Up Call," for instance, is not required on a call center operator's list of possible features. Different colored cards should also be used for each functional area to allow common and unique requirements to be identified.

Synchronizing Existing and New Capabilities

Once the cards have been marked by having the appropriate holes removed, they can be stacked and jogged to align the holes; then information can be derived from the card deck regarding features of importance. This is done by inserting a long stick, such as a small diameter chop stick or knitting needle, into a hole and then shaking the stack gently until all cards with the same hole punched out drop from the deck.

This process will result in a list of features that are used in the current system and that therefore must be supported by the new system. Users who only have requirements that are supported by the new system may be placed into the first group for migration. A list of those requirements will also need to be assembled. This process will also result in a list of features that were not known to be requirements of the new system but which must be included in the RFP. Features not supported in the initial release of a new system but which will be supported in subsequent releases can result in users needing those features to be placed in a second group for migration. This process will also result in a list of features that are never intended to be supported by the new system. The needs of these users must be somehow synchronized with the capabilities of any new packet telephony system through retraining, reworking of the need for the feature, or a rethinking of a move to the new packet telephony system until the features are available. In many cases, it should be possible to extend the lifeline of an existing system through the use of a feature or gateway or other mechanism to allow it to continue to provide the needed feature for the foreseeable future.

Voice over Packet

The broad term VoIP has been accepted by the industry and consumers to refer to a new, inexpensive way of making telephone calls using the "Internet." Although "insiders" understand that the IP network is not always the Internet, the common definition is convenient and easy. What VoIP actually means is that the voice information is sent using proprietary signaling protocols, such as Cisco's Skinny or H.323 and increasingly using Session Initiation Protocol (SIP). The term VoP, or Voice over Packet, is inclusive of VoIP and is a more general term meaning the coding of voice into binary and transmitting over a broader range of options, including ATM, Frame Relay, and DSL. By considering a wider range of voice over packet options, not just VoIP, an organization can often maximize use of their current networks, avoid dealing with regulatory issues in certain countries, and extend the life of existing assets.

Network Readiness Assessment

The chapter introduction talked about a race car analogy. At this point in the chapter, we have talked about the reasons to join the race and how to properly assess that the new race cars being purchased or built, at the very least, have all the capabilities of the race cars being replaced and, preferably, are more powerful, faster, and have more features. We now turn our attention to the race track: the existing IP network. Once the decision has been made to move to VoIP or IPT, an extremely important part of the planning process is to evaluate not just whether the existing IP network can handle the predicted call volumes while meeting the exacting real-time performance criteria associated with telephony, but also what enhancements are required to the IP network to ensure that it can do so. More than 60% of organizations that have already rolled out IPT did require some level of IP network upgrade and, in a not insignificant number of cases, the cost of the network upgrade ended up being equivalent to or greater than the cost of the entire new IPT system.

Many existing networks today evolved from departmental local area networks (LANs) that have grown over time. In some cases, regular, methodical redesign work has been performed every few years. Just like the PSTN undergoes constant traffic re-engineering changes, some IP networks have been finely tuned and redesigned to support new data applications. For others, the applications in use today may be very different than the original applications were. It's important to fully understand the network performance requirements of VoIP services being added and how they will impact existing network services.

Many companies begin voice integration projects fully understanding that network upgrades will be required. Network nodes such as routers, switches, and firewalls may already be running at high CPU utilization. They might not be able to support VoIP services without upgrade or replacement. Existing wide area network (WAN) circuits may already be overburdened carrying the existing data applications. Network bandwidth, robustness to single points of failure, and processing capacity are key factors in deploying any new service like integrated voice.

One of the most common mistakes, and one that has doomed more than a few IPT projects to certain failure, is skipping the network readiness assessment and jumping directly to implementation. There are four primary reasons for skipping the network readiness assessment, and all appear to be viable reasons until the project completely falls apart leaving the IT/telephony group with no credibility and the organization with no telephony system. The typical reasons are:

• "A network readiness assessment takes time and money. VoIP/IPT is just another IP application and we know it will work. Why waste time and money proving what we already know?"
• "We hooked up a VoIP server and some phones over the weekend and everything worked beautifully! We can now implement with confidence."
• "We have enough bandwidth in our network to transmit the entire World Book Encyclopedia twice every second. If our network can do that, we can definitely handle VoIP and, besides, our current network utilization is below 30%."
• "We can't upgrade our old TDM system anyway: we have to go to VoIP. Why do an assessment? We've got to move to VoIP anyway!"

The following horror stories, from real organizations who did not do network readiness assessments, will illustrate the inaccuracy, and risk, associated with not performing a comprehensive network readiness assessment before moving the first live call to the existing IP network.

Horror Story #1

A large US retail chain went straight to pilot without having completed a network assessment. Their call quality was terrible, the call setup delays were frequently more than 5 seconds, and down times were frequent and protracted. The pilot was deemed a failure, the roadmap to IP telephony was discarded, a lot of money was wasted, and they are still using their traditional TDM system.
Lesson Learned: Network readiness assessment is a critical part of any move to VoIP/IPT.

Horror Story #2

A large government agency went straight to live implementation without either assessing their network or executing a pilot. Telephony traffic saturated their network, with the result that their call quality was consistently unacceptable and all other distributed applications in their network experienced long delays resulting in extreme telephony and data user dissatisfaction and low productivity. To resolve the problems, the customer had to back out 75% of their IP phones. They are now in the process of doing their network assessment on a live network and will have to try to redesign and upgrade their network without impacting their live users. Their original ROI forecast has been blown away and their current budget analysis is that their IPT rollout will end up costing them more than double their original forecast.
Lesson Learned: Any change to the existing network has far-reaching implications on overall organizational operations and productivity. An investment in network readiness assessment ensures accurate planning and budgeting, minimum impact on the organization, a dramatically increase in the chances of success, and provides a safe fallback position in case things don't go as planned.

So, our recommendation? Do an IP network readiness assessment-the effort required will definitely be worth it, as it will help you plan a successful IPT implementation project that:

• Meets its target dates, as both the resource effort and time needed to upgrade the IP network are factored into the IPT rollout plan
• Comes in on or under budget, as the cost of the IP network upgrade will be factored into the overall cost of the deployment and budgeted for accordingly
• Meets user expectations of telephony performance without impacting on organizational productivity

The Network Readiness Assessment Process

Conducting a successful and valuable network readiness assessment is not as simple as simulating some calls over your IP network and noting the results. Here are some more horror stories from real organizations, but this time, they are from organizations who did conduct a network assessment but who still ended up with serious problems after going live with IPT.

Horror Story #3

A medium-sized enterprise set up their automated assessment tools to run overnight so that the telephony traffic wouldn't degrade the network QoS demanded by their users. The results of the assessment showed acceptable voice quality for all calls. An initial implementation was then rolled out and the voice quality was very low because the voice traffic was now competing with other IP applications for bandwidth.
Lesson Learned: A theoretical network readiness assessment can be accomplished completely offline to avoid negative impact during initial phases but real traffic must be simulated during real business hours to determine the true impact of the new IPT traffic prior to actual implementation.

Horror Story #4

A large distributed IT enterprise ran their own assessment and completed their network upgrade based on this information. However, when they completed implementation, they found that a large percentage of their off-net call attempts were suffering from very low voice quality. After acquiring a management tool, they used it to identify that, during peak hours of the week, there was insufficient bandwidth available to their primary PSTN gateway. It turned out that they had forgotten to simulate off-net traffic in their assessment.
Lesson Learned: Use existing call records from telephone carriers, PBXs, and other sources to ensure that the network readiness assessment includes all calls, both on-net and off-net, and that call volumes can be supported during the busy hours.

Horror Story #5

A university was conducting an assessment and based the distribution of their simulators on their network diagrams. One campus was shown, in the plans, to have a 10Mb link, so they designed the assessment to have 80 calls occurring simultaneously across this link. They found that the voice quality for these calls was appalling. They lowered the number of calls being simulated and discovered that acceptable call quality could only be achieved if the number of calls across this link was limited to 15. This made no sense, so they sent an engineer out to investigate. It turned out they did have a 10Mb switch on that link, but only 1 E1 card (that is, a 2Mb link) was connected to it-their network diagrams had been incorrect.
Lesson Learned: Always validate configurations, system capability, equipment inventory, call capacity, and so on.

In a Perfect World

In a perfect world, with an unlimited budget of time and money, the network readiness assessment would be a carefully applied four-step process. The first step would be to gather information from the live network. This information would be merged with projected network traffic loads anticipated from new IP telephony applications, which would then be subjected to static modeling, which is the process of creating what would, in effect, provide a theoretical snapshot at a moment in time. The output of the static model would provide the input for dynamic computer simulation, which would provide the basis for a proof of concept test. Then, and only then, would an actual field test and field trial be undertaken. Most organizations know that the investment of time and money in such an exhaustive series of steps is not warranted. That is, of course, until they either fail in their attempts to migrate voice over to their IP network or come very close to such a failure. It is only then that they appreciate what they have risked.

In the Real World

Sadly, in the less-than-perfect world of time and budget constraints where most of us live, it is generally not possible to go through this entire network readiness assessment process. Therefore, the minimum set of steps recommended to get the best value out of your assessment is to estimate projected traffic, perform a simple overnight assessment test run and, if successful, move to a daytime assessment test run, starting with low assessment traffic levels and gradually building up to simulating the estimated traffic. If this set of procedures is successful you could then move to a pilot phase. However, by adopting this minimal approach, you still have the opportunity to stop simulating traffic if the test begins to seriously impact the network and other applications and users. Unfortunately, many organizations move straight to a pilot, usually with less than acceptable results.

Understanding the Key Metrics of a Network Assessment

Whether you are conducting your IP network readiness assessment yourself or using an assessment service provider, it is good to understand the key metrics and factors involved.

The PSTN has evolved over time into a finely tuned network that has been optimized for delivering voice traffic. In business especially, for years you heard the phrase "toll quality voice" to describe a service level suitable for business. And of course, you have heard a description of service good enough to hear a pin drop. The Mean Opinion Score (MOS) described in Chapter 2 has been the accepted benchmark for measuring this quality. This network has been built and conditioned to do one thing really well-deliver voice conversations. Your data network has been optimized and honed to support the unique set of data applications your business requires. Integrating telephony services will place new, sometimes-inflexible demands on the resources of your network.

Data networks use IP to deliver traffic. IP is described as being unreliable and having no guarantees. It is a "best efforts" protocol. It was designed to carry sporadic, unpredictable traffic loads that burst to peak volumes at times. You've probably heard the phrase "bursty in nature" to describe most IP traffic. At the transport layer, above IP, there is Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). TCP provides the ability to guarantee delivery through a process of synchronization and acknowledgement messages, but this delivery guarantee also adds overhead.

Table 3.1: Voice and data traffic comparison.

What you see is that IP data networks have very different basic characteristics than traditional voice telephony networks:

• Unlike the dedicated circuit connection the PSTN establishes to carry a phone call, IP network traffic is composed of packets. Packets tend to be short in duration, although a phone call consists of hundreds, even thousands, of packets. Packet data is generally bursty in nature. Since packets are small in size, they are of short duration in terms of time spent on the network, and they can be routed over many diverse paths and carry addressing or routing information inside each packet. IP doesn't establish circuits, it's connectionless.
• IP packets aren't generally delay-sensitive. Email messages can be delayed 60 seconds, or 60 minutes without adverse impact to the "conversation." IP traffic is historically nonreal- time traffic. Delays are expected in an IP network. IP is a best efforts protocol with no guarantee of delivery. The PSTN is designed to minimize delay and provide nearinstantaneous delivery of voice conversations.
• IP uses all the available bandwidth when it has data to deliver. IP doesn't require dedicated bandwidth.

Today, IP networks are designed, redesigned, and constantly reconfigured to carry any kind of traffic. With digitization, any media (voice, video, data files, and so on) can be carried inside IP packets. The most common are data, voice, and video. The challenge you face in unifying communications is in delivering a business-quality telephony service with all the characteristics users expect, such as clarity, fidelity, and near-instantaneous delivery.

To understand the key metrics that will impact on the quality of your IP telephony service, let's take another look at the results of the Telephony Performance Expectations audit that was described earlier in this chapter. User expectations regarding telephony performance are generally quite consistent, as TDM has trained users to have high expectations. These expectations can be summarized as:

• High availability: A user expects to get a dial-tone every time they lift a phone handset.
• Call quality: A user expects that, if they dial the number correctly, then they will get either a ringback tone or a busy tone within no more than a few seconds-users become impatient quickly if they get no tone at all and get irritable if they consistently get a network congestion tone or announcement.
• Voice quality: A user expects to be able to hear the other party in the call clearly and does not want to hear echoes of their own voice. A user considers it to be unacceptable if they have to abandon the call because of poor voice quality.

It's important to note here that call quality and voice quality are both critical, but very different aspects when you look at quality of service in VoIP solutions. Voice quality focuses on the fidelity and user experience from the sound of the call. Call quality includes voice quality as a factor, but also reaches more broadly into the total user experience. How quickly was dial tone provided? Did touch tone dialing work on the first attempt? Do connections across the networks, between offices (or hops across the IP network) process quickly? Do calls complete as expected or do they fail after all digits have been dialed? Call setup delays or failures negatively impact the user experience, reducing call quality regardless of the actually quality of the voice traffic.

When a user perceives unacceptable call or voice quality, that user is likely to terminate the call. If this happens frequently, dissatisfaction with the service lingers. This perception is very difficult to overcome, so you are better off to plan and re-architect your IP network in advance, to make sure you don't end up in this situation.

High Availability

It's important to embrace the telephone network services as a mission-critical component of daily business operations. The PSTN has been engineered to provide 99.999 percent uptime of the telephony service, often referred to as "five nines" reliability. This is equivalent to approximately 5 minutes of downtime per year. Corporate data networks have rarely offered this level of reliability in the past. Think about your corporate network. Have you experienced more than 5 minutes of network downtime in the past year? At this phase of the VoIP/IPT project, it's crucial to understand that some redesign effort may be necessary to provide suitable network reliability to meet the voice and call quality requirements associated with a telephony service.

Five nines reliability is not just about uptime of routers, switches, interfaces and links in the network-it's about ensuring that the network can still provide telephony service even when there has been an outage of any kind, anywhere in the network. The general requirement on an IP network to deliver five nines reliability is that it can still provide full service to all users under any single point of failure. This requires that there be redundant paths and fault-tolerant or high availability equipment to guarantee availability in the event of the failure of a given node or device. It also requires that, even under any single point of failure, there must be sufficient bandwidth available for use by the IP telephony service so that it can still meet user expectations.

In enhancing your IP network to support your IP telephony service, it will be crucial to identify the IP network availability objective that will be committed to the IP telephony application in an SLA.

Call and Voice Quality

Both call and voice quality require adequate bandwidth, low latency, low jitter and low packet loss.

Bandwidth

There must always be enough bandwidth in the network to handle both your IP telephony traffic and all the traffic associated with your other distributed data applications, even under any single point of IP network failure. You probably already have a good idea of the usual profile of the bandwidth usage of your existing data applications, but you also need to calculate the bandwidth requirements for IP telephony. To do this, it's a good idea to first look at your existing TDM call traffic patterns, as the telephony habits of your staff are very likely to remain consistent after you've deployed IP telephony. More detailed guidelines for gathering these call traffic patterns are covered later in this chapter, but the basic idea is to base your bandwidth requirement calculations for each office around the number of calls placed and received during the busiest hour of the busiest day of the year for that office.

Once you have an idea of the maximum number of simultaneous calls that will be handled by each office in your organization, you'll next need figure out what your policies are going to be around codec utilization, as this will impact directly on the bandwidth that will be used by these calls.

Choosing the Right CODEC

To transmit voice over a data network, the voice conversation must be packetized. To transmit the conversation in packets, you need to digitize it. Voice digitization is not a new technology. In the 1960's, the US phone companies began using a digital carrier system called T-carrier while the rest of the world began using a slightly different system called E-1. Initially T-1s and E-1s were used as a trunking technology between phone company central offices. Today, the T-1 or E-1 circuit is a common business connection.

Earlier, we saw that voice represents an analog signal. To use IP, you must first convert it into digital format. This conversion is commonly accomplished in the traditional voice services through a technique known as ,pulse code modulation (PCM), using a coder and decoder (or codec). Using PCM, analog voice conversations are sampled 8000 times per second. A technique called pulse amplitude modulation (PAM) is used to convert each sample into one of 255 possible 8-bit words. Through a process of compressing and expanding (called companding), noise is reduced to help eliminate background hiss and changes in volume.

There are several voice processing standards that were developed by the International Telecommunication Union (ITU, formerly the CCITT) to standardize encoding of digital speech. In the PSTN, the G.711 standard is used worldwide.

More information about encoding standards is available at the ITU Web site at http://www.itu.int/.

Voice Compression Techniques

Different encoding mechanisms use different levels of compression. Although G.711 encoding is widely used, it typically generates a 64Kbps voice stream in each direction (that is, 128Kbps in total for a G.711 call). For some businesses, quality considerations might make a different encoding scheme more suitable. Greater compression of the voice reduces the bandwidth requirement, but voice quality may suffer as a result.

Table 3.2 provides a comparison of different encoding schemes that are all widely used. It lists the Codec types and algorithms used, the bit rate and sample size, and the algorithmic encoding delay. It also shows the maximum possible Mean Opinion Score (MOS) for these codecs. It is important to remember that factors such as encoding delays are cumulative with other delay in the network. If the total delay exceeds 250 milliseconds (ms), voice quality will suffer audibly.

These algorithms are described in depth in ITU-T standards (http://www.itu.int/) and a wide variety of papers.

Table 3.2: Voice encoding schemes

The following list highlights these encoding schemes:

• Pulse Code Modulation (PCM), or G.711, is the approach used in the PSTN today and is widely used in many VoIP environments to ensure consistent voice quality. Virtually every equipment vendor in the market supports G.711. This is also by far the most common codec used in intra-office calls, i.e. where calls are within the LAN.
• G.726, known as Adaptive Differential Pulse Code Modulation (ADPCM), could reduce the bandwidth requirements by half while only sacrificing 0.2 of a point on perceived quality in the MOS.
• G.728, or Low-Delay Code Excited Linear Predictive (LC-CELP), coding is widely used in voicemail systems for digitizing stored voice messages.
• G.729 can deliver an 8-kilobit sample with less than 16ms of processing time. It delivers the best tradeoff of all the standardized codecs, giving the best balance between low bandwidth utilization with very reasonable voice quality. It is widely used on the WAN for inter-office or trunked calls. As an aside, if you're considering using VoP rather than VoIP, the G.729 codec standard has often been used in Voice over Frame Relay (VoFR) and is supported by many frame relay equipment vendors.
• G.723.1, or Algebraic Code-Excited Linear Predictive (ACELP), creates models of the human voice, then predicts what the next sound will be. For efficiency, it encodes the difference between the actual sound and the predicted sound, and the difference is transmitted to the receiving end. In some implementations of this codec, users complained women and children's voices were not represented accurately, probably due to their higher pitch.

Note that the codecs with greater compression rates (G.728, G.729 and G.723.1), while needing less bandwidth, are generally considerably more resource intensive and therefore generally require more expensive equipment. So if you're examining how your codec utilization policy can save your organization money, keep in mind that the use of these codecs generally requires greater CAPEX, with potential long-term savings in OPEX.

A much simpler approach to bandwidth management for IP telephony has been to overprovision the network. This is analogous to the gigabandwidth approach mentioned earlier, but constrained to within the corporate network. In many cases this means adding bandwidth. Although overprovisioning might work initially, in the long run, it's a path to problems. First, it requires investment. Upgrading the network capacity in terms of connections, switches and routers can be a very expensive proposition. This approach might work for a time in a small LAN, but in the metropolitan or WAN or a larger enterprise, it's often too expensive to be a practical solution. One thing is certain: If the bandwidth is available, users will fill it. Already existing data applications can quickly consume the additional capacity, starving voice services. Overprovisioning also rarely improves call quality issues related to dial tone, call completion rate, and factors that might degrade service within a single node, such as codec processing or packetization delays.

You are far better off implementing tangible mechanisms for measuring the QoS and ensuring that network resources can support the required traffic load without service-affecting degeneration of call quality.

QoS

Voice and data are different applications. They each place different demands on the network. The requirements for any application are often described as a class of service. The unanswered question may be: How many classes of service are required to meet the complete QoS needs of all the different business applications on the network?

In order to meet performance-level requirements, the network needs to take into account all these factors:

• Throughput is most often measured in bandwidth. It's a simple measure to determine how much of the data inserted into the network makes it through to the destination.
• Error Rate is a measurement of data loss in some form. Remember that IP is a best efforts protocol and relies on higher-layer protocols, such as TCP, or the application itself to overcome errors and guarantee delivery. Legacy mainframe applications are generally very intolerant of high error rates and data loss.
• Delay is a fact of life in IP networks. Even the Ethernet network used inside an office is a contention-based technology. At its roots, Ethernet is a Carrier Sense Multiple Access/Collision Detection (CSMA/CD) technology regardless of speed. At the IP layer, routers use statistical multiplexing to process traffic and user data has a very bursty characteristic. There will be some transmission delay in any network. Nodal processing at each "hop" of the network adds to delay. Delay is also cumulative from one end of the transmission path to the other.
• Jitter is the variation in delay. Because packets can take different routes across the network, delay variation in IP networks is common. Jitter in voice conversations results in unintelligible conversations that sound "jerky." Jitter buffers can be deployed to reduce this impact, but buffering can only do so much to overcome impairment.
• Scalability is another factor. As companies grow and businesses change, the ability of the network to grow with evolving business needs is an important consideration.
• There have been many studies that demonstrate the most expensive component of network services to be management and administration of the network. This is a factor of return on effort that can directly impact OPEX. A network that is very labor intensive to manage requires more effort, increasing both the OPEX and the TCO.

New approaches to delay and jitter management include intelligent buffering that inserts this variation in delay by inserting it in dead spots in the conversation. Pauses between words or sentences might be indistinguishably increased. This is often referred to as delay distribution.

Today, conscious effort is made to design networks to meet specific performance criteria required by business applications. Telephony as a network service is one more application for which you need to design. The ongoing danger is that every new application potentially creates a new class of service. Network complexity can spin out of control. To maintain manageability, most network engineers favor using only a few critical service classes:

• Quick delivery supports real-time traffic such as voice and video
• Guaranteed delivery supports mission-critical traffic such as mainframe systems
• Best efforts delivery is standard IP to support everything else
• A management class to ensure the network can always be managed even at peak traffic loads

In a well-managed network with adequate bandwidth, QoS is simply a prioritization mechanism. One approach to QoS might be to aggregate similar traffic types to ensure each type takes the appropriate network path as a traffic engineering technique. There are several approaches to providing QoS for IPT. Each adds overhead in some fashion to support this prioritization. You might think of it as a "traffic cop" function.

Approaches to QoS with IP

The most common techniques for delivering QoS in IP networks fall into three broad categories:

• Signaled QoS-Integrated Services (IntServ) introduces a signaling protocol to IP. That's the overhead-another protocol. Using IntServ, the user's application sends a call setup signal to the network. This is basically a request for a set of service delivery parameters required to complete a call. Using the approach, the network can check resource availability and deliver traffic accordingly. This approach is very similar in process to the circuit setup and teardown associated with a telephone call on the PSTN. In the PSTN, ISDN (access networks) and SS7/CSS7 transit networks provide this signaling mechanism.
• Provisioned QoS-A second approach requires advance planning and design. Differentiated Services (DiffServ, also called the DiffServ Code Point-DSCP) requires specific routes through the network predefined and available for each type or class of traffic. Paths might be pre-existing as part of the total network design or involve yet some other protocol to set up resources on demand. DiffServ is most often used as an aggregation technique to direct similar traffic along the same major network paths.
• QoS "Shim" or Bypass- is an approach that eliminates the normal hop-by-hop routing IP uses. It adds a "tag" to each packet that essentially shortcuts delivery to the best available path for that type of traffic. MPLS is compatible with frame relay and ATM networks. It has become a widely used approach to delivering QoS in many environments.

There are other approaches used in providing QoS for VoIP call quality. 802.1p/q tagging is frequently implemented with VLANs at Layer 2 inside parts of the network. IP Type of Service (TOS) markings and IP precedence approaches have also been popular. There are a variety of Weighted Fair Queuing techniques used by different vendors to specifically address the issues of delay and jitter.

Each of these methods boils down to prioritization, aggregation, or some combination of the two. These techniques either request network resources or rely on some other protocol or mechanism to ensure the necessary paths are available through the network. These QoS approaches also provide traffic management and in some cases traffic shaping capability.

QoS implementation presents a hurdle because there are many options and approaches to choose from. Different vendors often prefer different approaches and techniques, sometimes making comparison of solutions challenging. Because QoS is really an approach to resource management in the network, distinguishing traffic types is a vital part of the process.

These issues not only need to be dealt with inside the LAN, they become even more critical in the WAN. WAN QoS raises the complexity significantly. If you maintain your own private WAN, you have direct control over traffic handling. If your WAN consists of circuits purchased through a network provider, you'll need to review, and perhaps revise the SLA you have in place with this provider, to guarantee that your prioritized traffic is properly handled. At the very least, you should ensure that this SLA addresses the key network performance requirements that you need in order to be able to meet your own telephony SLAs and ensure the delivery of any realtime intensive streamed services or applications in a manner that meets your users' requirements.

An effective SLA that fully documents IP network provider commitments should include:

• Availability assurances, usually expressed in uptime percentage of the network from an end-to-end perspective
• Throughput expressed in guaranteed bandwidth for a given traffic type; this might be expressed in kilobits or as a percentage of the network carrying capacity
• Delivery guarantees against packet loss expressed as percentage of lost/dropped packets
• Tolerable jitter characteristics; this facet of QoS will be addressed in more depth in the next chapter

To be effective, the voice service provider, whether they are a third party provider or an internal department, must monitor the network to ensure that the underlying network-centric SLAs are being met by the network provider. Chapter 6 will dig deeper into monitoring, and Chapter 7 will explore ongoing optimization.

WAN providers, the telcos and ISPs, have widely adopted MPLS technology, but you will need to negotiate how prioritization tagging applied within your network will be treated once it hits the provider network. This is the only way you can ensure suitable WAN performance. If the provider remaps MPLS tags to their scheme for their backbone QoS, you'll need to understand their approach, and make sure that you're getting the service delivery guarantees you need for your business services.

When testing network performance, especially across a WAN, it's crucial to test the end-to-end connection performance, not just node-to-node. Delay is cumulative. So is jitter. Voice is an endto- end service and can only be tested effectively by simulating live calling patterns.

Traffic engineering and testing must consider peak traffic loads. Testing in a controlled lab environment will yield very different results than an implementation in your production network. When evaluating your QoS approach, use a combination of network testing tools. Traffic generators need to simulate all traffic types in conditions that match your busiest times. Analyzers and monitors will help verify that bandwidth, throughput, error rate, delay, and jitter meet the requirements for IPT voice quality.

The right balance of network performance and QoS can be blended with MPLS and 802.1p/q and VLANs to enhance QoS. These techniques, when designed methodically, can also improve security by isolating voice service from other data traffic while enhancing call quality.

Tips and Tricks for A Successful Network Assessment

Now, having covered the key elements of a network assessment, let's have a look at a few tricks that will help you avoid the most common mistakes, so that you can get the best value out of your network assessment.

It's important that you methodically test the characteristics of the network to ensure that voice and call quality requirements can be achieved, even at peak telephony call rates, during peak utilization times on your IP network and during any single point of failure outages in your network.

It's also important to maintain a holistic view of network resource management. As a counterpoint to voice and call quality, it's crucial that IP telephony traffic doesn't starve other mission-critical data applications of network resources, primarily bandwidth. You have to plan for balance between real-time critical telephony traffic and other traffic (such as bursty email and Web traffic) that, while less time critical, is equally important to the productivity of your business.

You need to understand aspects of the data flows on your network such as traffic type, frame size, any prioritization schemes in use (MPLS or 802.1p/q, for example), utilization (both normal utilization and peak conditions), latency or delay, jitter, and loss. Measuring these factors will help in benchmarking service and application performance.

Simulating Calling Patterns

To ensure that your network assessment accurately measures the impact of telephony on your IP network, it is crucial that all IP telephony traffic modeling and simulation conducted during the assessment accurately reflects your organization's existing calling patterns. Call usage reports from either the current provider or existing system provide a wealth of data about your existing inbound and outbound telephony traffic flows.

Whether the current telephone service is delivered through a company-managed PBX or a telcoprovided Centrex-like service, this information is crucial and should be readily available either in the form of reports or Call Detail Records (CDRs). These reports help to identify important data elements such as the busy hour of the business day, the busy day of the week and month, and the peak call volumes that must be supported in the new system. Enterprise business will find that remote offices might have very different traffic patterns and requirements than the corporate headquarters location. Remote offices will also vary depending on the role they play in the enterprise. A sales office will place mostly outbound calls, while a customer service call center will mostly receive inbound calls. It's important to be model all these different calling patterns in your assessment, so that you get an accurate view of the impact of these different calling patterns on different parts of your network.

Many businesses experience cyclical trends. In agriculture, the growing season may be a factor. In transportation, summer vacation may put more traffic on the roads. Financial services often see cycles related to the fiscal year rather than the calendar year. It's prudent to evaluate these cycles to identify historical calling patterns for the past several months or even for the past year. Your assessment needs to model and simulate your peak activity periods, not just day-to-day business operations.

Simple VoIP calculators such as those available at http://www.voip-calculator.com/calculator/ can help you identify key issues:

• Estimating the bandwidth needed to support a known number of phone lines
• Calculating the bandwidth required to support busy-hour call volumes
• Determining how many paths might be needed across a WAN

Network analyzers, whether commercial or open source, offer performance measurement tools to help understand the current service levels provided in your network.

Simulating Gateways

Initially there were two types of gateways used for early IPT solutions. A signaling gateway provided the ability to connect to the SS7 network in the PSTN. A trunking gateway was used to connect the actual voice paths. This technique of separating functions into "command/control" and "traffic bearing" components was widely adopted for efficiency and to provide economy of scale. As multi-media usage has evolved in the past 10 years, we often heard the term "media gateways." Although it has remained a common practice to separate the signaling or command path from the media path, these functions are frequently consolidated into a single gateway.

There are three types of media gateways most commonly deployed in an IP telephony environment:

• Gateways to PSTN: These are gateways that perform a bridging function between your IP telephony environment and the PSTN, to facilitate the transit of outgoing and incoming calls from/to your organization. On the PSTN side of a gateway, the most common interconnect methods used are ISDN (PRI over T-1/E-1 or BRI over a single twisted-pair line) or analog, while the voice compression algorithm is PCM, as previously discussed. On the internal side of your organization, a gateway communicates with the rest of your IP telephony environment using IP telephony control protocols such as SIP, H.323 or MGCP and transits voice streams over the IP network using one of the codecs mentioned in the previous section. When someone in your organization makes an external call, the call is routed to the most appropriate gateway, which then initiates the call into PSTN and takes responsibility for mapping the PCM-encoded voice channel on the PSTN side into bi-directional RTP streams over the IP network using the appropriate codec. Similarly, for incoming calls to an organization, when the PSTN makes a call to the gateway, the gateway passes the call setup request into the IP telephony system, so that it can be routed to the appropriate end user device and, once the call is answered, again takes responsibility for mapping the PSTN voice channel into bi-directional RTP streams to the answering device.
• Gateways to traditional PBXs: Generally, an IP telephony migration may take months or even years. During the migration, it is necessary to be able to facilitate calls between users on traditional PBX handsets and IP telephony users in the IP network. This is accomplished by placing gateways between traditional PBXs or key systems and the IP telephony environment. The two most common form of interconnect provided by these gateways are analog lines and Q.SIG.
• Gateways to IP Telephony Service Providers: Many traditional telephony service providers are now providing IP telephony interconnects to enterprise and many new small IP telephony service providers are springing up every day. It is therefore becoming more and more common for enterprises to route incoming and outgoing calls via an IP telephony service provider. In this case, the gateway is in fact an IP-to-IP gateway, as it is actually routing IP telephony traffic on both sides. The major difference in this case is that each side of the gateway is in a different domain-the internal side of the gateway is in the enterprise's domain, whereas the outside of the gateway is in the service provider's domain. As such, these gateways are responsible not only for bridging between telephony environments, but also perform a vital telephony firewall function. Session Border Controllers (or SBCs) fall into this category of gateway.

Irrespective of which types of gateways you will be implementing in your environment, in all cases, they are likely to have specific performance requirements on the enterprise IP network and on the external (PSTN, traditional PBX or IP Telephony Service Provider) side of the gateway. This needs to be taken into consideration. If the data network bandwidth and QoS on the path to a gateway doesn't complement the trunking requirements of that gateway (i.e. the forecast number of simultaneous calls that that gateway will be required to support during peak hours), problems will follow. Overlooking details such as this can result in performance bottlenecks in your IP network or between the two networks. Don't forget to model and simulate gateways and their expected call traffic load and use a broad combination of network analyzers and monitoring or assessment tools to perform a comprehensive evaluation of your network's throughput and performance at these potential bottlenecks.

Plan For The Future

The primary motivator for conducting your network readiness assessment might be to plan towards an IP telephony deployment, but don't stop there. Don't just assess and understand voice service requirements in conjunction with all existing data services. Look to the future and evaluate business plans for other new services too. If you're planning a major CRM system rollout next year, that evolution has to be factored into the plans for voice integration. Just-intime planning might seem effective at first glance, but in the long term, often costs more than a methodical approach with comprehensive data gathering and information analysis. This methodical approach will yield a more resilient network design with the capacity to not only support a successful integrated voice service but also provide a growth path to support all the unified communications needs of your business.

Assessment Tools

If you opted for the "do-it-yourself" approach, you will have access to sophisticated tools embedded in the routers, switches, gateways, end systems, and other components of your networks. However, even if you haven't chosen the DIY option, there is still an array of tools you can use to provide "the big picture" as well as pinpoint areas that require a more granular focus.

Third-Party Tools

Third party tools for modeling, monitoring, measuring, and managing are invaluable. They provide broad, cross-platform visibility into facets of network operation that far exceed what humans alone can do without those tools. These third-party tools consist of a broad array of open source and commercial solutions. The selection of these tools is the subject of the third-party tools selection report card described in the next section and their application to the life cycle of the network are described in further detail in subsequent chapters.

Third-Party Tools Selection "Report Card"

Choosing third-party network modeling, monitoring, measuring, and management tools can be a daunting task. The job of reviewing any given tool is not so difficult but, rather, the comparison of multiple tools from multiple systems, the alignment of the various capabilities, and determining what is important can be staggering and is no peripheral task. The tool or tools in this group that are selected are critical path, make or break, choices that, to a very large extent, management might not even consider critical to success, thus, the acquisition of such tools may have to be justified, fought for, and ultimately won and put to good use.

To assist you in your selection process, I have created the Modeling, Measurement, Monitoring, and Management Tools Report Card (4MTRC). The report card is a set of six Microsoft Excel spreadsheets. There are five identical report card spread sheets that may be used to evaluate as many as five separate 4M tools. The sixth spreadsheet allows you to compare the tools side by side and support an intelligent selection process. The spreadsheets are locked to avoid inadvertent changes but a password is provided so that the spreadsheets may be modified by an organization for their own use. Those knowledgeable in the inner workings of Excel can take a look and see that there is nothing particularly clever about the coding. The real value is the knowledge that is embedded in the categories that were chosen for comparison as well as the weighting factors applied by the author to the different categories. For users with limited resources these two factors-the comparison list and associated weighting-will be an invaluable source of assistance in the selection process, while for the more resource-rich organization, will provide a convenient starting point for building your own customized selection report card for your organization.

Further, it can also be extremely difficult to justify to your management team the cost of purchasing network modeling and assessment tools that will only be used once. Fortunately, there are lots of consultants and systems integrators out there who not only own assessment tools, but who are also experts in conducting fast and efficient network readiness assessments. The purchase of a one-off assessment service from one of these experts is usually much easier to get budget approval for and has the added advantage that these experts are unlikely to overlook any significant details while conducting the assessment.

If you choose to go this route, use the report cards to assist you in differentiating between the capabilities of the consultants who bid for the assessment contract, as this will help you to narrow the field down to those consultants who can provide a comprehensive assessment service. Also, when you've selected an IPT assessment consultant and they come on-site, take advantage of their presence and assign some of your soon-to-be IPT operations staff to work with them' this is a great opportunity to get some free hands-on IPT training!

Finally, if you are thinking of using a systems integrator for the design and deployment of your IPT system, be aware that many systems integrators include IP network readiness assessment as part of their standard implementation service. However, keep in mind that the assessment service provided by an SI as part of a full rollout may not be as comprehensive or exacting as one provided by an independent network assessment specialist.

Summary: The Road to Success

While "your mileage may vary" in this chapter we have provided some basic steps every company must take to successfully integrate voice and data network services. IPT is one of many new technologies being deployed today. As previously discussed in greater detail, you will need to consider these basics when integrating any new technology:

• Requirements analysis-First map out your objectives. Why are you making this change? Don't make the decision to move to IPT and then try to explain why. What business needs are you addressing? What factors drive the decision? Document your expectations of the benefits you expect to see. The success of a VoIP deployment hinges on the data gathering and analysis. The more you understand ahead of time about your requirements, the further you are ahead of the game.
• SLAs-Formulate SLAs on which the success of the IP telephony deployment will be measured. Evaluate the impact of these telephony SLAs on the IP network SLAs that you have in place with your WAN service provider. Formulate new IP network SLAs if necessary.
• Planning-Be methodical and document every facet of the entire IP telephony deployment/implementation process. If there is ever a time to be overly thorough in documenting plans, this is it.
• Assessment testing-After you've documented your telephony requirements and mapped them into requirements on your IP network, test your network. This is the only way to know for certain that your network can support your VoIP requirements. Test and document all the related network parameters that influence successful voice delivery. Thorough analysis in the beginning guarantees that you know what to test at this point. It gives you the assurance of planned testing. Ad hoc testing of things that you guessed at won't increase your chances of success. Integrate your testing to support a fully converged network. Test everything, not just VoIP services capability. Your existing business applications on the WAN and LAN need to be tested while voice traffic is being simulated. It's also a good time to test your security posture. If you design without considerations for security, run all your VoIP traffic through firewalls later on, you're in for surprises. Security elements add overhead and delay. They can impact performance, and it's absolutely critical that you test to your coming real-world as thoroughly as possible.
• Acquiring the right resources-Resource acquisition means many different things. Sending your technical staff to training before you're halfway into the project is resource acquisition. For other companies, bringing in outside help from either a consultant or a trusted vendor partner is a tried and true method of acquiring resources in the short term. There is no shame in admitting you need expertise from outside, then working with a consulting partner. Leverage expertise where you can. Partners whose core competency is successful implementation can be a huge asset in deploying new services.
• Looking ahead-Don't look at integrating voice, whether you're looking at it as VoIP or IPT as the final destination. It's a step along the road of your constantly changing network environment. Evaluate the scalability of your chosen solution against future business strategies. Can your network continue to grow to support your business 3 years from now? 5 years? Once you can deliver voice services in your environment, can you continue to grow at a sustainable rate? How will new business applications affect voice service? This is a perfect time to review the overall future capacity of your network in conjunction with your strategic direction.

After reading this chapter, hopefully, you appreciate the vehicles as well as the track and have a deeper understanding of their relationship. This chapter has probed more deeply into the real value in diligent and thorough assessment of the network prior to beginning implementation. It has followed the methodical path established in Chapter 1 and has begun the exploration into the requirements for suitable bandwidth and how you might evaluate QoS approaches to ensure delivery of acceptable call quality. The next chapter will continue to dive deeper into the design and deployment life cycle.

The focus has continued to be on providing specific, actionable items that you can perform for your own situation and, and you can use the provided report card to assist you in the selection of the proper tool or tools for modeling, measuring, monitoring, and managing your multi-media network.

Chapter 4 will describe the process to translate the planning and assessment information developed in this chapter into a design upon which you can do pre-deployment testing. At this point, you have completed the first step in the IPT life cycle. Chapter 4 will explore the next step in making your VoP project a reality.

• Chapter 3: Planning and Assessment
• Business Drivers for Change
• Lower Costs
• The Myth of Bandwidth Savings
• Access Charge/Local
• Long Distance
• Support Costs
• Remote/Nomadic/Mobile Workers
• Enabling New Strategic Applications
• Worker Productivity
• Obsolescence of Older System
• Setting Proper Expectations
• Management Expectations
• End-User Expectations
• Inventory of Existing Capabilities
• Existing Telephony Performance Expectations Audit
• Existing Telephony Budgeting, Relationships and Tools Audit
• Existing Capabilities Audit
• Synchronizing Existing and New Capabilities
• Network Readiness Assessment
• The Network Readiness Assessment Process
• In a Perfect World
• In the Real World
• Understanding the Key Metrics of a Network Assessment
• High Availability
• Call and Voice Quality
• Tips and Tricks for A Successful Network Assessment
• Simulating Calling Patterns
• Simulating Gateways
• Plan For The Future
• Assessment Tools
• Summary: The Road to Success

Copyright Statement

' 2007 Realtimepublishers.com, Inc. All rights reserved. This site contains materials that have been created, developed, or commissioned by, and published with the permission of, Realtimepublishers.com, Inc. (the Materials") and this site and any such Materials are protected by international copyright and trademark laws.

THE MATERIALS ARE PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. The Materials are subject to change without notice and do not represent a commitment on the part of Realtimepublishers.com, Inc or its web site sponsors. In no event shall Realtimepublishers.com, Inc. or its web site sponsors be held liable for technical or editorial errors or omissions contained in the Materials, including without limitation, for any direct, indirect, incidental, special, exemplary or consequential damages whatsoever resulting from the use of any information contained in the Materials.

The Materials (including but not limited to the text, images, audio, and/or video) may not be copied, reproduced, republished, uploaded, posted, transmitted, or distributed in any way, in whole or in part, except that one copy may be downloaded for your personal, noncommercial use on a single computer. In connection with such use, you may not modify or obscure any copyright or other proprietary notice.

The Materials may contain trademarks, services marks and logos that are the property of third parties. You are not permitted to use these trademarks, services marks or logos without prior written consent of such third parties.

Realtimepublishers.com and the Realtimepublishers logo are registered in the US Patent & Trademark Office. All other product or service names are the property of their respective owners.

If you have any questions about these terms, or if you would like information about licensing materials from Realtimepublishers.com, please contact us via e-mail at info@realtimepublishers.com.

Searches related to The definitive guide to Successful deployment of VoIP and Ip Telephony :
IP Telephony | Understand IP Telephony | Free IP PBX Guide | Choose a Business VOIP Solution | On-demand PBX Flexible | Business Telephone System | Small Office IP Phones | Voice Over Internet Protocol | IP Telephony Resources | IP Telephony Definition | Services IP Telephony | IP Telephony Systems | IP Telephony Solutions | IP Telephony Overview | IP Telephony Extends | IP Telephony Internet | IP Telephony Basics | Internet Telephony | IP Telephony Definition | Portfolio of Telephony | Converged IP Telephony | Installing IP Telephony | Protocol Telephony General | Benefits of IP Telephony | Replace Your Hosted PBX | Compare Business VOIP Providers | Convergence IP Telephony | IP Telephony Service | IP Telephony Packet-based | IP Telecommunications Portal | IP Telephony Connectivity | IP Telephony Availability | IP Telephony Connections | Internet and IP-based Networks | Projet IP Telephony | IP Telephony Info | Businss IP Phone System | IP Telephony Applications | Innovative IP Telephony | Telephony-based Attack | VOIP IP Telephony | VOIP Understand IP Telephony | VOIP Free IP PBX Guide | VOIP Choose a Business VOIP Solution | VOIP On-demand PBX Flexible | VOIP Business Telephone System | VOIP Small Office IP Phones | VOIP Voice Over Internet Protocol | VOIP IP Telephony Resources | VOIP IP Telephony Definition | VOIP Services IP Telephony | VOIP IP Telephony Systems | VOIP IP Telephony Solutions | VOIP IP Telephony Overview | VOIP IP Telephony Extends | VOIP IP Telephony Internet | VOIP IP Telephony Basics | VOIP Internet Telephony | VOIP IP Telephony Definition | VOIP Portfolio of Telephony | VOIP Converged IP Telephony | VOIP Installing IP Telephony | VOIP Protocol Telephony General | VOIP Benefits of IP Telephony | VOIP Replace Your Hosted PBX | VOIP Compare Business VOIP Providers | VOIP Convergence IP Telephony | VOIP IP Telephony Service | VOIP IP Telephony Packet-based | VOIP IP Telecommunications Portal | VOIP IP Telephony Connectivity | VOIP IP Telephony Availability | VOIP IP Telephony Connections | VOIP Internet and IP-based Networks | VOIP Projet IP Telephony | VOIP IP Telephony Info | VOIP Businss IP Phone System | VOIP IP Telephony Applications | VOIP Innovative IP Telephony | VOIP Telephony-based Attack | IP Telephony VOIP | Understand IP Telephony VOIP | Free IP PBX Guide VOIP | Choose a Business VOIP Solution VOIP | On-demand PBX Flexible VOIP | Business Telephone System VOIP | Small Office IP Phones VOIP | Voice Over Internet Protocol VOIP | IP Telephony Resources VOIP | IP Telephony Definition VOIP | Services IP Telephony VOIP | IP Telephony Systems VOIP | IP Telephony Solutions VOIP | IP Telephony Overview VOIP | IP Telephony Extends VOIP | IP Telephony Internet VOIP | IP Telephony Basics VOIP | Internet Telephony VOIP | IP Telephony Definition VOIP | Portfolio of Telephony VOIP | Converged IP Telephony VOIP | Installing IP Telephony VOIP | Protocol Telephony General VOIP | Benefits of IP Telephony VOIP | Replace Your Hosted PBX VOIP | Compare Business VOIP Providers VOIP | Convergence IP Telephony VOIP | IP Telephony Service VOIP | IP Telephony Packet-based VOIP | IP Telecommunications Portal VOIP | IP Telephony Connectivity VOIP | IP Telephony Availability VOIP | IP Telephony Connections VOIP | Internet and IP-based Networks VOIP | Projet IP Telephony VOIP | IP Telephony Info VOIP | Businss IP Phone System VOIP | IP Telephony Applications VOIP | Innovative IP Telephony VOIP | Telephony-based Attack VOIP | SLA IP Telephony | SLA Understand IP Telephony | SLA Free IP PBX Guide | SLA Choose a Business VOIP Solution | SLA On-demand PBX Flexible | SLA Business Telephone System | SLA Small Office IP Phones | SLA Voice Over Internet Protocol | SLA IP Telephony Resources | SLA IP Telephony Definition | SLA Services IP Telephony | SLA IP Telephony Systems | SLA IP Telephony Solutions | SLA IP Telephony Overview | SLA IP Telephony Extends | SLA IP Telephony Internet | SLA IP Telephony Basics | SLA Internet Telephony | SLA IP Telephony Definition | SLA Portfolio of Telephony | SLA Converged IP Telephony | SLA Installing IP Telephony | SLA Protocol Telephony General | SLA Benefits of IP Telephony | SLA Replace Your Hosted PBX | SLA Compare Business VOIP Providers | SLA Convergence IP Telephony | SLA IP Telephony Service | SLA IP Telephony Packet-based | SLA IP Telecommunications Portal | SLA IP Telephony Connectivity | SLA IP Telephony Availability | SLA IP Telephony Connections | SLA Internet and IP-based Networks | SLA Projet IP Telephony | SLA IP Telephony Info | SLA Businss IP Phone System | SLA IP Telephony Applications | SLA Innovative IP Telephony | SLA Telephony-based Attack | IP Telephony SLA | Understand IP Telephony SLA | Free IP PBX Guide SLA | Choose a Business VOIP Solution SLA | On-demand PBX Flexible SLA | Business Telephone System SLA | Small Office IP Phones SLA | Voice Over Internet Protocol SLA | IP Telephony Resources SLA | IP Telephony Definition SLA | Services IP Telephony SLA | IP Telephony Systems SLA | IP Telephony Solutions SLA | IP Telephony Overview SLA | IP Telephony Extends SLA | IP Telephony Internet SLA | IP Telephony Basics SLA | Internet Telephony SLA | IP Telephony Definition SLA | Portfolio of Telephony SLA | Converged IP Telephony SLA | Installing IP Telephony SLA | Protocol Telephony General SLA | Benefits of IP Telephony SLA | Replace Your Hosted PBX SLA | Compare Business VOIP Providers SLA | Convergence IP Telephony SLA | IP Telephony Service SLA | IP Telephony Packet-based SLA | IP Telecommunications Portal SLA | IP Telephony Connectivity SLA | IP Telephony Availability SLA | IP Telephony Connections SLA | Internet and IP-based Networks SLA | Projet IP Telephony SLA | IP Telephony Info SLA | Businss IP Phone System SLA | IP Telephony Applications SLA | Innovative IP Telephony SLA | Telephony-based Attack SLA | Service Level Agreement SLA | IPT IP Telephony | IPT Understand IP Telephony | IPT Free IP PBX Guide | IPT Choose a Business VOIP Solution | IPT On-demand PBX Flexible | IPT Business Telephone System | IPT Small Office IP Phones | IPT Voice Over Internet Protocol | IPT IP Telephony Resources | IPT IP Telephony Definition | IPT Services IP Telephony | IPT IP Telephony Systems | IPT IP Telephony Solutions | IPT IP Telephony Overview | IPT IP Telephony Extends | IPT IP Telephony Internet | IPT IP Telephony Basics | IPT Internet Telephony | IPT IP Telephony Definition | IPT Portfolio of Telephony | IPT Converged IP Telephony | IPT Installing IP Telephony | IPT Protocol Telephony General | IPT Benefits of IP Telephony | IPT Replace Your Hosted PBX | IPT Compare Business VOIP Providers | IPT Convergence IP Telephony | IPT IP Telephony Service | IPT IP Telephony Packet-based | IPT IP Telecommunications Portal | IPT IP Telephony Connectivity | IPT IP Telephony Availability | IPT IP Telephony Connections | IPT Internet and IP-based Networks | IPT Projet IP Telephony | IPT IP Telephony Info | IPT Businss IP Phone System | IPT IP Telephony Applications | IPT Innovative IP Telephony | IPT Telephony-based Attack | IP Telephony IPT | Understand IP Telephony IPT | Free IP PBX Guide IPT | Choose a Business VOIP Solution IPT | On-demand PBX Flexible IPT | Business Telephone System IPT | Small Office IP Phones IPT | Voice Over Internet Protocol IPT | IP Telephony Resources IPT | IP Telephony Definition IPT | Services IP Telephony IPT | IP Telephony Systems IPT | IP Telephony Solutions IPT | IP Telephony Overview IPT | IP Telephony Extends IPT | IP Telephony Internet IPT | IP Telephony Basics IPT | Internet Telephony IPT | IP Telephony Definition IPT | Portfolio of Telephony IPT | Converged IP Telephony IPT | Installing IP Telephony IPT | Protocol Telephony General IPT | Benefits of IP Telephony IPT | Replace Your Hosted PBX IPT | Compare Business VOIP Providers IPT | Convergence IP Telephony IPT | IP Telephony Service IPT | IP Telephony Packet-based IPT | IP Telecommunications Portal IPT | IP Telephony Connectivity IPT | IP Telephony Availability IPT | IP Telephony Connections IPT | Internet and IP-based Networks IPT | Projet IP Telephony IPT | IP Telephony Info IPT | Businss IP Phone System IPT | IP Telephony Applications IPT | Innovative IP Telephony IPT | Telephony-based Attack IPT | Internet Protocol Telephony IPT | CTI IP Telephony | CTI Understand IP Telephony | CTI Free IP PBX Guide | CTI Choose a Business VOIP Solution | CTI On-demand PBX Flexible | CTI Business Telephone System | CTI Small Office IP Phones | CTI Voice Over Internet Protocol | CTI IP Telephony Resources | CTI IP Telephony Definition | CTI Services IP Telephony | CTI IP Telephony Systems | CTI IP Telephony Solutions | CTI IP Telephony Overview | CTI IP Telephony Extends | CTI IP Telephony Internet | CTI IP Telephony Basics | CTI Internet Telephony | CTI IP Telephony Definition | CTI Portfolio of Telephony | CTI Converged IP Telephony | CTI Installing IP Telephony | CTI Protocol Telephony General | CTI Benefits of IP Telephony | CTI Replace Your Hosted PBX | CTI Compare Business VOIP Providers | CTI Convergence IP Telephony | CTI IP Telephony Service | CTI IP Telephony Packet-based | CTI IP Telecommunications Portal | CTI IP Telephony Connectivity | CTI IP Telephony Availability | CTI IP Telephony Connections | CTI Internet and IP-based Networks | CTI Projet IP Telephony | CTI IP Telephony Info | CTI Businss IP Phone System | CTI IP Telephony Applications | CTI Innovative IP Telephony | CTI Telephony-based Attack | IP Telephony CTI | Understand IP Telephony CTI | Free IP PBX Guide CTI | Choose a Business VOIP Solution CTI | On-demand PBX Flexible CTI | Business Telephone System CTI | Small Office IP Phones CTI | Voice Over Internet Protocol CTI | IP Telephony Resources CTI | IP Telephony Definition CTI | Services IP Telephony CTI | IP Telephony Systems CTI | IP Telephony Solutions CTI | IP Telephony Overview CTI | IP Telephony Extends CTI | IP Telephony Internet CTI | IP Telephony Basics CTI | Internet Telephony CTI | IP Telephony Definition CTI | Portfolio of Telephony CTI | Converged IP Telephony CTI | Installing IP Telephony CTI | Protocol Telephony General CTI | Benefits of IP Telephony CTI | Replace Your Hosted PBX CTI | Compare Business VOIP Providers CTI | Convergence IP Telephony CTI | IP Telephony Service CTI | IP Telephony Packet-based CTI | IP Telecommunications Portal CTI | IP Telephony Connectivity CTI | IP Telephony Availability CTI | IP Telephony Connections CTI | Internet and IP-based Networks CTI | Projet IP Telephony CTI | IP Telephony Info CTI | Businss IP Phone System CTI | IP Telephony Applications CTI | Innovative IP Telephony CTI | Telephony-based Attack CTI | Computer Telephony Integration CTI | PTT IP Telephony | PTT Understand IP Telephony | PTT Free IP PBX Guide | PTT Choose a Business VOIP Solution | PTT On-demand PBX Flexible | PTT Business Telephone System | PTT Small Office IP Phones | PTT Voice Over Internet Protocol | PTT IP Telephony Resources | PTT IP Telephony Definition | PTT Services IP Telephony | PTT IP Telephony Systems | PTT IP Telephony Solutions | PTT IP Telephony Overview | PTT IP Telephony Extends | PTT IP Telephony Internet | PTT IP Telephony Basics | PTT Internet Telephony | PTT IP Telephony Definition | PTT Portfolio of Telephony | PTT Converged IP Telephony | PTT Installing IP Telephony | PTT Protocol Telephony General | PTT Benefits of IP Telephony | PTT Replace Your Hosted PBX | PTT Compare Business VOIP Providers | PTT Convergence IP Telephony | PTT IP Telephony Service | PTT IP Telephony Packet-based | PTT IP Telecommunications Portal | PTT IP Telephony Connectivity | PTT IP Telephony Availability | PTT IP Telephony Connections | PTT Internet and IP-based Networks | PTT Projet IP Telephony | PTT IP Telephony Info | PTT Businss IP Phone System | PTT IP Telephony Applications | PTT Innovative IP Telephony | PTT Telephony-based Attack | PTT Postal Telephone Telegraph |