Planning the Cisco CallManager Implementation

Planning, designing, and implementing a Cisco IP Telephony solution is a much more manageable task if you carefully consider each step outlined in this chapter before moving on to each subsequent step.

Cisco IP Telephony operates at a system level by interacting with many different IP Telephony components: CallManager, IP phones, gateways, applications, and much more. The system as a whole must be properly configured and maintained to ensure a smooth, successful deployment. This book highlights those best practices that aid in a successful deployment, and this chapter helps you ensure that all aspects of the IP Telephony solution work together seamlessly to meet business objectives and fulfill user expectations.

You'll notice a strong focus on PBX migration in this chapter because this type of installation is becoming the most prevalent. However, successful implementations of any telephony solution depend on careful planning. Most steps covered in this chapter apply equally well to green field deployments (new installations with no prior IP telephony) because most users have experienced phone systems before and have a standard set of expectations. A good plan ensures a smooth, methodical, documented deployment of the complete Cisco CallManager solution. This chapter focuses first on the current environment as it covers these topics:

• Assessing and documenting the current network infrastructure to ensure proper quality of service (QoS), availability, and security

• Documenting the existing and desired dial plan, classes of service, analog requirements, recording needs, and the call detail record (CDR) method to ensure transparency of operation

• Talking with existing users to determine the current applications in use, phone usage patterns, and most-used features

• Understanding the various add-on hardware in use by end users, including headsets, conference room microphones, amplifiers, wallboards (used in call centers for displaying real-time queue statistics), and recording equipment

• Choosing Cisco equipment

Then the focus of the chapter progresses to the actual implementation of the solution, with topics such as:

• Creating various templates for phone creation

• Selecting training topics

• Establishing a rollout plan

• Developing a second-day support plan

• Creating a problem reporting and escalation plan

• Establishing operations procedures

Read the Solution Reference Network Designs

This book is not meant to be a design guide. Cisco Solution Reference Network Designs (SRND), shown in Figure 1-1, provide guidelines for designing network infrastructures. The SRNDs are based on the experiences of many Cisco customers and engineers and give you information that outlines the best deployments. The SRNDs supply design guidance to implement an overall network architecture. There's no reason to repeat that information here, because all the SRNDs can be found on Cisco.com at either of the following links:

http://www.cisco.com/go/srnd

http://www.cisco.com/warp/public/779/largeent/it/ese/srnd.html

Figure 1-1 SRNDs on Cisco.com

Check the Compatibility Matrix

Cisco posts a compatibility matrix on Cisco.com (see Figure 1-2) that helps you determine whether the parts of the IP telephony system you want to deploy are compatible with other parts. You need to be certain that all upgrades, firmware loads, applications, gateways, and other hardware devices are compatible with the version of CallManager you plan to deploy. Access the compatibility matrix at the following link or search Cisco.com for "CallManager compatibility matrix" (when you get the search results, look for the Cisco recommendation to the right of the results screen):

http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/ccmcomp.htm

Figure 1-2 CallManager Compatibility Matrix on Cisco.com

Assess the Current Data Infrastructure

The most important aspect of a successful implementation is ensuring that your data infrastructure is stable before you attempt to deploy voice applications. There are many factors to consider. QoS, availability, and security are the top three. The following sections help you determine whether the network can support the level of service to which telephony users are accustomed.

Implement Quality of Service

Voice is a delay-sensitive application. You have to ensure that the network components can support consistent delay characteristics to keep voice sounding natural and smooth. You have to configure the network devices to provide a priority queue for voice packets in case network congestion occurs. For a complete guide to implementing QoS, read "Cisco AVVID Network Infrastructure Enterprise Quality of Service Design," available at the following link or search Cisco.com for "Quality of Service Solutions Reference Network Design" or "Cisco AVVID Network Infrastructure."

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns17/c649/ccmigration_
09186a00800d67ed.pdf

Maintain the Highest Availability Possible

Network availability has many facets. To maintain the highest level of availability, focus on power and network design, as discussed in the following sections.

Make Sure You Have an Uninterruptible Power Supply

To maintain service in the event of a power failure, you should provide uninterruptible power for all network devices, such as servers, switches, and routers. Whether you rack-mount uninterruptible power supplies (UPS) in each closet or provide a centralized UPS for the entire building, redundant power is crucial. When putting UPSs in your closets, the most important decisions are how long the battery backup must last and what receptacles your switches should use. In addition, it's important to use a UPS that conditions power so that you can protect your switching equipment from power spikes.

Ensure an Optimum Operational Environment

All network devices should be placed in locations with stable environmental characteristics such as adequate heat dissipation, ventilation, and air conditioning. Excessive heat has a large impact on mean time between failures (MTBF). Although it is surprising, some deployments actually store servers and switches in broom closets and under desks. Improper care of your equipment contributes to environmental and security hazards that can disable or degrade your voice deployment. Security is discussed in detail in Chapter 6, "Securing the Environment."

For exact specifications on operating temperatures, see the data sheets posted on Cisco.com at the following link. You also can search Cisco.com for the phrase "data sheet" coupled with the product name (for example, "CallManager Attendant Console data sheet" or "Cisco CallManager version data sheet").

http://www.cisco.com/en/US/products/sw/voicesw/ps556/
products_data_sheets_list.html

Build Redundancy into Your Network Design

Your network design should have a redundant core (central site) and distribution layer switching. Network designs that employ a single switch in the distribution layer with two supervisor modules do not provide the desired level of redundancy. Should you incur a software bug that causes the switch to reset spontaneously, an entire building could be adversely affected. For more information on network designs, see the "Cisco IP Telephony Solution Reference Network Design" document at the following link, or search Cisco.com for "CallManager SRND."

http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c649/
ccmigration_09186a008017bb4a.pdf

A separate server farm layer in your network, connected in a redundant fashion to the core, is highly recommended. This lets you keep servers off the core and distribution switches, which is critical to running a network that can be upgraded and maintained without service interruption. When servers are attached to core and distribution layer switches, performing upgrades and maintenance is more difficult, because rebooting a switch after an upgrade causes a server outage. If you are a voice support person, be sure to work with your data networking team to follow the network design recommendations outlined in the SRND.

Security

It's critical to ensure that the data network is as secure as possible before adding voice. When planning for IP telephony, you should take many security facets into account:

• Physical security—First and foremost, physical security is important. At a bare minimum, do not leave any network devices, including servers, routers, and switches, in open areas that do not have locked doors. Keep access limited to key individuals, and, if possible, use electronic door locks that provide an access log.

