If you receive errors when attempting to view this white paper, please install the latest version of
"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
The definitive guide to Successful deployment of VOIP and IP Telephony
VOIP and IP Telephony is also known as :
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,
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
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.
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.
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
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
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
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 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
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
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.
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 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
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.
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
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 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
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
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.
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
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
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
- 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
- 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-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
- 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
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
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
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
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
- "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
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
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
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.
|Connection-oriented-A dedicated path is
established for each telephone call.
||Connectionless-Voice conversations are digitized
and bundled inside IP packets, then transmitted
over the best route based on routing protocols.
|Calls are long in duration (3 minutes on average).
||Although IP telephone calls have the same duration
as traditional ones, the individual packets are small,
so conversations are cut up into many packets,
typically lasting only a few milliseconds.
|Delivery is guaranteed once the call path is
||Best efforts are made to deliver traffic but there are
|Designed to use specific bandwidth. The PSTN
uses a 64Kbps voice channel.
||Uses the bandwidth that is available.
|Real-time voice traffic is very sensitive to delay.
||IP data traffic is often delay-insensitive.
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
- 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
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.
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
Call and Voice Quality
Both call and voice quality require adequate bandwidth, low latency, low jitter and low packet
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
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
||Adaptive Differential Pulse Code
||Low-Delay Code Excited Linear
||Conjugated Structure Algebraic
Code-Excited Linear Predictive
||Algebraic Code-Excited Linear
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
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.
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
- 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
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
- 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
- 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
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
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
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
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.
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
- 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
- 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.
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
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
- 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
- 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
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
' 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
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