Home > Articles > Cisco Network Technology > General Networking > Planning the Cisco CallManager Implementation

Planning the Cisco CallManager Implementation

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Sep 24, 2004.

Chapter Description

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.

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":


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


You might prefer to record your interview feedback in an application such as Microsoft Excel, which would provide greater flexibility than handwritten documents.

Check the Cisco Press website for a free starter spreadsheet that you can use or customize for your deployment (go to http://www.ciscopress.com/1587051397). Check the site regularly for updates to the spreadsheet or the book chapters. Figure 1-3 shows the FeatureInventory.xls file that is available for download.

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 3Figure 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":


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)


Cisco VG248

Cisco VG224

Cisco IOS gateways


Cisco VG248

Cisco VG224

Cisco IOS gateways


Cisco IOS gateways


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)


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.

5. Choose the Right Equipment | Next Section Previous Section

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020