• Virus/worm mitigation—Mitigating the effect of viruses and worms is important at both the network and server level. At the network level, viruses and worms consume bandwidth resources that can adversely affect communications between the various devices. At the server level, they can attack the various IP telephony servers and render them unusable.

At a bare minimum, you should run Cisco Security Agent (CSA) on all IP telephony servers. CSA is provided in a headless version free of charge from Cisco. To download it, go to the following link or search Cisco.com for "Cisco Security Agent":

http://www.cisco.com/en/US/products/sw/secursw/ps5057/index.html

• Layer 2 security—Unprotected IP networks are vulnerable to various man-in-the-middle attacks, Dynamic Host Configuration Protocol (DHCP) rogue server attacks, DHCP starvation, and Address Resolution Protocol (ARP) spoofing/poisoning attacks. Cisco has enabled IOS and CatOS software to defeat these attacks. Features such as port security, DHCP snooping, dynamic ARP inspection, and IP SourceGuard mitigate these attacks and keep the network available for IP telephony use. See Chapter 6 for more information.

• Routing protocol security—Use neighbor authentication when configuring your routing protocols. Without it, hackers can form neighbor adjacencies with your routers and inject invalid routes into the network. Cisco's RIPv2, EIGRP, OSPF, and BGP implementations all support authenticated neighbors.

• Firewall policy—If you have a firewall between the IP voice network subnets and the traditional data subnets, be sure your firewall policy allows the passing of all necessary protocols to ensure functionality. Be ready to approach your network security group to make changes to the firewalls if applicable. For more information about security, see Chapter 6.

The key message is this: plan for security to ensure availability. Making sure your network is protected is critical to ongoing success and uptime.

For more in-depth information on security, see Chapter 6. Also refer to the white paper "SAFE: IP Telephony Security in Depth," located at the following link or search Cisco.com for "SAFE IP telephony security."

http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns128/networking
_solutions_white_paper09186a00801b7a50.shtml

Document the Current Data Infrastructure

The importance of up-to-date documentation cannot be overstated. Be sure to have both physical and logical representations of the network to assist in troubleshooting. It's also essential to have copies of the topological diagrams saved in a portable format such as PNG, JPG, or GIF to give technical support personnel easy access to data. Not everyone will have identical network diagramming packages, so having documentation in a usable format speeds up the troubleshooting process.

Assess the Current Voice Environment

Organizations profit from the unique expertise and skills of their employees and partners. A properly configured, flexible telephone system can help you take advantage of these unique skills by providing customized features at users' desktops. But deploying these customized features requires that the installer understand the skills required of each individual in the organization. Deploying appropriate phone features and eliminating unused features makes the most effective use of the system. You should inventory user requirements and skills and then categorize users into user classes. User classes are an effective method of distributing the right features and capabilities to the right users. Planning this activity before the initial installation and configuration avoids customer frustration and change orders and saves you time and money.

Creating user classes has an ongoing advantage. As new users are added to an organization or existing users are moved from one part of the organization to another, they inherit phone feature requirements associated with their new positions. Applying an existing feature template that efficiently serves users with similar job descriptions consumes less time than creating a customized template for each new user. Over the system lifetime, it is this concept of user and feature templates that saves system administrators configuration time. CallManager provides softkey templates, phone button templates, device profiles, and device pools to aid in developing user class-based configurations. In addition, Cisco provides several different phone models designed for different types of employees. For example, phones models differ in the number of line/feature buttons they provide, because some employees, such as executives or their assistants, might need more buttons than other employees.

Conduct a Feature Inventory and Create User Classes

If you're migrating from an existing phone system, the simplest path to efficient inventory and classification is to use what is already at hand. In many cases, an enterprise's voice team already maintains separate spreadsheets or databases of users and the phone features associated with their jobs. Frequently, these databases associate a named user class to each user. This user class represents a set of users with equivalent requirements and skills. Common phone features are normally assigned to each phone in a given user class. In the absence of an existing spreadsheet or database, some PBXs have tools to create such databases or spreadsheets based on the existing PBX configuration. Use these tools when available to provide a good starting point. Third-party data extraction tools such as those from Unimax (http://www.unimax.com/) can aid in the transition as well. You can find a list of all certified partners at the following link or search Cisco.com for "AVVID find a partner":

http://www.cisco.com/pcgi-bin/ecoa/Search

Data extraction tools can form the basis of CallManager softkey and button templates. Without these tools or existing data, you would need to create the database from scratch. The accuracy and time required for this inventory are a direct function of the scope of the inventory: The broader the database, the longer it takes to create it.

The approach of gathering the inventory has two extremes—representative sample and exhaustive sample. The representative sample is composed of a sample of the user population that represents a reasonable percentage of each user class in the organization. The exhaustive sample approach requires an interview with every user in the organization. An advantage of the representative sample approach is that the time required to complete the interviews and inventory is considerably shorter than with the exhaustive sample approach. The primary disadvantage of the representative sample approach is the likelihood that one or more special user classes will fall through the cracks, necessitating follow-up interviews and inventories.

The recommended approach includes a combination of representative sample and exhaustive sample. Conduct random sample interviews of up to 10 percent of the total organization's population. Conduct a 50 percent sampling of users identified as having critical positions within the organization. When an organization has fewer than five critical users, interview and inventory all of them. In addition, consider a baseline of users across all job functions that might require special features or services. For example, users with hearing impairments have special requirements such as amplified handsets. Finally, event-specific features associated with an event or brief task normally are not assigned as common features to a user class. An example is a malicious call trace, which might be applied to an individual's phone during a brief interval.

The first step in creating the feature inventory database from scratch is to construct a list of all users to be interviewed. List all user features and capabilities in rows, and list all the interviewees in columns. As users in the listing are interviewed, query them for the features they have used in the past and the job responsibilities they have not been able to fulfill as a result of existing phone feature deficiencies. The goal of the interview is to identify requirements as well as deficiencies in previous phone configurations that have prevented or hindered users from accomplishing their jobs. Table 1-1 is a sample interview form.

You can complete the form by devising a legend for interviewee responses, such as R for a required feature, D for a desired feature, X for an unused feature, and so on, and marking the interviewees' responses in the row associated with each feature. Be sure to have a second page listing all the interviewees' names so that you have a place to make notes during the interviews. You can photocopy Table 1-1 or download it (FeatureInventory.pdf) from the Cisco Press website (go to http://www.ciscopress.com/1587051397). If Table 1-1 doesn't satisfy your needs, use it as an example for the tables you design. Be sure your tables include all the features and custom IP phone services your deployment offers.

Table 1-1 Sample Interview Form

Click to view Table 1-1

For future releases of CallManager, the form you use, whether Table 1-1 or the downloadable file shown in Figure 1-3, should be updated to include new features.

Figure 1-3 Exec Admin Tab on FeatureInventory.xls

The interviewing sessions with members of the various user groups in your organization are also opportunities to educate users about new features, services, and capabilities that could help them work more effectively. For example, Cisco provides a broad range of mobility solutions that give mobile users choices for staying connected while on the road or moving around the organization's campus. Exposing these new capabilities to users allows you to provide a solution to a user's problem that might not have been solvable with a previous phone system. The interview also serves as an opportunity to set user expectations about phone system operation, planned training, and installation and configuration plans.

After the feature inventory is collected, create a set of user classes that represent a common set of user features and capabilities identified during the interviews. Although CallManager can store hundreds of button template configurations, you should try to limit the number of user classes to a reasonably manageable quantity—10 or fewer—to most efficiently manage subsequent personnel moves, adds, and changes.

Document the Existing and Desired Dial Plan

During every installation, whether new or existing, you should document the dial plan in fine detail—down to the last known number. Whether you are integrating with a PBX, replacing a PBX, or bringing up a new site, the dial plan is an essential element you must master.

If you don't know the numbers in use in your system, you are completely in the dark. In some cases, you might be neglecting certain populations of users without knowing it. When the cutover to Cisco IP Telephony occurs, those users will not have 100 percent service. At the worst, you might be assigning numbers to IP phones that are already in use in other parts of the network, which can cause serious havoc.

The most common uses of dial plan numbers are

• Internal extensions

• Rollover extensions (if line 1 is busy)

• Emergency numbers

• Trunk-access codes

• Tie-line access codes

• Message waiting indicator (MWI) on/off numbers

• Application numbers (call center, voice mail)

• System speed dials

• Route/hunt patterns

• Translation patterns

You must meticulously document the existing dial plan and determine where the IP phones and applications will fit. The best way to do this is by using a spreadsheet that details the number ranges in use, groups of devices to which the number ranges are assigned, and any number translations in use. For an example of a dial plan document, check the Cisco Press website (http://www.ciscopress.com/1587051397) for a downloadable dial plan document in Visio format called Sample-Dial-Plan.vsd. You can modify this sample document and use it for your deployment.

Document Classes of Service

It's important to understand any existing restrictions and to whom they apply. By understanding the current environment, you can provision CallManager to meet the same level of restriction. Many times, only the simplest forms of restriction are implemented. Some of the most common classes of numbers in the U.S. are

• Internal-only

• Local

• National

• International

• Intra-LATA (Local Access and Transport Area)

• Local toll

• 900

• 976

Non-North American Numbering Plan dial plans might use classes such as

• Internal-only

• National

• Mobile and pager

• Emergency

• Premium rate numbers

• Free-call

Normally, partitions are designed around some of these classes of service. They are classes of numbers that represent route patterns that can be assigned to partitions, which are then assigned to calling search spaces (CSS), which in turn are applied to phones. You can use any combination of these classes to create calling search spaces that result in classes of restriction for users. Restricting calls by using calling search spaces is discussed in more detail in Chapter 7, "Configuring CallManager and IP Telephony Components."

How the classes actually get implemented depends on your company culture. Some companies like to restrict long distance calls for certain employees. Generally, all premium-rate services (such as 976 and 900 numbers in the U.S.) are blocked. Publicly accessible phones generally offer local calling only. These are just guidelines; every organization is different.

Document the CDR Method

If you're migrating from an existing phone system, you should document the method you're currently using to gather call details. It's important to understand the existing system, if any, and to choose the right CDR package to meet your billing and call accounting needs. If you are not using any CDR method currently, Cisco provides a solution. The CDR Analysis and Reporting (CAR) tool offers some CDR functionality. However, in most cases, and especially for deployments with existing CDR systems, a third-party tool may be required.

In most PBX environments, transfer of CDR data is achieved via serial interface to the PBX using a printer, PC, or spooling server. One improvement that IP telephony brings, especially in a centralized call processing environment, is that a single CDR management system can service many sites. Traditional PBXs require a PC at every PBX location.

See Chapter 11, "Administering Call Detail Records," for more information on CDRs.

Talk with Existing Users

A critical component of any successful deployment is learning from the various user communities how people actually interact with their phones. Without direct input from the end users, it's impossible to determine the proper softkey templates and training topics. If you have an existing PBX, you have to pay close attention to the difference in feature access methods and address these differences in your training sessions.

Talking to manager/assistant (boss/admin) users and to console operators or receptionists is essential. You'll find that many boss/admin interactions differ. Not everyone uses the functions in the same way. For some users, IP Manager Assistant (IPMA) is the right application, but for others a simple shared-line scenario suffices. Depending on the type of business or organization, other user types might include the following:

• General worker (individual contributor)

• Mobile workers/telecommuters

• Sales or marketing

• Dorm residents

• Teachers/professors in a classroom

Get a representative sample of users from all these types and other types that are applicable to your organization or business. See the earlier section "Conduct a Feature Inventory and Create User Classes" for more information.

It's also critical to understand how end users interact with callers and how their customers are used to being handled. Do not make any assumptions. During the planning process, be sure to sit with some end users and watch them work using the current system. Try to map what they're doing to possible CallManager configurations, but at the same time, try to build a better mousetrap using CallManager's advanced functionality. Perhaps you can improve their call-handling iterations. A good example is how PBXs handle music on hold (MOH). Generally, a single music source is attached to a CD player. With CallManager, up to 50 different groups or departments can stream different, specially recorded messages to callers on hold. Rather than meaningless music, you can play a unique message that can positively impact your clients or customers.

Categorize users into various groups based on how they use their phones. You will surely find that the majority of users use hold, transfer, and conference. You also might find a group that uses park and group pickup.

The user features get implemented using different CallManager components such as button templates, calling search spaces, partitions, and more. So, after you talk to the users and build a matrix of user classes and features, you can use it to define each of the required components. If you are not yet familiar with components such as calling search spaces, partitions, and softkey templates, read through the documentation and other Cisco Press books in the Cisco AVVID Solutions series and get a little hands-on experience. The following list provides some examples of user features.

• Calling restrictions required by different user types—These allow you to start scoping the different calling search spaces, such as Internal/Emergency, Local, National, and International. You'll read more about calling restrictions in Chapter 7.

• Line appearance requirements—You can define different phone button templates, such as Standard (Cisco IP Phone 7960 with one line appearance), Manager (7960 with two line appearances and a privacy button), Receptionist (7960 with a 7914 line expansion module to have 10 line appearances), and so on.

• Feature requirements—You can define the different softkey templates, such as Standard, Manager (iDivert), Receptionist (CallBack, Quality Reporting Tool [QRT], Malicious call trace), and so on.

• MOH requirements—You can define multiple MOH audio sources, with names like Silence, Standard, Department Specific, and so on.

With these components created, plus the other device-specific features defined within the matrix, the specific user classes can be accurately described in a way that anyone can implement. Table 1-2 provides an example.

Table 1-2 Sample User Classes and Configurations

Click to view Table 1-2

Determine the Current Applications

Determine all the voice applications that are currently running on the voice network. These may include but are not limited to those listed in Table 1-3, which are provided either natively in CallManager, via an optional Cisco solution, or optional third-party solution. Table 1-3 does not provide a comprehensive list of partner solutions. You should check the Cisco AVVID Find a Partner page on Cisco.com at the following link for the complete list of third-party solutions, or search Cisco.com for "AVVID find a partner":

http://www.cisco.com/pcgi-bin/ecoa/Search

Table 1-3 List of Features and Cisco Equivalents

PBX Application	Cisco and Third-Party Equivalent
Automatic Call Distributor (ACD)	Cisco IP Contact Center (IPCC) Express
Interactive Voice Response (IVR)	Cisco IP IVR
Call center	Cisco IPCC
Call recording	Third-party systemwide applications from NICE, Witness, MIND CTI, and more (http://www.cisco.com/pcgi-bin/ecoa/Search > IP Telephony > IP Voice Endpoints > Search) Third-party single phone from JK Audio THAT-1
Remote monitoring	CallManager Serviceability's Real-Time Monitoring Tool (Application > Cisco CallManager Serviceability > Tools > Real-Time Monitoring Tool) Third-party applications from Integrated Research Prognosis, NetIQ, Vivinet, and more (http://www.cisco.com/pcgi-bin/ecoa/Search > IP Telephony > Operations, Administration & Maintenance (OAM) > Search)
Modem	Cisco VG248 Cisco VG224 Cisco IOS gateways
Fax	Cisco VG248 Cisco VG224 Cisco IOS gateways
ISDN	Cisco IOS gateways
Tie-lines	Centralized call processing Intercluster trunks
Ringdown lines	Use of NULL translation pattern (see Chapter 7)
Elevator phones	Cisco VG248 Cisco VG224 Cisco IOS gateways
Overhead paging	Third-party applications from Bogen Communications (Bogen units generally are connected to CallManager via a standard Foreign Exchange Station [FXS] interface)
PBX Application	Cisco and Third-Party Equivalent
Zone paging	Third-party products available from Norstan
Emergency phones	Direct to Central Office
Encryption devices	Cisco IP Phone model 7970 Third-party phones that connect inline with a phone handset
Forced account codes	CallManager releases 3.3(4), 4.1, and beyond (Feature > Client Matter Code) Third-party solutions from Berbee, Circle 24, and more (http://www.cisco.com/pcgi-bin/ecoa/Search > IP Telephony > IP Phone Applications > Search)
Client matter codes	CallManager releases 3.3(4), 4.1, and beyond (Feature > Client Matter Code) Third-party solutions from Berbee, Circle 24, and more (http://www.cisco.com/pcgi-bin/ecoa/Search > IP Telephony > IP Phone Applications > Search)
Hoteling	Extension mobility (Cisco Extension Mobility service)
Call coverage paths	Hunt list logic (Route Plan > Route/Hunt > Route/Hunt List) Third-party solutions from Berbee and more (http://www.cisco.com/pcgi-bin/ecoa/Search > IP Telephony > IP Phone Applications > Search)

You should have a migration plan for each of these applications, all of which can be developed either natively with CallManager or Cisco products or with third-party solutions. The point is to avoid overlooking anything and to address all needed applications at the beginning of the project. Nothing puts a project off schedule like missing applications. You also want to avoid having to explain why an application doesn't work as expected.

Document All Existing Hardware

Various types of nonphone hardware are in use at most companies or organizations. These include devices such as

• Headsets

• Amtel units (user-to-user text messaging)

• Recording equipment

• Dictaphones

• Attendant consoles

• Conference room speakerphones

• Remote microphones

• Wallboards (used in call centers for displaying real-time queue statistics)

• CD players

• Muzak units (piped-in ambient music, also known as elevator music)

• Wireless phones such as Cisco Wireless IP Phone 7920 or other third-party wireless (DECT) phones

Check and fully test the compatibility of each of these devices with CallManager. In some cases, you can phase out the existing equipment and use native CallManager functionality. A good example of this is CD players used for MOH. Given the prevalence of the MP3 file format, you might decide to stream hold music directly from a server rather than worrying about connectivity to a CD player or Muzak box.

Choose the Right Equipment

In general, it's good to use switches with redundant power and redundant supervisor modules such as the Catalyst 4507R and Catalyst 6500 series. Making your access layer switches as redundant as possible results in greater network availability should something fail.

Choose a Server Hardware Vendor

First, use the Cisco IP Telephony SRND to determine the desired number of each type of server in the cluster, the redundancy strategy the cluster uses, and the physical server placement. (For the SRND, go to http://www.cisco.com/warp/public/779/largeent/it/ese/srnd.html, or search Cisco.com for "IP Telephony Solutions Reference Network Design.") Then you must decide whether to use the Cisco-branded Media Convergence Servers (MCS) or the private-label servers from Compaq and IBM. In addition to the design guidelines provided in the SRND, you must consider other important ramifications when choosing a server hardware vendor.

In general, it's difficult to make a blanket recommendation, because there are so many variables to consider. Surely the easiest and most hassle-free option is to choose all Cisco MCS. These servers are specially built, thoroughly tested, and easily ordered, and they provide a single-vendor solution. However, the decision is not always so simple.

You must consider other factors when deciding whether to purchase Cisco MCS or Cisco-certified hardware from Compaq or IBM:

• Relationship with the server vendors—Perhaps you have a great relationship with your Cisco account team and support structure, and you prefer all Cisco hardware to get a single point of support for the CallManager software, hardware, and network infrastructure. On the other hand, maybe you have a large server farm that is all IBM, and you prefer to keep your environment all-IBM hardware.

• Pricing and discounts—You might have an aggressive pricing structure with a particular server vendor that you want to leverage when purchasing servers for your CallManager implementation.

• Service and support—Purchasing non-Cisco branded hardware causes your solution to be implemented using equipment from multiple vendors, potentially adding a layer of complexity when you're trying to determine whether a problem's cause is hardware or software. If the problem is the hardware, you must contact a different support organization to troubleshoot or replace the non-Cisco branded hardware.

• Hardware availability—Both Compaq and IBM frequently release new hardware. Cisco does not certify every platform available from every vendor, so only certain models are tested and approved for use with CallManager. It's quite possible that Cisco will not support new hardware at the time of its release, and older models might not be available except through Cisco. Any hardware used must be approved by Cisco. For a list of supported platforms, check the Cisco 7800 Series Media Convergence Servers brochure at http://www.cisco.com/go/swonly.

Server Memory Requirements

You should also consider another server specification: the amount of memory required by the various applications. You should have at least 1 GB of RAM in your server, but additional memory is advisable. The general rule is that you can never have too much memory. However, no matter how much memory is present in a server running Windows 2000 Server, no more than 2 GB of memory can be allocated to a particular process. For example, the CallManager service controls call processing on all CallManager servers. If you have a server with 3 GB of memory, CallManager can use all the memory it can get and leave the rest for other processes. Cisco MCS 7845 servers use Windows 2000 Advanced Server, which can address 3 GB of RAM per process, the amount of RAM that is recommended for large clusters with tens of thousands of phones.

If you want a server with less than 2 GB of RAM, you must consider the number of device weights and dial plan weights supported by the server when determining the minimum amount of RAM required for each CallManager server. For the latest information on device weights and their effect on memory requirements, refer to the SRNDs on Cisco.com (see the earlier section "Read the Solution Reference Network Designs").

Adding Hard Drives to a Server

The CallManager redundant array of independent disks (RAID) configuration uses two mirrored disks. Each drive is partitioned into a C:\ partition containing the operating system and program files and a D:\ or E:\ partition containing some operating system installation files.

Adding a disk to the system might be a good idea for these reasons:

• Storing log files—When troubleshooting CallManager, the trace facility can produce numerous log files. Rather than limit the number of log files you can keep, using an extra disk to store log files might be the best way of keeping the install drive from running out of space.

In addition, you can send the extra drive to the Cisco Technical Assistance Center (TAC) when the log files contain so much data that they cannot easily be sent over the Internet. A good example of this is SDL trace files.

• Storing downloads and patches—The size of the various CallManager upgrade files and operating system (OS) patches has been growing since CallManager was released. Often, administrators download the images from the Voice Software Center on Cisco.com (http://www.cisco.com/kobayashi/sw-center/sw-voice.shtml) and place them on the CallManager server's C:\ drive. The result is excessive clutter and the potential to overload the drive, which usually causes CallManager failures. Instead, as a best practice, use a spare drive or a network share to store these files.

Choosing Phone Types

Company policy often dictates the right phone for the various user classes. In the absence of established policy, common Cisco IP Phone-to-user pairs are shown in Table 1-4.

The choice of the standard employee phone often depends on company culture. Some organizations believe that everyone should have headset capability, speakerphones, and speed dials. Other organizations have policies that oppose the use of speakerphones in cubicles and other unenclosed areas.

Table 1-4 User Type and Phone Model Pairings

User Type	Cisco IP Phone Model
Call center employee	Cisco 7940G (XML is required for phone agent)
Standard employee	Cisco 7912G, 7940G, 7960G, Cisco IP Communicator
Executive assistant	Cisco 7960G with Cisco IP Phone 7914 Expansion Module(s)
Executive	Cisco 7970G Cisco 7960G Cisco 7936G
Attendant operator	Cisco 7960G with Cisco IP Phone 7914 Expansion Module(s)
User Type	Cisco IP Phone Model
Conference rooms	Cisco 7936G
Warehouse employee	Cisco 7920
Telecommuter	Cisco 7902G, 7905G, Cisco IP Communicator
Common/public area phones	Cisco 7902G

As discussed earlier, using an inventory of the existing system (in the case of a PBX migration) is the best way to achieve parity. Many customers make a matrix of the existing phones in use and then map Cisco devices to those of the existing vendor. This works extremely well and is recommended because it keeps the amount of change for users to a minimum.

Create a Training Curriculum for Users and Administrators

Training is an important part of any implementation. Your users need training on the most-used functions of their phones and user-accessible web pages. Administrators must understand all aspects of the system so that they can perform daily management and monitoring, as well as moves, adds, and changes.

You should also consider appointing employees in each department to undergo training before the cutover or initial deployment. That way, on the first and second day that the new system is deployed, employees can ask knowledgeable peers for help.

User Training Techniques

How you perform user training is entirely up to you. It usually depends on your time and resource allocations. However, it's important to perform your training before you actually place the phones on users' desks. Training gives users exposure to the new system before they have to use the phones in production. The recommended approach is to use a large conference room to stage up to 24 phones for user training sessions.

Invite 24 students per class, and have them pair off to follow the different lessons by calling each other and testing the features. If more than two people must be involved, such as for conference-related functions, student pairs can call other student pairs.

Training for the Cisco CallManager User Options web page is best conducted in electronic format. Tools such as Camtasia from TechSmith (http://www.techsmith.com) can be used to record the instructor's interactions. You can then add voice-overs and post the finished file on your company intranet in a variety of formats. Live training of anything PC-based is difficult because of the large number of PCs that must be dedicated to the task. Offering web-based training is much better, because students can follow along with the training at their own pace and even rewind and fast-forward.

The most important topics to cover during user training are

• Managing multiple calls per line

• Alternating between the speaker, handset, and headset modes

• Using hold

• Using transfer

• Using conference

• Using call join

• Using barge/cBarge

• Using call park

• Using the drop any party softkey

• Using malicious call trace

• Using immediate divert

• Blocking caller ID on a per-call basis

In addition to all the feature-related training, you should train users on how to seek support. When calling the Help Desk for support, the user should provide the following information:

• The time as displayed on the phone at the time of the problem

• The line appearance on which the problem occurred

• The called party number if applicable

• A specific description of the problem

Having this information lets Help Desk personnel troubleshoot the problem much more effectively. The most important thing is the time. Without that, it's harder to find the exact information in the trace files. It's important to get the time that is displayed on the phone because phones are synched with CallManager, making the correlation between phone time and times listed in CCM trace files more precise.

Be sure to read the sections on user training in Chapter 7 for additional information.

Administrator Training

You should plan on providing formal training for your administrators. Many options are available. Cisco has a standard curriculum, as shown in Figure 1-4, which is offered by various Cisco Certified training partners. Use the following link and click IP Telephony Training, or search Cisco.com for "IP Telephony training":

http://www.cisco.com/en/US/learning/le31/le29/learning_training_from_cisco_ learning_partners.html

How you provide the administrator training is up to you. Options include customized training, in-house training, and the standard five-day CIPT classes. The key is to determine exactly what your administrators need. For example, if you are having Cisco Advanced Services or a Cisco Certified Partner install your systems, do you really need to cover installation in the training, or can that be part of the knowledge transfer from the installation team?

In addition to formal training, there's train-the-trainer. This style of training can be even more valuable, because it is one-on-one and more concentrated. Your staff member can take the learning class(es), filter out the information that's pertinent to your deployment, and then train all the administrators on what they really need to know.

Figure 1-4 IP Telephony Training for System Administrators

If a Cisco reseller is installing the system for you, it's important (if possible) to watch and learn what the implementation team does and to absorb the subtleties of the installation from the people actually installing the system.

The key things to watch for are

• Dial plan configuration

• Enterprise parameters configuration

• Gateway configuration

• IP Phone services configuration

• Media resource configuration

• Phone configuration

Also, you should consider adding the following books to your library:

• Cisco CallManager Fundamentals: A Cisco AVVID Solution (ISBN: 1-58705-008-0)

• Troubleshooting Cisco IP Telephony: A Cisco AVVID Solution (ISBN: 1-58705-075-7)

• Cisco IP Telephony (ISBN: 1-58705-050-1)

Be sure to search ciscopress.com periodically for new IP Telephony- or CallManager-related titles and second editions of existing Cisco AVVID Solution books.

Establish a Rollout Plan

A rollout plan represents the method you will use to enter phones into the CallManager database and distribute the actual phones to users' desks. A rollout plan should include

• Time of day of phone placement

• How users will be notified of the technician's visit to their offices

• How phones will be connected to the network

The rollout plan is critical to the success of any installation. Without a solid plan, your visits to users' desks will be haphazard, you might forget some users, or you might place the wrong phone models on the wrong desks. Without a plan to keep you on track, you might not finish the rollout on time, which is probably one of the worst things that can happen, especially for a large cutover. On top of that, without the plan, you could find yourself running around the building at 3 A.M. on a Sunday morning looking for someone's office because you didn't have the right floor plan, didn't know that a user moved his or her desk, or couldn't get security personnel to open the necessary doors.

Determine How to Add Phones to the System

Depending on the size of your rollout, the most labor-intensive job might be placing the phones on users' desks. There are two basic approaches: Use BAT in concert with the Tool for Auto-Registered Phones Support (TAPS) with dummy MAC addresses generated by BAT, or configure all the phones in the system with the actual MAC address and extensions.

To decide between these two approaches, you have to consider the following factors:

• Number of phones

• Amount of time to cutover

• Quality of end-user logistics

Consideration: Number of Phones

If you are rolling out a large number of phones (more than 200 to 300), it's probably best to use TAPS. With TAPS, you can add the phones to CallManager using dummy MAC addresses, which means you don't have to enter every MAC address for all the phones and associate them with a directory number. Instead, TAPS assigns dummy addresses that are later updated with the phone's actual MAC address when a user dials a specific directory number to download the phone's configuration. Using TAPS means that technicians can simply place the phones and an instruction sheet on users' desks. The instructions should explain how to plug in the phone (if the technicians do not install the phones), dial a specific directory number, and follow the steps to use TAPS. By the time the user hangs up, the phone will have downloaded its specific configuration and will be ready to use.

The TAPS method is relatively low-risk and works well. The downside is that the users must perform some actions to make the phones work; they don't just arrive at work on Monday and find a working phone. TAPS is deployed as part of an IVR through Cisco Extended Services. Extended Services Customer Response Solution (CRS) ships with two ports only, so the maximum number of simultaneous calls that TAPS can accept is two. On a full CRS deployment, the number of simultaneous calls into TAPS depends on the number of licenses you purchase and the number of computer telephony integration (CTI) ports you configure for TAPS. Consult the CRS and TAPS documentation on Cisco.com for installation and configuration information.

• TAPS is documented as part of the Bulk Administration Tool documentation at http://www.cisco.com/univercd/cc/td/doc/product/
  voice/sw_ap_to/admin/bulk_adm/index.htm.

• CRS documentation is available at http://www.cisco.com/en/US/products/sw/custcosw/ps1846/
  prod_software_versions_home.html.

TAPS is a great tool when used in combination with a single, standard phone model for all users because you don't have to spend a lot of time on the logistics of where specific users sit. When you're installing a system, location is by far the hardest information to gather accurately, especially in a green field installation. The information almost always changes, resulting in people having the wrong phone models.

A middle-ground approach involves gathering as much user information as possible and having the installer do the TAPS login at install time. The issue with this approach is the uncertainty involved with getting the correct user information.

If you are a Cisco Certified AVVID partner, be sure to have several company employees available on site to help you locate users' offices and cubicles and to open doors. It's also critical to have the support of the security officers at the site. Ask for additional security officers to be on hand to help unlock doors.

Consideration: Amount of Time to Cutover

When you're working on a tight schedule, you might not have time to unbox all the phones, enter their MAC addresses in CallManager Administration, and rebox the phones for placement on desks. Using TAPS means you can simply dispatch the phones to the proper locations for placement and have end users dial TAPS to configure their phones. When you have more time during the cutover, you have the luxury of adding the phones' actual MAC addresses into CallManager Administration.

Consideration: Quality of End-User Logistics

When you are working in an environment in which you don't have good floor plans for the buildings, you have almost no idea where specific users sit. For that reason, using TAPS in combination with a single, standard phone model for all users (such as Cisco IP Phone 7960) allows you to put phones in every occupied cubicle or office, and people can dial the TAPS number and enter their extensions to download the phone configuration. In addition, there are delicate situations in which getting information about extension numbers can be challenging. Again TAPS helps, because users can enter their own information. If you encounter such a situation during the planning process, it's generally a good idea to make the rollout easier by using a standard phone model for most or all users.

If you have up-to-date floor plans with up-to-date usernames, adding the phones using the real MAC addresses is quite feasible, because you know where people sit, you can count on security to open the doors, and you can plan certain floors for certain nights.

Migrating from PBX or Green Field

TAPS is generally very good for green field deployments, because no existing information needs to be converted on a user-by-user basis. However, in certain PBX migration scenarios, especially when direct inward dial (DID) numbers are changed or when phone migrations are happening in small groups (rather than in large batches), using the Bulk Administration Tool (BAT) or manually entering the phones in CallManager Administration is probably a better method.

Determine the Cutover Method

When planning the system's rollout, you must decide how to migrate from the existing system (if applicable) to the new system. If you're working in a new environment or green field, no cutover choice needs to be made, so you can skip this section.

The following sections discuss the three different ways to migrate a system:

• Flash cut

• PBX migration

• Dual phone

Flash Cut

A flash cut is a clean break from one system to the other. It often occurs over a weekend. Users go home on Friday and come in on Monday to a new phone system. All original phones are removed, and users begin using the new system immediately.

Flash cuts are best for small organizations and for small remote sites attaching to a larger cluster in a centralized CallManager deployment.

One of the most significant factors in a flash cut is user training and second-day support, which was discussed earlier in this chapter. Without good training before the cutover, there's no way for users to become familiar with the phone until it is on their desks in full production.

Testing the system is critical when doing a flash cut. After the system is installed and configured, it must be thoroughly tested in what is generally a short time frame. Flash cuts require a great deal of precision in the planning phase to ensure readiness.

Most often, the servers are preinstalled and configured in a staging environment before being brought onsite, which makes a flash cut a little more manageable. Instead of a staging environment, you might have had the system running in pilot mode with select users for a few weeks (known as an alpha cluster). Even with either of these pre-deployment testing phases in place, second-day support is critical because there are always unforeseen configuration tasks that get missed with high-pressure flash cuts. Users have no alternative phone system after the new system is installed, so having good user support in the first week after the cutover is highly recommended.

For more information about installation, refer to Chapter 3, "Installing CallManager."

PBX Migration

PBX migration is the type of cutover that involves connecting tie-lines between CallManager and the existing PBX. Tie-lines are simply lines that connect CallManager and the PBX. This method is often used in larger deployments because there is simply no other way.

In general terms, these kinds of cutovers are used especially when new buildings are put up or remote sites are added to the network. There are groups of users using CallManager, and groups of users using the PBX, and they need to talk to each other.

This method is quite viable, but there are some key best practices you should adhere to:

• Use Primary Rate Interface (PRI) or Q.SIG when integrating—These protocols provide the most functionality between the two systems. Things such as calling and called party name display are supported.

• Have enough tie-line trunks available—It's better to overprovision the trunking between systems than have too few channels between systems. When integrating systems, you must choose whether the CallManager phones will have their own Public Switched Telephone Network (PSTN) trunks. If the CallManager phones are on a campus, it's recommended that you have them act as extensions off the PBX and use the PBX for inbound and outbound PSTN connectivity. Because of cost and PBX space constraints, you might not be able to overprovision trunks. You might have to migrate tie-lines one at a time, which requires some level of accuracy. One way to get an idea of how many trunks you need between systems is to do a traffic study on the PBX for the groups of users you intend to migrate. For example, say you intend to migrate Building A. If you have the capability, check the call detail records on the PBX to see how much calling the users of Building A actually do. Using this information ensures that you have enough trunks between CallManager and the PBX when you migrate the users. If the CallManager phones are at a remote site, it's best to provision PSTN connectivity directly on CallManager.

For more information about traffic analysis, refer to the "Traffic Analysis for Voice over IP" document at the following link or search Cisco.com for "traffic analysis for VoIP."

http://www.cisco.com/en/US/tech/tk652/tk701/
technologies_white_paper09186a00800d6b74.shtml

• Understand the impact on the attendant operator—During your migration, you will have some users on the PBX and some on CallManager, which means that any attendant operators need visibility into the busy status of all the phones on the system. If maintaining visibility status of all phones is important to you during the migration, you have to use a console application that supports both platforms. It's impossible to give a recommendation because of the number of variables involved, such as PBX type and supported features. Check with your PBX vendor for supported third-party console applications, and cross-reference them with Cisco's Find a Partner list at http://www.cisco.com/pcgi-bin/ecoa/Search.

• Establish the voice mail integration method early on, and test—A difficult and critical decision involves voice mail integration. There are many options. If you decide to use your existing PBX voice mail, you can use a Cisco VG248 gateway and Simplified Message Desk Interface (SMDI) to integrate CallManager. If you have an Octel system with digital interfaces, you can use a Cisco Digital Phone Adapter (DPA).

If you decide to use Cisco Unity with CallManager and integrate Unity with your existing voice mail system, you can use either the VPIM or AMIS-A protocols. If your PBX voice mail system is an Octel system, you can integrate using Analog Octelnet with the Cisco Unity Bridge. Refer to the "Cisco Unity Interoperability Features and Functionality Comparison" document at the following link or search Cisco.com for "Cisco Unity Interoperability."

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/
products_data_sheet0900aecd800fe15f.html

Migrating your existing PBX voice mail to Unity is supported by Unity's dual-switch integration feature. For PBX compatibility with Unity, check the Cisco Unity Bridge System Requirements, and Supported Hardware and Software documentation at the following link or check the "Supported Phone System Integrations" section of the "Cisco Unity System Requirements and Supported Hardware and Software" document.

http://www.cisco.com/en/US/products/sw/voicesw/ps2237/
prod_pre_installation_guide09186a008020aaf0.html

Dual Phone and Then Flash Cut

Some people managing deployments migrating from a PBX decide to place both CallManager and PBX phones on the users' desks but do not integrate the systems at all. This lets you configure and test CallManager completely and then flash cut the system in one evening.

This approach provides the greatest amount of time to actually roll out the phones, perform the training, complete all the needed testing, and answer all the users' questions and concerns before cutting over to the new system.

At the time of cutover, you have to move the components that CallManager will use from the PBX to CallManager. These components include PSTN trunks, analog stations, and voice mail connections. You also need to power off the PBX.

In addition, this approach provides a degree of safety in that you can simply power on the PBX and move the components back over if a catastrophic event occurs.

The dual phone and then flash cut option is recommended for large campus installations that leave their PBX behind and do not call for integration of CallManager. The sheer number of phones that have to be placed means that a simple flash cut won't work. In some cases you don't want to integrate with the PBX because of a lack of tie-line trunk ports on the PBX or a lack of license for the PRI and/or Q.SIG protocols.

Create User Information Packets

A best practice that is too frequently ignored is providing information to the user. Without a list of instructions, second-day support is made much harder because the Help Desk gets overwhelmed with calls.

Be sure to distribute user information packets (leave-behind materials) that give the user the following information:

• Extension (for example, 1000)

• Full DID number (for example, 214-555-1000)

• Voice mail number (internal access number, such as 5000, and external access number, such as 214-555-5000)

• Voice mail password

• Voice mail quick reference

• Phone PIN

• Help Desk number

• Phone user guide

• Name of installation technician

• Date, time, and contact information for phone training

One often-used technique is to print simple business cards with the name of the installer and the Help Desk number. These can be left on the users' chairs or stuck in their keyboards, where they will not be missed.

Without this information, users roam the halls looking for information and are generally not in a good mood on the first day of production. Users who can't acquire the information they need feel that the change from the previous phone system to the new one is a bad idea and that the new system is much harder to use. This significantly reduces satisfaction with the deployment and makes training the users on the new system more difficult.

Establish a Second-Day Support Plan

Most second-day support centers around the following items:

• Moves, adds, and changes—Be sure to have a plan to cover the inevitable changes that must occur during the first and second days of production. Have a handful of CallManager configuration people at the ready. The most common changes are the addition of shared lines, fixing incorrect extension numbers, and configuring intercom groups.

• Additional training—Users invariably need one-on-one training for certain features and functions. Some of this happens informally within workgroups, but it's important to be ready to do some handholding.

• Establish a "war room"—Reserve a dedicated conference room (sometimes called a "war room" during IP telephony deployments) where support staff can all work together to field questions as they arise and make any needed modifications to the system. Having the support team close to each other gives a sense of camaraderie and provides a way for everyone to learn from the problems and solutions that invariably occur during the first week of an installation.

• Addressing complaints about the process—This is one of those touchy subjects that always causes consternation among users. Sometimes users just need to vent their frustration with the process and the differences with the new phone system. Be sure to have a sympathetic ear, and be ready to help the user adjust.

• Broken or missing items in offices—Installing phones in people's offices sometimes results in damage. Be sure that you have some kind of formal grievance process for users to lodge their complaints and concerns. Sometimes personal items are misplaced or damaged as a result of installing the phone. In general, the network cable from the user's PC is plugged into the back of the phone, and a cable from the back of the phone is plugged back into the computer. This means that the technician installing the phone needs to get at the back of the PC. People have a habit of burying their PCs under lots of personal effects or in hard-to-reach corners of their desks. Be sure to instruct your installation technicians to report any damage. Institute a policy that allows for direct communication with the affected user, and replace damaged items. Being candid about any damage is always the best policy.

Institute a Problem Reporting and Escalation Plan

During the rollout period, it's important for the system administrator to understand how to get help. In addition, it's important to have the proper staff to address issues in a timely fashion.

The best approach if you need extra help is to use Cisco Advanced Services (shown in Figure 1-5; search Cisco.com for "advanced services"). You also can arrange for a Cisco Certified Partner to supply onsite resources up to two weeks after implementation to handle the influx of issues any new phone system can bring.

Figure 1-5 Cisco Advanced Services Page on Cisco.com

Companies often are caught short of resources, and customer service levels suffer. Regardless of resource constraints, be sure to set the right expectation with your users during training sessions so that they are not caught by surprise, waiting for problem resolution.

It's also important to have an escalation plan for employees who have critical needs. Be sure to have all Cisco Technical Support contracts and support numbers handy, and be ready to prioritize your users' needs. Again, increasing the size of your staff is highly recommended in the first two weeks of implementation.

Establish Operations Procedures

It's extremely important to synchronize the network operations team with the telephony operations team to ensure that network connectivity is not spontaneously interrupted. One of the biggest problems you'll face is that your phones are up and working, but you don't have an operations and management infrastructure in place. One of the first things you should do is create an e-mail/voice mail distribution list that includes either the heads of all departments or all users so that you can keep the relevant personnel informed when changes will occur.

Operations tasks include the following:

• Scheduled network upgrades—One of the biggest issues you could face is that random network engineer who constantly reboots switches and routers in the middle of the day because there's a problem or because a switch needs to be upgraded. Each time this happens, phone service or supplementary services such as conferencing might go down for some or all of your users.

It's critical to establish a regular outage window in which to perform upgrades. In addition, it's important to establish an e-mail or voice mail distribution list to alert all involved parties to any planned or unplanned outages.

Voice is one of the most critical applications you can put on a network. You need to ensure that the telephony operations personnel are aware of any network maintenance activity. Many unplanned phone outages are caused by simple lack of communication.

• Scheduled application server upgrades—It's important that you avoid taking down your voice systems every time a new patch or software version is released. You need to have a schedule and a procedure that alerts people that an upgrade is taking place. Be sure to document and send e-mail to your users if any changes in phone behavior occur. No one likes to be surprised when something as seemingly simple and basic as phone operation suddenly changes without warning.

• Scheduled dial plan changes—Sometimes making changes to the dial plan necessitates the restarting of CallManager services. Do not make major changes to the dial plan in the middle of the day and start resetting services, which causes calls to terminate without warning. Bring up new circuits and connect to other systems during a scheduled maintenance window using a standard change control procedure, not during regular production hours when a large number of users are affected.

• Scheduled new application deployment—When bringing new applications online, whether call center applications, Emergency Responder, Cisco MeetingPlace, and so on, it's important to use a scheduled outage window to perform these installations. Even with proper testing before deployment, you can't be 100 percent certain of the impact the application will have on the network until you deploy it, and it's best to not affect production users.

• Scheduled media resource moves, adds, and changes—If you intend to change conference, MOH, or media termination point (MTP) configurations, do so during a standard change control window, not during production hours.

• Scheduled gateway moves, adds, and changes—If you need to make changes to gateways, do so during a scheduled change control window. In almost every case, gateways need to be reset for the changes to take effect. Resetting a gateway during production hours most likely results in dropped calls, so it's best to make necessary changes when they least affect users (nonproduction hours).

• Established change management procedures—This is where some companies fall flat: They let their staff make fundamental changes to the system without following a change management procedure. In one real-life example, a company changed the name of its gateway routers during business hours, causing a major outage, but no one on the voice team knew anything about the changes. Because the voice team didn't know about the change, they didn't change the Media Gateway Control Protocol (MGCP) name in CallManager Administration. Therefore, the company suffered an outage while troubleshooting the issue. Establishing a change management and control procedure that includes everyone involved is important. See the "Change Management: Best Practices White Paper" at the following link or search Cisco.com for "Document ID 22852."

http://www.cisco.com/en/US/tech/tk869/tk769/technologies_
white_paper09186a008014f932.shtml

Summary

Planning, designing, and implementing a Cisco IP Telephony solution is a much more manageable task if you carefully consider each step before moving on to each subsequent step. Efficient installation starts with a good plan that ensures a smooth, methodical, and successful deployment of the complete CallManager solution.

In addition to the resources discussed in this chapter (Cisco certified training, Cisco partners, Cisco Advanced Services, other Cisco Press books), periodically check the Technical Support website (http://www.cisco.com/en/US/support/index.html > click the link to Technology Support > choose the Voice category). This website provides articles on all aspects of voice technology, as shown in Figure 1-6.

Figure 1-6 Voice Technical Support on Cisco.com