642-444 CIPT 4.1 Vol1

CIPT1
Cisco IP Telephony
Part 1
Volumes 1 & 2
Version 4.1
Student Guide
CLS Production Services: 08.18.05
Copyright
2005, Cisco Systems, Inc. All rights reserved.
Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax
numbers are listed on the Cisco Website at www.cisco.com/go/offices.
Argentina Australia Austria Belgium Brazil Bulgaria Canada Chile China PRC Colombia Costa Rica
Croatia Cyprus Czech Republic Denmark Dubai, UAE Finland France Germany Greece
Hong Kong SAR Hungary India Indonesia Ireland Israel Italy Japan Korea Luxembourg Malaysia
Mexico The Netherlands New Zealand Norway Peru Philippines Poland Portugal Puerto Rico Romania
Russia Saudi Arabia Scotland Singapore Slovakia Slovenia South Africa Spain Sweden Switzerland
Taiwan Thailand Turkey Ukraine United Kingdom United States Venezuela Vietnam Zimbabwe
Copyright 2005 Cisco Systems, Inc. All rights reserved. CCSP, the Cisco Square Bridge logo, Follow
Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live,
Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, ASIST,
BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo,
Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Empowering
the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive,
GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard,
LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar,
Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, StrataView
Plus, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are
registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of
the word partner does not imply a partnership relationship between Cisco and any other company. (0501R)
DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED AS IS. CISCO MAKES AND YOU RECEIVE NO
WARRANTIES IN CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY
OR IN ANY OTHER PROVISION OF THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO
SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY,
NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING,
USAGE OR TRADE PRACTICE. This learning product may contain early release content, and while Cisco believes it to be
accurate, it falls subject to the disclaimer above.
Volume 1
Table of Contents
Course Introduction
Overview
Learner Skills and Knowledge
Course Goal and Objectives
Course Flow
Additional References
Cisco Glossary of Terms
Your Training Curriculum
Getting Started with Cisco CallManager

Overview
Module Objectives
Introducing Cisco CallManager
Overview
Objectives
Cisco AVVID
Cisco CallManager Functions
Example: Basic IP Telephony Call
Cisco CallManager Operating System, Database, and Supporting Applications
Cisco CallManager Servers
Installation CD-ROMs
Installation Configuration Data
Example: Configuration Data Worksheet
Postinstallation Procedures
Activating Cisco CallManager Services
Upgrading Prior Cisco CallManager Versions
Summary
References
Identifying Cisco CallManager Cluster and Deployment Options

Overview
Objectives
Microsoft SQL Cluster Relationship
Intracluster Communication
Cluster Redundancy Designs
Call-Processing Deployment Models
Single-Site Deployment
Multisite WAN with Centralized Call Processing
Multisite WAN with Distributed Call Processing
Clustering over the IP WAN
Summary
References
Module 1 Summary
Module 1 Self-Check
Module 1 Self-Check Answer Key
Establishing an On-Cluster Call

Overview
Module Objectives
Identifying Cisco IP Telephony Endpoints

Overview
Objectives
Cisco IP Phone Overview
Entry-Level Cisco IP Phones
Midrange and Upper-End Cisco IP Phones
Additional Cisco IP Telephony Endpoints
1
1
1
3
4
5
6
7
1-1
1-1
1-1
1-3
1-3
1-3
1-4
1-5
1-7
1-8
1-9
1-10
1-11
1-13
1-15
1-17
1-20
1-21
1-22
1-23
1-23
1-23
1-25
1-27
1-28
1-30
1-31
1-34
1-36
1-39
1-41
1-42
1-43
1-44
1-46
2-1
2-1
2-1
2-3
2-3
2-3
2-4
2-5
2-7
2-9
IP Phone Startup Process

Cisco IP Phone Codec Support
Summary
References
Configuring Cisco CallManager to Support IP Phones
2-17
Configuring Cisco Catalyst Switches
2-35
Configuring Cisco IP Communicator
2-55
Using the Bulk Administration Tool
2-67
Overview
Objectives
Server Configuration
Configuring Device Pools
Example: Device Pool Configuration
Example: Cisco CallManager Group Configuration
Example: Region Configuration
IP Phone Button Templates
Example: Naming a Phone Button Template
Manual IP Phone and Directory Number Configuration
Configuring IP Phone Auto-Registration
Summary
References
Overview
Objectives
Catalyst Switch Role in IP Telephony
Powering the Cisco IP Phone
Types of PoE Delivery
Catalyst Family of PoE Switches
Configuring PoE
Configuring Dual VLANs
Configuring Class of Service
Summary
References
Overview
Objectives
Cisco IP Communicator Overview
Cisco IP Communicator Installation and Configuration Overview
Configuring Cisco CallManager for Cisco IP Communicator
Deploying and Updating Cisco IP Communicator
Postinstallation Configuration Tasks
Summary
References
Overview
Objectives
Introducing the Bulk Administration Tool
Installing BAT
Using the BAT Wizard
Configuring BAT Templates
Creating CSV Files
Validating Data Input Files
Inserting IP Phones into Cisco CallManager
Updating IP Phones with BAT
Using the Tool for Auto-Registered Phone Support
Summary
References
Module 2 Summary
Module 2 Self-Check
ii
2-11
2-13
2-14
2-15
Cisco IP Telephony Part 1 (CIPT1) v4.1
2-17
2-17
2-18
2-19
2-20
2-22
2-24
2-26
2-27
2-28
2-30
2-33
2-33
2-35
2-35
2-36
2-37
2-38
2-41
2-43
2-45
2-50
2-52
2-53
2-55
2-55
2-56
2-59
2-60
2-61
2-64
2-65
2-66
2-67
2-67
2-68
2-72
2-74
2-78
2-81
2-85
2-86
2-87
2-89
2-93
2-94
2-95
2-96
2-100
2005, Cisco Systems, Inc.
Volume 2
Establishing an Off-Cluster Call
3-1
Overview
Module Objectives
3-1
3-1
Configuring Gateways and Trunks
3-3
Overview
Objectives
The Gateway in an IP Telephony Infrastructure
Analog and Digital Gateways
Core Gateway Requirements
Gateway Communication Overview
Configuring Access Gateways
Example: H.323 Gateway Configuration
Example: MGCP Gateway Configuration
Cisco CallManager Trunk Types
Configuring Intercluster Trunks
SIP and Cisco CallManager
Forwarding DTMF Digits
Generating DTMF Digits
Configuring SIP Trunks
Summary
References
3-3
3-3
3-4
3-5
3-6
3-7
3-9
3-11
3-16
3-19
3-21
3-24
3-27
3-27
3-28
3-29
3-30
Configuring Basic Route Plans
3-31
Configuring Hunt Groups and Call Coverage
3-57
Configuring Complex Route Plans
3-85
Overview
Objectives
External Call Routing
Route Groups
Route Lists
Route Patterns
Digit Analysis
Summary of Call Routing
Example: Route Plan
Summary
References
3-31
3-31
3-32
3-35
3-37
3-39
3-45
3-51
3-54
3-55
3-56
Overview
Objectives
Call Distribution Overview
Hunting and Forwarding
Configuring Line Groups, Hunt Lists, and Hunt Pilots
Configuring Final Forwarding
Hunting and Forwarding Usage Scenarios
Summary
References
3-57
3-57
3-58
3-65
3-68
3-73
3-77
3-83
3-84
Overview
Objectives
Route Filters
Discard Digits Instructions
Transformation Masks
Translation Patterns
Route Plan Report
Summary
References
3-85
3-86
3-87
3-92
3-94
3-99
3-102
3-104
3-104
iii
Implementing Class of Control
3-105
Implementing Multiple-Site Deployments
3-127
Overview
Objectives
Class of Service
Partitions and Calling Search Spaces Overview
Configuring Partitions and Calling Search Spaces
Example: Assigning DNs to Partitions
Example: Assigning Partitions to Calling Search Spaces
Time-of-Day Routing Overview
Time Periods
Time Schedules
End Users and Time-of-Day Routing
Configuring Time-of-Day Routing
Time-of-Day Routing Usage Scenario
Summary
References
Overview
Objectives
Call Admission Control Overview
Locations-Based Call Admission Control Overview
Example
Locations-Based Call Admission Control Configuration
AAR Overview
AAR Configuration
Automated Alternate Routing Enable in System Parameters
Cluster-Wide Parameters
Adding an AAR Group in CallManager
Gatekeeper Call Admission Control Overview
Gatekeeper Communication
Gatekeeper Call Admission Control Configuration
Example
SRST Overview
SRST Configuration
Summary
References
Module 3 Summary
Module 3 Self-Check
Enabling Features and Services

Overview
Module Objectives
Configuring Media Resources
Overview
Objectives
Introduction to Media Resources
Conference Bridge Resources
Media Termination Point Resources
Annunciator Resources
Example: Call Completion Failure and Announcement
Transcoder Resources
Music on Hold Resources
Media Resource Management
Example: MRG Resource Allocation
Summary
References
iv
3-105
3-105
3-106
3-107
3-108
3-108
3-109
3-110
3-113
3-114
3-114
3-115
3-122
3-124
3-125
3-127
3-128
3-129
3-131
3-132
3-133
3-134
3-137
3-138
3-138
3-140
3-148
3-149
3-153
3-154
3-156
3-161
3-166
3-167
3-168
3-169
3-173
4-1
4-1
4-1
4-3
4-3
4-3
4-4
4-6
4-13
4-16
4-17
4-20
4-23
4-33
4-35
4-43
4-44
Adding Users and Customizing User Options
4-45
Configuring User Features Part 1
4-63
Configuring User Features Part 2
4-99
Overview
Objectives
Adding a User
User Login and Device Selection
Call Forward
Example: Call Forwarding
Speed Dials
Example: Adding an Access Code to Speed Dial Numbers
Cisco IP Phone Services Subscription
Example: Subscribing to a Stock Quote Service
Personal Address Book and Fast Dial
Message Waiting Lamp Policy
Example: Setting the Message Waiting Lamp Policy
Personalizing Device and Web Page Locale
Example: Setting the User Locale on the Phone
Summary
References
Overview
Objectives
Core IP Phone Features
Enhanced IP Phone Features
Example: Configuration Settings for Multiple Calls per Line Appearance
Example: Direct Transfer Call
Example: Called Party Presses iDivert Softkey
Example: Caller Presses iDivert Softkey
Working with Softkey Templates
Example: Nonstandard Softkey Template
Call Park, Call Pickup, and Cisco Call Back
Example: Call Park Feature in Department Store
Example: Cisco Call Back
Barge and Privacy
Cisco IP Phone Services
Add an IP Phone Service
Add the Service URL to a Phone Button
Summary
References
Overview
Objectives
Cisco CallManager Extension Mobility
Client Matter Codes and Forced Authentication Codes
Call Display Restrictions
Calling Line ID Presentation
Connected Line ID Presentation
Ignore Presentation Indicators (Internal Calls Only)
Malicious Call Identification
Multilevel Precedence and Preemption
Example: MLPP Call
Summary
References
Module 4 Summary
Module 4 Self-Check
4-45
4-45
4-46
4-49
4-51
4-51
4-52
4-52
4-53
4-53
4-54
4-58
4-58
4-59
4-60
4-61
4-62
4-63
4-63
4-64
4-69
4-70
4-71
4-73
4-73
4-74
4-75
4-81
4-81
4-87
4-88
4-92
4-94
4-94
4-97
4-98
4-99
4-99
4-100
4-108
4-117
4-118
4-119
4-119
4-124
4-130
4-131
4-132
4-133
4-134
4-135
4-138
Configuring Cisco CallManager Applications

Overview
Module Objectives
Configuring Cisco CallManager Attendant Console
Overview
Objectives
Introduction to Cisco CallManager Attendant Console
Cisco CallManager Attendant Console Components
Cisco Telephony Call Dispatcher
Cisco CallManager Attendant Console Directory
Cisco CallManager Attendant Console Client
Call Routing and Queuing
Cisco CallManager Attendant Console Redundancy
Server and Administration Configuration
Changing the Default JTAPI Username and Password
Enabling Broadcast or Circular Hunting
Installing and Configuring the Client
Cisco CallManager Attendant Console Features
Summary
References
Configuring Cisco IP Manager Assistant
Overview
Objectives
Cisco IP Manager Assistant Overview
Cisco IP Manager Assistant Architecture
Configuring Cisco IPMA for Shared-Line Support
Manager Configuration
Assistant Console
Summary
References
Module 5 Summary
Module 5 Self-Check
vi
5-1
5-1
5-1
5-3
5-3
5-4
5-5
5-7
5-8
5-9
5-9
5-11
5-13
5-15
5-23
5-24
5-25
5-27
5-35
5-36
5-37
5-37
5-37
5-38
5-42
5-43
5-51
5-52
5-54
5-55
5-56
5-57
5-59
CIPT1
Course Introduction
Overview
Cisco IP Telephony Part 1 (CIPT1) v4.1 prepares you for installing, configuring, and
maintaining a Cisco IP telephony solution. This course focuses primarily on Cisco
CallManager, the call routing and signaling component for the Cisco IP telephony solution.
This course includes lab activities in which you will perform postinstallation tasks and
configure Cisco CallManager; configure gateways, gatekeepers, and switches; and build route
plans to place intra- and intercluster Cisco IP Phone calls. You will also configure telephony
class of service (calling restrictions) and numerous user telephone features, services, media
resources, and applications.

This subtopic lists the skills and knowledge that learners must possess to benefit fully from the
course. The subtopic also includes recommended Cisco learning offerings that learners should
complete to benefit fully from this course.

Skill or Knowledge
Cisco Learning Offering
Working knowledge of fundamental terms Interconnecting Cisco Network

and concepts of computer networking, to Devices (ICND)
include LANs, WANs, and IP switching
Cisco CCNA certification
and routing
recommended prerequisite
Ability to configure and operate Cisco
routers and switches and to enable
VLANs and DHCP
Building Cisco Multilayer

Switched Networks (BCMSN)
Fundamental knowledge of converged

voice and data networks
Cisco Voice over IP (CVOICE)
Ability to configure voice interfaces on

Cisco voice-enabled equipment for
connection to traditional, nonpacketized
telephony equipment and to configure the
call flows for POTS and VoIP dial peers
2005 Cisco Systems, Inc. All rights reserved.
CIPT1 v4.13
Course Goal and Objectives
This topic describes the course goal and objectives.
Course Goal
To prepare learners to install, configure, and

maintain a Cisco IP telephony solution. The
course focuses on the Cisco CallManager,
which is the call routing and signaling
component for the Cisco IP telephony
solution.
Cisco IP Telephony Part 1
CIPT1 v4.14
Upon completing this course, you will be able to meet these objectives:
Deploy a Cisco CallManager server in a cluster by using a supported IP telephony
deployment model
Configure Cisco CallManager and the Cisco Catalyst switch to enable on-cluster calls and
add users, phones, and Cisco IP Communicator to the Cisco CallManager database using
manual configuration, auto-registration, or BAT
Configure Cisco gateways and intercluster trunks, create hunt groups, and create a route
plan in Cisco CallManager to enable calling to remote clusters so that the WAN is not
oversubscribed, calls are preserved if the WAN fails, and user calling restrictions are in
place
Configure Cisco CallManager to enable features and services, including conferencing,
music on hold (MOH), speed dials, Call Park, Call Pickup, Cisco Call Back, Barge,
Privacy, Cisco IP Phone Services, Cisco CallManager Extension Mobility, Cisco
CallManager Attendant Console, and Cisco IP Manager Assistant (IPMA) and also use
these features on Cisco IP Phones
Configure Cisco CallManager and the client PC to enable Cisco CallManager Attendant
Console and Cisco IPMA
Course Introduction
Course Flow
This topic presents the suggested flow of the course materials.
Course Flow
Day 1
Day 2
Day 3
Course
Introduction
A
M
Establishing
an On-Cluster
Call
Getting
Started with
Cisco
CallManager
Establishing
an Off-Cluster
Call
Day 4
Establishing
an Off-Cluster
Call
Enabling
Features and
Services
Enabling
Features
and Services
Configuring
Cisco
CallManager
Applications
Lunch
P
M
Establishing
an On-Cluster
Call
Establishing
an On-Cluster
Call
Establishing
an Off-Cluster
Call
Day 5
Enabling
Features and
Services
Configuring
Cisco
CallManager
Applications
Wrap-Up
Establishing an
Off-Cluster Call
CIPT1 v4.15
The schedule reflects the recommended structure for this course. This structure allows enough
time for the instructor to present the course information and for you to work through the lab
activities. The exact timing of the subject materials and labs depends on the pace of your
specific class.
Additional References
This topic presents the Cisco icons and symbols used in this course, as well as information on
where to find additional technical references.
Course Icons and Symbols

Router
Cisco
CallManager
Voice Router
Traditional PBX
Relational
Database
IP Phone
Switch Router
Switch
Voice Multilayer Switch
LDAP
Directory
Server
Phone
SRST-Enabled Router
File
Server
Gateway
Switch
PSTN
CO Switch
Digital Signal
Processor
DSP
VLAN or Cluster
(Color May Vary)
CIPT1 v4.16
Course Icons and Symbols (Cont.)

PC
Printer
WAN
Telecommuter
Camera
PC/Video
Digital
Certificate
Fax
Mobile User
Laptop
Videoconference
Video
Camera
Building
Building
CIPT1 v4.17
Course Introduction
Cisco Glossary of Terms

For additional information on Cisco terminology, refer to the Cisco Internetworking Terms and
Acronyms glossary of terms at http://www.cisco.com/univercd/cc/td/doc/cisintwk/ita/index.htm.
Your Training Curriculum
This topic presents the training curriculum of this course.
Cisco Voice Career Certifications

Expand Your Professional Options
and Advance Your Career
Cisco Voice Career Certifications
Professional-level recognition in Cisco Voice Career

Certifications
Expert
CCIE
Gateway
Gatekeeper
Professional
CCVP
Associate
CCNA
<Insert Career
Certification>
Required
Exam
Recommended Training Through

Cisco Learning Partners
Implementing Cisco Voice Gateways
and Gatekeepers
IPTT 642-425
IP Telephony Troubleshooting
(IPTT)
QOS 642-642
Implementing Cisco Quality of

Service (QOS)
CIPT 642-444

CVOICE 642432
Cisco Voice Over IP
CIPT2 v4.11
http://www.cisco.com/go/certifications
You are encouraged to join the Cisco Certification Community, a discussion forum open to
anyone holding a valid Cisco Career Certification (such as Cisco CCIE , CCNA, CCDA,
CCNP, CCDP, CCIP, CCVP, or CCSP). It provides a gathering place for Cisco
certified professionals to share questions, suggestions, and information about Cisco Career
Certification programs and other certification-related topics. For more information, visit
www.cisco.com/go/certifications.
Course Introduction
Module 1
Getting Started with Cisco

CallManager
Overview
Cisco CallManager is the software-based, call-processing component of the Cisco IP telephony

solution. This module discusses the servers that Cisco CallManager supports, explores the
available deployment models for using Cisco CallManager in a Cisco IP telephony solution,
and reviews the Cisco CallManager server installation process.
Module Objectives
Upon completing this module, you will be able to deploy a Cisco CallManager server in a
cluster using a supported IP telephony deployment model. This ability includes being able to
meet these objectives:
Identify the functions that Cisco CallManager provides in the overall Cisco AVVID
strategy and identify the hardware, software, and tasks required for a Cisco CallManager
installation
Determine the optimum Cisco CallManager cluster option and IP telephony deployment
model for your enterprise
1-2
Lesson 1-1

Overview
A Cisco IP telephony deployment relies on Cisco CallManager for its call-processing and
call-routing functions. Understanding the role that Cisco CallManager plays in a converged
network from a system, software, and hardware perspective is necessary to successfully install
and configure Cisco CallManager.
This lesson discusses the Cisco Architecture for Voice, Video and Integrated Data (AVVID)
and Cisco CallManager functions, hardware requirements, software requirements, and
installation and upgrade information.
Objectives
Upon completing this lesson, you will be able to identify the functions that Cisco CallManager
provides in the overall Cisco AVVID strategy and identify the hardware, software, and tasks
required for a Cisco CallManager installation.
This ability includes being able to meet these objectives:
Describe the purpose and key components of each Cisco AVVID layer
Identify the primary Cisco CallManager functions
Identify the software that Cisco CallManager depends upon for its operating system,
database, directory, and backup
Identify the major features of each base platform on which Cisco CallManager Release 4.1
is supported
Identify the Cisco CallManager CDs that are required for installation
Identify all configuration data that is required to install Cisco CallManager software
Perform postinstallation procedures to help secure the server and optimize server resources
Activate Cisco CallManager services
Identify the supported versions of Cisco CallManager required to upgrade to release 4.1
Cisco AVVID
This topic describes the purpose and key components of each Cisco AVVID layer.
Cisco AVVID
Client
Video
Cisco IP Communicator IP Phone
PC
Applications
TAPI, JTAPI, SMDI
Cisco Unity
Cisco IPCC
Call Processing
Call Admission, Call Routing
Cisco CallManager Directory
Infrastructure
Cisco IOS Network Services
Gateway Router
Switch
CIPT1 v4.11-3
Cisco AVVID provides the foundation for converged networks. The Cisco AVVID strategy
encompasses voice, video, and data traffic within a single network infrastructure. Cisco
AVVID equipment is capable of managing all three traffic types and interfacing with all
standards-based network protocols in each network class.
This figure shows the four standard layers of the Cisco AVVID voice infrastructure model: the
infrastructure layer, which lays the foundation for network components; the call-processing
layer, which maintains PBX-like functions; the applications layer, where applications that
provide additional network functionality reside; and the client layer, where end-user devices
reside. The key points about the four standard layers are as follows:
Infrastructure layer: The infrastructure carries data between all network devices and
applications and consists of routers, switches, and voice gateways.
Call-processing layer: Call processing is physically independent of the infrastructure.
Thus, a Cisco CallManager in Chicago can process call control for a bearer channel in
Phoenix.
Applications layer: Applications are physically independent of call-processing functions
and the physical voice-processing infrastructure; that is, they may reside anywhere within
the network.
Client layer: The client layer brings applications to the user, whether the end device is a
Cisco IP Phone, a PC using a Cisco IP Communicator, or a PC delivering converged
messaging.
1-4
This topic describes the primary Cisco CallManager functions within the Cisco IP telephony
solution.

Call processing
Signaling and device control
Dial plan administration
Phone feature administration
Directory services
Programming interface to external
applications
Course acronym vx.x#-6
Cisco CallManager extends enterprise telephony features and functions to packet telephony
network devices. These network devices include Cisco IP Phones, media-processing devices,
voice over IP (VoIP) gateways, and multimedia applications. Additional data, voice, and video
services, such as converged messaging, multimedia conferencing, collaborative contact centers,
and interactive multimedia response systems, interact with the IP telephony solution through
the Cisco CallManager application programming interface (API).
Cisco CallManager provides the following functions:
Call processing: Call processing refers to the complete process of routing, originating, and
terminating calls, including any billing and statistical collection processes.
Signaling and device control: Cisco CallManager sets up all of the signaling connections
between call endpoints and directs devices such as phones, gateways, and conference
bridges to establish and tear down streaming connections.
Dial plan administration: The dial plan is a set of configurable lists that Cisco
CallManager uses to determine call routing. Cisco CallManager provides the ability to
create secure dial plans for users.
Phone feature administration: Cisco CallManager extends services such as hold, transfer,
forward, conference, speed dial, last-number redial, Call Park, and other features to IP
Phones and gateways.
1-5
Directory services: Cisco CallManager uses DC-Directory as an embedded Lightweight

Directory Access Protocol (LDAP) directory. This directory stores authentication and
authorization information about users and is a standard feature of Cisco CallManager (it
does not require any special configuration or installation). However, Cisco CallManager
can also be integrated with a corporate LDAP directory.
Programming interface to external applications: Cisco CallManager provides a
programming interface to external applications such as Cisco IP SoftPhone, Cisco IP
Interactive Voice Response (IVR), Cisco Personal Assistant, and Cisco CallManager
Attendant Console.
Cisco CallManager Functions (Cont.)

Cisco CallManager
Skinny Protocol Signaling
IP Phone
Party A
Skinny Protocol Signaling
Real-Time Transport Protocol (RTP) Media Path
IP Phone
Party B
Cisco CallManager performs call setup and maintenance tasks

using Skinny.
IP Phones stream audio using RTP.
CIPT1 v4.11-5
Cisco CallManager use the Skinny Client Control Protocol (SCCP, or Skinny) signaling
protocol over IP to communicate with Cisco IP Phones for call setup and maintenance tasks.
When the call is set up, Cisco IP Phones communicate directly using Real-Time Transport
Protocol (RTP) to carry the audio.
You can better understand how Cisco CallManager performs key functions by tracking a basic
IP telephony call.
1-6
Example: Basic IP Telephony Call

In the figure shown, Party A (left telephone) wants to call Party B (right telephone). Party A
picks up the handset and dials the number of Party B. In this environment, dialed digits are sent
to Cisco CallManager, the call-processing engine. Cisco CallManager finds the address and
determines where to route the call.
Using the Skinny protocol, Cisco CallManager signals the calling party over IP to initiate a ring
back, and Party A hears ringing. Cisco CallManager also signals the destination phone to
initiate ringing.
When Party B picks up the telephone, the RTP media path opens between the two stations.
Party A or Party B may now initiate a conversation.
The IP Phones require no further communication with Cisco CallManager until either Party A
or Party B invokes a feature, such as call transfer, call conferencing, or call termination.
1-7
Cisco CallManager Operating System, Database,

and Supporting Applications
This topic identifies key software on which Cisco CallManager depends.
Operating System, Database, and

Applications
Windows 2000 Server
Microsoft SQL Server 2000
DC-Directory
Cisco IP Telephony Backup and Restore System
CIPT1 v4.11-6
Cisco CallManager server relies on Microsoft Windows 2000 for its operating system and
Microsoft Structured Query Language (SQL) Server 2000 for its database (both provided by
Cisco Systems). The operating system version that Cisco provides is called the Cisco IP
Telephony Operating System. Cisco CallManager 4.1(2) requires Cisco IP Telephony
Operating System Version 2000.2.6 (or later) and the latest Cisco IP Telephony Server
Operating System service release (2000-2-6 sr3 or later). Cisco CallManager 4.1(3) requires
Cisco IP Telephony Operating System Version 2000.2.7 (or later) and the latest service release
(2000-2-7 sr2 or later).
Cisco CallManager uses DC-Directory as an embedded LDAP directory. This directory stores
authentication and authorization information about users and is standard with Cisco
CallManager (it does not require any special configuration or installation). Authentication
establishes the right of the user to access the system, while authorization identifies the
telephony resources that a user is permitted to use, such as a specific telephone extension.
The Cisco Customer Directory Plugin allows you to integrate Cisco CallManager with one of
the following enterprise directories:
Microsoft Active Directory, available with Microsoft Windows 2000
Microsoft Active Directory, available with Microsoft Windows 2003
Netscape Directory Server, Versions 4.1 and 4.2,
Sun ONE Directory Server 5.x
The Cisco IP Telephony Backup and Restore System (BARS) can be used to back up Cisco
CallManager. Cisco BARS is installed separately from Cisco CallManager.
1-8
Cisco CallManager Servers
This topic describes the major features of the supported server hardware platforms for Cisco
CallManager Release 4.1.
Cisco 7800 Series MCS

Platform
Space
Processor
CPU Equipped
CPU
Max.
Max. Phones
Per Cluster
MCS 7815-I1
Tower
Pentium 4 3060 MHz
300
MCS 7825-I1
1U Rack
Mount
Pentium 4 3400 MHz
1000
MCS 7835-I1
2U Rack
Mount
Nocona Xeon
3400 MHz
2500
MCS 7845-I1
2U Rack
Mount
Nocona Xeon
3400 MHz
7500
MCS 7825-H1
1U Rack
Mount
Pentium 4 3400 MHz
1000
MCS 7835-H1
2U Rack
Mount
Nocona Xeon
3400 MHz
2500
MCS 7845-H1
2U Rack
Mount
Nocona Xeon
3400 MHz
7500
CIPT1 v4.11-7
Because voice networks should maintain an uptime of 99.999 percent, you must install Cisco
CallManager on a server that meets Cisco configuration standards. For this reason, Cisco has
collaborated with two server hardware manufacturers, Hewlett-Packard and IBM, to create
Cisco Media Convergence Servers (MCSs). Hewlett-Packard and IBM designed these server
hardware platforms specifically for Cisco voice applications.
All of these servers are rack-mountable and do not include a monitor, mouse, or keyboard.
Cisco designed the Cisco MCS for local setup, rack mounting, and remote administration.
For a list of servers on which Cisco CallManager 4.1 is supported, refer to the Cisco
CallManager 4.1 data sheet at:
http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/products_data_sheet0900aecd
801979f0.html.
1-9
Installation CD-ROMs
This topic identifies the CD-ROMs that you must use to install a Cisco CallManager server.
Installation Disks
Disks essential for new Cisco
CallManager 4.1 installation:
Hardware Detection
Cisco CallManager Installation,
Upgrade, and Recovery
Cisco CallManager 4.1 Software
Cisco CallManager 4.1 upgrade software can be

downloaded from Cisco.com or ordered on DVD/CD
(includes Cisco CallManager software only, does not
include operating system)
CIPT1 v4.11-8
All Cisco MCSs and customer-provided servers that meet approved Cisco configuration
standards ship with a blank hard drive. When you purchase a Cisco IP telephony application,
you use the appropriate disks to install or upgrade the operating system and application:
Cisco IP Telephony Server Operating System Hardware Detection Disk: Checks the
server and displays an error message if it detects an unsupported server. After you boot the
server using the Hardware Detection CD-ROM, the automated installation process prompts
for the correct CD-ROMs to use.
Cisco IP Telephony Server Operating System Installation and Recovery Disk: Installs
the operating system. Use only one of the server-specific Cisco IP Telephony Server
Operating System Installation and Recovery disks that come in your software kit. During
the operating system installation, a prompt instructs you to insert the appropriate disk into
the drive.
Cisco CallManager 4.1 Software Disk: This disk installs the Cisco CallManager
application on the server.
You may also receive a Cisco IP Telephony Server Operating System Upgrade Disk. Use this
disk to upgrade the operating system on existing (not new) servers in the cluster. You do not
need to use this disk if you are performing a new operating system installation.
1-10
Installation Configuration Data
This topic describes the configuration data that you will need when installing a Cisco
CallManager server.
Configuration Information
New installation or server
replacement
TCP/IP properties
Cisco product key
SNMP community string
Username and
organization name
Computer name
Workgroup
Domain Name System

Database server
Password for system
administrator
Domain suffix
CIPT1 v4.11-9
As you perform the Cisco CallManager installation, the automated setup process prompts you
for the information that is necessary to build Windows 2000, Microsoft SQL Server 2000, and
Cisco CallManager with a base configuration. The entire operating system installation process,
excluding preinstallation tasks, takes approximately 25 to 45 minutes per server, depending on
your server type. Installing Cisco CallManager, excluding pre- and postinstallation tasks, takes
45 to 90 minutes per server, depending on your server type.
The process erases all data on the server hard disk. During the installation, you are prompted
for the following items:
New installation or server replacement: Choose this option if you are installing the Cisco
IP telephony application for the first time, overwriting an existing installation, or replacing
a server. To replace the server, you must store the data to a network directory or tape
device before the operating system installation. Choosing this setting erases all existing
drives.
Cisco product key: Cisco supplies a product key when you purchase a Cisco IP telephony
product. The product key is based on a file encryption system that allows you to install only
the components that you have purchased. It also prevents you from installing other supplied
software for general use. The product key consists of alphabetical characters only.
Username and organization name: The system will prompt you for a username and an
organization name to register the software product that you are installing. Do not leave the
field blank. You can enter letters, numbers, hyphens (-), and underscores (_).
1-11
Computer name: The system will prompt you to assign a unique computer name, using 15
characters or fewer, to each Cisco CallManager server. The computer name may contain
alphabetic and numeric characters, hyphens, and underscores, but it must begin with a letter
of the alphabet. Follow your local naming conventions, if possible. If you want to change
the computer name after the application installation, you must completely reinstall the
operating system and the application.
Workgroup: The system will also prompt you for a workgroup name. A workgroup
consists of a collection of computers that share the same workgroup name. Computers in
the same workgroup can more easily communicate with each other across the network.
Ensure that this entry, which must also be 15 characters or fewer, follows the same naming
conventions as the computer name.
Domain suffix: When prompted, you must enter the Domain Name System (DNS) suffix
in the format mydomain.com or mycompany.mydomain.com. If you are not using
DNS, use a fictitious domain suffix, such as fictitioussite.com.
TCP/IP properties: You must assign an IP address, subnet mask, and default gateway
when installing a Cisco CallManager server. You should not change the IP addresses after
installation because they are permanent properties.
Note
It is strongly recommended that you choose static IP information, which ensures that the
Cisco CallManager server obtains a fixed IP address. With this selection, Cisco IP Phones
can register with Cisco CallManager when the telephones are plugged into the network.
Using Dynamic Host Configuration Protocol (DHCP) can cause problems, including failure of
the telephony system.
DNS: You must identify a primary DNS server for this optional field. By default, the
telephones will attempt to connect to Cisco CallManager using DNS. Therefore, you must
verify that the DNS server contains a mapping of the IP address and the fully qualified
domain name (FQDN) of the Cisco CallManager server. If you do not use DNS, use the
server IP address, instead of a server name, to register the telephones with Cisco
CallManager. Refer to the Cisco CallManager Administration Guide, or the online help in
the Cisco CallManager application, for information about changing the server name.
Note
Before you begin installing multiple servers in a cluster, you must have a name resolution
method in place, such as DNS, Windows Internet Naming Service (WINS), or local name
resolution using a configured LMHOSTS file.
If you use DNS, you must verify that the DNS server contains a mapping of the IP address
and the hostname of the server that you are installing. This verification must take place
before you begin the installation.
If you use local name resolution, ensure that the LMHOSTS file is updated on the existing
servers in the cluster before you begin the installation on the new subscriber server. You
must add the same information to the LMHOSTS file on the new server during installation.
SNMP community string: The Windows 2000 Simple Network Management Protocol
(SNMP) agent provides security through the use of community names and authentication
traps. All SNMP implementations universally accept the default name "public." Cisco sets
the community rights to none for security reasons. If you want to use SNMP with this
server, you must configure it.
1-12
Database server: You must determine whether you will configure this server as a
publisher database server or as a subscriber database server. This selection is permanent.
You must reinstall the Cisco CallManager server if you want to reassign the database server
type at a later date.
Note
You must install a Cisco CallManager publisher server before you can install any subscriber
servers.
Note
When you are configuring a subscriber database server, ensure that the server that you are
installing can connect to the publisher database server during the installation. This
connection facilitates the copying of the publisher database to the local drive on the
subscriber server. You must supply the name of the publisher database server and a
username and password with administrator access rights on that server. The installation will
be discontinued if, for any reason, the publisher server cannot be authenticated.
New password for the system administrator: Cisco CallManager Releases 3.0 and later
support password protection. A prompt at the end of the installation procedure will ask you
to supply a new password for the system administrator.
Note
For Cisco CallManager database replication, you must enter the same replication account
password for the publisher and all of the subscribers in the cluster.
Example: Configuration Data Worksheet

This table shows the configuration information that you need to install software on your server.
You should complete all of the fields in the table, unless otherwise noted. You must gather this
information for each Cisco CallManager server that you are installing in the cluster. Make
copies of this table, and record your entries for each server in a separate table. You should have
the completed tables available when you begin the installation.
1-13
Configuration Data for Cisco MCS

Configuration
Data
Cisco product key

Username
Name of your organization
Computer name
Workgroup
Microsoft NT domain (optional)
DNS domain suffix
Current time zone, date, and time
DHCP parameters
It is recommended that you program a fixed IP address in

TCP/IP properties for the server instead of using DHCP.
TCP/IP properties (required if DHCP

is not used):
IP address
Subnet mask
Default gateway
DNS servers (optional):
Primary
Secondary
WINS servers (optional):
Primary
Secondary
LMHOSTS file (optional)
Database server (choose one):
Publisher
Subscriber
If you are configuring a subscriber
server, supply the username and
password of the publishing database
server:
Publisher username
Publisher password
Backup (choose one or both):

Server
Target
New Windows 2000 administrator
password
1-14
This topic examines the tasks that Cisco recommends that you perform after installing Cisco
CallManager.
Change passwords:
During upgrades, password resets to default.
Change passwords on all servers in a cluster.
Stop unnecessary services:

Publisher and subscribers:
DHCP Client, Fax Service, FTP Publishing Service, Smart
Card, Smart Card Helper, Computer Browser, Distributed
File System, License Logging Service
Subscribers:
IIS Admin Service, World Wide Web Publishing Service
Activate services
Install backup utility and configure the backup settings.
CIPT1 v4.11-10
You should perform postinstallation tasks to ensure the optimal operation of Cisco
CallManager. Perform the following tasks for each server that you have installed:
Change passwords: During installation, all accounts are set to a default password. The
server will prompt you to change the passwords for the Cisco CallManager accounts after
installation is complete. These passwords must be the same for each of the Cisco
CallManager servers in the cluster.
Stop unnecessary services: The Windows 2000 operating system may have services
running that are not necessary. When you stop unnecessary services, you gain additional
resources that you can allocate to mission-critical Cisco CallManager processes. You
should stop all of the following services and set them to manual-start status unless they are
otherwise needed on the system:
DHCP Client
Fax service (Cisco CallManager 3.2 and earlier)
FTP Publishing Service
Smart Card (Cisco CallManager 3.2 and earlier)
Smart Card Helper (Cisco CallManager 3.2 and earlier)
Computer browser (Cisco CallManager 3.2 and earlier)
Distributed File System
License Logging Service
1-15
In addition to the services listed here, you should stop and set the following services to manual
on the subscriber servers:
Microsoft Internet Information Server (IIS) Admin Service: You can provide an
additional level of security by turning off IIS on Cisco CallManager servers that do not
need web access, such as subscriber servers. Turning off IIS protects unauthorized users
from accessing Cisco CallManager in a distributed architecture.
World Wide Web Publishing Service
Both the FTP Publishing Service and the World Wide Web Publishing Service depend on the
IIS Admin Service. When the IIS Admin Service stops, the FTP Publishing Service and World
Wide Web Publishing Service also stop. You must set the FTP Publishing Service and the
World Wide Web Publishing Service to manual.
To open services, choose Start > Programs > Administrative Tools > Services. Right-click
each service and choose Properties. Then choose the startup type, stop the service, and click
Apply.
Activate services: Activate Cisco CallManager services that you want to run on each
server in the cluster.
Install the backup utility: Install Cisco BARS and configure the backup settings that
determine when the Cisco CallManager data is backed up and to what device.
1-16
Activating Cisco CallManager Services
This topic explains the process of selecting and activating Cisco CallManager services after
installation.
Cisco CallManager Service Selection

Cisco CallManager Service
Cisco TFTP
Cisco Messaging Interface
Cisco IP Voice Media
Streaming Application
Cisco CTIManager
Cisco Telephony Call
Dispatcher
Cisco MOH Audio Translator
Cisco RIS Data Collector
Cisco Database Layer
Monitor
Cisco CDR Insert

Cisco CTL Provider
Cisco Extended Functions
Cisco Serviceability Reporter
Cisco WebDialer
Cisco IP Manager Assistant
Cisco Extension Mobility
Cisco CTL Provider
Cisco Certificate Authority
Proxy Function (CAPF)
CIPT1 v4.11-12
If you are installing Cisco CallManager for the first time, all services that are required to run
Cisco CallManager automatically install on the system; however, none of the services are
activated at the completion of the installation (except for the Cisco Database Layer Monitor
service). Cisco CallManager Serviceability provides a web-based Service Activation tool that is
used to activate or deactivate multiple services and to select default services to activate.
It is recommended that you activate only the required components for each server in the cluster.
Each component that you activate adds to the server load.
If you are upgrading Cisco CallManager, the services that you have already started on your
system will start after the upgrade.
Each service performs specific functions for the IP telephony network. Some services may need
to run on a single Cisco CallManager server in a cluster; other services may need to run on all
of the Cisco CallManager servers in the cluster.
The following information briefly describes each available Cisco CallManager service:
Cisco CallManager Service: Allows the server to actively participate in telephone
registration, call processing, and other Cisco CallManager functions. Cisco CallManager
Service is the core service of the Cisco CallManager platform.
Cisco TFTP: Activates a TFTP server on Cisco CallManager. The TFTP service delivers
Cisco IP Phone configuration files to IP Phones, along with streamed media files, such as
music on hold (MOH) and ring files.
1-17
Cisco Messaging Interface: Allows Cisco CallManager to interface with a Simplified

Message Desk Interface (SMDI)-compliant, external voice-mail system.
Cisco IP Voice Media Streaming Application: Allows Cisco CallManager to act as an
Media Termination Point (MTP), a conference bridge, a music on hold (MOH) server, and
an annunciator.
Cisco CTIManager: Allows Cisco CallManager to support computer telephony
integration (CTI) services and provides Telephony Application Programming Interface
(TAPI) or Java Telephony Application Programming Interface (JTAPI) client support.
Cisco CTIManager allows you to use applications such as Cisco IP SoftPhone.
Cisco Telephony Call Dispatcher: Distributes calls to multiple telephone numbers (hunt
groups). Cisco WebAttendant and Auto Attendant require Cisco Telephony Call Dispatcher
(TCD).
Cisco MOH Audio Translator: Allows Cisco CallManager to convert MP3 or WAV
audio files into the MOH format.
Cisco Real-Time Information Server (RIS) Data Collector: Allows Cisco CallManager
to write trace and alarm file information to a database or alert an SNMP server.
Cisco Database Layer Monitor: Monitors aspects of the Microsoft SQL 2000 database, as
well as call detail records (CDRs).
Cisco CDR Insert: Allows Cisco CallManager to write CDRs to the local database and
replicates CDR files to the Microsoft SQL publisher at a configured interval.
Cisco CTL Provider: Works with the Cisco Certificate Trust List (CTL) client to change
the security mode for the cluster from nonsecure to secure.
Cisco Extended Functions: Provides support for some Cisco CallManager features,
including Cisco Call Back and Quality Report Tool (QRT).
Cisco Serviceability Reporter: Generates the following daily reports: Device Statistics,
Server Statistics, Service Statistics, Call Activities, and Alert.
Cisco WebDialer: Provides click-to-dial functionality by using a web page or a desktop
application.
Cisco IP Manager Assistant: Allows Cisco CallManager to support the Cisco IP Manager
Assistant (IPMA).
Cisco CallManager Extension Mobility: Allows Cisco CallManager to support extension
mobility functions for roaming users.
Cisco Certificate Authority Proxy Function: Working in conjunction with the Cisco
Certificate Authority Proxy Function (CAPF) application, the Cisco CAPF service can
perform the following tasks, depending on your configuration:
1-18
Issue locally significant certificates to supported Cisco IP Phone models
Request certificates from third-party certificate authorities on behalf of supported

Cisco IP Phone models
Upgrade existing certificates on the phones
Retrieve phone certificates for troubleshooting
Delete locally significant certificates on the phone
Cisco CallManager Service Activation
CIPT1 v4.11-13
The Service Activation tool activates services in automatic mode. It also checks for service
dependencies based on a single-server configuration. When you click the Set Default button,
the Service Activation tool chooses the services that are required to run Cisco CallManager
based on a single-server configuration. For example, if you choose one service, you will be
prompted to choose whether you want all the other services that depend on that service to run
Cisco CallManager based on a single-server configuration.
You can activate the Cisco CallManager services in the Service Activation window. To activate
these services, complete the following steps:
Step 1
Open Internet Explorer, and go to http://<CallManager_IP_Address>/ccmadmin.

The <CallManager_IP_Address> is the IP address of the Cisco CallManager server.
Enter the administrative username and password information.
Step 2
From the Application menu, choose Cisco CallManager Serviceability. The

CallManager Serviceability interface appears.
Step 3
From the Tools menu, choose Service Activation. A window similar to the window
shown here appears.
Step 4
Click the server that you would like to configure from the Servers column. Next,
click the services that you would like to activate, and click the Update button. (You
will experience a slight delay.) The Service Activation window will refresh when the
process is complete.
Caution
You should activate the Cisco CallManager services from the Service Activation window. If
you manually start the services through the Windows 2000 Services administrative tool,
unpredictable results may occur.
1-19
Upgrading Prior Cisco CallManager Versions
This topic identifies the supported versions of Cisco CallManager required to upgrade to
Release 4.1.
Upgrading to Cisco CallManager 4.1

Direct upgrades
from:
3.3(4)
3.3(5)
4.0(1)
4.0(2a)
4.1
Other upgrades must go through one of

the releases above.
CIPT1 v4.11-11
Cisco supports the upgrade to Cisco CallManager 4.1 from Cisco CallManager Release 3.3(4),
3.3(5), 4.0(1), and 4.0(2a). Upgrades from prior versions must first go through one of these
releases before you can upgrade to version 4.1.
If your server runs a version of Cisco CallManager Release 3.2 or earlier, you must first
upgrade every server in the cluster to the latest version of Cisco CallManager Release 3.3
before you can upgrade to a version of Cisco CallManager Release 4.1.
Before you perform any upgrade procedures, it is strongly recommended that you install the
latest operating system upgrade and service release, SQL service releases and hotfixes, and
Cisco CallManager service release for the versions that currently run in the cluster. Cisco
provides the service release and corresponding readme documentation on Cisco.com. To
obtain these documents, go to http://www.cisco.com/kobayashi/sw-center/sw-voice.shtml.
Cisco requires that you install Cisco IP Telephony Server Operating System Version 2000.2.6
(or 2000.2.4 with upgrade to 2000.2.6) before you upgrade to Cisco CallManager Release 4.1.
1-20
Summary
This topic summarizes the key points discussed in this lesson.
Summary
The Cisco AVVID strategy provides the foundation for
converged networks and includes the infrastructure,
call-processing, applications, and client layers.
Cisco CallManager functions include call processing,
signaling and device control, dial plan administration, phone
feature administration, directory services, and a
programming interface.
Cisco CallManager server requirements are Windows 2000
and Microsoft SQL Server 2000. DC-Directory is an
embedded LDAP directory, and BARS can be used for
backups.
Cisco CallManager hardware requirements include Cisco
MCSs, which have been designed specifically for Cisco voice
applications by HP and IBM.
CIPT1 v4.11-14
Summary (Cont.)
Installing the operating system and Cisco CallManager IP
telephony application for a new installation requires several
disks. Upgrades can be downloaded from Cisco.com
(with required privileges) or ordered on disks.
Gather configuration data before installing a Cisco
CallManager server.
Postinstallation procedures include changing passwords,
stopping unnecessary services, activating services, and
backing up the system.
You must activate required services for a new installation. If
you are upgrading, those services that you have already
started on your system will start after the upgrade.
Direct upgrades to Cisco CallManager 4.1 can be made from
versions 3.3(4), 3.3(5), 4.0(1), or 4.0(2a).
CIPT1 v4.11-15
1-21
References
For additional information, refer to these resources:
Cisco Systems, Inc. Cisco CallManager documentation.
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/index.htm.
Cisco Systems, Inc. Cisco 7800 Series Media Convergence Servers overview.
http://www.cisco.com/en/US/partner/products/hw/voiceapp/ps378/index.html.
1-22
Lesson 1-2
Identifying Cisco CallManager

Cluster and Deployment
Options
Overview
To ensure the same service availability that the traditional voice network provides, it is critical
to build redundancy and failover capabilities into the IP telephony network design. The primary
ways to achieve these capabilities are to cluster Cisco CallManager servers and to follow
recommended design and deployment practices.
This lesson discusses the Microsoft SQL cluster relationship and its impact on the Cisco
CallManager cluster and options that are available to enterprises to deploy a highly available IP
telephony network.
Objectives
Upon completing this lesson, you will be able to determine the optimum Cisco CallManager
cluster option and IP telephony deployment model for your enterprise. This ability includes
being able to meet these objectives:
Describe how the Microsoft SQL cluster relationship provides publisher database
redundancy and server failover capability
Describe the two types of communication that are used to ensure database replication and
synchronization throughout the cluster
Describe the advantages and disadvantages of two design schemes that provide
call-processing redundancy within the cluster
Identify the four supported IP telephony call-processing deployment models
Identify the major characteristics and design guidelines of a single-site IP telephony
deployment model
Identify the major characteristics and design guidelines of a multiple-site centralized

call-processing deployment model
Identify the major characteristics and design guidelines of a multiple-site distributed cluster
call-processing deployment model
Identify the characteristics, limitations, and advantages of clustering over the IP WAN
1-24
This topic describes how the Microsoft SQL cluster relationship provides database redundancy
and failover capability.

Two or more servers share
a database and support a
common group of IP
devices.
Clustering provides
redundancy for the SQL
database.
A cluster has one
publisher server and up to
eight subscriber servers.
One database on the
publisher replicates to
subscribers.
Publisher
Subscriber
Subscriber
Subscriber
CIPT1 v4.11-3
The voice network is one of the most reliable business networks because PBX vendors design
their systems to provide 99.999 percent uptime. To provide the same level of voice network
reliability for IP telephony service, you must cluster Cisco CallManager servers. A Cisco
CallManager cluster is two or more servers that share the same database and work together to
support a common group of IP telephony devices.
Clustering servers provides two important functions: It eliminates a single-server point of
failure and allows multiple devices to work together in one call-processing entity. The database
replication capability provided by Microsoft SQL Server makes clustering possible by allowing
the same database to be on multiple machines. Database replication makes it appear as if a
single machine is handling call processing and other functions and ensures that standby
processors can seamlessly step in and fulfill the functions if the primary processor fails.
You must have at least two Cisco CallManager servers to obtain this redundancy, and one of
these servers must be a publisher database server. The publisher database server manages the
only writable copy of the Microsoft SQL Server 2000 database. The subscriber database servers
maintain read-only copies of the database. You can have only one publisher server and up to
eight subscriber servers per cluster (a Microsoft SQL restriction).
When you make changes to the Cisco CallManager configuration, these changes are written
directly to the publisher server. The publisher then replicates these changes to the subscriber
servers. When the publisher server is offline, the Microsoft SQL Server 2000 database
automatically locks, and thus prevents further database changes. The IP telephony network
continues to operate, but you will not be able to add or configure any devices that are managed
by Cisco CallManager.
1-25
When the publisher is down, the subscribers store Call Detail Records (CDRs) until the
publisher comes back online, and then the subscribers update the publisher with the CDRs.
In Cisco CallManager Release 3.3 and later, a cluster is capable of handling approximately
30,000 Cisco IP Phones. This cluster limitation does not restrict the size of the voice over IP
(VoIP) network. By creating additional clusters, you can increase the network size. Intercluster
trunks allow devices to communicate between cluster boundaries.
1-26
This topic examines the two types of intracluster communication.
Microsoft SQL
Database
Intracluster
Run-Time Data
Publisher
Subscriber
Subscriber
Subscriber
Cluster Determination
Device Registration
and Redundancy
CIPT1 v4.11-4
This figure illustrates the two types of intracluster communication: Microsoft SQL Server 2000
database replication and Cisco CallManager run-time data.
Database replication: During normal operation, all of the Cisco CallManager servers in a
cluster read data from and write data to the publisher database. Periodically, the publisher
automatically updates the backup copies of the database. If the publisher database becomes
unavailable, the various Cisco CallManager servers in the cluster continue to operate from
their local backup copies of the database. All data entry to the publisher database is denied
if the link to the publisher, or the publisher itself, is down. When the publisher database is
restored, normal operations resume.
Run-time data: The second type of intracluster communication is run-time data, which is
used for registration of Cisco IP Phones, gateways, and digital signal processor (DSP)
resources. Run-time data is shared with all of the members of the cluster and ensures the
optimum routing of calls between members of the cluster and the associated gateways.
When a device (such as a Cisco IP Phone) registers with its primary Cisco CallManager
server, the primary updates all of the other Cisco CallManager servers in the cluster. After
registration, the device sends a TCP keepalive message to the primary server every 30
seconds and sends a TCP connect message to its secondary Cisco CallManager server.
When the Cisco IP Phone detects the failure of its TCP keepalive message with the primary
Cisco CallManager server, the device attempts to register with its secondary Cisco
CallManager server. The secondary CallManager server accepts the registration from the
device and announces the new registration (through intracluster run-time communication)
to all of the Cisco CallManager servers in the cluster. The device initiates a TCP keepalive
message to the secondary Cisco CallManager server (the new primary of the device) and
sends a TCP connect message to a tertiary Cisco CallManager server (the new secondary of
the device).
1-27
Cluster Redundancy Designs
This topic examines two cluster designs that provide call-processing redundancy.
1:1 Redundancy Design

Primary
Secondary/
Backup
2500 IP Phones
(5000 Device Units)
Cisco MCS 7835
High availability (upgrade)

Increased server count
Simplified configuration
5000 IP Phones
(10,000 Device Units)
Primary
1 to 2500
Backup
Cisco MCS 7835
Cisco MCS 7835
Publisher and
TFTP Server
(Not Req. <1000)
10,000 IP Phones
Publisher and
TFTP Server
Backups
1 to
2500
2501 to
5000
Publisher and
TFTP Server
Backups
Backups
1 to
2500
2501 to
5000
5001 to
7500
7501 to
10,000
CIPT1 v4.11-5
In a 1:1 Cisco CallManager redundancy deployment design, you can have a dedicated backup
server for each primary server. This design guarantees that Cisco IP Phone registrations will
never overwhelm the backup servers, even if multiple primary servers fail. However, the 1:1
redundancy design considerably limits the maximum cluster size and is not cost-effective.
Each cluster must also have a designated TFTP server. Depending on the number of devices
that a server is supporting, you can combine this TFTP server functionality with the publisher
or subscriber Cisco CallManager servers, or you can deploy the TFTP functionality on a
separate, standalone server. The TFTP server is responsible for delivering IP Phone
configuration files to each telephone, along with streamed media files, such as music on hold
(MOH) and ring files; therefore, the TFTP server can experience a considerable network and
processor load.
In this example, a Cisco 7835 Media Convergence Server (MCS) is used because each Cisco
CallManager server installed on that platform supports a maximum of 2500 Cisco IP Phones. A
single Cisco CallManager is the primary server, with a secondary server acting as a dedicated
backup. The primary or backup server can also serve as the Microsoft SQL publisher and the
TFTP server in smaller IP telephony deployments (fewer than 1000 IP Phones).
When you increase the number of IP Phones, you must increase the number of Cisco
CallManager servers that are required to support the telephones. Some network engineers may
consider the 1:1 redundancy design excessive, because a well-designed network is unlikely to
lose more than one primary server at a time. With the low possibility of server loss and the
increased server cost, many network engineers elect to use a 2:1 redundancy design.
1-28
2:1 Redundancy Design

Primary
Secondary/
Backup
2500 IP Phones
(5000 Device Units)
Cisco MCS 7835
Cost-efficient redundancy
Service impacted during upgrade
5000 IP Phones
Primary
1 to 2500
Backup
Cisco MCS 7835
Cisco MCS 7835
Publisher and
TFTP Server
(Not Req. <1000)
10,000 IP Phones
Publisher and
TFTP Server
Backup
1 to
2500
2501 to
5000
Publisher and
TFTP Server
Backup
Backup
1 to
2500
2501 to
5000
5001 to
7500
7501 to
10,000
CIPT1 v4.11-6
In a 2:1 Cisco CallManager redundancy deployment design, you have a dedicated backup
server for every two primary servers. Although this design offers some redundancy, there is the
risk of overwhelming the backup server if multiple primary servers fail. In addition, upgrading
the Cisco CallManager servers can cause a temporary loss of service because you must reboot
the Cisco CallManager servers after the upgrade is complete.
Network administrators use this 2:1 redundancy model in most IP telephony deployments
because of the reduced server costs. If you are using a Cisco MCS 7835 (shown in the figure),
that server is equipped with redundant, hot-swappable power supplies and hard drives. When
you properly connect and configure these servers, it is unlikely that multiple primary servers
will fail at the same time, which makes the 2:1 redundancy model a viable option for most
businesses.
1-29
Call-Processing Deployment Models
This topic lists the call-processing deployment models that Cisco IP telephony supports.
Deployment Models
Supported IP telephony deployment models:
Single-site deployment
Multisite WAN with centralized call processing
Multisite WAN with distributed call processing
Defining characteristics of each:
Type of traffic that is carried over the WAN
(data only or data and voice)
Location of call-processing agent
Size of the deployment
CIPT1 v4.11-7
This figure illustrates the types of deployment models that Cisco Systems supports. Each model
differs in three areas: type of traffic that is carried over the WAN, location of the callprocessing agent, and size of the deployment. Cisco IP telephony supports these deployment
models:
Single-site
Multisite with centralized call processing
Multisite with distributed call processing
1-30
Single-Site Deployment
This topic describes the single-site deployment model.
Single Site: Overview

Cisco CallManager
servers, applications,
and DSP resources at
same physical location
IP WAN (if one) used for
data traffic only;
PSTN used for all
external calls
Supports approximately
30,000 IP Phones per
cluster
Applications
Cisco
CallManager
Cluster
PSTN
CIPT1 v4.11-8
In a single-site deployment model, all Cisco CallManager servers applications, and DSP
resources are in the same physical location. You can implement multiple clusters and
interconnect them through intercluster trunks if you need to deploy more IP Phones in a singlesite configuration. Gateway trunks that connect directly to the Public Switched Telephone
Network (PSTN) handle external calls. If an IP WAN exists between sites, it is used to carry
data traffic only; no telephony services are provided over the WAN.
Use this model for a single campus or site with fewer than 30,000 lines.
1-31
Single Site: Design Guidelines

Understand the current calling patterns within the
enterprise.
Use the G.711 codec; DSP resources can be
allocated to other functions, such as conferencing
and MTP.
Off-net calls should be diverted to the PSTN or
sent to the legacy PBX.
Choose a uniform gateway for PSTN use.
Deploy the recommended network infrastructure.

Do not oversubscribe the Cisco CallManager and
clustering capability.
CIPT1 v4.11-9
Single-site deployment is a subset of the distributed and centralized call-processing model. This
deployment requires that you adhere to the recommended best practices specific to this model
for future scalability. When you develop a stable, single-site infrastructure that is based on a
common infrastructure philosophy, you can easily expand the IP telephony system applications,
such as video streaming and videoconferencing, to remote sites.
These are the guidelines for single-site deployments:
You must understand the current calling patterns within the enterprise. How and where are
users making calls? How many calls are intersite or interbranch versus intrasite? If calling
patterns dictate that most calls are intrasite, use the single-site model to deploy IP
telephony and make use of the relatively inexpensive PSTN. This design also simplifies the
dial plans and avoids provisioning dedicated bandwidth for voice in the IP WAN.
The G.711 coder-decoder (codec) should be used. The call will stay in the LAN, and G.711
is a simple mechanism for deployment. It does not require dedicated DSP resources for
transcoding (which means converting between codec types, such as between G.711 and
G.729), and older voice-mail systems may support only G.711. You can allocate these DSP
resources to other functions, such as conferencing and Media Termination Point (MTP).
Although the 64 kpbs per-call bandwidth that G.711 consumes is higher than that of all
other codecs, it is not a concern in this design because the call is not traversing the WAN,
where bandwidth is generally limited.
All off-net calls will be diverted to the PSTN or sent to the legacy PBX for call routing if
the PSTN resources are being shared during migratory deployments.
Use Media Gateway Control Protocol (MGCP) gateways for the PSTN if H.323
functionality is not required. Centralize the gateway functions using H.323 gatekeepers
when deploying multiple clusters, rather than using MGCP gateways.
Deploy the recommended network infrastructure for high-availability connectivity options
for telephones (inline power), quality of service (QoS) mechanisms, and other services.
1-32
Do not oversubscribe Cisco CallManager to scale larger installations. In prior software

releases, Cisco used various schemes to allow the capacity of a system to be calculated
using device weights, busy hour call attempt (BHCA) multipliers, and dial plan weights.
With Cisco CallManager Release 4.0, this scheme has been replaced by a capacity tool to
allow for more accurate planning of the system. The capacity planning tool is currently
available only to Cisco employees. If your system does not meet the guidelines found in the
Cisco IP Telephony Solution Network Reference Design, or if you consider the system to be
more complex and would like to verify the capacity, please contact your Cisco Systems
engineer. The Cisco IP Telephony Solution Reference Network Design (SRND) is found at:
http://www.cisco.com/univercd/cc/td/doc/solution/esm/.
1-33
Multisite WAN with Centralized Call Processing
This topic examines the multisite WAN with centralized call-processing deployment model.
Multisite Centralized Call Processing:

Overview
Applications
Cisco
CallManager
Cluster
PSTN
SRST-Enabled
Router
IP WAN
Branch A
Headquarters
Cisco CallManager at central site; applications and
DSP resources centralized or distributed
IP WAN carries voice traffic and call control signaling
Supports approximately 30,000 IP Phones per cluster
Call admission control (limit number of calls per site)
Survivable remote site telephony (SRST) for remote branches
Automated alternate routing (AAR) used if WAN bandwidth is
exceeded
Branch B
CIPT1 v4.11-10
The figure illustrates the multisite centralized call-processing deployment model with a Cisco
CallManager cluster at a central site and a connection to several remote sites through a
QoS-enabled IP WAN. The remote sites rely on the centralized Cisco CallManager cluster to
handle call processing. Applications such as voice mail and interactive voice response (IVR)
systems usually reside at the central site, thus reducing the overall cost of ownership and
centralizing administration and maintenance. However, this design is not a requirement.
The WAN connectivity options include the following:
Leased lines
Frame Relay
ATM
ATM to Frame Relay Service InterWorking (SIW)
Routers that reside at WAN edges require QoS mechanisms, such as priority queuing and
traffic shaping, to protect voice traffic from data traffic across the WAN (where bandwidth is
typically scarce).
To avoid oversubscribing the WAN links with voice traffic (thus causing deterioration of the
quality of established calls), the network may need a call admission control scheme. With the
introduction of Cisco CallManager Release 3.3, centralized call-processing models can take
advantage of automated alternate routing (AAR) features. AAR allows Cisco CallManager to
dynamically reroute a call over the PSTN if the call exceeds the WAN bandwidth.
1-34
You can provide PSTN access for the voice network through a variety of Cisco gateways.
When the IP WAN is down, the users at remote branches can dial an access code and place
their calls through the PSTN, or the Cisco Survivable Remote Site Telephony (SRST) feature
that is available for Cisco IOS gateways can provide call processing during the outage.
ISDN can also provide backup data connectivity during WAN failures; however, voice traffic
should not use the ISDN links because these interfaces do not support the required QoS
features.
Multisite Centralized Call Processing:

Design Guidelines
Installations adopting the centralized
call-processing deployment model are limited to
hub-and-spoke topologies.
SRST on the branch router limits remote offices to
a maximum of 480 IP Phones when using a Cisco
7200 Series router.
CIPT1 v4.11-11
Follow these best-practice guidelines when deploying a centralized call-processing model:

Installations adopting the centralized call-processing deployment model are limited to huband-spoke topologies because the locations-based call admission control mechanism used
in centralized call processing deployments records only the available bandwidth in and out
of each location.
There is no limit to the number of IP Phones at each individual remote branch. However,
the capability that is provided by the SRST feature in the branch router limits remote
branches to 480 Cisco IP Phones on a Cisco 7200 Series router during failover. Smaller
platforms have lower limits.
1-35
Multisite WAN with Distributed Call Processing

This topic examines distributed multisite call-processing design.
Multisite Distributed Call Processing:

Overview
Cisco
CallManager
Cluster
Applications
Cisco
CallManager
Cluster
GK
Headquarters
Applications
PSTN
IP WAN
Gatekeeper
Cisco CallManager and applications located

at each site
IP WAN does not carry call control signaling
Scales to hundreds of sites
Transparent use of the PSTN if the IP WAN

is unavailable
Branch A
Cisco
CallManager
Cluster
Applications
Branch B
CIPT1 v4.11-12
A multisite distributed call-processing deployment has one or more call-processing agents at

each site, and each site has its own Cisco CallManager cluster. You can trunk these sites
together through an IP WAN.
Depending on your network design, a distributed call-processing site may consist of the
following:
A single site with its own call-processing agent, which may be a Cisco CallManager or a
third-party call agent
A centralized call-processing site (and all of its remote sites) that the network views as a
single site for distributed call processing
A legacy PBX with a VoIP gateway or a legacy PBX that is attached using a time-division
multiplexing (TDM) interface to a VoIP gateway
You can interconnect all distributed call-processing sites through an IP WAN. Cisco considers
a site that is connected only through the PSTN to be a standalone site.
The WAN connectivity options include the following:
Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN)
Voice and Video Enabled IPSec VPN (V3PN)
Leased lines
Frame Relay
ATM
ATM to Frame Relay SIW
1-36
Multisite distributed call processing allows each site to be completely self-contained. In the
event of an IP WAN failure or insufficient bandwidth, the site does not lose call-processing
service or functionality. Cisco CallManager simply sends all calls between the sites across the
PSTN.
In summary, the main benefits of this deployment model are as follows:
Cost savings when you are using the IP WAN for intersite calls
Toll-bypass savings when you are using remote gateways to drop off into the PSTN
(known as tail end hop off, or TEHO)
No loss of functionality during an IP WAN failure
Scalability to hundreds of sites
Multisite Distributed Call Processing:

Design Guidelines
Use of Hot Standby Router Protocol (HSRP)
gatekeeper pairs is currently recommended.
Use of a single WAN codec is currently
recommended.
Use a logical hub-and-spoke topology for the

gatekeeper.
Gatekeeper networks scale to hundreds of sites.
CIPT1 v4.11-13
The multisite WAN with distributed call-processing deployment model is a superset of the
single-site and multisite WAN with centralized call-processing models. You should follow the
best practices guidelines for single-site and multisite deployments in addition to those listed
here, which are specific to this deployment model.
The gatekeeper or Session Initiation Protocol (SIP) proxy servers are among the key elements
in the multisite WAN with distributed call processing. Both provide dial plan resolution, with
the gatekeeper also providing call admission control.
1-37
A gatekeeper is an H.323 device that provides call admission control and E.164 dial plan
resolution. Additional gatekeeper guidelines include the following:
It is recommended that you use alternate gatekeeper support to provide a gatekeeper
solution with high availability. It is also recommended that you use multiple gatekeepers to
provide spatial redundancy within the network.
It is recommended that you use a single WAN codec. This design makes capacity planning
easy and does not require you to overprovision the IP WAN to allow for worst-case
scenarios.
Use a logical hub-and-spoke topology for the gatekeeper. A gatekeeper can manage the
bandwidth into and out of a site or between zones within a site, but it is not aware of the
topology.
Gatekeeper networks can scale to hundreds of sites, and the design is limited only by the
hub-and-spoke topology.
Also include information on SIP proxy servers.
SIP devices provide resolution of E.164 numbers as well as SIP uniform resource identifiers
(URIs) to enable endpoints to place calls to each other. Cisco CallManager supports the use of
E.164 numbers only.
The following best practices apply to the use of SIP proxies:
Provide adequate redundancy for the SIP proxies.
Ensure that the SIP proxies have the capacity for the call rate and number of calls required
in the network.
For more detail on bandwidth capacity planning and call admission control for each
deployment model, refer to the Cisco IP Telephony Solution Reference Network Design
(SRND) for Cisco CallManager 4.0 at:
http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/products_implementation_des
ign_guide_book09186a00802c370c.html.
1-38
This topic examines clustering over the IP WAN.
Clustering over the IP WAN: Overview

Cisco
CallManager
Cluster
Voice-Mail
Server
Voice-Mail
Server
IP Phones
Los Angeles
IP Phones
San Diego
CIPT1 v4.11-14
Cisco supports Cisco CallManager clusters over a WAN. Although there are stringent
requirements, this design offers these advantages:
Single point of administration for users for all sites within the cluster
Feature transparency
Shared line appearances
Extension mobility within the cluster
This design is useful for customers that require more functionality than the limited feature set
that is offered by SRST. This network design also allows remote offices to support more Cisco
IP Phones than SRST in the event that the connection to the primary Cisco CallManager is lost.
1-39
Clustering over the IP WAN: Design

Guidelines
Publisher/
TFTP
<40 ms Round-Trip Delay
QoS-Enabled Bandwidth
40-ms round-trip delay between any two Cisco

CallManager servers in the cluster
900 kbps for every 10,000 BHCAs within the cluster
Up to eight small sites using the remote failover
deployment model
Failover across WAN supported (more bandwidth)
CIPT1 v4.11-15
Although the distributed single-cluster call-processing model offers some significant

advantages, it must adhere to these strict design guidelines:
Two Cisco CallManager servers in a cluster must have a maximum round-trip delay of
40 ms between them. In comparison, high-quality voice guidelines dictate that one-way
end-to-end delay should not exceed 150 ms. Because of this strict guideline, you can use
this design only between closely connected, high-speed locations.
For every 10,000 BHCAs within the cluster, you must support an additional 900 kbps of
WAN bandwidth for intracluster run-time communication. The BHCA represents the
number of call attempts made during the busiest hour of the day.
Up to eight small sites are supported using the remote failover deployment model. Remote
failover allows you to deploy the backup servers over the WAN. Using this deployment
model, you may have up to eight sites with Cisco CallManager subscribers being backed up
by Cisco CallManager subscribers at another site.
SRST can function in this model but is not necessary. The telephones can fail over across
the WAN to other Cisco CallManager servers. This design may require significant
additional bandwidth, depending on the number of telephones at each location.
1-40
Summary
Summary
Clusters provide database redundancy. One
publisher maintains the only writable database. Up to
eight subscribers maintain read-only copies.
There are two types of intracluster communications:
database replication and run-time data.
There are two different failover models: the 1:1 model
and the 2:1 model.
Supported Cisco IP telephony deployment models
are single-site, multisite with centralized call
processing, multisite with distributed call
processing, and clustering over the IP WAN.
CIPT1 v4.11-16
Summary (Cont.)
In the single-site deployment model, the Cisco CallManager
applications and the DSP resources are at the same physical
location; the PSTN handles all external calls.
The multisite centralized model has a single call-processing
agent; applications and DSP resources are centralized or
distributed; and the IP WAN carries voice traffic and call
control signaling between sites.
The multisite distributed model has multiple independent
sites each with a call-processing agent, and the IP WAN
carries voice traffic between sites but not call control
signaling.
The benefits of clustering over an IP WAN include a unified
dial plan, feature extension to all offices, the ability to handle
more phones at a remote site during failover (and the server
is local), and central administration.
CIPT1 v4.11-17
1-41
References
Cisco Systems, Inc. Cisco CallManager documentation.
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/index.htm.
Cisco Systems, Inc. Cisco IP Telephony Solution Reference Network Design (SRND) for
Cisco CallManager 4.1.
http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_1/srnd4_1/ind
ex.htm
1-42
Module 1 Summary
This topic summarizes the key points discussed in this module.
Module Summary
Deploying Cisco CallManager in an Cisco IP
telephony solution entails selecting the Cisco MCS
hardware platform, installing the Cisco
CallManager software, and performing
postinstallation procedures.
The primary redundancy designs for the cluster
are 1:1 (one backup for every primary) and 2:1.
Cost is a primary driver impacting your selection.
There are four call-processing deployment models.
These models differ based on whether call
processing is centralized or distributed and
whether the cluster is located within a single site
or dispersed across multiple sites.
CIPT1 v4.11-1
This module covered the key factors to be considered when you are initially using a Cisco
CallManager server in an IP telephony deployment. This module presented the role that Cisco
CallManager plays in the overall Cisco AVVID strategy, the Cisco CallManager hardware and
software requirements, the Cisco CallManager installation and upgrade process, and
postinstallation procedures. The module then covered how the Microsoft SQL relationship
provides redundancy and failover and the requirements, advantages, and disadvantages of
deploying a 1:1 server redundancy design versus a 2:1 redundancy design. The module ended
with a discussion of the four call-processing deployment models.
1-43
Module 1 Self-Check
Use the questions here to review what you learned in this module. The correct answers and
solutions are found in the Module 1 Self-Check Answer Key.
Q1)
Which four of the following are IP telephony deployment models that are supported by
Cisco? (Choose four.) (Source: Lesson 1-2, Identifying Cisco CallManager Cluster and
Deployment Options)
A)
B)
C)
D)
E)
Q2)
A 1:1 redundancy design offers _________. (Source: Lesson 1-2, Identifying Cisco
CallManager Cluster and Deployment Options)
A)
B)
C)
D)
Q3)
local failover
database replication
at least two servers
directory access
Which two of these are NOT functions of Cisco CallManager? (Choose two.) (Source:
Lesson 1-1, Introducing Cisco CallManager)
A)
B)
C)
D)
E)
1-44
completely self-contained individual sites

WAN bandwidth cost savings
a common dial plan across all sites
more IP Phone features during failover
scalability to hundreds of sites
Which two of the following enable the cluster to achieve redundancy? (Choose two.)
(Source: Lesson 1-2, Identifying Cisco CallManager Cluster and Deployment Options)
A)
B)
C)
D)
Q5)
increased redundancy; however, the increased server cost is often prohibitive

some redundancy; however, a server reboot is required after an upgrade
maximum uptime; however, no more than a 20-ms round-trip delay can exist
between servers
high availability; however, you may overwhelm the backup servers
A single cluster that spans multiple sites can have which two benefits compared to a
branch office in a multisite WAN with a centralized call-processing deployment?
(Choose two.) (Source: Lesson 1-2, Identifying Cisco CallManager Cluster and
Deployment Options)
A)
B)
C)
D)
E)
Q4)
a single site with one call-processing agent

multiple sites with centralized call processing
multiple sites each with its own call-processing agent
a single cluster with distributed call processing
multiple clusters with no call-processing agent
interactive voice response

signaling control
device control
dial plan
voice messaging
Q6)
Which layer of Cisco AVVID contains Cisco CallManager? (Source: Lesson 1-1,
Introducing Cisco CallManager)
A)
B)
C)
D)
Q7)
Cisco CallManager uses which of these operating systems? (Source: Lesson 1-1,
A)
B)
C)
D)
Q8)
enhances server call processing and redundancy

maximizes the number of devices in a cluster
disables the use of remote terminal services
helps prevent unauthorized access to the server
When you first install Cisco CallManager software, which CD-ROM should you use to
boot the server to determine the correct CD-ROM to insert next? (Source: Lesson 1-1,
A)
B)
C)
D)
E)
Q10)
Linux
Windows 95
Windows NT
Windows 2000
Why is it recommended that you stop IIS on the subscriber servers if it is not needed?
(Source: Lesson 1-1, Introducing Cisco CallManager)
A)
B)
C)
D)
Q9)
client
applications
call-processing
infrastructure
Cisco CallManager 4.0 Software Disk

Cisco IP Telephony Server Operating System Hardware Detection Disk
Cisco CallManager Installation, Upgrade, and Recovery Disk
Cisco IP Telephony Server Backup and Restore Disk
Cisco Extended Services and Locales Disk
If you are not using DNS, what must you configure to resolve server names? (Source:
Lesson 1-1, Introducing Cisco CallManager)
A)
B)
C)
D)
DHCP
backup server
LMHOSTS file
DNS reverse lookup
1-45
1-46
Q1)
A, B, C, D
Q2)
Q3)
C, D
Q4)
B, C
Q5)
A, E
Q6)
Q7)
Q8)
Q9)
Q10)
Module 2
Establishing an On-Cluster
Call
Overview
Numerous components and considerations are involved before you can place Cisco IP Phone
calls within the same cluster. This module discusses the various Cisco IP Phone models that
you may encounter when administering a Cisco IP telephony network and how to configure the
Cisco Catalyst switch to power Cisco IP Phones and support voice traffic. This module also
discusses how to configure Cisco CallManager to support IP Phones and users, how to make
PC-based IP phone calls, and how to use Cisco CallManager tools to bulk-add users and
devices.
Module Objectives
Upon completing this module, you will be able to configure Cisco CallManager and the Cisco
Catalyst switch to enable on-cluster calls. You will also be able add users and phones to the
Cisco CallManager database using manual configuration, auto-registration, and BAT. This
ability includes being able to meet these objectives:
Distinguish among the various Cisco IP endpoints, including IP Phones, conference
stations, and PC-based phones, and describe how they work within a Cisco IP telephony
solution
Configure Cisco CallManager system settings and use auto-registration and manual
configuration to add Cisco IP Phones to the Cisco CallManager database and assign a
directory number
Implement a Cisco Catalyst switch in an IP telephony network to provide inline power to
the IP Phones, prioritize voice traffic, and create a separate voice VLAN for IP Phones
Install and configure Cisco IP Communicator and make IP Phone calls from the PC
Use BAT and TAPS to add and auto-register Cisco IP Phones, users, and ports in bulk in an
IP telephony network
2-2
Lesson 2-1
Identifying Cisco IP Telephony

Endpoints
Overview
An important task of implementing and supporting an IP telephony deployment is managing the

end-user devices, or endpoints. You should be able to distinguish between the various Cisco IP
telephony end-user devices that you may encounter during the course of deploying and
administering a Cisco IP telephony network. In addition, understanding the boot and
registration communication between a Cisco IP Phone and Cisco CallManager is important for
understanding normal voice network operations and for troubleshooting purposes.
This lesson will explain the various models of Cisco IP Phones and how they work within a
Cisco IP telephony solution. You will learn the basic features of Cisco IP Phones, analog
adapters, and conference stations; the IP Phone power-up and registration process; and the
audio coders-decoders (codecs) that are supported by Cisco IP Phones.
Objectives
Upon completing this lesson, you will be able to distinguish among the various Cisco IP
telephony endpoints and describe how Cisco IP Phones work within a Cisco IP telephony
solution. This ability includes being able to meet these objectives:
Describe the basic features of Cisco IP Phones
List the entry-level Cisco IP Phones and their features
List the midrange and upper-end Cisco IP Phones and their features
Describe the features and functions of additional Cisco IP telephony endpoints, including
video endpoints, conference stations, expansion modules for Cisco IP Phones, PC-based
Cisco IP Phones, and analog adapters
Identify the six steps of the Cisco IP Phone startup process in the correct order
Identify the two audio codecs that are supported by Cisco IP Phones
This topic provides an overview of Cisco IP Phones and the features that are common to the
majority of Cisco IP telephony endpoints.

Cisco IP Phones have
the following
enhancements:
Display-based
User customization
Inline PoE.
Support of the G.711 and
G.729 audio codecs
CIPT1 v4.12-3
To the user, the telephone is the most visible component of the voice communications network.
Cisco IP Phones are next-generation, intelligent communication devices that deliver essential
business communications. Fully programmable, the growing family of Cisco IP Phones
provides the most frequently used business features.
The majority of Cisco IP Phones provide the following enhancements:
Display-based user interface
Straightforward user customization
Inline power over Ethernet (PoE)
Support for the G.711 and G.729 audio codecs
Each Cisco IP Phone provides toll-quality audio and does not require a companion PC. Because
it is an IP-based phone, you can install it in any location on a corporate local or wide-area IP
network.
2-4
This topic describes the entry-level Cisco IP Phones that are available and provides a brief
overview of their features.

Cisco IP Phone 7902G
Cisco IP Phone 7910G+SW Cisco IP Phone 7912G
Basic-featured IP Phones for low-to-medium

telephone use
Single line/DN
Display-based (except Cisco 7902G)
Message waiting indicator
CIPT1 v4.12-4
Cisco has produced a number of entry-level IP Phones for a variety of business functions.
Depending on user requirements, these IP Phones may function well for employees or for use
only in public areas, such as lobbies or break rooms.
Entry-level Cisco phones provide the following common features:
Display-based user interface (except Cisco IP Phone 7902G)
G.711 and G.729 codec
Single line (directory number [DN])
Cisco inline power, powered patch panel, or local power option support via a power cube
(the same power supply as the Cisco IP Phone 7910, 7940, or 7960)
Visual message waiting indicator (MWI)
No speakerphone or headset port
2-5
Here is a brief description of the major features of each entry-level Cisco IP Phone:
Cisco IP Phone 7902G: The Cisco IP Phone 7902G is a single-line, entry-level, no-display
business phone with fixed feature keys that provide one-touch access to the redial, transfer,
conference, and voice-mail access features. Here is a brief description of the major features
of the Cisco IP Phone 7902G:
Ability to handle low telephone traffic
Fixed features: redial, transfer, conference, messages
Hard Hold key
Single RJ-45 connection (no internal Ethernet switch)
Cisco IP Phone 7905G and Cisco IP Phone 7912G: The Cisco IP Phone 7905G provides
single-line access and four interactive softkeys that guide a user through call features and
functions via the pixel-based liquid crystal display (LCD). Use this IP Phone for employees
who do not need a full-featured phone or for a common area such as a hallway,
manufacturing floor, break room, reception space, or office cubicle. The Cisco IP Phone
7912G includes an integrated Ethernet switch that provides LAN connectivity to a
colocated PC. Here is a brief description of the major features of the Cisco IP Phone 7905G
and Cisco 7912G:
Ability to handle low-to-medium telephone usage
Pixel-based display (approximately five lines plus softkeys and date, time, and menu
title)
Hard Hold key
Access to all standard IP Phone features through four on-screen softkeys
Support for limited Extensible Markup Language (XML) script processing
Support for Cisco Skinny Client Control Protocol (SCCP), H.323 version 2 (Cisco
7905G only), and Session Initiation Protocol (SIP; compliant with RFC 2543)
Cisco IP Phone 7910G+SW: The Cisco IP Phone 7910G+SW is for common-use areas
that require only basic features, such as dialing out, accessing 911, and intercom calls.
Locations that might benefit from these limited features include lobbies, break rooms, and
hallways. The Cisco IP Phone 7910G+SW includes a two-port switch for use in
applications where you require basic IP Phone functionality and a colocated PC. The
following is a brief description of the major features of the Cisco 7910G+SW:
2-6
Ability to handle low-to-medium telephone usage
Single line with call waiting
Display area of 2 x 24 inches (5.08 x 60.96 cm)
Cisco 10BASE-T/100BASE-T, two-port Ethernet switch
Basic features: line, hold, transfer, settings, messages, conference, forward, speed
dial, redial
Adjustable foot stand (flat to 60 degrees)
Basic and optional wall mounting
This topic describes the midrange and upper-end Cisco IP Phones and their features.

10/100/1000
Full-featured IP Phones for medium-to-high

telephone use
Multiline
Large pixel-based displays
Integral switch
Built-in headset and high-quality speakerphone
Multiprotocol-capable (SCCP, SIP, MGCP)
CIPT1 v4.12-5
Cisco designed the IP Phones 7940G, 7960G, and 7970G and 7971G-GE to meet the demand
for a corporate-level, full-featured IP Phone for medium-to-high telephone use. A description
of features that are common to all three phones follows:
Multiline capability
Large pixel-based displays, which allow for the inclusion of XML and future features
Integrated two-port 10/100-Mbps Ethernet switch
Built-in headset connection and quality full-duplex speakerphone (does not come with a
headset)
Information key for online help with features
A minimum of 24 user-adjustable ring tones
Adjustable foot stand (flat to 60 degrees) and basic or wall mounting
SCCP, Media Gateway Control Protocol (MGCP), and SIP support
XML service support
An EIA/TIA-232 port for options, such as line expansion and security access
2-7
Additional details of these phone models follow:

Cisco IP Phone 7940G: The Cisco IP Phone 7940G is for medium traffic and has these
features:
Ideal for transaction workers who use cubicle phones
Two lines and programmable feature buttons, and four interactive softkeys
PoE compatible (Cisco prestandard PoE)
Cisco IP Phone 7960G: The Cisco IP Phone 7960G is for high or busy telephone traffic
and has these features:
Ideal for professionals or managers
Six lines and programmable feature buttons, and four interactive softkeys
PoE compatible (Cisco prestandard PoE)
Cisco IP Phone 7970G:
Ideal for executives, decision makers, and environments with no PCs
Eight lines and programmable feature buttons, and five interactive softkeys
Color display with touchscreen
3.5-mm stereo jack sockets for connection to PC-style speakers or headphones, and
microphone
PoE compatible (both Cisco prestandard PoE and IEEE 802.3af PoE)
Advanced XML development platform for more dynamic applications
Cisco IP Phone 7971G-GE:
2-8
Delivers Gigabit Ethernet bandwidth to the desktop with an integrated

10/100/1000-Mbps switch
Feature identical to the Cisco IP Phone 7970G
PoE compatible (IEEE 802.3af PoE only; does not support Cisco prestandard PoE)
This topic describes the features and functions of additional Cisco IP telephony endpoints.
Cisco VT Advantage
Cisco ATA 186 and 188

Cisco Conference Station 7936
Cisco 7914 Expansion Module
Cisco IP Communicator
Cisco Wireless IP Phone 7920

CIPT1 v4.12-6
Cisco provides a complete portfolio of IP endpoints to meet business needs for conferencing,
wireless voice communications, PC-based voice calls, and connecting analog phones to the
VoIP network. These products are as follows:
Cisco VT Advantage: Cisco VT Advantage is a video telephony solution consisting of the
Cisco VT Advantage software application and Cisco VT Camera, a video telephony
Universal Serial Bus (USB) camera. With the Cisco VT Camera attached to a PC that is
colocated with a Cisco IP Phone, users can place and receive video calls on their enterprise
IP telephony network. Users make calls from their Cisco IP Phones using familiar phone
interfaces, but calls are enhanced with video on a PC, without requiring any extra button
pushing or mouse clicking. When registered to Cisco CallManager, the Cisco VT
Advantage-enabled IP Phone has the features and functionality of a full-featured IP
videophone. System administrators can provision a Cisco IP Phone with Cisco VT
Advantage as they would any other Cisco IP Phone, which can greatly simplify deployment
and management.
Cisco IP Conference Station 7936: The Cisco IP Conference Station 7936 is a fullfeatured, IP-based, full-duplex, hands-free conference phone for use on desktops, in offices,
and in small-to-medium conference rooms. The Cisco IP Conference Station 7936 offers
external microphone ports, optional external microphone kit, audio-tuned speaker grill, and
a backlit LCD display. The optional microphone kit includes two microphones with 6-foot
(1.8288-m) cords so that you can place the microphones across a 12-foot (3.6576-m) area,
effectively expanding to a suggested conference room size of 20 x 30 feet (6.096 x
9.144 m). The backlit LCD display improves visibility in low light conditions. The display
font size is also adjustable for improved distant viewing.
2-9
Cisco IP Communicator: The Cisco IP Communicator is a Microsoft Windows softwarebased application that delivers enhanced telephony support through personal computers.
This application endows computers with the functionality of Cisco IP Phones and provides
high-quality voice calls on the road, in the office, or from wherever users may have access
to the corporate network. Cisco IP Communicator has an intuitive design, is easy to use,
and delivers convenient access to a host of features, including eight lines and five softkeys.
Cisco IP Communicator offers handset, headset, and high-quality speakerphone modes.
Cisco Analog Telephone Adaptor (ATA) 186 and 188: The Cisco ATA 186 and Cisco
ATA 188 interface regular telephones with your IP-based telephony network. These
adapters are useful for customers that have existing analog devices, such as fax machines or
telephones, that they do not want to replace after they have migrated to VoIP. The Cisco
ATA 186 provides two voice ports, each with its own independent telephone number, and a
single 10BASE-T Ethernet port for network connectivity. The Cisco ATA 188 provides
two voice ports and two 10/100-Mbps Ethernet connections, which allows for network
connectivity and the ability to colocate a network device with the analog voice equipment.
Cisco IP Phone 7914 Expansion Module: The Cisco IP Phone 7914 Expansion Module
extends the capabilities of the Cisco IP Phone 7960 with additional buttons and an LCD
display. The Cisco IP Phone 7914 helps administrative assistants and others who must
monitor, manage, and cover the various status of a number of calls beyond the six-line
capability of the Cisco 7960. This expansion module enables you to add 14 buttons to the
existing 6 buttons of the Cisco IP Phone 7960, increasing the total number of buttons to 20
with one module or 34 with two modules. You can use up to two Cisco 7914 Expansion
Modules with a Cisco IP Phone 7960.
Cisco Wireless IP Phone 7920: The Cisco Wireless IP Phone 7920 is an easy-to-use IEEE
802.11b wireless IP phone that provides comprehensive voice communications in
conjunction with Cisco CallManager and the Cisco Aironet 1200, 1100, 350, and 340
Series of Wi-Fi (IEEE 802.11b) access points. The Cisco Wireless IP Phone 7920 is
designed for ease of use, with a pixel-based display to access calling features and two
softkeys, a four-way rocker switch, a Hold key, a Mute key, and a Menu key that allows
quick access to information such as directories, call history, and phone settings.
2-10
This topic describes the process that a Cisco IP Phone uses to boot and register with the Cisco
CallManager.

Cisco
CallManager
DHCP
Cisco TFTP
6
1
1.
2.
3.
4.
5.
6.
IP Phone obtains power from the switch

Phone loads stored image
Switch provides VLAN information to IP
Phone
Phone sends DHCP request; receives IP
information and TFTP server address
IP Phone gets configuration from TFTP
server
IP Phone registers with Cisco
CallManager server
CIPT1 v4.12-7
This figure provides an overview of the startup process for a Cisco IP Phone if you are using a
Cisco Catalyst switch that is capable of providing Cisco prestandard Power over Ethernet
(PoE).
1. Obtain power from the switch: When a Cisco IP Phone is connected to a Cisco Catalyst
switch model that is capable of providing inline power (called Power over Ethernet (PoE)),
the switch automatically detects an unpowered phone and sends power down the Ethernet
cable to the IP Phone. The details of how the switch detects an unpowered IP Phone and
how it delivers power to the IP Phone are covered in the lesson Configuring Cisco
Catalyst Switches.
2. Load the stored phone image: The Cisco IP Phone has nonvolatile flash memory in which
it stores firmware images and user-defined preferences. At startup, the phone runs a
bootstrap loader that loads a phone image stored in flash memory. Using this image, the
phone initializes its software and hardware.
3. Configure the VLAN: After the IP Phone receives power and boots, the switch sends a
Cisco Discovery Protocol packet to the IP Phone. This Cisco Discovery Protocol packet
provides the IP Phone with voice VLAN information, if that feature has been configured.
4. Obtain the IP address and TFTP server address: Next, the IP Phone broadcasts a
request to a DHCP server. The DHCP server responds to the IP Phone with a minimum of
an IP address, a subnet mask, and the IP address of the Cisco TFTP server.
2-11
5. Contact the TFTP server for configuration: The IP Phone then contacts the Cisco TFTP
server. The TFTP server has configuration files (.cnf file format or .cnf.xml) for telephony
devices, which define parameters for connecting to Cisco CallManager. The TFTP server
sends the configuration information for that IP Phone, which contains an ordered list of up
to three Cisco CallManagers. In general, any time that you make a change in Cisco
CallManager that requires a phone (device) to be reset, a change has been made to the
configuration file of that phone. If a phone has an XML-compatible load, it requests an
XMLDefault.cnf.xml configuration file; otherwise, it requests a .cnf file.
6. If you have enabled auto-registration in Cisco CallManager, the phones access a
default configuration file (sepdefault.cnf.xml) from the TFTP server. If you have
manually entered the phones into the Cisco CallManager database, the phone accesses a
.cnf.xml file that corresponds to its device name. The .cnf.xml file also contains the
information that tells the phone which image load that it should be running. If this image
load differs from the one that is currently loaded on the phone, the phone contacts the
TFTP server to request the new image file, which is stored as a .bin file.
7. Register with Cisco CallManager: After obtaining the file from the TFTP server, the
phone attempts to make a TCP connection to a Cisco CallManager, starting with the
highest-priority Cisco CallManager in its list.
2-12
This topic describes the codecs that are supported by Cisco IP Phones.
Audio codecs:
Potentially able to
compress audio signals
Cisco IP Phones support:

G.711: 64 kbps
G.729: 8 kbps
CIPT1 v4.12-8
Before a VoIP device is able to stream audio, the analog audio signal must be converted to a
digitized format. This is accomplished by an audio codec, which digitizes the audio input at the
transmitting end and converts the digital stream back to analog audio at the receiving end.
Because converted audio streams can consume a significant amount of bandwidth, many of the
audio codecs also provide a level of compression, which can considerably reduce the
bandwidth that they consume. However, compression can cause degraded voice quality, which
is why the different audio codecs offer different levels of compression.
The International Telecommunication Union Telecommunication Standardization Sector
(ITU-T) standards committee specifies several standards (called recommendations) for audio
codecs. Cisco IP Phones natively support two primary codecs: G.711 and G.729. The G.711
and G.729 codecs deliver relatively equal sound quality (both considered toll quality), with
G.711 scoring slightly higher than G.729 in a mean opinion score (MOS) test. Because of this
similarity, some network administrators choose to operate an entirely G.729-based network,
while others choose to implement G.729 over the WAN and G.711 on the LAN.
Although this configuration is ideal for many network environments, you may eventually
encounter a codec mismatch. A codec mismatch occurs when two devices cannot negotiate a
common codec or when the network administrator has forbidden the use of their common
codec, such as using G.711 over the WAN. Regardless of the cause, you now have a need for
transcoding. Transcoding resources perform conversions between the audio codecs. These
resources are often costly and can introduce significant delay and quality degradation into your
IP telephony network. When designing a voice network, you should attempt to limit the amount
of transcoding that takes place between devices.
2-13
Summary
Summary
Cisco IP Phones are display-based, support
customization, have inline power, and provide
support for the G.711 and G.729 audio codecs.
Entry-level Cisco IP Phones include the Cisco IP
Phone 7902G, 7905G, 7910G+SW, and 7912G.
Midrange and upper-end Cisco IP Phones include
the Cisco IP Phone 7940G, 7960G, 7970G, and
7971G-GE.
CIPT1 v4.12-9
Summary (Cont.)
Additional IP telephony devices include the Cisco
Conference Station 7936, Cisco IP Communicator,
Cisco ATA 186 and 188, and Cisco 7914 Expansion
Module.
An IP Phone follows a specific process each time
that it boots.
Audio codecs convert analog voice signals to a
digitized stream and compress the output to save
bandwidth. Cisco IP Phones support the G.711 and
G.729 codecs.
2-14
CIPT1 v4.12-10
References
Cisco Systems, Inc. Cisco 7900 Series IP Phones product index page with links to product
models, technical documentation, and Software Center.
http://www.cisco.com/en/US/products/hw/phones/ps379/index.html.
Cisco Systems, Inc. Cisco IP Phones and Services documentation.
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/index.htm.
2-15
2-16
Lesson 2-2
Configuring Cisco
CallManager to Support IP
Phones
Overview
Configuring Cisco CallManager to support Cisco IP Phones is a critical part of implementing a

Cisco IP telephony network. This lesson prepares you for the initial IP Phone setup and
configuration and for the maintenance of existing IP Phones.
This lesson describes the Cisco CallManager configuration to support Cisco IP Phones. This
lesson will teach you how to configure Cisco CallManager to manually and automatically add
IP Phones and assign directory numbers (DNs). You will also learn how to configure device
pools to provide a convenient way to define a set of common characteristics that can be
assigned to devices, such as date or time zone, codec use, and other functionalities.
Objectives
Upon completing this lesson, you will be able to configure Cisco CallManager to support Cisco
IP Phones, including server configuration, device pools, phone button templates, and DNs. This
ability includes being able to meet these objectives:
Configure Cisco CallManager to eliminate IP Phone reliance on DNS
Configure device pools in Cisco CallManager to define sets of common characteristics for
IP Phones
Use Cisco CallManager default phone button templates and create new templates to assign
a common button configuration to a large number of IP Phones
Manually add and configure IP Phones in Cisco CallManager and assign DNs
Configure Cisco CallManager to support IP Phone auto-registration to automatically issue
directory numbers to new IP Phones
Server Configuration
This topic discusses server configuration in Cisco CallManager Administration.
Removing DNS Reliance
Enables Cisco IP Phones and other Cisco CallManager-controlled

devices to contact the Cisco CallManager without resolving a DNS name
CIPT1 v4.12-3
Changing the name of the selected server to the IP address of the server in the Cisco
CallManager Administration window is the first step in configuring Cisco CallManager to
support Cisco IP Phones.
Renaming the server to the IP address has the following benefits:
It allows IP Phones and other devices to find Cisco CallManager on the network without
having to query the Domain Name System (DNS) server to help resolve the server name to
an IP address.
It prevents the IP telephony network from failing if the IP Phones lose the connection to the
DNS server.
It decreases the time that is required when a device attempts to contact Cisco CallManager.
Complete these steps to eliminate DNS reliance:
Step 1
In Cisco CallManager Administration, choose System > Server.

The Find and List Servers window appears.
Step 2
Click a server name.

The Server Configuration window appears.
Step 3
2-18
Remove the hostname and enter the IP address for the server in the Host Name/IP
Address field. Click Update.
Configuring Device Pools
This topic describes device pool configuration.
Device Pool Configuration
CIPT1 v4.12-4
Device pools provide a convenient way to define a set of common characteristics that can be
assigned to devices, such as IP Phones, instead of assigning individual characteristics to
individual phones. Device pools enable you simply assign the phone to the device pool so that
the phone automatically inherits the common configuration items. You must configure the
device pool for Cisco IP Phones before adding them to the network.
To create a new device pool, you must first create (or use default settings where applicable) the
following minimal mandatory components:
Cisco CallManager group
Date/time group
Region
Softkey template
Cisco Survivable Remote Site Telephony (SRST) reference: The SRST Reference field
allows you to specify the IP address of the Cisco SRST router. Cisco SRST enables routers
to provide call-handling support for Cisco IP phones when they lose their connection to
remote Cisco CallManager installations or when the WAN connection is down.
These components (except for the SRST reference) are covered later in this lesson. SRST is
covered later in the course.
The device pool combines all of the individual configurations that you have created into a
single entity. You will eventually assign this entity to individual devices, such as IP Phones.
This process will configure these devices with most of the configuration elements that they
need to operate efficiently in your IP telephony network.
2-19
Complete these steps to create the device pool:

Step 1
Choose System > Device Pool. The Find and List Device Pools window opens.
Step 2
Click the Add a New Device Pool link to open the Device Pool Configuration
window. Choose, at a minimum, the Cisco CallManager group, date/time group,
region, and softkey template.
Example: Device Pool Configuration

Configuring 100 different Cisco IP Phones to use the Arizona time zone, the English language,
and the classical-style music on hold (MOH) option is tedious. Instead, you can create a device
pool, named Arizona, that configures the correct time zone, language, and MOH, and you can
make a single assignment of the Arizona device pool to each IP Phone.
The configuration table here shows the device characteristics that you can specify for a device
pool. You must configure these items before you configure a device pool if you want to choose
the items for the device pool.
2-20
Device Pool Configuration Items

Field
Description
Device Pool Name*
Describes a name for the device pool.
Cisco CallManager Group*
Selects a redundancy group for the device pool. This

redundancy group can contain a maximum of three redundant
Cisco CallManager servers.
Date/Time Group*
Assigns the correct time zone to the device.
Region*
Determines the coder-decoder (codec) selection used by the

device, depending on the end location of the call.
Softkey Template*
Defines the type and order of the softkeys that are displayed on
the liquid crystal display (LCD) of a Cisco IP Phone.
SRST Reference*
Configures SRST and selects the gateway that will support the
device if the connection to the Cisco CallManager is lost.
Calling Search Space for

Auto-Registration
Defines whom an IP Phone is able to call if it auto-registers with

the Cisco CallManager.
Media Resource Group List
Assigns media resource support to a device for functions such

as conferencing, transcoding, or MOH.
Network Hold MOH Audio Source
Selects the audio that Cisco CallManager should play when a

user presses the Transfer or Conference button on the Cisco IP
Phone.
User Hold MOH Audio Source
Selects the audio that Cisco CallManager should play when a

user presses the Hold button on the Cisco IP Phone.
Network Locale
Defines the tones and cadences that the device uses.
User Locale
Defines the language that the device uses.
Connection Monitor Duration
Defines the amount of time that the IP phone monitors its

connection to Cisco CallManager before it unregisters from
SRST and re-registers to Cisco CallManager. This is to ensure
that the link is stable (not flapping). The default for the
enterprise parameter specifies 120 seconds, which can be
modified on a device-pool basis or left at the default value.
MLPP Precedence and Preemption

Information
Used to manage Multilevel Precedence and Preemption

(MLPP) settings:
MLPP Indication: Specifies whether devices in the device
pool that are capable of playing precedence tones will use
the capability when the devices plan an MLPP precedence
call
MLPP Preemption: Specifies whether devices in the
device pool that are capable of pre-empting calls in
progress will use the capability when the devices plan an
MLPP precedence call
MLPP Domain: A hexadecimal value for the MLPP domain
that is associated with the device pool
Note
An asterisk (*) Indicates a required field.
2-21
If you make changes to a device pool, you must reset the devices in that device pool before the
changes will take effect.
You cannot delete a device pool that has been assigned to any device or one that is used for
device defaults configuration. To find out which devices are using the device pool, click the
Dependency Records link in the Device Pool Configuration window. If you try to delete a
device pool that is in use, an error message is displayed. Before deleting a device pool that is
currently in use, you must perform one of the following tasks:
Update the devices to assign them to a different device pool.
Delete the devices that are assigned to the device pool that you want to delete.
Individual components of a device pool are explored in the following subtopics.
Cisco CallManager Group Configuration
CIPT1 v4.12-5
A Cisco CallManager group specifies a prioritized list of Cisco CallManager servers o register
to, with a maximum of three in the list. The first Cisco CallManager in the list serves as the
primary Cisco CallManager for devices that are assigned to that group. The other members of
the group serve as the secondary and tertiary backups. Changes to the Cisco CallManager group
affect the configuration file that is given to Cisco IP Phones by the TFTP server when they
initially boot.
Example: Cisco CallManager Group Configuration

In the figure, the Cisco CallManager group, called Arizona, has three Cisco CallManager
servers You assign the Cisco CallManager group to a device pool, and you then assign this
device pool to the Cisco IP Phone. The IP Phone uses the Arizona Cisco CallManager as its
primary Cisco CallManager, the California Cisco CallManager as its secondary, and the
Michigan Cisco CallManager as its tertiary. Cisco CallManager Administration will present an
error message if you attempt to add a fourth Cisco CallManager (for example, the EAST1A
Cisco CallManager) to the list.
2-22
Checking the Auto-Registration Cisco CallManager Group check box enables the Cisco
CallManager to place any new IP Phones that auto-register (IP Phones that are added to the
network without manual administrative configuration) into this group by default.
Complete these steps to configure a Cisco CallManager group:
Step 1
Choose System > Cisco CallManager Group. The default group that was created
by Cisco CallManager during the installation appears.
Step 2
Choose Add New Cisco CallManager Group to create a new Cisco CallManager
group.
Step 3
Move the existing Cisco CallManager servers using the Left and Right arrows, and
change the order of Cisco CallManager servers using the Up and Down arrows.
Date/Time Group Configuration
CIPT1 v4.12-6
Date/time groups define time zones for the various devices that are connected to Cisco
CallManager. You can assign each device to only one device pool. As a result, the device has
only one date/time group.
Cisco CallManager has a default date/time group called CMLocal. The CMLocal date/time
group synchronizes to the active date and time of the operating system on the Cisco
CallManager server. You can change the settings for CMLocal after installing Cisco
CallManager.
Complete these steps to configure the date/time group:
Step 1
Choose System > Date/Time Group. The default CMLocal group appears.
Step 2
Choose Add a New Date/Time Group to insert additional date/time groups as

required.
2-23
Note
For a worldwide distribution of Cisco IP Phones, you may want to create one named
date/time group for each of the 24 time zones.
Region Configuration
CIPT1 v4.12-7
When you create a region, you specify the audio codec that can be used for calls between
devices (such as IP Phones) within that region and between that region and other regions. As of
Cisco CallManager Release 4.0, you can also specify the video call bandwidth.
You can create regions to modify the codec selection for any reason; however, most network
administrators create regions based on geographical areas. The default voice codec for all calls
through Cisco CallManager is G.711. If you do not plan to use any other voice codec, you do
not need to use regions. The system will use the default region.
Example: Region Configuration

In the figure shown here, there are four regions: Arizona, California, Default, and Michigan;
the configuration of the Michigan region is displayed. If a device that is assigned to the
Michigan region calls another device in the Michigan region, the devices use the G.711 codec.
However, if a device assigned to the Michigan region calls a device that is assigned to the
Arizona region, the devices use the G.729 codec. Cisco CallManager creates the Default region
during the installation process. You can rename the Default region to a more logical name to
avoid confusion, or you can ignore it and use only regions that you have created.
Complete these steps to configure a region:
2-24
Step 1
Choose System > Region. The default region that was created during the Cisco
CallManager installation appears.
Step 2
Choose Add a New Region to configure the regions, and choose the codec and
video bandwidth as appropriate between the regions.
Softkey Template Configuration
CIPT1 v4.12-8
The Softkey Template Configuration window allows the administrator to manage the on-screen
softkeys that the Cisco IP Phones support (such as the Cisco IP Phone 7960 and 7940 models).
You can configure these softkeys with many Cisco CallManager functions and features.
Applications that support softkeys can have one or more standard softkey templates that are
associated with them; for example, Cisco IP Manager Assistant (IPMA) has the Standard IPMA
Assistant, the Standard IPMA Manager, and the Standard IPMA Manager Shared Mode softkey
templates associated with it. You cannot modify standard softkey templates. First you copy the
template and then modify the copy.
Choose Device > Device Settings > Softkey Templates to access the Softkey Template
Configuration window in Cisco CallManager Administration.
2-25
This topic discusses the configuration and application of the Cisco IP Phone button templates.

Default 7960 template
is 2 lines, 4 speed dials
Prepare for anything;
configure all possible
combinations:
1 line, 5 speed dials
3 lines, 3 speed dials
5 lines, 1 speed dial
CIPT1 v4.12-9
Creating and using templates provides a fast way to assign a common button configuration to a
large number of Cisco IP Phones. Cisco CallManager includes several default phone button
templates. When adding IP Phones, you can assign one of these templates to each IP Phone or
assign custom templates that you have created.
You must assign at least one line per IP Phone; usually this line is button 1. Depending on the
Cisco IP Phone model, you can assign additional lines. IP Phones generally have several
features, such as speed dial and call forwarding, assigned to the remaining buttons.
Before adding any IP Phones to the system, create phone button templates with all of the
possible combinations for all IP Phone models. An IP Phone model may have various
combinations; for example, a Cisco IP Phone 7960 supports six lines and can use the following
phone button template combinations:
One line, five speed dial buttons
Two lines, four speed dial buttons (default)
Three lines, three speed dial buttons
Four lines, two speed dial buttons
Five lines, one speed dial button
Six lines, no speed dial button
2-26
IP Phone Button Template Names

Use the model number, line
and speed dial settings in
the name:
7960 1-5
7960 3-3
Template updates affect the
IP Phones that use that
template
Renaming a template does
not affect the IP Phones
using that template
Cannot delete a template
assigned to one or more
devices
CIPT1 v4.12-10
Create easily recognizable naming conventions for the phone button template. A suggested best
practice is to use the model number of the Cisco IP Phone followed by the number of lines and
speed dials. For example, a phone button template named 7960 1-5 would indicate a Cisco
7960 IP Phone with one line and five speed-dial buttons.
To create a template, copy an existing template and assign a unique name to the template. You
can make changes to the default templates that are included with Cisco CallManager or to the
custom templates that you have created.
You can rename existing templates and modify them to create new ones. You can also update
custom templates to add or remove features, lines, or speed dial buttons. When you update a
template, the change affects all of the IP Phones that use it.
Renaming a template does not affect the IP Phones that use that template. All Cisco IP Phones
that use this template continue to use this template after you rename it.
You can delete IP Phone templates that are not currently assigned to any IP Phone in your
system. You cannot delete a template that is assigned to one or more devices. Currently, there is
not an easy way to query whether a template is in use or not. Before you can delete a template,
you must reassign all of the Cisco IP Phones that are using the template to a different phone
button template.
Example: Naming a Phone Button Template

If you have a special request or only a limited number of users who need three lines and three
speed dial buttons on the Cisco IP Phone 7960G, you can create a phone button template that
supports three lines and three speed dials, name the template 7960 3-3, and quickly assign the
phone button template 7960 3-3 to the IP Phones.
2-27
Manual IP Phone and Directory Number

Configuration
This topic discusses manual Cisco IP Phone and DN configuration in Cisco CallManager
Administration.
Phone and Directory Number Configuration
MAC
Address
of IP
Phone
CIPT1 v4.12-11
Manually adding new IP Phones to the network is often tedious, but it can constitute a large
part of day-to-day voice network management. The Bulk Administration Tool (BAT) allows
you to add a large number of IP Phones to the Cisco CallManager database at once, but BAT is
not appropriate for adding or modifying a single IP Phone for a new employee.
Cisco CallManager uses the IP Phone MAC address to track the phone in the voice network.
Cisco CallManager ties all IP Phone configuration settings to the IP Phone MAC address.
Before you can perform any configuration on a Cisco IP Phone through Cisco CallManager,
you must find the MAC address of that IP Phone. Use the following guidelines to locate a
MAC address:
You can find the MAC address in the text and Universal Product Code (UPC) form, which
is imprinted on the shipping box for the IP Phone. Some administrators use bar code
scanners to simplify the process of adding multiple IP Phones.
You can also find the MAC address in the text and UPC form on the back of the IP Phone,
on a sticker near the bottom.
If you boot the IP Phone, you can press the Settings button on the face of the phone. Use
the arrow keys to navigate, and choose Network Configuration. The MAC address will be
displayed on line 3 of the network configuration.
2-28
You can continue the Cisco IP Phone configuration on the Cisco CallManager configuration
after you have the MAC address of the IP Phone, as follows:
Step 1
In Cisco CallManager Administration, choose Device > Phone to open the Find and
List Phones window.
Step 2
Choose Add a New Phone in the upper-right corner of the window.
Step 3
Choose the model of the IP Phone from the drop-down menu, and click Next.
Step 4
At a minimum, you must configure the MAC Address and Device Pool fields; then
click Insert.
Step 5
Cisco CallManager prompts you to add a DN for line 1; then click OK.
Step 6
When the Directory Number Configuration window appears, enter the DN of the IP
Phone in the appropriate field, and click Insert.
2-29
Configuring IP Phone Auto-Registration
This topic describes how to configure Cisco CallManager for auto-registering Cisco IP Phones.
Auto-Registration Configuration
CIPT1 v4.12-12
Auto-registration allows Cisco CallManager to issue extension numbers to new IP Phones,

which is similar to the way in which the Dynamic Host Control Protocol (DHCP) server issues
IP addresses. When a new IP Phone boots and attempts to register with Cisco CallManager for
the first time, Cisco CallManager issues an extension number from a configured range. After
Cisco CallManager issues the extension, it records the extension number to the MAC address
mapping in the Microsoft Structured Query Language (SQL) database.
Although auto-registration simplifies the process of deploying a new IP telephony network, it is
an option that is available only in some new IP telephony deployments. Because administrators
deploy most IP telephony networks as a migration from a PBX environment, users have
existing telephone extensions. These existing telephone extensions typically map to Direct
Inward Dial (DID) numbers from the Public Switched Telephone Network (PSTN) and cannot
change. Therefore, these IP telephony deployments usually use manual configuration rather
than auto-registration.
You should carefully evaluate auto-registration before implementing it because its use can pose
a security risk to the network. Auto-registration allows anyone with physical assess to the voice
network to connect an IP phone and use it, whether authorized or not. For this reason, many
organizations, as part of their security policy, disable the use of auto-registration or use
auto-registration in a secure staging environment for initial Cisco CallManager configuration.
2-30
Complete these steps to configure the Cisco CallManager server to support auto-registration:
Step 1
From Cisco CallManager Administration, choose System > Cisco CallManager.
Step 2
From the list of Cisco CallManager servers, select the server that you want to
support auto-registration.
Step 3
Under the Auto-Registration Information Configuration section, enter the

appropriate DN range in the Starting and Ending Directory Number fields.
Step 4
Ensure that the Auto-Registration Disabled on this Cisco CallManager check box is
unchecked.
Device Defaults
CIPT1 v4.12-13
Use device defaults to set the default characteristics of each type of device that registers with a
Cisco CallManager. The device defaults for a device type apply to all auto-registered devices of
that type within a Cisco CallManager cluster. You can set the following device defaults for
each device type to which they apply:
Device load: Lists the firmware load that is used with a particular type of hardware device
Device pool: Allows you to select the device pool that is associated with each type of
device
Phone button template: Indicates the phone button template that is used by each type of
device
When a device auto-registers with a Cisco CallManager, it acquires the device default settings
for its device type. After a device registers, you can update its configuration individually to
change the device settings.
Installing Cisco CallManager automatically sets device defaults. You cannot create new device
defaults or delete existing ones, but you can change the default settings.
2-31
Complete these steps to update the device defaults:

Step 1
In Cisco CallManager Administration, choose System > Device Defaults to open

the Device Defaults Configuration window.
Step 1
In the Device Defaults Configuration window, modify the appropriate settings for
the device that you want to change.
Step 2
Click Update to save the changes in the Cisco CallManager configuration database.
Step 3
Click the Reset icon to the left of the device name to reset all the devices of that
type and load the new defaults on all Cisco CallManager servers in the cluster.
If you choose not to reset all devices of that type, only new devices that are added
after you change the device defaults receive the latest defaults.
2-32
Summary
Summary
Assigning an IP address to Cisco CallManager
eliminates IP Phone reliance on DNS.
Device pools simplify configuration by allowing you to
define sets of common characteristics for devices.
Creating and using IP Phone button templates provides
a fast way to assign a common button configuration to
a large number of IP Phones.
Manually configuring the IP Phone is appropriate when
you want to add or modify a single or a few IP Phones.
Using IP Phone auto-registration allows you to
automatically issue extension numbers and a default
configuration to new phones.
CIPT1 v4.12-14
References
Cisco Systems, Inc. Cisco CallManager System Guide, Release 4.1(3, )System
Configuration Overview and System-Level Configuration Settings.
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_b
ook09186a00803be4ee.html.
Cisco Systems, Inc. Cisco CallManager Administration Guide, Release 4.1(3).
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_administration_guide_b
ook09186a00803be4ec.html.
2-33
2-34
Lesson 2-3
Configuring Cisco Catalyst

Switches
Overview
Deploying IP telephony requires planning how the IP Phones will be powered and how the
voice network will be combined with the data network while ensuring that the data traffic does
not degrade the quality of the voice calls.
Cisco Catalyst switches provide three features that aid an IP telephony deployment: inline
power, voice VLANs, and class of service (CoS). Using the Cisco Catalyst switch to power IP
Phones can save on wiring costs and simplifies management. Enabling multiple VLANs in a
single port and placing voice packets in one VLAN and data in another VLAN saves money by
reducing the number of switch ports. Extending CoS to the IP Phone improves voice quality by
ensuring that voice packets receive priority over data.
This lesson discusses the three major functions that Cisco Catalyst switches perform in an IP
telephony network and describes how to configure a Cisco Catalyst switch to enable these
functions.
Objectives
Upon completing this lesson, you will be able to implement a Cisco Catalyst switch in an IP
telephony network to provide PoE to IP Phones, prioritize voice traffic, and create a separate
voice VLAN for IP Phones This ability includes being able to meet these objectives:
Identify the functions that Cisco Catalyst switches perform in a Cisco IP telephony solution
Describe the three options for powering Cisco IP Phones
Describe the two types of PoE that Cisco Catalyst switches provide
Identify the Cisco Catalyst switches that support PoE
Identify the commands to configure PoE on Cisco Catalyst switches
Configure dual VLANs on a single port on a Cisco Catalyst switch so that the IP Phones
reside in a separate VLAN
Configure CoS on Cisco Catalyst switches so that voice traffic has priority over data traffic
as it travels throughout the network
Catalyst Switch Role in IP Telephony
This topic describes the role of Cisco Catalyst switches in the IP telephony infrastructure.
Cisco Catalyst Switch Role in IP Telephony

Supplies inline power
to IP Phones
Supports voice and
data VLANs on a
single port
Prioritizes voice traffic
with class of service
(CoS) marking
CIPT1 v4.12-3
Cisco voice-capable Catalyst switches can provide three primary features to assist you with
your IP telephony deployment:
Inline power: Inline power capabilities allow a Cisco Catalyst switch to send power
through the Ethernet copper to a Cisco IP Phone or other inline power-compatible devices
(such as wireless access points) without the need for an external power supply. Inline
power is also referred to as Power over Ethernet (PoE). Inline power was developed in
2000 by Cisco to support the emerging IP telephony solution.
Auxiliary VLAN support: Auxiliary VLAN support allows a switch to support multiple
VLANs on a single port. You can connect one or more network devices to the back of the
Cisco IP Phone because some Cisco IP Phones have built-in switches. Auxiliary VLANs
allow you to place the IP Phone, and the devices that are attached through the IP Phone, on
separate VLANs.
Class of service (CoS) marking: CoS marking is data link layer (Layer 2) marking that is
used to prioritize network traffic. Prioritizing voice traffic is critical in IP telephony
networks. If voice traffic is not given priority, poor voice quality may result because voice
frames wait in the switch queue behind large data frames. The switch can use existing CoS
marking to prioritize network traffic and can also classify and mark traffic that it receives.
2-36
Powering the Cisco IP Phone
This topic describes the three options for powering Cisco IP Phones.
Three Ways to Power IP Phones

Power over Ethernet (PoE):
Power
Needs PoE line cards or PoE ports

for Cisco Catalyst switches
Delivers -48 V DC over data pairs
(pins 1, 2, 3, and 6)
Midspan power injection:
No Power
Power Injector
Power
Needs external power source

equipment
Delivers -48 V DC over spare pairs
(pins 4, 5, 7, and 8)
Wall power:
Needs DC converter for
connecting IP Phone to wall outlet
AC
Source
110 V AC
Wall Power
to 48 V DC
Converter
CIPT1 v4.12-4
Most Cisco IP Phone models are capable of using the following three options for power:
PoE: With PoE, the phone plugs into the data jack that connects to the switch, and the user
PC in turn connects to the IP Phone. Power-sourcing equipment (PSE), such as Cisco
Catalyst PoE-capable modular and fixed-configuration switches, insert power over the
Ethernet cable to the powered device, for example, an IP Phone or 802.11 wireless access
point.
Midspan power injection: Because many switches do not support PoE, the powered
device must support a midspan power source. This midspan device sits between the LAN
switch and the powered device and inserts power on the Ethernet cable to the powered
device. A technical difference between the midspan and inline power mechanism is that
power is delivered on the spare pairs (pins 4, 5, 7, and 8). An example of midspan PSE is a
Cisco Catalyst Inline Power Patch Panel.
Wall power: Wall power needs a DC converter for connecting the IP Phone to a wall
outlet.
Note
You must order the wall power supply separately from the Cisco IP Phone.
2-37
Types of PoE Delivery
This topic discusses the two types of PoE delivery that Cisco Catalyst switches can provide.
Two Types of PoE Delivery

Cisco original implementation:
Provides -48 V DC at up to 6.3 to 7.7 W per port over data pins
1, 2, 3, and 6.
Supports most Cisco devices (IP Phones and wireless access points).
Uses a Cisco proprietary method of determining if an attached device
requires power. Power is delivered only to devices that require power.
IEEE 802.3af Power over Ethernet:

Specifies -48 V DC at up to 15.4 W per port over data pins 1, 2, 3, and 6
or spare pins 4, 5, 7, and 8.
Enables a new range of Ethernet-powered devices because of increased
power.
Standardizes the method of determining if an attached device requires
power. Power is delivered only to devices that require power.
Has several optional elements, including power classification.
CIPT1 v4.12-5
Cisco provides two types of inline power delivery: the Cisco original implementation and the
IEEE 802.3af PoE standard. You can refer to both inline power types as PoE:
Cisco original implementation PoE: Cisco was the first to develop PoE. The original
Cisco (prestandard) implementation supports the following features:
Provides 48 V DC at up to 6.3 to 7.7 watts (W) per port over data pins 1, 2, 3,
and 6.
Supports most Cisco devices (IP Phones and wireless access points).
Uses a Cisco proprietary method of determining whether an attached device requires

power. Power is delivered only to devices that require power.
IEEE 802.3af PoE: Since first developing PoE, Cisco has been driving the evolution of
this technology toward standardization by working with the IEEE and member vendors to
create a standards-based means of providing power from an Ethernet switch port. The IEEE
802.3af committee has ratified this capability. The IEEE 802.3af standard supports the
following features:
2-38
Specifies 48 V DC at up to 15.4 W per port over data pins 1, 2, 3, and 6 or the

spare pins 4, 5, 7, and 8 (a PSE can use one or the other, but not both).
Enables a new range of Ethernet-powered devices that consume additional power.
Standardizes the method of determining whether an attached device requires power.

Power is delivered only to devices that require power. This type has several optional
elements, such as power classification, where powered devices can optionally
support a signature that defines the maximum power requirement. PSE that supports
power classification reads this signature and budgets the correct amount of power
per powered device, which will likely be significantly less than the maximum
allowed power.
Without power classification, the switch reserves the full 15.4 W of power for every device.
This behavior may result in oversubscription of the available power supplies so that some
devices will not be powered even though there is sufficient power available.
Power classification defines these five classes:
0 (default): 15.4 W reserved
1: 4 W
2: 7 W
3: 15.4 W
4: Reserved for future expansion
All Cisco IEEE 802.3af-compliant switches support power classification.
The Cisco Power Calculator is an online tool that enables you to calculate the power supply
requirements for a specific PoE configuration. The Cisco Power Calculator is available to
registered Cisco.com users at www.cisco.com/go/poe.
Cisco Prestandard Device Detection
FLP
Switch
It is an inline device.
Pin3
Pin6
Pin1
Pin2
Cisco Prestandard
Implementation
Powered Device Port
Rx
FLP
Tx
CIPT1 v4.12-6
2-39
The figure illustrates how a Cisco prestandard Catalyst switch detects a Cisco IP phone,
wireless access point, or other inline power-capable device. When a switch port that is
configured for inline power detects a connected device, the switch sends an Ethernet Fast Link
Pulse (FLP) to the device. The Cisco powered device (IP Phone) loops the FLP back to the
switch to indicate its inline power capability. The switch then delivers 48 V DC PoE (inline)
power to the IP Phone or other inline power-capable endpoint.
IEEE 802.3af Device Detection

IEEE 802.3af Powered Device
IEEE 802.3af PSE

-2.8 V to -10 V Pin3
Switch
Detect Voltage Pin6
It is an IEEE
Powered Device
Pin1
Pin2
Rx
Tx
25 K-Ohm
Resistor
CIPT1 v4.12-7
The figure illustrates how a Cisco Catalyst IEEE 802.3af-compliant switch detects a Cisco IP
phone, wireless access point, or other inline power-capable device. The PSE (Cisco Catalyst
switch) detects a powered device by applying a voltage in the range of 2.8 V to 10 V on the
cable and then looks for a 25K ohm signature resistor. Compliant powered devices must
support this resistance method. If the appropriate resistance is found, the Cisco Catalyst switch
delivers power.
2-40
Catalyst Family of PoE Switches
This topic describes the Cisco Catalyst PoE switch models.
Cisco Catalyst Family of PoE Switches

Cisco Catalyst 6500
Cisco Catalyst 4500

Cisco Catalyst 3750
Cisco EtherSwitch Network Module*

Cisco Catalyst 3560
*Cisco prestandard PoE only

CIPT1 v4.12-8
The Cisco Catalyst LAN switching portfolio is the industry-leading family of intelligent
switching solutions delivering a robust range of security and quality of service (QoS)
capabilities. The Cisco Catalyst switch portfolio allows organizations to enable new business
applications and integrate new technologies such as wireless and IP telephony into their
network infrastructure. Here are the switches in the Cisco Catalyst family:
Cisco Catalyst modular switching: The Cisco Catalyst 6500 Series delivers a 96-port
10BASE-T/100BASE-T line card and 48-port 10BASE-T/100BASE-T and
10BASE-T/100BASE-T/1000BASE-T line cards. The Catalyst 6500 Series offers a
modular PoE daughter card architecture for the 96-port card and the 48-port 10/100/1000
card. The Cisco Catalyst 4500 Series delivers 48-port 10/100 and 10/100/1000 line cards.
All line cards support both IEEE 802.3af and Cisco prestandard inline power. The cards are
compatible with any Cisco Catalyst 6500 or 4500 chassis and Supervisor Engine. The
Cisco Catalyst modular chassis switches can deliver 15.4 W per port for all 48 ports on a
module simultaneously.
Cisco Catalyst stackable switching: The Cisco Catalyst 3750 Series offers 48- and
24-port Fast Ethernet switches that comply with IEEE 802.3af and Cisco prestandard PoE.
The Cisco Catalyst 3560 Series offers 48- and 24-port Fast Ethernet switches that support
both the industry standard and Cisco standard PoE.
2-41
Cisco EtherSwitch modules: The Cisco 36- and 16-port 10/100 EtherSwitch modules for
Cisco 2600 and 3700 Series routers offer branch office customers the option to integrate
switching and routing in one platform. These modules can support Cisco prestandard PoE
and provide straightforward configuration, easy deployment, and integrated management in
a single platform. The Cisco 2600 Series requires a separate external PoE power supply;
the Cisco 3700 Series integrates the power supply.
This table lists the Cisco Catalyst PoE options.
Catalyst Switch PoE Options
2-42
Cisco
Catalyst
6500
Cisco
Catalyst
4500
Cisco
Catalyst
3750
Cisco
Catalyst
3560
Cisco
EtherSwitch
Module
PoE
Configuration
Options
48-, 96-port
10/100 or
48-port
10/100/1000
48-port
10/100 or
10/100/1000
24-, 48-port
10/100
24-, 48-port
10/100
16-, 36-port
10/100
IEEE 802.3afCompliant
Yes
Yes
Yes
Yes
No
Cisco
Prestandard
PoE
Yes
Yes
Yes
Yes
Yes
Note
Cisco does not offer an IEEE 802.3af midspan injection product. The 48-port Cisco Catalyst
Inline Power Patch Panel supports Cisco prestandard PoE.
Note
The switches that are listed here also support multiple VLANs per port and CoS.
Configuring PoE
This topic discusses the configuration of PoE on Cisco Catalyst switches.
Cisco Catalyst Switch: Configuring PoE

Cisco CatOS:
-

Native Cisco IOS software:

CIPT1 v4.12-9
Use the set port inlinepower command on a switch that is running Cisco Catalyst Operating
System software (CatOS). The two modes are auto and off. In the off mode, the switch does
not power up the port even if an unpowered phone is connected. In the auto mode, the switch
powers up the port only if the switching module has discovered the phone. Examples of devices
running Cisco CatOS include the Cisco Catalyst 6500, 4500, and 4000 Series.
Use the power inline command on switches that are running native Cisco IOS software
(examples include the Catalyst 6500, 4500, 3750, and 3560 switches). The powered devicediscovery algorithm is operational in the auto mode. The powered device-discovery algorithm
is disabled in the never mode. Other modes exist for allocating power, depending on the version
of Cisco IOS. For example, the ability to allocate power on a per-port basis with the allocation
milliwatt mode.
Note
The Catalyst 6500 Series can run either Cisco Catalyst operating system software or native
Cisco IOS software if the switch Supervisor Engine has a Multilayer Switch Feature Card
(MSFC). Otherwise, these switches can run only Cisco Catalyst software. The Cisco
Catalyst 4500 and 4000 Series can also run Cisco Catalyst software or native Cisco IOS
software, depending on the Supervisor Engine. Generally, late-edition Supervisor Engines
run native Cisco IOS software; however, you should check the product documentation to
determine the Supervisor Engine and the operating system that is supported on your
specific model.
2-43
Cisco Catalyst Switch: Show Inline Power

Status
-
- -
- -
-
-
-
-
-
CIPT1 v4.12-10
Use the command shown in the figure to display a view of the power allocated on Cisco
Catalyst switches. The switch shows the default allocated power as 10 W in addition to the
inline power status of every port. The Inline Power Syntax Descriptions table provides a brief
description of the syntax output.
Inline Power Syntax Descriptions
Column Heading
Description
Port
Identifies the port number on the module
Inline Powered
Admin
Identifies the port configuration from using the set inlinepower mod/port
[auto | off] command
Oper
Identifies whether the inline power is operational
Power Allocated
2-44
Detected
Identifies whether power is detected
mWatt
Identifies the milliwatts supplied on a given port
mA @42V
Identifies the milliamps at 42 V supplied on a given port (the actual voltage

is 48 V)
Configuring Dual VLANs
This topic describes the configuration of a multi-VLAN access port.
A Multi-VLAN Access Port
An access port able to handle two VLANs

Access (data) VLAN and voice (auxiliary) VLAN
Access Port
Tagged 802.1Q
Untagged 802.3
CIPT1 v4.12-11
All data devices typically reside on data VLANs in the traditional switched scenario. You may
need a separate voice VLAN when you combine the voice network into the data network. (The
Cisco Catalyst software command-line interface (CLI) refers to this new voice VLAN as the
auxiliary VLAN for configuration purposes.) You can use the new voice VLAN to represent
Cisco IP Phones. Although you can think of it as a voice VLAN, in the future, other types of
nondata devices will reside in the voice VLAN.
The placement of nondata devices (such as IP Phones) in a voice VLAN makes it easier for
customers to automate the process of deploying IP Phones. IP Phones will boot and reside in
the voice VLAN if you configure the switch to support them, just as data devices boot and
reside in the access (data) VLAN. The IP Phone communicates with the switch via Cisco
Discovery Protocol when it powers up. The switch provides the telephone with the appropriate
VLAN ID.
Administrators can implement multiple VLANs on the same port by configuring an access port.
A tagging mechanism must exist to distinguish among VLANs on the same port. 802.1Q is the
IEEE standard for tagging frames with a VLAN ID number. The IP Phone sends tagged 802.1q
frames. The PC sends untagged frames and the switch adds the access VLAN tag before
forwarding toward the network. When the switch receives a frame from the network destined
for the PC, it will remove the access VLAN tag before forwarding the frame to the PC.
2-45
There are some advantages in implementing dual VLANs:

This solution allows for the scalability of the network from an addressing perspective. IP
subnets usually have more than 50 percent (often more than 80 percent) of their IP
addresses allocated. A separate VLAN (separate IP subnet) to carry the voice traffic allows
you to introduce a large number of new devices, such as IP Phones, into the network
without extensive modifications to the IP addressing scheme.
This solution allows for the logical separation of data and voice traffic, which have
different characteristics. This separation allows the network to handle these two traffic
types individually.
This solution allows you to connect two devices to the switch using only one physical port
and one Ethernet cable between the wiring closet and the IP Phone or PC location.
Configuring Voice VLANs Using

Cisco CatOS
- -
---
-
CIPT1 v4.12-12
Configure auxiliary VLAN ports in Cisco Catalyst software 5.5 and above using the set port
auxiliaryvlan command to configure the auxiliary VLAN ports:
set port auxiliaryvlan mod[/port] {vlan | untagged | dot1p | none}
2-46
Syntax Description
Command
Description
Command
Description
mod[/port]
Number of the module and (optional) ports.
vlan
Number of the VLAN; valid values are from 1 to 1000.
untagged
Keyword to specify that the IP Phone 7960 send untagged

packets without 802.1p priority.
dot1p
Keyword to specify that the IP Phone 7960 send packets with

802.1p priority.
The voice VLAN ID in this example is set to the value of 222 for ports 2/1 through 2/3. The
switch instructs the IP Phone to reside in VLAN 222 when it powers up. You can use this
command to set the voice VLAN ID on a per-port basis, for a range of ports, or for an entire
module.
Configuring Voice VLANs Using Native

Cisco IOS
- -
-- ---
-- --
-- -
CIPT1 v4.12-13
Use the commands shown in the figure to configure voice and data VLANs on the single-port
interface of a switch that is running native Cisco IOS software. These commands apply the
same functionality as setting a port to use an auxiliary VLAN on a Cisco Catalyst switch that is
running Cisco Catalyst software.
2-47
Catalyst Switch Voice Interface Commands

Command
Description
switchport mode access
Configures the switchport to be an access (non-trunkjng) port
switchport voice vlan voiceVLAN_ID
Configures the switchport with the voice VLAN (261 in this

example) to be used for voice traffic. The range is 1 to 4094.
By default, the IP phone forwards the voice traffic with an IEEE
802.1Q priority of 5...
switchport access vlan

data_VLAN_ID
Configure the interface as a static access port with the access

VLAN ID (262 in this example); the range is 1 to 4094.
spanning-tree portfast
Causes a port to enter the spanning-tree forwarding state

immediately, bypassing the listening and learning states. You
can use PortFast on switch ports that are connected to a
single workstation or server (as opposed to another switch or
network device) to allow those devices to connect to the
network immediately.
Verifying Voice VLAN Configuration Using

Cisco CatOS
- -
-
- -
CIPT1 v4.12-14
You can check the status of the auxiliary VLAN on a port or module in one of two ways:
Use the show port auxiliaryvlan vlan-id command to show the status of that auxiliary
VLAN and the module and ports where it is active.
Use the show port [module[/port]] command to show the module, port, and the auxiliary
VLAN and the status of the port.
2-48
Verifying Voice VLAN Configuration Using

Native Cisco IOS
--- - -

- - - - -- -
-

--

CIPT1 v4.12-15
You can verify your voice VLAN configuration on the Cisco Catalyst switches that are running
native Cisco IOS software by using the show interface mod/port switchport command.
2-49
Configuring Class of Service
This topic describes the configuration of CoS when a PC and a Cisco IP Phone share the same
switch port.
Extending QoS to the IP Phone

This feature allows the extension of the trusted boundary
to the IP Phone.
Phone VLAN = 200

CoS = 5
PC VLAN = 3
CoS = 7
Access port
IP Phone:
IP Subnet B
Desktop PC:
IP Subnet A
PC is not trusted
CoS set to 0 (normal)
CoS = 0
CoS = 7
PC is not trusted
CoS set to 2
CoS = 2
CoS = 7
CoS = 7
CoS = 7
PC is trusted
CIPT1 v4.12-16
CoS is a data link layer marking that you can use to classify traffic as it passes through a
switch. You should ensure that voice traffic has priority as it travels throughout your network
because it is extremely sensitive to delay. Cisco IP Phones send all voice packets tagged with
CoS 5 by default, which is the highest level of CoS that is recommended for user traffic.
The multi-VLAN port also receives packets from the devices (PCs and workstations) that are
connected to the access port of the IP Phone. The attached device, if it is not in the native
VLAN, can send packets with a CoS equal to or higher than the packets that are being sent by
the IP Phone, which can cause severe voice quality problems on your IP telephony network.
This can be done only if the device is not in the native VLAN.
Cisco Catalyst switches have the ability to extend the boundary of trust to the IP Phone. You
can use the switch to instruct the IP Phone to accept the CoS value of frames that are arriving
from connected devices (trust) and allow the CoS to remain unchanged. Alternatively, you can
choose not to trust the attached device and set the CoS to 0 or set the CoS to a configured value
that you determine.
The Cisco Catalyst switch uses Cisco Discovery Protocol to send this configuration information
to the IP Phone. The switch sends an additional Cisco Discovery Protocol packet to the IP
Phone whenever there is a change in the CoS configuration.
The switch uses its queues, which are available on a per-port basis, to buffer incoming and
outgoing frames. The switch can use the CoS values to place the frames in the appropriate
queues. Voice frames should be placed in the priority queue for minimal delay.
2-50
Configuring CoS
Cisco CatOS
- - - -
Set the default value for all packets that have arrived through an untrusted
port
- - - - -
-
Allows you to trust or not trust (set to 0) the CoS assigned to the device
attached to the IP Phone
Native Cisco IOS
-
-
- -
Choose to modify, ignore, or trust the CoS of the attached device
CIPT1 v4.12-1
You can configure the switch with different QoS settings on a per-port basis. Use the
set port qos cos command to set the default value for all packets that have arrived
through an untrusted port. The cos-value specifies the CoS value for a port; valid values
are from 0 to 7. Seven is the highest priority. The default is 0 (not trusted).
For example, the command set port qos 3/1 cos 3 sets the cos value to 3 on port 3/1.
Use the set port qos mod/ports... trust-ext {trusted | untrusted} command to either extend
trust to the PC by specifying that all traffic received through the access port passes through the
phone switch unchanged, or to not trust the port and change the CoS value to 0.
Use the switchport priority extend interface configuration command to set a port priority for
the incoming frames received by the IP phone connected to the specified port. The cos-value is
used to set the IP phone port to override the priority received from PC or the attached
device. Valid values for the cos-value from 0 to 7. Seven is the highest priority. The
default is 0 (not trusted). Alternatively, the trust keyword causes the IP phone port to
trust the priority received from PC or the attached device, that is, to not change the CoS
value.
The Implementing Cisco Quality of Service (QOS) course provides more information about
voice QoS theory and configuration.
2-51
Summary
Summary
Cisco voice-capable switches support three
primary feature sets that can assist with an IP
telephony deployment: POE, dual VLANs, and CoS.
Most Cisco IP Phone models are capable of using
three options for power: inline power, external
power, and wall power.
Two types of inline power delivery are the Cisco
prestandard implementation and IEEE 802.3af PoE.
These differ in the amount of power supplied, how
powered devices are discovered, and optional
enhancements.
CIPT1 v4.12-18
Summary (Cont.)
The Cisco Catalyst 6500, 4500, 3750, and 3560 switches
support 802.3af and Cisco PoE, dual VLANs, and CoS.
Configure inline power using the set port inline power
command (Catalyst operating system) or power inline
(native Cisco IOS software) command.
Using dual VLANs on a single-port Cisco Catalyst
switch improves network scalability when you combine
a voice network into a data network.
When a PC and an IP Phone share the same switch
port, you can use the CoS on Cisco Catalyst switch
models to classify circuits so that voice packets have
priority over data packets.
2-52
CIPT1 v4.12-19
References
Cisco Systems, Inc. Multilayer LAN switches documentation.
http://www.cisco.com/univercd/cc/td/doc/product/lan/index.htm.
Cisco Systems, Inc. Understanding IP Phone In-Line Power Provisioning on the Catalyst
6500/6000 Switch.
http://www.cisco.com/warp/public/788/AVVID/cat6k_inline_pwr.html#second.
2-53
2-54
Lesson 2-4
Configuring Cisco IP
Communicator
Overview
Businesses often want to provide users who travel or telecommute with a supplemental
telephone that provides them with the same familiar phone services on the road or in the home
office that users enjoy from the main office. Cisco IP Communicator is a software-based
application that delivers enhanced telephony support through personal computers with the same
features, functionality, and interface as a desktop Cisco IP Phone. This application allows
computers to function as Cisco IP Phones, providing high-quality voice calls on the road, in the
office, or from wherever users may have access to the corporate network.
This lesson discusses Cisco IP Communicator features and functions, installation,
configuration, and deployment.
Objectives
Upon completing this lesson, you will be able to install Cisco IP Communicator and make IP
Phone calls from the PC. This ability includes being able to meet these objectives:
Describe the features and function of Cisco IP Communicator
Identify the steps to install and configure Cisco IP Communicator
Configure Cisco CallManager to enable Cisco IP Communicator
Deploy Cisco IP Communicator using a supported deployment option and the Cisco IP
Communicator Administration Tool
Perform required and recommended postinstallation configuration tasks to enable Cisco IP
Communicator to function properly or to allow users to access some features
This topic describes the features and function of Cisco IP Communicator.

Gives your PC the functionality of an
IP phone
Allows you to access your phone
extension and services outside the
office (on and off campus)
Provides parity with the advanced
Cisco IP Phones
Windows-based IP Phone
implementation compatible with
Cisco CallManager Version 3.3(3)
SR3 and later
Multiple language support using
Cisco IP Telephony Locale Installer
CIPT1 v4.12-3
Cisco IP Communicator is a software-based application that endows computers with the

functionality of IP Phones, providing high-quality voice calls on the road, in the office, or from
wherever users may have access to the corporate network.
When registered to Cisco CallManager system, Cisco IP Communicator has the features and
functionality of a full-featured Cisco IP Phone, including the ability to transfer calls, forward
calls, and conference additional participants into an existing call. System administrators can
provision Cisco IP Communicator as they would any other Cisco IP Phone, simplifying IP
Phone management.
Cisco IP Communicator is a Microsoft Windows-based IP Phone compatible with Cisco
CallManager Release 3.3(3) SR3 and later versions using the Skinny Client Control Protocol
(SCCP).
Cisco IP Communicator is available in languages besides English. If you are using Cisco IP
Communicator in a locale where a language other than English is spoken, install the Cisco IP
Telephony Locale Installer on every Cisco CallManager server in the cluster. Doing so ensures
that you have the latest translated text, user and network locales, and country-specific phone
tones available. For more information, refer to Cisco IP Telephony Locale Installer at:
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/locinst/index.htm.
2-56
Cisco IP Communicator Features

Ease of use
Feature parity with advanced Cisco IP Phones
Multiple lines
IP Phone services support (XML) such as extension mobility
Management
Unified administration with Cisco IP phones
Scaling 1 to 1 with IP Phones (unlike TAPI-based)
Automatic software updates
Deployment
Autodetection of Cisco VPN client
Voice quality
Advanced jitter buffer and packet loss concealment algorithms

Audio Tuning Wizard for setting levels
Echo suppression and noise cancellation
CIPT1 v4.12-4
Details of Cisco IP Communicator features are covered in the slide and in the following list:
Ease of use
Cisco IP Communicator delivers feature parity with advanced Cisco IP Phones such
as the Cisco 7940 and up
There are multiple lines: eight line keys and five softkeys.
IP Phone services such as extension mobility are supported. This solution also
enables customers and developers to deliver Extensible Markup Language (XML)based applications to the display.
Management
It scales 1:1 with IP phones. Cisco IP Communicator is a lighter-weight device

than Telephony Application Programming Interface (TAPI)-based applications such
as Cisco IP SoftPhone, so it places less load on Cisco CallManager.
Software updates automatically. AutoUpdate is part of the Cisco IP Communicator

software that helps you automatically update Cisco IP Communicator. Every time
Cisco IP Communicator registers with a Cisco CallManager, AutoUpdate compares
the current Cisco IP Communicator software load with the version in the
configuration file. AutoUpdate downloads and installs new software components
from the TFTP server when it detects that they are available. In addition,
AutoUpdate can use HTTP to download from the server if you have enabled HTTP
access to your TFTP server. Run the Cisco IP Communicator Administration Tool to
enable HTTP.
Deployment
Cisco Virtual Private Network (VPN) clients are automatically detected, and support
for most VPN clients (including the Microsoft Point-to-Point Tunneling Protocol
[PPTP] client) is automated.
2-57
Voice quality
Kernel mode operation prevents resource intensive applications from affecting

audio.
Cisco IP Communicator offers advanced jitter buffer and packet loss concealment
algorithms.
The Audio Tuning Wizard can be used for setting input and output levels.
Features include echo suppression and noise cancellation.
Cisco IP Communicator also offers voice activity detection, silence suppression, and
error concealment.
Cisco IP SoftPhone and IP Communicator

Feature Comparison
Cisco IP
Communicator
Cisco IP
SoftPhone 1.3
SCCP
Yes
No
Multiple Lines or Directory Numbers
Yes
No
Enterprise Call Features: Shared Lines, Park,

Pickup, MeetMe Conference, Barge
Yes
No
XML Support
Yes
No
Automatic Software Updates
Yes
No
Date and Time Display
Yes
No
Skin (Display) Options
Yes
No
VPN Support for Remote Access
Yes
No
Third Party Application IntegrationTAPI

(NetMeeting for Collaboration, Outlook, and
So On)
No
Yes
Drag and Drop Dialing
No
Yes
Collaboration
No
Yes
Alphanumeric Translation
No
Yes
Feature
CIPT1 v4.12-5
The figure identifies the differences between Cisco IP Communicator and Cisco IP SoftPhone.
Additional details on some of the differences are as follows:
Skin (display) options: Cisco IP Communicator comes with two desktop appearances
called skins that enable you to change the look of the phone display.
Alphanumeric translation: Cisco IP SoftPhone can translate alphanumeric dialing strings
into keypad digits. For example, if you enter 1-800-GOCISCO, Cisco IP SoftPhone
correctly translates the dial string to 1-800-462-4726. The values for Q and Z are translated
to 7 and 9, respectively.
Drag and drop dialing: Cisco IP SoftPhone displays a history of the calls that you have
placed, missed or answered in the call log. To place a call to a number in the call log, you
can select the entry and click Dial or select the entry and drag and drop it to the SoftPhone
interface.
VPN support for remote access: Cisco IP Communicator supports autodetection of Cisco
VPN client and automated support for many VPN clients that appear as alternative network
interfaces (such as the Microsoft PPTP client).
2-58
Cisco IP Communicator Installation and

Configuration Overview
This topic identifies the steps to install and configure Cisco IP Communicator.
Configuration Steps for Cisco IP

Communicator
1. Add the device in Cisco CallManager.
2. Run the Cisco IP Communicator
Administration Tool.
3. Install the phone load on the publisher or TFTP
server to enable AutoUpdate.
4. Install Cisco IP Communicator software on
client PCs.
5. Perform postinstallation tasks.
CIPT1 v4.12-6
To install and configure Cisco IP Communicator, follow this procedure:

Step 1
Add the device in Cisco CallManager. The procedure for adding Cisco IP
Communicator is similar to the procedure for adding an IP Phone.
Step 2
Run the Cisco IP Communicator Administration Tool to enable HTTP access and
access the Directory Wizard if desired.
Step 3
Install the phone load. The phone load is a patch to enable Cisco IP Communicator
to use AutoUpdate via the TFTP server of the Cisco CallManager (similar to IP
Phone firmware updates). AutoUpdate will occur when the application is launched
or a device reset is performed. The file name of the phone load will be of the form
cmterm-CIPC.CIPC-1-1-2-0.exe or cmterm-CIPC.CIPC-1-1-3-0.exe. The phone
load is bundled with the Cisco IP Communicator software package contents.
Step 4
Install Cisco IP Communicator on the client PC.
Step 5
Perform postinstallation tasks before first use.
Additional details on Steps 1, 2, 4, and 5 are covered in the next topics.
2-59
Configuring Cisco CallManager for Cisco IP

Communicator
This topic describes how to configure Cisco CallManager to enable Cisco IP Communicator.
Adding the Device to Cisco CallManager

Database
Method
MAC
Address?
Auto-registration
No
Auto-registration
with TAPS
No
Using Cisco
CallManager
Administration
Using BAT
Yes
Using Cisco CallManager Administration
Yes
CIPT1 v4.12-7
Before installing the Cisco IP Communicator application, you must add devices to the Cisco
CallManager database. Just as with Cisco IP Phones, there are four ways to add devices to the
Cisco CallManager database:
Auto-registration: You can use this method without first gathering MAC addresses from
client PCs. When auto-registration is enabled, Cisco CallManager provides a directory
number as soon as you run the Cisco IP Communicator application after installation.
Auto-registration with Tool for Auto-Registered Phones Support (TAPS): You can use
this method without first gathering MAC addresses from client PCs. TAPS works in
conjunction with the Cisco Bulk Administration Tool (BAT) to update devices that were
previously added to the Cisco CallManager database using dummy MAC addresses. Use
TAPS to update MAC addresses and download predefined configurations for Cisco IP
Communicator devices.
Using Cisco CallManager Administration: To use Cisco CallManager Administration,
you need to first collect the appropriate MAC address from the network interface for each
client on which you want the Cisco IP Communicator application installed. After you have
collected MAC addresses, choose Device > Add a New Device in Cisco CallManager
Administration.
Using BAT: The Cisco BAT is a plug-in application for Cisco CallManager that enables
system administrators to perform batch operations, including registration, on large numbers
of devices, including Cisco IP Phones and Cisco IP Communicator devices. To add devices
using BAT only (not in conjunction with TAPS), you first need to collect the appropriate
MAC address from the network interface for each client on which you want the Cisco IP
Communicator application installed.
2-60
Deploying and Updating Cisco IP Communicator
The topic describes using the Cisco IP Communicator Administration Tool to deploy the Cisco
IP Communicator and the supported deployment methods.
Administration Tool
Enables HTTP access
Faster AutoUpdate
downloads than TFTP
Directory Wizard
Required if using
unsupported VPN clients
Includes Directory Wizard
Includes Quick Search
feature to access a
personal or corporate
directory on Cisco
CallManager from Cisco
IP Communicator
CIPT1 v4.12-8
As part of your deployment preparations, it is strongly recommended that you run the Cisco IP
Communicator Administration Tool on the Cisco CallManager publisher and select the option
in the tool to enable HTTP access. This is a requirement if you have any users in your network
who rely on an unsupported VPN client. Supported software VPN clients include Cisco VPN
Client 3.x or 4.x and the Microsoft PPTP client. Other third-party VPN clients might be
unsupported. A VPN solution is typically unsupported if it is not a Cisco product and does not
function like a network interface card.
Enabling HTTP will improve the performance of AutoUpdate for remote users. (Downloading
software updates over a dialup or broadband connection using TFTP can take more than 15
minutes.)
Some VPN clients, such as Cisco VPN Client 3.x, assign the VPN IP address at a very low
level, which makes it difficult for Cisco IP Communicator to specify the correct address. To
eliminate this problem, Cisco IP Communicator queries the Cisco VPN Client directly.
Other VPN clients, such as the Microsoft PPTP client and Cisco VPN Client 4.x, simply appear
as alternative network interfaces. In these cases, the IP address can be selected with the same
autodetection process that is used to resolve selection when there are multiple interfaces.
2-61
Other third-party VPN clients might be unsupported and result in one-way audio. To fix the
problem, run the Cisco IP Communicator Administration Tool to create a getIP.asp audio IP
address reflector web page, then specify the URL for the web page in Cisco CallManager
Administration. Cisco IP Communicator will attempt to fetch this reflector page rather than
using other methods of autodetection. The reflector page returns the IP address from which it
sees the request originate, which is a relatively reliable way to identify the Cisco IP
Communicator VPN IP address.
Quick Search enables users to access a personal or corporate directory on the Cisco
CallManager server. To configure Quick Search, use the Directory Wizard. (To install the
Directory Wizard, run the Cisco IP Communicator Administration Tool.) The Directory Wizard
creates an XML configuration file (LdapDirectories.xml) that tells Cisco IP Communicator
which Lightweight Directory Access Protocol (LDAP) directories to search. Cisco IP
Communicator downloads this file at startup and saves the list of specified LDAP directories.
When a user invokes the Quick Search feature, Cisco IP Communicator searches the specified
LDAP directories, stopping at the first directory where one or more matches are found.
(Therefore, if you have two directories specified, and your search string is matched in the first
directory, the second directory will not be searched, regardless of whether or not it contains
matching entries.)
You can apply Quick Search configuration to all devices in a Cisco CallManager cluster by
using the Cisco IP Communicator Directory Wizard, or you can manually create a custom
Quick Search XML file to apply to a specific device.
Tip
Make sure that the Telephone Number field in the User Configuration window of Cisco
CallManager Administration shows the user phone number. The Quick Search feature
displays this phone number in search results.
Deployment Options
Deploy to a shared location
Deploy executable or MSI package to a shared
location or use command-line option with MSI
package to create a server image
Use a software
deployment tool
Required if users do not have administrative
privileges on their computers
Run the installer on a client PC
2-62
CIPT1 v4.12-9
You can deploy Cisco IP Communicator using either of the following installer packages:
CiscoIPCommunicatorSetup.exe: This executable contains the required Microsoft
Windows Installer engines and default verbose logging for typical deployments.
CiscoIPCommunicatorSetup.msi: This Microsoft Windows Installer package (MSI
package) allows you to provide deployment customization using command-line options.
Logging is not automatically set when you use the MSI package.
Whether you use the executable or the MSI package, you have three options for performing
installation:
Deploy to a shared location: You can place the installer on a shared location where you or
a user can run it. (To use this method, users must have administrative privileges on their
PCs.)
You can deploy the executable or MSI package to a shared location, such as a web server,
where users can access it to perform installation. Alternately, you can use the following
command-line option with the MSI package to create a server image of Cisco IP
Communicator at a specified network location:
msiexec.exe /a CiscoIPCommunicatorSetup.msi.
Use a software deployment tool: You can perform installation for an entire enterprise by
using a software distribution technology. (This method will temporarily elevate user
privileges for installation purposes, if necessary.)
You can use a software deployment tool to distribute Cisco IP Communicator to client PCs.
In fact, you must use this deployment method if users do not have administrative privileges
on their computers (and if you want to avoid installing the application manually on each
client PC). A software deployment tool can temporarily elevate user privileges on the client
PC for installation purposes.
Using a software distribution tool that can pass a command line to a system allows you to
take advantage of the Windows Installer package and customize values such as the device
name and TFTP server address or addresses at the time of deployment. Using commandline options to specify these values at deployment means that users do not have to
configure these settings after installation. This greatly simplifies the postinstallation
process for users.
Use the installer on the client PC: You can perform installation operations directly on an
individual computer.
You can deploy either the executable or the MSI package directly to the client PC and
perform installation by running the installer and following the installation wizard. If
necessary, use an administrator account to do this task.
2-63
This topic describes required and recommended postinstallation configuration tasks to enable
Cisco IP Communicator to function properly or to enable users to access some features.

Audio Tuning Wizard
1.
Select and tune audio

devices.
2.
Specify a TFTP server

address.
3.
Select a device name.
4.
Run Cisco IP
Communicator
Administration Tool and
enable HTTP access
(if not previously
completed).
5.
Provide users with

usernames and
passwords.
CIPT1 v4.12-10
After the software has been installed on the client PC, you or the user might need to perform a
few configuration tasks before Cisco IP Communicator can function properly or before users
can access some features. The need to perform these tasks depends upon variables such as
settings on the client PC and the software VPN solution of the user, among other factors. These
tasks are as follows:
2-64
Step 1
Select and tune audio devices (input microphone levels and output headset levels).
Use the Audio Wizard to select and tune audio devices on Cisco IP Communicator
startup.
Step 2
Specify a TFTP server address. This step is required if you are not using Dynamic
Host Configuration Protocol (DHCP) with Option 150 enabled.
Step 3
Choose a device name; this name is required at launch if the client has multiple PC
interfaces.
Step 4
Run the Cisco IP Communicator Administration Tool and enable HTTP access if
you have not done so already.
Step 5
Provide users with usernames and passwords, which are required if users are going
to access the Quick Search or User Options web pages.
Summary
Summary
Cisco IP Communicator is a PC- and Windows-based application with
all the functionality of a full-featured Cisco IP Phone.
Installation and configuration entails adding Cisco IP Communicator in
Cisco CallManager, running the Cisco IP Communicator Administration
Tool, installing the phone load, installing the software on client PCs,
and performing postinstallation tasks.
Configuring Cisco CallManager for Cisco IP Communicator entails
adding the device (PC) in Cisco CallManager either manually, using
auto-registration, or by using BAT.
Deploying Cisco IP Communicator entails running the Cisco IP
Communicator Administration Tool and deploying either to a shared
location, using a software deployment tool, or using the Installer
directly on the client PC.
Postinstallation configuration tasks include tuning audio devices,
specifying the TFTP server address, and providing usernames and
passwords to users.
CIPT1 v4.12-11
2-65
References
Cisco Systems, Inc. Cisco IP Communicator technical documentation, including links to
data sheets, the Cisco IP Communicator User Guide, and the Cisco IP Communicator
Administration Guide.
http://www.cisco.com/en/US/products/sw/voicesw/ps5475/tsd_products_support_series_ho
me.html
Cisco Systems, Inc. Install and Configure IP Communicator with CallManager 4.x
TechNote.
http://www.cisco.com/en/US/products/sw/voicesw/ps5475/prod_tech_notes_list.html
2-66
Lesson 2-5
Using the Bulk Administration

Tool
Overview
Adding, updating, and deleting phones, users, and gateway ports are important functions in the
day-to-day activities of a Cisco CallManager administrator. When you use Cisco CallManager
Administration, each database transaction requires an individual manual operation. Manually
adding and configuring large numbers of these entities can be time-consuming and tedious. The
Cisco Bulk Administration Tool (BAT) automates the process and achieves faster add, update,
and delete operations so that the system administrator can focus on more business- and
network-critical activities.
The lesson covers BAT Release 5.1(4) and Tool for Auto-Registered Phones Support (TAPS).
BAT is a web-based application for Cisco CallManager that allows you to add, update, or
delete a large number of similar telephones, users, or ports at the same time. TAPS works in
conjunction with BAT to update MAC addresses and download a predefined configuration for
new phones.
Objectives
Upon completing this lesson, you will be able to use BAT and TAPS to bulk-add and
auto-register Cisco IP Phones, users, and ports in an IP telephony network. This ability includes
Identify the major features and components of the BAT application
Install the BAT application on a Cisco CallManager publisher server
Use the BAT Wizard to perform bulk configuration tasks
Create an IP Phone template to use with BAT
Identify the two ways to create CSV files for importing data into BAT
Use the BAT Wizard to validate the IP Phone template and CSV file for errors prior to
inserting the devices into the Cisco CallManager database
Use the BAT wizard to insert the IP Phones into the Cisco CallManager database
Describe how to use BAT to update IP Phone settings for a group of similar phones
Describe the major requirements for proper installation of TAPS
Introducing the Bulk Administration Tool
This topic examines the features and components of BAT, a product that enables the Cisco
CallManager administrator to complete bulk additions, updates, and deletions for Cisco IP
Phones, users, ports, and other records.
Introduction to BAT
Supports bulk transactions for:
Cisco IP Phones, CTI ports, and H.323 clients
Users and user device profiles
Cisco IP Manager Assistant (IPMA) managers
and assistants
Cisco Catalyst 6000 FXS Analog Interface
Module
Cisco VG200 analog gateways and ports
Forced authorization codes and client matter
codes
Call Pickup groups
Locally significant certificates
Includes TAPS
CIPT1 v4.12-3
You can use BAT (Release 5.1(4) or later), to work with the following types of devices and
records:
Add, update, and delete Cisco IP Phones, including voice gateway chalice (VGC) phones,
computer telephony interface (CTI) ports, and H.323 clients
Add, update, and delete users
Add, update, and delete user device profiles
Add, update, and delete Cisco IP Manager Assistant (IPMA) managers and assistants
Add, update, and delete ports on a Cisco Catalyst 6000 FXS Analog Interface Module
Add or delete Cisco VG200 analog gateways and ports
Add or delete forced authorization codes
Add or delete client matter codes
Add or delete Call Pickup groups
Update or delete locally significant certificates on Cisco IP Phones
BAT provides an optional application, TAPS, which retrieves the predefined configuration for
auto-registered telephones.
2-68
Only Cisco CallManager system administrators require access to BAT, but end users can use
TAPS with permission from a system administrator to register new IP Phones.
Cisco Systems has based the BAT utility on the Cisco CallManager Administration interface.
You can access BAT from Cisco CallManager Administration or the Application menu.
BAT Components
=
Template
+
CSV File
Bulk configuration process uses two

components:
Template for the device type that
contains common settings
(number of softkeys)
CSV file that contains unique
information (directory numbers)
CIPT1 v4.12-4
Every device includes a multitude of individual attributes, settings, and information fields that
enable the device to function in the network and provide its telephony features. Many devices
have the same attributes and settings in common, while other values, such as the directory
number (DN), are unique to a user or to a device.
For bulk configuration transactions involving the Cisco CallManager database, the BAT
process uses two components: a template for the device type that includes settings that devices
have in common and a data file in comma-separated values (CSV) format that contains the
unique values for configuring a new device or updating an existing record in the database. The
CSV data file works in conjunction with the device template.
For instance, when you create a bulk transaction for a group of Cisco IP Phones, you set up the
CSV data file that contains the unique information for each phone, such as the DN and MAC
address. In addition, you set up or choose the BAT template that contains the common settings
for all phones in the transaction, such as a Cisco IP Phone 7960 template.
Caution
Because bulk transactions can affect Cisco CallManager performance and call processing,
use BAT only during off-peak hours.
2-69
BAT Features
Bulk Administration Tool Wizard
Flexible data input file format
Master phone templates
Validation feature
Reporting utility
Custom file support
Export utility
CIPT1 v4.12-5
BAT Release 5.0(1) includes a number of useful feature enhancements:

Bulk Administration Tool Wizard: The Bulk Administration Tool Wizard guides
administrators through bulk configuration tasks with step-by-step procedures that link to
the web pages for each task. Administrators can easily update phones and lines by using the
BAT web interface.
Flexible CSV data input file: Administrators can use a flexible CSV data input file format
for phones and user device profiles. Administrators can choose the phone or user device
profile fields to use in the CSV file and arrange the order of the fields. The first record of
the CSV file shows the customized file format. Values in the CSV file take precedence over
template values.
Master phone templates: When you are adding a group of phones that have multiple lines,
you can create a master phone template that provides multiple lines and the most common
values for a specific phone model. You can use the master template to add phones that have
differing number of lines but do not exceed the number of lines in the master phone
template. For example, you can create a master phone template for a Cisco IP Phone 7960
that has eight lines. You can use this template to add phones that have one line, two lines,
or up to eight lines.
Validation feature: A validation routine checks that that the CSV data file and BAT phone
template have populated all required fields, such as device pool and locations, or that the
number of lines that are configured on the device does not exceed the number specified on
the device template.
Report utility: A BAT report utility generates reports in CSV format with information
about phones, users, user device profiles, managers and assistants, and gateway records.
Reports do not get generated for the Cisco Catalyst 6000 Foreign Exchange Station (FXS)
ports. Administrators can customize reports for phones and user device profiles by
selecting and arranging the fields in the report. You can import report data into Microsoft
Excel to format and print the report.
2-70
Custom file support: Administrators can use a custom file to update and delete users when
using queries is not feasible.
Export utility: System administrators need the ability to move large numbers of phone
records to another Cisco CallManager database for department moves, reorganizations, or
equipment upgrades. The export utility in BAT gives you the ability to export large
numbers of phone, user, and user device profile records from a Cisco CallManager
database to a data file in CSV format. Then you can import the records into a different
Cisco CallManager database.
2-71
Installing BAT
This topic examines the BAT installation steps.
Installing BAT
Click the
setup icon
to install
BAT.
CIPT1 v4.12-6
BAT must be installed on the same server as the publisher database for Cisco CallManager.
During BAT installation, the setup program stops the following services:
Microsoft Internet Information Server (IIS) Administration
World Wide Web publishing
FTP publishing
These services automatically restart when the installation is complete.
When BAT is installed, the Microsoft Excel file BAT.xlt file for the BAT spreadsheet is placed
on the publisher database server at the following path: C:\CiscoWebs\BAT\ExcelTemplate\.
BAT Release 5.1(4) supports Cisco CallManager Release 4.1(3). BAT Release 5.1(3) supports
Cisco CallManager Release 4.1(2).
These steps describe the BAT installation process:
Step 1
Note
Step 2
2-72
Using administrator privileges, log in to the system running the publisher database
for Cisco CallManager.
You must install BAT directly on the publisher server; do not use Windows Terminal
Services.
Choose Application > Install Plugins. The Install Plugins window is displayed, as
shown here.
Step 3
Double-click the setup icon for the Cisco Bulk Administration Tool.
Step 4
A standard Windows dialog box appears. Determine whether to copy the BAT
installation executable to the system or run it from the current location.
If an existing version of BAT is detected on the server, you are prompted to confirm
the reinstallation or upgrade. To reinstall BAT or to upgrade from a previous
version, click OK.
Step 5
The Welcome screen appears. Click Next, and the Current Settings window appears.
Step 6
Click Next to install to the default location C:\CiscoWebs\BAT\. BAT installs to

C:\CiscoWebs\BAT\. You cannot change this path. The Start Copying Files window
appears. The setup program begins copying files.
Step 7
The Setup Complete window appears. You have successfully installed BAT.
Step 8
To close setup, click Finish.
Step 9
After you have installed BAT, from Cisco CallManager Administration, choose
Application > BAT to access BAT. If after you have installed BAT, BAT is not
visible under the Application menu, refresh your browser.
2-73
Using the BAT Wizard
This topic describes using the BAT Wizard to complete the bulk configuration process.
BAT Configuration Process

1. Set up the template for data input.
2. Create the CSV data file.
3. Validate the data input files with the Cisco
CallManager database.
4. Insert the devices into the Cisco CallManager
database.
CIPT1 v4.12-7
BAT uses a multistep process to prepare the bulk configuration transaction. BAT Release
5.0(1) introduced a wizard to step you through bulk configurations. The BAT configuration
process includes these tasks:
Step 1
Set up the template for data input. You can create BAT templates for the following
types of device options:
Phones: All Cisco IP Phone models and Cisco ATA 186, Cisco VGC phones,
CTI ports, and H.323 clients
Gateways: Cisco VG200 and ports for the Cisco Catalyst 6000 FXS Analog
Interface Module
User device profiles: Cisco IP Phone 7900 Series and Cisco SoftPhone
2-74
Step 2
Define a format for the CSV data file. You can use the BAT spreadsheet or a text
editor to create the CSV data file.
Step 3
Validate the data input files with the Cisco CallManager database. Cisco
CallManager runs a validation routine that checks the CSV file and the template for
errors against the publisher database.
Step 4
Insert the devices into the Cisco CallManager database.
Using BAT Wizard: Step 1 of 3

Choose the
device or
option to
configure.
10
CIPT1 v4.12-8
From the Configure menu, you can access the wizard by choosing one of these devices or
configuration options:
Phones
Users
Managers/Assistants
User Device Profiles
Gateways
Forced Authorization Codes
Client Matter Codes
Pickup Group
TAPS (optional, when installed)
2-75
Using the BAT Wizard: Step 2 of 3

Choose
the task
you want
to perform.
CIPT1 v4.12-9
After you choose a device or configuration option, the wizard displays a list of configuration
tasks that are specific to that option. For example, when you choose Phones, the following list
of tasks is displayed:
Insert Phones: Add new phones
Update Phones: Locate and modify existing phones
Delete Phones: Locate and delete phones
Export Phones: Locate and export specific phone records or all phone records
Update Lines: Locate and modify lines on existing phones
Add Lines: Add new lines to existing phones
Reset/Restart Phones: Locate and reset or restart phones
Insert Phones with Users: Add new phones and users
Generate Phone Reports: Generate customized reports for phones
CAPF Configuration: Locate and modify or delete the digital certificates (called locally
significant certificates [LSCs]) issued by the Cisco Authority Proxy Function (CAPF)
server to IP Phones
2-76
Using the BAT Wizard: Step 3 of 3
Wizard
guides you
through
steps
specific to
the task.
CIPT1 v4.12-10
After you choose the configuration task, the wizard provides a list of steps that are specific to
the task. For example, to guide you through the Insert Phones task, the wizard displays the
following steps:
Step 1
Add, view, or modify existing phone templates.
Step 2
Create the CSV data file.
Step 3
Validate phone records.
Step 4
Insert phones.
When you choose a step from the task list, you open a configuration window such as the Phone
Template Configuration window. The configuration window provides the entry fields for
defining a template.
2-77
Configuring BAT Templates
This topic describes how to use BAT to configure a Cisco IP Phone template.
Phone Template Configuration: Step 1
16
1.
2.
3.
Name phone template

Select device type
Assign device pool
CIPT1 v4.12-11
The first task in the BAT configuration process is to set up a template for the devices that you
are configuring. You specify the type of phone or device that you want to add or modify, and
then you create a BAT template that has features that are common to all the phones or devices
in that bulk transaction.
Prior to creating the template, make sure that phone settings, such as device pool, location,
calling search space, button template, and softkey templates, have already been configured in
Cisco CallManager Administration. You cannot create new settings in BAT.
The first steps in configuring an IP Phone template are to give the phone template a unique
name, and choose an IP Phone (device) type in the Phone Template Configuration window, as
shown here. Choose the template that encompasses all of the IP Phones in the group. If you
have multiple telephone types in a given group, you must create multiple templates.
Next, assign the template to a device pool. After you have configured the initial template
information, click Insert to add the template to the BAT utility.
2-78

After adding the template in the BAT utility, you can configure
necessary line settings.
Scroll down and

click a line.
14
CIPT1 v4.12-12
After configuring the initial template settings, you can modify specific line configurations.
Choose a line to configure, and a new configuration window appears. These general
configuration settings can apply to multiple IP Phones, such as partitions, calling search spaces,
and call waiting settings. BAT obtains line configurations that are specific to the user from the
imported Microsoft Excel spreadsheet.
2-79

Configure line
settings for template
15
CIPT1 v4.12-13
Configure the line settings by choosing the desired options from the menus and then clicking
Insert and Close.
When you are adding a group of phones that have multiple lines, you can create a master phone
template that provides multiple lines and the most common values for a specific phone model.
You can use the master template to add phones that have differing numbers of lines, but do not
exceed the number of lines in the master phone template. For example, you can create a master
phone template for a Cisco IP Phone 7960 that has six lines. You can use this template to add
phones that have one line, two lines, or up to six lines.
2-80
Creating CSV Files
This topic describes how to create a CSV file to use with BAT.
Creating CSV Files
BAT
spreadsheet
or
Text editor
CIPT1 v4.12-14
The CSV data file contains the unique settings and information for each individual device, such
as its DN, MAC address, and description. Make sure that all phones and devices in a CSV data
file are the same phone or device model and match the BAT template. The CSV data file can
contain duplicates of some values from the BAT template. Values in the CSV data file override
any values that were set in the BAT template. You can use the override feature for special
configuration cases.
You can create CSV files in one of two ways: by using the Microsoft Excel spreadsheet
BAT.xlt file or by using a text editor such as Microsoft Notepad. The BAT spreadsheet
simplifies the creation of CSV data files. When you are adding new devices to the system, you
can use this spreadsheet, which was designed to use with BAT. You can add multiple devices
and view the records for each device in a spreadsheet format. It allows you to customize the file
format within the spreadsheet and provides validation and error checking automatically to help
reduce configuration errors. Experienced BAT users who are comfortable with working in a
CSV-formatted file can use a text editor to create a CSV data file.
2-81
Creating CVS File Using BAT Spreadsheet:

Phones
CIPT1 v4.12-15
This figure shows the BAT.xlt Microsoft Excel spreadsheet. You can find this spreadsheet in
the directory C:\CiscoWebs\BAT\ExcelTemplate\ on the publisher database server. You
probably do not have Microsoft Excel running on the publisher, so you must copy the file to a
local machine (using either a floppy disk or a mapped network drive). After you have copied
the file, double-click BAT.xlt. When prompted, click Enable Macros.
The BAT spreadsheet includes tabs along the bottom of the spreadsheet for access to the
required data input fields for the various devices and user combinations in BAT. The CSV data
file works in combination with the BAT template. For example, when you choose the Phone tab
in the BAT spreadsheet, you can leave Location, Forward Busy Destination, or Call Pickup
Group blank. The values from the BAT phone template are used for these fields; however, if
you specify values for Forward Busy Destination or Call Pickup Group, those values override
the values for these fields that were set in the BAT phone template.
After entering the data into the BAT spreadsheet, click Export to BAT Format to create the
CSV file. The format for CSV files is <tabname><timestamp>.txt. The system saves the file to
C:\XLSDataFiles\ or to a folder of your choice. You must move the converted CSV file from
the C:\XLSDataFiles\ folder on your local computer back to the publisher, where BAT can
access the CSV file and place it in the appropriate folder under C:\BATFiles. (For example, you
would save a phone CSV data file to the C:\BATFiles\Phones\ Insert\ folder on the publisher
database for Cisco CallManager.)
2-82
Creating CSV File Using Text Editor
Step 1:
Create a
custom
file format.
CIPT1 v4.12-16
Creating CSV File Using Text Editor (Cont.)

Step 2:
Create the CSV
data file that
follows the file
format.
Step 3:
Associate the file
format with the CSV
data file.
CIPT1 v4.12-17
2-83
Using a text editor is the other way to create a CSV file. When using a text editor, follow these
steps:
Step 1
Note
Step 2
Create the customized file format using the BAT File Format Configuration
window. The file format specifies the order in which you enter values in the text file.
This allows you to add attributes to the file format that are also in the BAT template,
and override the template entry with a specific attribute for a device. For instance,
you can choose the route partition attribute for your file format and enter different
partitions for each phone in the CSV data file.
Earlier versions of BAT supported only a default file format with a fixed and limited number
of attributes and settings for each device and an All Details format that includes all attributes
and settings for each device.
Associate the file format with the CSV data file.

You can associate only one file format with a CSV data file. Use the Add File
Format window to choose the name of the CSV data file <CSVfilename>.txt from
the File Name drop-down menu. Next, you choose your file format from the File
Format Name drop-down menu. The data in the CSV data file must match the
custom file format that you have chosen.
2-84
Validating Data Input Files
This topic describes the process for validating data input files prior to inserting the devices into
the Cisco CallManager database.
Validating Data Input Files: Phones
CIPT1 v4.12-18
In the next task in the BAT wizard, you use the Validate File option. In this task, you choose
the name of the CSV data file and the BAT template for the device or the model when you have
a CSV data file with all details. You have these options for how records are validated:
Specific Details: For validating records that follow the default or custom file format
All Details: For validating records from a file that was generated with the export utility by
using the All Details option
When you choose Validate, the system runs a validation routine to check for errors against the
publisher database. These checks ensure the following:
Fields such as description, display text, and speed-dial label use valid characters.
Cisco CallManager groups, device pools, partitions, and other referenced attributes are
already configured.
The number of lines that are configured on a device does not exceed the device template.
Validation does not check for the existence of a user or for mandatory or optional fields that are
BAT-defined, such as the dummy MAC address.
2-85
Inserting IP Phones into Cisco CallManager
This topic describes how to insert Cisco IP Phones into the Cisco CallManager database.
Inserting Phones
CIPT1 v4.12-19
Inserting the device into the Cisco CallManager database is the last step in using BAT to
perform bulk configurations. The following steps are involved in this procedure:
Step 1
In the File Name field, choose the CSV data file that you created for this specific
bulk transaction.
Step 2
To enable the use of applications such as Cisco IP SoftPhone, check the Enable CTI
Application Use check box (for CTI ports only).
Step 3
Choose the Insert option that corresponds to your CSV data file.
Step 4
In the Phone Template Name field, choose the BAT phone template that you created
for this type of bulk transaction.
Step 5
If you did not enter individual MAC addresses in the CSV data file, check the
Create Dummy MAC Address check box.
This field automatically generates dummy MAC addresses in the following format:
XXXXXXXXXXXX, where X represents any 16-character, hexadecimal (0 to 9 and A
to F) number. You can update the phones or devices later with the correct MAC
address by manually entering this information into Cisco CallManager
Administration or by using TAPS.
Step 6
2-86
Click Insert to insert the phone records.
Updating IP Phones with BAT
This topic describes how to use BAT to update Cisco IP Phones and lines.
Updating IP Phones: Step 1
Choose field to
query and enter
search string.
CIPT1 v4.12-20
This figure shows the Update Phones query window. To update phone settings, such as
changing or adding a device pool or calling search space for a group of similar phones, choose
Phones > Update Phones in the BAT Configure window.
You can locate the existing phone records by using a query or a custom file containing the
device names or DNs. You can query using any number of fields, such as the model, device
name, DN, or description. You can also specify search criteria such as begins with,
contains, or is exactly. Choose View Query Result to check that the query returns the
information that you need. Choose Clear Query to remove the query items.
2-87
Updating IP Phones: Step 2

View query results.
Specify parameter
to update.
Reset or restart devices after changes are made.

CIPT1 v4.12-21
After you have defined the query or custom file to search for phones, follow this procedure to
update the IP Phones or users to the Cisco CallManager database in bulk:
Step 1
Specify the values to be updated within Cisco CallManager.
Step 2
Click Update.
Step 3
Reset or restart the IP Phones through Cisco CallManager, or plug them in and apply
power.
To check the status of your insertion, read the status line, located above the Insert button.
If the status bar indicates a failure, click View Latest Log File to display a window that will
help you to determine where the operation failed.
2-88
Using the Tool for Auto-Registered Phone

Support
This topic describes how to install and configure TAPS.
Introduction to TAPS
1
3
Call TAPS DN
Phone Configuration
Dummy MAC Address
Actual MAC Address
1. BAT adds dummy MAC address into Cisco

CallManager Administration
2. Administrator plugs phones into network
3. User or administrator dials a TAPS directory
number
4. Cisco CallManager downloads configuration
5. Phone updates Cisco CallManager with correct
MAC address
CIPT1 v4.12-22
Use TAPS in conjunction with BAT to provide two features:

Update MAC addresses and download predefined configuration for new phones
Reload configuration for replacement phones
When new phones are added to Cisco CallManager, TAPS works in conjunction with BAT to
update phones that were added to BAT using dummy MAC addresses. After BAT has been
used to bulk-add the telephones with dummy MAC addresses to Cisco CallManager
Administration, you can plug the telephones into the network. You or the user of the telephone
can dial a TAPS DN that causes the phone to download its configuration. At the same time, the
telephone is updated in Cisco CallManager Administration with the correct MAC address. You
must make sure that auto-registration is enabled in Cisco CallManager Administration (System
> Cisco CallManager) for TAPS to function.
2-89
TAPS Installation
With BAT Release 5.0(1), TAPS is installed
separately.
TAPS installation prerequisites:
Make sure the publisher database for Cisco
CallManager is configured and running.
Ensure that the Cisco CRS server is configured.
Ensure that the Windows 2000 Services window
is closed.
Ensure that the latest BAT is installed on the
publisher database server for Cisco
CallManager.
CIPT1 v4.12-23
Prior to BAT Release 5.0(1), TAPS installation and uninstallation for Cisco CallManager was
part of the BAT installation program. With BAT Release 5.0(1) and above, TAPS is installed
separately.
During TAPS installation or reinstallation on the publisher database server, the setup program
halts the following services:
Microsoft IIS Administration
World Wide Web publishing
FTP publishing
These services restart when the installation is finished.
You cannot use Windows Terminal Services to install TAPS. You must install TAPS directly
from the Cisco CallManager publisher server and the Cisco Customer Response Solutions
(CRS) server.
These prerequisites apply to the TAPS installation for BAT:
Make sure that the publisher database for Cisco CallManager is configured and running.
The publisher database can reside on its own server or on the same server as Cisco
CallManager.
Before installing TAPS, ensure that the latest BAT release is installed on the publisher
database server for Cisco CallManager.
Have the IP address for the Cisco CallManager publisher server and the private phrase for
the installation procedure.
Ensure that the Cisco CRS server is configured. The Cisco CRS Version 3.5 application
can reside on its own dedicated server or can be colocated on the same server as Cisco
CallManager.
2-90
Be sure to use the locale installer to create the country-specific TAPS prompts.
Ensure that the Windows 2000 Services window is closed.
Complete the following steps to install TAPS:
Step 1
Log in with administrator privileges to the system that is running the publisher
database for Cisco CallManager (where you installed BAT).
Step 2
Access BAT.
Step 3
Choose Applications > Install Plugins.
Step 4
Double-click the TAPS setup icon.
Step 5
Determine whether to copy the TAPS installation executable to the system or run it
from the current location.
Step 6
The Welcome window for the installation wizard opens. This installation program
installs TAPS on the Cisco CallManager publisher server and the CRS applications
server at the same time, if applications are colocated on the same server. Click Next.
Note
When you are installing TAPS in a network with a dedicated CRS server, you must run the
TAPS installation program again on the CRS server. Use CRS online help for assistance
with installation and configuration.
Step 7
Enter the private phrase for the Cisco CallManager publisher server in the Installing
Cisco CallManager Components window and click Next. The Installing
TAPSonCCM window displays a progress bar that shows the status of the
installation.
Step 8
The Installation Completed window is displayed when the installation ends. Click
Finish.
2-91
TAPS Configuration Requirements
Install CTI Route Points
Administrator
Publisher
Add a computer telephony integration (CTI) route

point, CTI ports, and users in Cisco CallManager
Administration.
CIPT1 v4.12-24
You must configure TAPS by adding a CTI route point, CTI ports, and users in Cisco
CallManager Administration, as shown here. One CTI route point and at least one CTI port are
required for TAPS.
The following procedure describes how to configure TAPS in Cisco CallManager
Administration:
Note
Step 1
Create a CTI route point and assign it a unique DN.
Step 2
Choose the Call Forward Busy, Call Forward No Answer, and Call Forward on
Failure options for the operator number on the TAPS CTI route point.
Step 3
Create one or more CTI ports with consecutive DNs. You can create CTI ports in
BAT or Cisco CallManager Administration.
Step 4
Create a user. The TAPS route point and ports should be in the Controlled Devices
list of the user.
Step 5
Create an auto-registration partition or calling search space or both to prevent IP

Phones that have auto-registered from dialing any DN other than the number that is
assigned to the TAPS CTI route point. Restricting access to this DN ensures that
users download the proper configuration information for their IP Phones.
Note
2-92
To use TAPS, verify that auto-registration is enabled in Cisco CallManager. Because TAPS
can replace a DN, you can protect certain DNs from being overwritten by using the Secure
TAPS option.
TAPS supports a maximum number of simultaneous sessions equal to the number of CTI
ports that are configured for TAPS. For example, if you have configured five CTI ports, up to
five users can dial into TAPS at same the time. The sixth caller cannot connect to TAPS.
Summary
Summary
BAT uses a template and CSV file to insert bulk
transactions into the Cisco CallManager database.
You must install BAT on the same server as the
publisher database for Cisco CallManager.
The BAT Wizard steps you through the BAT
configuration process.
BAT templates enable you to insert, update, or

delete IP Phones, gateways, and user device
profiles.
You can create a CSV file using the BAT
spreadsheet or text editor.
CIPT1 v4.12-25
Summary (Cont.)
After creating the CSV file, BAT must validate the
file and template.
Inserting the Cisco IP Phones, users, or device is
the last step in bulk configuration.
To update phones, query to find the phones,
specify the values, and then reset the phones.
TAPS, an optional application that BAT provides,
retrieves the predefined configuration for
auto-registered IP Phones.
CIPT1 v4.12-26
2-93
References
For additional information, refer to this resource:
Cisco Systems, Inc. Bulk Administration Tool User Guide, Release 5.1(4).
http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_1/bulk_adm/in
dex.htm.
2-94
Module 2 Summary
Module Summary
Cisco IP telephony endpoints support the G.711 and G.729 codecs and
include the full range of desktop, PC-based, and conference-room IP
Phones. To register to a Cisco CallManager, an IP Phone obtains a VLAN ID
and IP address and downloads configuration information from the TFTP
server.
Configuring Cisco CallManager to automatically or manually add IP
endpoints entails changing the Cisco CallManager name to its IP address,
configuring device pools, and assigning phone button templates.
Cisco Catalyst switches provide three important functions in an IP telephony
deployment: voice VLANs, CoS, and PoE.
Cisco IP Communicator is a PC-based phone with all the features of a
high-end Cisco IP Phone. Adding Cisco IP Communicator to the Cisco
CallManager database is similar to adding a Cisco IP Phone 7940, 7960,
or 7970.
BAT enables you to add large numbers of devices, users, and ports to the
Cisco CallManager database. BAT can be used anytime but is typically used
during deployment or when making wholesale changes to phone extensions.
Day-to-day changes to an individual phone are normally done in Cisco
CallManager Administration.
CIPT1 v4.12-1
This module covered the key ingredients to enable IP telephony within a cluster. This module
first presented the range of Cisco IP endpoints that you can use in an IP telephony deployment
and the system-level parameters that you configure in Cisco CallManager to enable and support
the endpoints. The module then covered the three functions that the Cisco Catalyst switches
provide in an IP telephony deployment: enabling separate voice VLANs for the IP phones,
providing CoS to the voice traffic so that it receives preferential treatment, and providing PoE
to power the IP phones and potentially other endpoints. The Cisco IP Communicator was
presented as a fully featured PC-based alternative to a desktop IP phone for mobile and remote
users. The module ended with a discussion of how to use the BAT when you want to bulk-add
or update users, phones, ports, and a variety of other settings.
2-95
Module 2 Self-Check
Q1)
BAT enables you to perform which tasks? (Source: Lesson 2-5, Using the Bulk
Administration Tool)
A)
B)
C)
D)
E)
Q2)
Place these steps in the order that an IP Phone must go through before it can register
with Cisco CallManager. (Source: Lesson 2-1, Identifying Cisco IP Telephony
Endpoints)
A)
B)
C)
D)
Q3)
publisher server
subscriber server
primary server
secondary server
A company wants to migrate to a VoIP network, but it has an expensive all-in-one

voice-fax-copier device that it wants to connect to the VoIP network. Which device
would you recommend? (Source: Lesson 2-1, Identifying Cisco IP Telephony
Endpoints)
A)
B)
C)
D)
E)
2-96
Media Resource Group List

Cisco CallManager group
date/time group
region
softkey template
device pool name
phone template
phone load
device defaults
On which server must you install BAT? (Source: Lesson 2-5, Using the Bulk
Administration Tool)
A)
B)
C)
D)
Q5)
obtain 48 V DC power
get configuration from TFTP server
load firmware image
obtain VLAN information
Which five settings are required to configure a device pool? (Choose five.) (Source:
Lesson 2-2, Configuring Cisco CallManager to Support IP Phones)
A)
B)
C)
D)
E)
F)
G)
H)
I)
Q4)
reload configuration for replacement phones

add, update, and delete IP Phones, users, and devices in mass
collect user data such as passwords and account identification
update MAC addresses and download configurations for new phones
save a detailed log of Cisco CallManager events for troubleshooting
Cisco Conference Station 7936

Cisco IP SoftPhone
Cisco ATA 188
Cisco 7905G
Cisco 7914 Expansion Module
Q6)
Which command enables inline power on port 3 of module 2 of a Cisco Catalyst 6000
Series switch that is running Cisco Catalyst software? (Source: Lesson 2-3,
Configuring Cisco Catalyst Switches)
A)
B)
C)
D)
E)
Q7)
Which of the following is a valid phone button template configuration for a Cisco IP
Phone 7960? (Source: Lesson 2-2, Configuring Cisco CallManager to Support IP
Phones)
A)
B)
C)
D)
Q8)
convert SCCP signaling packets from the IP Phone to MGCP

power IP Phones through the same Ethernet cable that carries data
enable the classification and prioritization of voice packets at Layer 2
instruct the IP Phone to change the CoS of an incoming data frame
determine available bandwidth before placing a call over the WAN
What are the two ways to create CSV files? (Choose two.) (Source: Lesson 2-5, Using
the Bulk Administration Tool)
A)
B)
C)
D)
Q11)
device pool
directory number
softkey template
MAC address
calling search space
button template
Cisco Catalyst switches can provide which three functions in an IP telephony

deployment? (Choose three.) (Source: Lesson 2-3, Configuring Cisco Catalyst
Switches)
A)
B)
C)
D)
E)
Q10)

6 lines, 1 speed dial
Before you can create a BAT template, you must make sure which four settings have
already been configured in Cisco CallManager Administration? (Choose four.)
(Source: Lesson 2-5, Using the Bulk Administration Tool)
A)
B)
C)
D)
E)
F)
Q9)
power inline in global configuration mode

power inline auto in interface configuration mode
set port inline power default
set port inline power 3/2 802.3
set port inline power 2/3 auto
choose Configure > CSV File

use a text editor and save to the correct folder
modify BAT.xlt and export to BAT format
save the IP Phone template in CSV format
Which navigation path would you use to configure Cisco CallManager to automatically
register an IP Phone? (Source: Lesson 2-2, Configuring Cisco CallManager to Support
IP Phones)
A)
B)
C)
D)
E)
System > Server

System > Cisco CallManager
Service > Service Parameters
Device > Phone
System > Device Pool
2-97
Q12)
What are three requirements for configuring dual VLANs on a single port that is
attached to an IP Phone? (Choose three.) (Source: Lesson 2-3, Configuring Cisco
Catalyst Switches)
A)
B)
C)
D)
E)
Q13)
How does Cisco CallManager tie configuration information to the IP Phones in the
Microsoft SQL database? (Source: Lesson 2-2, Configuring Cisco CallManager to
Support IP Phones)
A)
B)
C)
D)
E)
Q14)
setting up a template
creating CSV files
installing BAT
inserting phones and devices
validating records
obtaining MAC addresses
creating the CTI point
A firm wants to install a Cisco IP Phone in the lobby area. The IP telephony network
runs only the G.729a codec. The IP Phone should support a single line and all standard
features. An LCD display is not required because cost is a concern. Which IP Phone
would best meet these requirements? (Source: Lesson 2-1, Identifying Cisco IP
Telephony Endpoints)
A)
B)
C)
D)
2-98
CRS
BAT
plug-ins
Extension Mobility
The BAT Wizard guides you through which four tasks? (Choose four.) (Source: Lesson
2-5, Using the Bulk Administration Tool)
A)
B)
C)
D)
E)
F)
G)
Q16)
IP address
unique GUID
hostname
MAC address
device pool ID
Which two items must be installed for TAPS to function properly? (Choose two.)
(Source: Lesson 2-5, Using the Bulk Administration Tool)
A)
B)
C)
D)
Q15)
Configure the interface as a trunk.

Tag the voice packets with an identifier.
Extend the CoS boundary to the IP Phone.
Ensure that the IP Phone has an internal switch.
Ensure that the IP Phone is inline power-capable.

Cisco IP Phone 7910G+SW
Q17)
What must you do if you do not want to trust the device that is attached to the IP
Phone? (Source: Lesson 2-3, Configuring Cisco Catalyst Switches)
A)
B)
C)
D)
Q18)
List two functions of the Cisco IP Communicator Administration Tool. (Choose two.)
(Source: Lesson 2-4, Configuring Cisco IP Communicator)
A)
B)
C)
D)
Q19)
Change the CoS value on the voice VLAN to a number lower than 5.
Use the switchport priority extend untrust interface command.
Do nothing; the IP phone will automatically change the CoS to 0 for the
attached devices.
Create a dual VLAN on the access port and place the data packets in the native
VLAN.
collects PC MAC addresses

is a software deployment tool
improves audio input quality
helps obtain VPN IP addresses
If you do not know the MAC address of the Cisco IP Communicator device, which two
methods can you use to add the device to Cisco CallManager? (Choose two.) (Source:
Lesson 2-4, Configuring Cisco IP Communicator)
A)
B)
C)
D)
E)
BAT with TAPS

auto-registration
Device menu
Administration Tool
Directory Wizard
2-99
2-100
Q1)
Q2)
A, C, D, B
Q3)
B, C, D, E, F
Q4)
Q5)
Q6)
Q7)
Q8)
A, C, E, F
Q9)
B, C, D
Q10)
B, C
Q11)
Q12)
A, B, D
Q13)
Q14)
A, B
Q15)
A, B, D, E
Q16)
Q17)
Q18)
B, D
Q19)
A, B
Module 3
Establishing an Off-Cluster
Call
Overview
Cisco CallManager automatically routes calls to destinations within the same cluster. If the
voice call stays on the local LAN, issues of voice quality and availability are greatly simplified.
Enabling voice calls across an IP WAN or the Public Switched Telephone Network (PSTN)
requires that you implement a number of additional provisions, including a route plan, calling
restrictions, and mechanisms to ensure the quality of calls across the IP WAN and preserve
calls should the WAN link fail.
This module discusses how to configure the gateways and intercluster trunks used to make
off-cluster calls; how to create basic route plans, hunt groups, and complex dial plans; and how
to apply calling restrictions using partitions, calling search spaces, and time-of-day routing.
This module also discusses how to configure call admission control to preserve the quality of
voice calls as they traverse the WAN, automated alternate routing (AAR) to reroute calls
through the PSTN when there is insufficient WAN bandwidth, and Cisco Survivable Remote
Site Telephony (SRST) to preserve calls if the WAN fails.
Module Objectives
Upon completing this module, you will be able to configure Cisco gateways and intercluster
trunks, create hunt groups, and create a route plan. This ability includes being able to meet
these objectives:
Configure Cisco access gateways and intercluster trunks to support voice calls over the IP
WAN and to the PSTN
Configure route groups, route lists, and route patterns to place calls over the IP WAN and
PSTN
Create a hunt group that includes line groups, hunt lists, and a hunt pilot and provides final
forwarding if hunting exhausts
Use complex route plan elements to block access to specified area codes and manipulate
digits to change the caller and calling ID number, and enable transparent calling, whether
the call is routed over the IP WAN or PSTN
Configure partitions and calling search spaces to restrict user traffic and to create a hotline,
and explain how time-of-day routing enables call routing or restrictions based on when a
call is placed
Configure call admission control in a centralized and in a distributed call processing
environment so that the voice calls do not consume all of the available WAN bandwidth,
and explain how AAR reroutes calls through the PSTN when the WAN bandwidth is
insufficient
3-2
Lesson 3-1
Configuring Gateways and

Trunks
Overview
Voice gateways and trunks provide the bridge between an IP telephony network and the Public
Switched Telephone Network (PSTN), and between Cisco CallManager clusters. This lesson
prepares you for integrating Cisco gateways and trunks in a Cisco CallManager solution.
You will learn about analog and digital gateways, recommended gateway requirements,
gateway protocols, the types of trunks that Cisco CallManager supports, and how to configure
gateways, intercluster trunks, and Session Initiation Protocol (SIP) trunks.
Objectives
Upon completing this lesson, you will be able to configure Cisco Systems H.323 and MGCP
access gateways, and add and configure the gateways and nongatekeeper-controlled intercluster
trunks in Cisco CallManager Administration to enable calling to remote clusters and the PSTN.
Describe the role of the gateway in an IP telephony infrastructure
Compare analog and digital gateways with respect to interfaces and the types of telephony
devices that they can connect
Describe the core gateway requirements that a gateway must have to support an IP
telephony network
Describe the gateway communication protocols that Cisco CallManager supports
Add and configure H.323, MGCP, and non-IOS MGCP gateways in Cisco CallManager
and on the gateway to interface to the IP WAN and PSTN and support analog phones and
faxes
Choose the appropriate trunk type to satisfy deployment requirements for call-control
requirements and call routing
Configure nongatekeeper-controlled trunks in Cisco CallManager Administration to enable
calling to remote clusters across an IP WAN
Describe the SIP signaling protocol and how it is implemented in Cisco CallManager
Explain how to create a SIP trunk and route calls to a SIP endpoint
The Gateway in an IP Telephony Infrastructure
This topic describes the importance of Cisco access gateways in the overall design of the IP
telephony infrastructure.
Cisco Gateway Role in IP Telephony
Voice Gateway
Voice Gateway
Headquarters
PSTN
Regional Center
Converts IP voice packets into analog or digital

signals
Connects IP voice network to analog or digital trunks
or individual analog stations
CIPT1 v4.13-3
A gateway is a device that translates one type of signal into another type of signal. One type of
gateway is the voice gateway. A voice gateway is a router or switch that converts IP voice
packets to analog or digital signals that are understood by trunks or stations. Gateways are used
in several situations, for example, connecting to a PSTN or PBX, or connecting individual
devices such as an analog phone or fax.
Note
3-4
This lesson provides an overview of the voice gateways that you can use with the Cisco
CallManager system and describes their basic configuration . For more information on
configuring voice gateways, refer to the Cisco Voice over IP (CVOICE) course or the
Implementing Gateways and Gatekeepers (GWGK) course.
This topic describes analog and digital access gateways.

Analog Trunk
FXS
FXO
PSTN
FXS
PRI,
BRI,
T1 CAS,
E1
Digital Trunk
CIPT1 v4.13-4
There are two types of Cisco access gateways: analog and digital:
Cisco access analog gateways: There are two categories of Cisco analog access gateways:
Access analog station gateways: Access analog station gateways connect Cisco
CallManager to plain old telephone service (POTS) analog telephones, interactive
voice response (IVR) systems, fax machines, and voice-mail systems. Station
gateways provide Foreign Exchange Station (FXS) ports for connecting to analog
devices such as telephones and faxes.
Access analog trunk gateways: Access analog trunk gateways connect Cisco
CallManager to PSTN central office (CO) or PBX trunks. Trunk gateways provide
Foreign Exchange Office (FXO) ports for PSTN or PBX access and E&M (known
by various names, primarily receive and transmit, or ear and mouth, or earth and
magneto) ports for analog trunk connection to a legacy PBX. Analog Direct Inward
Dial (DID) is also available for PSTN connectivity.
Cisco access digital trunk gateways: A Cisco access digital trunk gateway connects Cisco
CallManager to the PSTN or to a PBX via digital trunks, such as PRI common channel
signaling (CCS), BRI, T1 channel-associated signaling (CAS), or E1. Digital T1 PRI trunks
may also connect to certain legacy voice-mail systems.
3-5
This topic provides an overview of the core requirements for a gateway to support an IP
telephony network.

DTMF relay:
Signaling method that uses specific pairs of frequencies
within the voice band for signals.
Supplementary services:
Provide user functions, such as hold, transfer, and
conferencing.
Cisco CallManager redundancy:
A secondary Cisco CallManager should be able to pick up
control of all gateways initially managed by the primary Cisco
CallManager.
Call survivability:
The voice conversation between two IP endpoints is preserved
when the Cisco CallManager that the endpoint is registered to
is no longer reachable.
CIPT1 v4.13-5
IP telephony gateways must meet these core feature requirements:

Dual tone multifrequency (DTMF) relay capabilities: DTMF signaling tones must be
processed. Gateways must separate DTMF digits from the voice stream and then send the
signaling in voice over IP (VoIP) signaling protocols such as H.323, Cisco IOS software
Media Gateway Control Protocol (MGCP), SIP, and so on.
Supplementary services support: These services are typically basic telephony functions,
such as hold, transfer, and conferencing.
Cisco CallManager redundancy support: Cisco CallManager clusters provide for Cisco
CallManager redundancy. The gateways must support the ability to rehome to a secondary
Cisco CallManager in the event of a primary Cisco CallManager failure, which differs from
call survivability in the event of a Cisco CallManager or network failure.
Call survivability in Cisco CallManager: The voice gateway preserves the Real-Time
Transport Protocol (RTP) bearer stream (the voice conversation) between two IP endpoints
when the Cisco CallManager that the endpoint is registered to is no longer reachable.
Any IP telephony gateway that you select for an enterprise deployment should support these
core requirements. Additionally, every IP telephony implementation has its own site-specific
feature requirements, such as analog or digital access, DID, and capacity requirements.
3-6
This topic describes the gateway protocols that Cisco CallManager supports and identifies key
Cisco access gateways that support these protocols.

H.323: Peer-to-peer, more complex configuration
on gateway because the gateway must maintain
the dial plan and route pattern
Examples: Cisco VG224 (FXS only), Cisco 2600,
Cisco 2800, Cisco 3700, Cisco 3800
MGCP: Client-server, simplified configuration,

Cisco CallManager maintains the dial plan and
route pattern
Examples: Cisco VG224 (FXS only), Cisco 2600,
Cisco 2800, Cisco 3700, Cisco 3800
Non-IOS MGCP example: Catalyst 6000 WS-X6608T1 and -E1
SCCP (Skinny): Client-server, simplified

configuration, Cisco CallManager maintains the
dial plan and route pattern
Examples: Cisco VG224 (FXS only), Cisco VG248
CIPT1 v4.13-6
Cisco CallManager 4.0 supports these three types of gateway protocols:

H.323: H.323 uses a peer-to-peer model. You perform most of the configuration through
Cisco IOS software on the voice gateway device. With the peer-to-peer model, Cisco
CallManager does not have control over the gateway, which limits the Cisco CallManager
feature support on H.323 gateways. For example, H.323 gateways do not support call
survivability, and only devices that support H.323 version 2 (H.323v2) can take advantage
of Cisco CallManager supplementary services such as hold, transfer, and conference
features. However, H.323 gateways support additional Cisco IOS features outside of Cisco
CallManager that the other gateways do not, such as call admission control and Cisco
Survivable Remote Site Telephony (SRST).
Examples of Cisco gateway devices that support H.323 include the Cisco VG224 Analog
Phone Gateway (FXS only), Cisco 2600, Cisco 2800, Cisco 3700, and Cisco 3800 devices.
3-7
MGCP: MGCP uses a client-server model, with voice-routing intelligence that resides in a
call agent (the Cisco CallManager). Because of its centralized architecture, MGCP
simplifies the configuration of voice gateways (the gateway requires no dial-peer
configuration) and supports multiple (redundant) call agents in a network. MGCP gateways
provide call survivability (the gateway maintains calls during failover and fallback). If the
MGCP gateway loses contact with its Cisco CallManager, it falls back to using H.323
control to support basic call handling of FXS, FXO, T1 CAS, and T1 and E1 PRI
interfaces.
Examples of Cisco gateway devices that support MGCP are the Cisco VG224 (FXS only),
Cisco 2600, Cisco 2800, Cisco 3700, and Cisco 3800 devices. Examples of non-IOS
devices that support MGCP are the Cisco Catalyst 6000 WS-X6608-T1 and -E1.
SCCP: Skinny Client Control Protocol (SCCP, or Skinny), is a client-server protocol that
uses Cisco proprietary messages to communicate between IP devices and Cisco
CallManager. The Cisco IP Phone is an example of a device that registers and
communicates with Cisco CallManager as an SCCP client. During registration, a Cisco IP
Phone receives its line and all other configurations from Cisco CallManager. After it
registers, it is notified of new incoming calls and can make outgoing calls. SCCP is used
for VoIP call signaling and enhanced features such as message waiting indication (MWI).
Examples of Cisco devices that support SCCP are the Cisco VG224 Analog Phone
Gateway (FXS only) and the Cisco VG248 Analog Phone Gateway. The Cisco VG224
gateway is 24-port gateway for analog phones, fax machines, modems and speakerphones
using Cisco CallManager or Cisco CallManager Express. The Cisco VG248 device is a
48-port gateway
Note
SIP can also be used as a gateway control protocol. Most Cisco IOS images that support
H.323 and MGCP also support SIP. Cisco CallManager 4.0 supports SIP trunks to connect
CallManager to distributed SIP networks.
Most gateway devices support multiple gateway protocols. Selecting the protocol to use
depends on site-specific requirements and your installed base of equipment. You may prefer
MGCP to H.323 because of the simpler configuration of MGCP or its support for call
survivability during a Cisco CallManager switchover from a primary to a secondary Cisco
CallManager. Additionally, you may prefer H.323 to MGCP because of the interface robustness
of H.323 or the ability to use it with call admission control or SRST.
3-8
Configuring Access Gateways
This topic discusses the configuration of the H.323, MGCP, and non-IOS MGCP gateways in
Cisco CallManager and on the gateway itself.
H.323 Gateway Configuration
Device NameIP Address
CIPT1 v4.13-7
Complete these steps to add an H.323 gateway:

Step 1
Choose Gateway from the Device menu in the Cisco CallManager Administration
window.
Step 2
Click the Add a New Gateway link and choose H.323 Gateway from the Gateway
Type menu.
Step 3
Cisco CallManager automatically populates the Device Protocol field with H.225.
Click Next. For the device name, enter the IP address of the Cisco router that will be
acting as the gateway.
Step 4
In the Device Name field, use the IP address of the H.323 gateway or a unique
name.
Step 5
Assign the gateway to a device pool.
Step 6
Click Insert when finished.
Note
This topic covers the required configuration items when adding an H.323 gateway. For
information on all the settings available in the Gateway Configuration window, refer to the
Cisco CallManager Help option for gateway configuration or to the Cisco CallManager
documentation.
3-9
Because H.323 is a peer-to-peer protocol, you must configure most of the gateway
configuration using Cisco IOS software on the gateway itself. The table lists the Cisco IOS
commands that are used to configure an H.323 voice gateway.
Cisco IOS Commands to Configure an H.323 Voice Gateway
Command
Description
Enables H.323 VoIP gateway functionality. After you enable the

gateway, it attempts to discover a gatekeeper by using an H.323
gatekeeper request message.

--
Creates an H.323 voice class that is used to configure a TCP

timeout duration.
--

--
Configures the H.225 TCP timeout duration in seconds. Possible

values are 0 to 30. The default is 15. If you specify 0, the H.225
TCP timer is disabled.
When the duration (seconds) of the H.225 TCP is exceeded, the
voice gateway will use the next ordered dial peer (controlled via
the preference command), which points to a backup Cisco
CallManager.
3-10
Creates a VoIP dial peer.
Assigns the previous created voice class to this dial peer.
-
-
Configures the dial string that this dial peer matches.
---
--
Identifies the IP address to route a call to when the destination

pattern in the previous command is matched. The IP address is
the address of the Cisco CallManager on an H.323 gateway.
Assigns a preference to a dial peer when multiple dial peers

contain the same destination pattern but different session targets.
0 is the highest, 10 is the lowest (used to configure Cisco
CallManager redundancy on H.323 gateways).
Configures the gateway to use out-of-band DTMF relay. DTMF

relay sends DTMF tones across the signaling channel, instead of
as part of the voice stream. DTMF relay is needed when you are
using a low-bit-rate coder-decoder (codec) for voice compression,
because the potential exists for DTMF signal loss or distortion.
Example: H.323 Gateway Configuration

Here is an example of an H.323 gateway that has been configured for Cisco CallManager
redundancy.
H.323 Gateway Configuration for Cisco CallManager Redundancy
Command
Description
IP address of the primary Cisco CallManager.
---

Specifies this dial peer as the connection to the

primary Cisco CallManager.

-
---
IP address of the secondary Cisco CallManager.
Specifies this dial peer as the connection to the

secondary Cisco CallManager.
Note
The Cisco Voice over IP (CVOICE) and Implementing Gateways and Gatekeepers (GWGK)
courses discuss the detailed configuration of the H.323 gateway.
3-11
Call Classification
Classify gateways and
trunks as OnNet or
OffNet at device or
global level
Restrict OnNet-toOffNet transfers and
drop an ad hoc
conference when no
OnNet parties remain
Default is OnNet for
ICTs and Use System
Default for other
gateways
Service parameter
default is OffNet
Gateway Configuration
Service Parameters Setting
CIPT1 v4.13-8
The Call Classification feature, introduced in Cisco CallManager Release 4.1, provides the
ability to configure gateways and trunks as on the network (OnNet) or off the network (OffNet)
at the device or at the global level. As a result, a call through these devices is classified as either
OnNet or OffNet. With these classifications, Cisco CallManager provides the ability to restrict
OnNet-to-OffNet transfers and to drop an ad hoc conference when no OnNet parties remain in
the conference. This field provides an OnNet or OffNet alerting tone when the call is classified
as OnNet or OffNet, respectively.
The corresponding Call Classification field in the gateway and trunk configuration windows
marks the corresponding devices as OnNet or OffNet or Use System Default. The default Call
Classification settings are OnNet for intercluster trunks and Use System Default for other
gateways.
A global setting as a new service parameter Call Classification is provided. The default value is
OffNet. When Use System Default is selected at the device level for a particular gateway or
trunk, the value of the service parameter is used to judge the device as OnNet or OffNet.
Therefore, gateways are classified as external (OffNet) by default.
FXS ports and IP Phones are not configurable and are always treated as OnNet.
The parameters that determine whether a transfer is allowed or restricted follow:
The Call Classification setting on the Gateway or Trunk.
The Call Classification setting and Allow Device Override check box setting on the Route
Pattern. If the Allow Device Override check box is checked, the Call Classification setting
on the gateway or trunk takes precedence.
The Service parameter Block OffNet to OffNet Transfer. When this parameter is set to
False, the transfer is not restricted. When this parameter is set to True and the transfer is
initiated between two OffNet parties, the transfer is blocked.
3-12
Note
The ability to restrict external transfers and to drop an ad hoc conference when no OnNet
parties remain on the call help to prevent toll fraud. Preventing toll fraud and many other IP
Telephony security considerations are covered in detail in the Cisco IP Telephony Part 2
(CIPT2) course.
MGCP Configuration Information
MGCP Domain Name:

Hostname of Gateway
Network Module 2 VICS
1/1/1 1/1/0 1/0/1 1/0/0
Endpoint Identifiers
CIPT1 v4.13-9
Complete these steps to add an MGCP gateway:

Step 1
window.
Step 2
Click the Add a New Gateway link and choose one of the various MGCP-capable
devices from the Gateway Type menu.
Step 3
Cisco CallManager automatically populates the Device Protocol field. Click Next.
Step 4
For the Domain Name field, enter the unique hostname of the Cisco device that will
be acting as the gateway.
Step 5
Assign the gateway to a Cisco CallManager group for redundancy.
Step 6
Choose the type of network modules that are used in the MGCP gateway.
Step 7
Choose the type of voice interface cards (VICs) that are used in the subunit slots of
the MGCP gateway.
Step 8
Click Insert.
Step 9
Click an endpoint identifier (for example, 1/0/0) to configure device protocol

information and add ports for the installed types of VICs.
3-13
Note
This topic covers the required configuration items when adding an MGCP gateway. For
information on all the settings available, refer to the Cisco CallManager Help option for
gateway configuration or to the Cisco CallManager documentation.
The following table lists commands to help configure endpoint identifiers for connections to
analog devices (residential gateway). To configure an interface that connects to a digital PSTN
trunk (trunking gateway), see
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_configuration_guide_book
09186a008020bd29.html Cisco IOS MGCP and Related Protocols Configuration Guide (the
Overview of MGCP and Related Protocols and Basic MGCP Configuration sections).
3-14
Cisco IOS Commands

Command
Description
Assigns a unique name to the voice gateway so that the Cisco

CallManager server can identify it. This name must be unique
throughout the network.
Enables MGCP on the voice gateway.

--
Identifies the primary Cisco CallManager for the gateway.
Indicates to the gateway that the Cisco CallManager is using

MGCP.

-
--
--
Specifies the secondary and tertiary Cisco CallManager servers

that are used for Cisco CallManager redundancy.
-
-
Specifies how the gateway behaves if the primary server

becomes unavailable and later becomes available again. The
keywords and arguments are as follows:
Completes all outstanding calls before
returning the gateway to the control of the primary Cisco

CallManager server.
Returns the gateway to the control of the
primary Cisco CallManager server without delay, as soon as

the network connection to the server is re-established.
- Returns the gateway to the

control of the primary Cisco CallManager server at the
specified time, where hh:mm is the time according to a
24-hour clock. If the gateway re-establishes a network
connection to the primary server after the configured time,
the switchback occurs at the specified time on the following
day.
- Returns the gateway to the
control of the primary Cisco CallManager server when the

primary server runs for a specified number of minutes after a
network connection is re-established to the primary server.
Valid values are from 1 to 1440 (from 1 minute to 24 hours).
Configures the gateway to use out-of-band DTMF relay for all

codecs. If this command is not configured, DTMF tones will be
not be regenerated correctly on remote endpoints.
Creates a POTS dial peer.
Configures the dial peer to use the MGCP application. The

MGCPAPP option is case-sensitive in some Cisco IOS software
releases. Unless you know that your version is not casesensitive, always issue this command in uppercase. You can
check whether your version is case-sensitive after you configure
this command by looking at the output of the show runningconfig command.
Associates the dial peer with a voice port.
3-15
Example: MGCP Gateway Configuration

The following output is from an MGCP gateway with a primary, secondary, and tertiary Cisco
CallManager configured for redundancy using the mgcp call-agent (primary) and
ccm-manager redundant-host (secondary and tertiary) commands.
-
-
-

Note
The Cisco Voice over IP (CVOICE) and Implementing Gateways and Gatekeepers (GWGK)
courses discuss the complete configuration of the MGCP gateway.
Non-IOS MGCP Cisco Catalyst 6000,

WS-X6608-x1
MAC Address of Port
3-16
CIPT1 v4.13-10
Complete these steps to add a non-IOS MGCP gateway to Cisco CallManager:

Step 1
window.
Step 2
Click the Add a New Gateway link and choose one of the various non-IOS MGCP
devices from the Gateway Type menu. If you have selected the Cisco Catalyst 6000
T1 or E1 VoIP Gateway module (WS-X6608), the Device Protocol field provides
you with the option of specifying either digital access PRI or digital access T1. After
you have made your selection, click Next.
Step 3
Add the MAC address to the MAC Address field.
Cisco CallManager associates with a non-IOS MGCP gateway (such as the Cisco Catalyst 6608
T1 or E1 blade) through the MAC address of the port. The show port mod command from
enable mode on the Cisco Catalyst 6000 is a quick way to identify and list the MAC addresses
of each digital gateway port on the Voice T1/E1 and Services (WS-X6608) module.
-
--
--
To display detailed information about a specific port on the module use the show port
mod/port command.
Step 4
Assign the gateway to a device pool.
Step 5
Configure additional parameters as desired, and click the Insert button when
finished.
Step 6
Repeat Steps 1 through 5 for each T1 or E1 port that you want to add as a gateway in
Cisco CallManager administration.
After you add the gateway to the database, Cisco CallManager creates a configuration file in
the cluster on the Cisco TFTP server, and this file is where the T1 or E1 port downloads its
configuration details, which include an ordered list of Cisco CallManager servers.
3-17
Configuring the Gateway

On the gateway itself (Cisco Catalyst 6500 T1 or E1 port), it is recommended that you statically
configure the IP address, subnet mask (rather than using Dynamic Host Configuration Protocol
[DHCP]), default gateway, and TFTP server address of each T1 and E1 port that is used as a
digital gateway. The TFTP server address should be the IP address of the Cisco CallManager to
which you want the port to register and download its configuration file. The following
command disables DHCP and statically configures the following voice port settings: IP
address, subnet mask, VLAN ID, TFTP server IP address, and default gateway:
- -

Note
3-18
When a port resets, the module has the ability to reset the adjoining port because all eight
ports on the WS-X6608 module share the same XA processor. This reset process creates a
domino effect, and all of the ports on the module reset. If you are not going to use a port,
you should either disable the port or configure and register it to Cisco so that it does not
continually perform an asynchronous reset.
This topic describes the types of trunks that Cisco CallManager supports.
Definitions
Trunks
Signaling interfaces to a gatekeeper, to an intercluster

trunk without a gatekeeper, or to a SIP network
Do not carry voice data

Intercluster trunk
H.323 connection that connects two Cisco CallManager

clusters
Gatekeepers
Provide call admission control and address resolution for

a distributed call-processing environment
CIPT1 v4.13-11
Shown in the figure are baseline terms and definitions used in the discussion of Cisco
CallManager trunk types.

H.225 trunk (gatekeeper-controlled)
Required in a mixed environment
(Cisco CallManager, Cisco CallManager Express)
Toll bypass or integration with an existing H.323 environment
Intercluster trunk (gatekeeper-controlled):
Recommended only for deployments based entirely on
Cisco CallManager (must have gatekeeper) with distributed or
centralized call processing
WAN without hub-and-spoke topology
Intercluster trunk (nongatekeeper-controlled):
Recommended only for deployments based entirely on
Cisco CallManager with centralized call processing
WAN with hub-and-spoke topology
SIP trunk
For interworking with a SIP network or gateways
SIP phone registration to Cisco CallManager unsupported at
this time
CIPT1 v4.13-12
3-19
Your choices for configuring trunks in Cisco CallManager depend on whether the IP WAN
uses gatekeepers to handle call routing and on the types of call-control protocols that are used
in the call-processing environment.
Cisco CallManager Administration supports the following trunk types:
H.225 trunk gatekeeper-controlled: Use an H.225 gatekeeper-controlled trunk for toll
bypass or for integration with an existing H.323 environment. The H.225 gatekeepercontrolled trunk enables Cisco CallManager to communicate with Cisco CallManager
clusters and other H.323 devices registered to the H.323 gatekeeper. The H.225 gatekeepercontrolled trunk is not recommended in a pure Cisco CallManager environment, but it is
required in a mixed environment with Cisco CallManager and Cisco CallManager Express
or other H.323 gateway. The H.225 trunk attempts to discover the other H.323 device on a
call-by-call basis. If it discovers a device that understands intercluster trunk protocol, it
automatically uses that protocol. If it cannot discover the other device, Cisco CallManager
uses the standard H.225 protocol. To use this method, choose Device > Trunk and choose
H.225 Trunk (Gatekeeper Controlled).
Intercluster trunk gatekeeper-controlled: The intercluster gatekeeper-controlled trunk
enables Cisco CallManager to communicate with other Cisco CallManager clusters
registered to an H.323 gatekeeper. It is recommended that you use the intercluster
gatekeeper-controlled trunk only in deployments based entirely on Cisco CallManager. To
use this method, choose Device > Trunk and choose Inter-Cluster Trunk (GateKeeper
Controlled) in Cisco CallManager Administration.
Intercluster trunk nongatekeeper-controlled: In a distributed network that has no
gatekeeper control, you must configure a separate intercluster trunk for each device pool in
a remote cluster that the local Cisco CallManager can call over the IP WAN. The
intercluster trunks statically specify the IP addresses or hostnames of the remote devices.
To use this method, choose Device > Trunk and choose Inter-Cluster Trunk (NonGateKeeper Controlled) in Cisco CallManager Administration.
SIP trunk: Cisco CallManager Release 4.0 supports a Session Initiation Protocol (SIP)
trunk for interworking with a SIP network or gateways, but it currently does not allow SIP
IP Phones to register directly with Cisco CallManager. To use this method, choose Device
> Trunk and choose SIP Trunk in Cisco CallManager Administration.
3-20
Configuring Intercluster Trunks
This topic discusses gatekeeper-controlled and nongatekeeper-controlled intercluster trunks.
Gatekeeper and Intercluster Trunk

Overview
Cisco IOS Gatekeeper
IP WAN
Intercluster Trunk
H.225 RAS Signaling
Voice Path
CIPT1 v4.13-13
A gatekeeper provides call admission control by using the H.225 Registration, Admission, and
Status (RAS) protocol message set that is used for call admission control, bandwidth allocation,
and dial pattern resolution (call routing). The gatekeeper provides these services for
communications between Cisco CallManager clusters and H.323 networks. Note that the voice
path is between the endpoints.
3-21
Gatekeeper and Trunk Configuration

NongatekeeperControlled Trunks
GatekeeperControlled Trunks
Cluster
2
Cluster
1
Gatekeeper
IP WAN
Cluster
3
Cluster
4
Separate intercluster trunks

required to communicate with
each remote cluster
Cluster
2
Cluster
1
Cluster
3
Cluster
4
Single intercluster trunk

sufficient to communicate with
all remote clusters
CIPT1 v4.13-14
You can configure gatekeepers and trunks in Cisco CallManager Administration to function in
either of the following ways:
Nongatekeeper-controlled trunks: In this case, you explicitly configure a separate
intercluster trunk for each remote device cluster that the local Cisco CallManager can call
over the IP WAN. You also configure the necessary dial plan details to route calls to and
from the various intercluster trunks. The intercluster trunks statically specify the IP
addresses of the remote devices. To use this method, choose Device > Trunk and then
choose Inter-Cluster Trunk (Non-Gatekeeper Controlled) in Cisco CallManager
Administration.
Gatekeeper-controlled trunks: In this case, a single intercluster trunk suffices for
communicating with all remote clusters. Similarly, you need only a single H.225 trunk to
communicate with multiple H.323 gatekeeper-controlled endpoints. In this configuration,
the gatekeeper can dynamically determine the appropriate IP address for the destination of
each call to a remote device, and the local Cisco CallManager uses that IP address to
complete the call.
This configuration works well in large as well as smaller systems. For large systems where
many clusters exist, this configuration helps to avoid the configuration of individual
intercluster trunks between each cluster. To use this method, choose Device > Trunk and
choose Inter-Cluster Trunk (Gatekeeper Controlled) in Cisco CallManager
Administration.
If you configure gatekeeper-controlled trunks, Cisco CallManager automatically creates a
virtual trunk device. The IP address of this device changes dynamically to reflect the IP
address of the remote device as determined by the gatekeeper.
3-22
Intercluster Trunk Configuration
Device NameUnique ID
IP Address of Remote
Cisco CallManagers
CIPT1 v4.13-15
Complete these steps to configure a nongatekeeper-controlled intercluster trunk:

Step 1
Choose Trunk from the Device menu in the Cisco CallManager Administration
window.
Step 2
Click the Add a New Trunk link and choose Inter-Cluster Trunk (NonGatekeeper Controlled) from the Trunk Type drop-down menu.
Step 3
Cisco CallManager populates the Device Protocol field with the appropriate
protocol. Click Next to continue.
Step 4
Add the device name. It does not have to be the IP address, but it must be unique
throughout the cluster.
Step 5
Add the IP addresses of up to three Cisco CallManager servers in the remote cluster.
You must add the IP address for one remote CallManager.
Note
This topic covers the required configuration items when adding an intercluster trunk. For
information on all the settings available, search the Cisco CallManager Help option for
intercluster trunk configuration to obtain additional information.
Note
Configuring gatekeeper-controlled intercluster trunks is covered later in the course.
3-23
SIP and Cisco CallManager
This topic describes the Session Initiation Protocol (SIP) signaling protocol and how it is
implemented in Cisco CallManager.
SIP Basics
SIP is defined in IETF RFC 2543 and RFC 3261.
SIP is a peer-to-peer protocol where end devices
(user agents) initiate sessions.
SIP defines the signaling mechanism for
multimedia calls and conferences.
SIP uses several existing IETF protocols to provide
message formatting (HTTP 1.1), media negotiation
(Session Description ProtocolSDP), media (RTP),
name resolution and mobility (DHCP and DNS), and
application encoding (MIME).
SIP is ASCII text-based for easy implementation
and debugging.
CIPT1 v4.13-16
SIP is specified in Internet Engineering Task Force (IETF) RFC 2543, published in 1999. Since
the initial publication, nine bis versions (or revisions) have been published, and in 2002, RFC
2543-bis-09 was renumbered to RFC 3261.
SIP is an ASCII-based, application-layer control protocol that can be used to establish,
maintain, and terminate multimedia sessions, such as Internet telephony calls between two or
more endpoints. SIP works in client-server relationships as well as in peer-to-peer relationships.
SIP is a VoIP signaling protocol (as are SCCP, MGCP, and H.323) with the following
capabilities:
Determines the availability of the target endpoint: If a call cannot be completed because
the target endpoint is unavailable, SIP determines whether the called party is connected to a
call already or did not answer in the allotted number of rings. SIP then returns a message
indicating why the target endpoint was unavailable.
Establishes a session between the originating and target endpoints: If the call can be
completed, SIP establishes a session between the endpoints. SIP also supports midcall
changes, such as the addition of another endpoint to the conference or the changing of a
media characteristic or codec.
Handles the transfer: SIP supports the transfer of calls from one endpoint to another.
During a call transfer, SIP establishes a session between the transferee and a new endpoint
(specified by the transferring party) and terminates the session between the transferee and
the transferring party.
Terminates call: At the end of a call, SIP terminates the sessions among all parties.
3-24
SIP Network Topology
Registrar
Redirect
Location
Database
SIP Servers and Services
SIP Proxy
SIP User
Agents
SIP User
Agents
SIP-GW
SIP address: sip:<user>@<host>

CIPT1 v4.13-17
A SIP network in a Cisco CallManager environment uses the following components:

Cisco SIP Proxy Server: The proxy server works as an intermediate device that receives
SIP requests from a client and then forwards the requests on behalf of the client. Proxy
servers can provide functions such as authentication, authorization, network access control,
routing, reliable request retransmission, and security.
Redirect server: The redirect server provides the client with information about the next
hop or hops that a message should take, and the client then contacts the next-hop server or
user agent server directly.
Registrar server: The registrar server processes requests from user agent clients (UACs)
for registration of their current location. Redirect or proxy servers often contain registrar
servers.
User agent: A combination of UAC and user agent server (UAS) that initiates and receives
calls. A UAC initiates a SIP request. A UAS is a server application that contacts the user
when it receives a SIP request. The UAS then returns a response (such as ring, busy,
connected, or no answer) on behalf of the user. Cisco CallManager can act as both a server
or client (a back-to-back user agent) and can initiate and accept calls simultaneously.
SIP uses a request-and-response method to establish communications between various
components in the network and to ultimately establish a call or session between two or more
endpoints. A single session may involve several clients and servers.
Identification of users in a SIP network is by a SIP URL that takes the form sip:user@host. The
user part is a username, telephone number, or E.164 address. The host part is either a domain
name or a numeric network address.
3-25
Cisco CallManager SIP Trunk

SCCP
MGCP
Conf
CTI
SIP
Xcode
VMail
Apps
Microsoft
Messenger
SCCP
Phones
Cisco SIP
IP Phone
Cisco IOS
SIP Gateway
SoftPhones
Goal is to communicate with a SIP network via an edge SIP Proxy Server.
CIPT1 v4.13-18
Cisco CallManager Release 4.0 introduced a native SIP signaling interface in Cisco
CallManager referred to as a SIP trunk. The SIP trunk enables interoperability between Cisco
CallManager networks and SIP networks served by a SIP Proxy Server, and allows any existing
devices controlled by Cisco CallManager to communicate with SIP networks.
DTMF Relay Calls Between SIP Endpoints

and Cisco CallManager
RTP Stream
SIP
IP Phone
MTP
TDM
2
Cisco
CallManager
PSTN
PRI Gateway

1
SCCP
Phone
RTP
Stream
3
MTP
RTP
Stream
TDM
PSTN
SIP Gateway
CIPT1 v4.13-19
SIP sends DTMF in-band digits, while Cisco CallManager supports only out-of-band digits. An
RFC 2833-compliant Media Termination Point (MTP) device is required to monitor the
payload type and translate between in-band and out-of-band payload types.
3-26

This example shows the MTP software device processing in-band DTMF digits from the SIP IP
Phone to communicate with PRI gateway. The Real-Time Transport Protocol (RTP) stream
carries RFC 2833 DTMF, as indicated by a dynamic payload type.
1. The SIP IP Phone initiates a payload type response when the user enters a number on
the keypad. The SIP IP Phone transfers the DTMF in-band digit (per RFC 2833) to the
MTP device.
2. The MTP device extracts the in-band DTMF digit and passes the digit out of band to
Cisco CallManager.
3. Cisco CallManager then relays the DTMF digit out of band to the gateway or IVR
system.

This example shows the software MTP device receiving the DTMF out-of-band tones and
generating DTMF in-band tones to the SIP client.
1. The SCCP IP Phone user presses buttons on the keypad. Cisco CallManager collects
the out-of-band digits from the SCCP IP phone.
2. Cisco CallManager passes the out-of-band digits to the MTP device.
3. The MTP device converts the digits to RFC 2833 RTP-compliant in-band digits and
forwards them to the SIP client.
3-27
Configuring SIP Trunks
This topic discusses how to create SIP trunks to route calls via a Cisco SIP Proxy Server to a
SIP endpoint.
Cisco CallManager 4.1(2) SIP Trunk

Configuration
SCCP Phones
172.16.1.1
SIP Network
Proxy server
address
172.16.3.1
SIP Phones
Port Cisco CallManager uses to

send SIP traffic to proxy server
Port Cisco CallManager listens to
for incoming SIP traffic
CIPT1 v4.13-20
Follow these steps to add a SIP trunk in Cisco CallManager Administration:
3-28
Step 1
Choose Device > Trunk > SIP Trunk in Cisco CallManager Administration to
display the Trunk Configuration window.
Step 2
Click Add a New Trunk and choose SIP Trunk from the Trunk Type drop-down
menu. The Device Protocol field is automatically filled in.
Step 3
Assign the SIP trunk to the device pools, location, and automated alternate routing
(AAR) group as appropriate. The system checks the Media Termination Point
Required check box by default, and you cannot uncheck it. SIP functionality and
compliance with RFC 2833 (RTP Payload for DTMF Digits, Telephony Tones and
Telephony Signals) requires an RFC 2833-compliant MTP device.
Step 4
The Destination Address field indicates the IP address, fully qualified domain name
(FQDN), or Domain Name System (DNS) server address of the proxy server. It
applies to outgoing calls only; incoming calls do not use the destination address.
Step 5
The Destination Port field indicates the port through which to send SIP traffic to the
proxy server. The default specifies port 5060, which can be changed to any unique
value from 1024 to 65,535.
Step 6
The Incoming Port field is the port that Cisco CallManager listens to for incoming
SIP traffic. The default specifies port 5060, which can be changed to any unique
value from 1024 to 65,535.
Step 7
Summary
Summary
Cisco voice gateways enable Cisco CallManager to
communicate with non-IP telecommunications
devices.
Station gateways and trunk gateways are the two
types of analog gateways. The only type of digital
gateway is the Cisco access digital trunk gateway.
Voice gateways should support these core
requirements: DTMF relay, supplementary
services, server redundancy, and call survivability.
Cisco CallManager supports H.323, MGCP (Cisco
IOS and gateways), and SCCP gateway protocols.
CIPT1 v4.13-22
Summary (Cont.)
Configuring gateways requires configuring the
gateway itself and configuring Cisco CallManager.
Cisco CallManager supports intercluster trunks
(gatekeeper and nongatekeeper-controlled), H.225
trunks (gatekeeper-controlled), and SIP trunks.
Configuring intercluster trunks requires the IP
address of the remote Cisco CallManager.
SIP is a peer-peer, ASCII-based, IETF-standard
signaling protocol for multimedia calls and
conferences.
SIP trunks (or signaling interfaces) connect Cisco
CallManager clusters with a SIP proxy server.
CIPT1 v4.13-23
3-29
References
Cisco Systems, Inc. Cisco CallManager System Guide, , Release 4.1(3), Understanding
Cisco CallManager Voice Gateways, Understanding Session Initiation Protocol (SIP),
and Understanding Cisco CallManager Trunk Types section in Call Admission Control.
http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_1/sys_ad/4_1_
3/ccmsys/index.htm.
Cisco Systems, Inc. Cisco CallManager Administration Guide, Release 4.1(3), Gateway
Configuration and Trunk Configuration.
3/ccmcfg/index.htm.
Cisco Systems, Inc. WAN Switching Products.
http://www.cisco.com/warp/public/779/largeent/select_products/wan/WAN_ms.html.
3-30
Lesson 3-2
Configuring Basic Route Plans

Overview
To determine where to route calls, Cisco CallManager requires knowledge of the patterns of
digits that users dial to reach a particular telephone number. These patterns include access
codes, area codes, and combinations of the digits that are dialed. The route plan is the set of
configurable lists that provide Cisco CallManager with the knowledge of where to route calls.
Related to call routing is call distribution, which, simply put, is the ability to specify the order
and other factors in which Cisco CallManager extends calls to members of a group.
This lesson discusses the basic components of a route plan within Cisco CallManager. Basic
components of a route plan include route groups, route lists, and route patterns.
Objectives
Upon completing this lesson, you will be able to configure basic route plans that include route
groups, route lists, and route patterns to place calls over the IP WAN and PSTN and to analog
devices that are attached to access gateways. This ability includes being able to meet these
objectives:
Identify the necessary elements for creating external route plans in Cisco CallManager,
including gateways and trunks, route groups, route lists, and route patterns
Explain how route groups are used to prioritize and group gateways to send external calls
out of a preferred path and keep a backup path for redundancy
Explain how route lists are used to prioritize route groups that contain different types of
gateways that connect to the IP WAN or PSTN
Explain how to create route patterns that use wild cards to route calls to gateways or route
lists
Describe how Cisco CallManager analyzes dialed digits to determine where to route calls
Describe how route groups, route lists, and route patterns are used in a basic route plan to
route calls to the IP WAN or PSTN
External Call Routing
This topic explains external call routing in a basic route plan.
Route Plan Call Types

Route
Pattern
9.1408xxxxxxx
Cisco CallManager
1000
1001
Gatekeeper
GK
Remote
Cisco CallManager
IP WAN
Router/Gateway
PSTN
914085264000
Cisco CallManager routes two basic call types:

Internal (on-cluster) callsDestination DN is registered with Cisco
CallManager.
External (off-cluster) callsExternal route patterns must be
configured on Cisco CallManager.
CIPT1 v4.13-3
When you place a call from a Cisco IP Phone, Cisco CallManager analyzes the dialed digits. If
the dialed number matches a directory number (DN) that is registered with the Cisco
CallManager cluster, Cisco CallManager routes the call to the destination Cisco IP Phone that
is associated with the matching DN. This type of call is an internal (or on-cluster) call. Cisco
CallManager handles the call internally without the need to route the call to an external
gateway.
IP Phones are not the only devices that can place and receive internal calls; any device that
registers a DN with Cisco CallManager can place and receive internal calls. Examples of other
devices include the Cisco IP SoftPhone and analog telephones that are attached to Media
Controller Gateway Protocol (MGCP) or Skinny Client Control Protocol (SCCP, or
Skinny)-based gateways.
When a Cisco IP Phone dials a number that does not match a registered DN, it assumes that the
call is an external (or off-cluster) call. Cisco CallManager then searches its external route table
to determine where to route the call. Cisco CallManager uses the concept of route pattern and
translation pattern tables to determine where and how to route an external call. The route
pattern and translation pattern tables are very similar to the routing table that a Cisco router
maintains for routing data.
3-32
External Route Elements in

Cisco CallManager
Route pattern:
Route
Pattern
Matches dialed number for external calls

Performs digit manipulation (optional)
Points to a route list for routing
Route list:
Chooses path for call routing

Points to prioritized route groups
Route
List
First
Choice
Route group:
Route
Group
Devices:
IP WAN
Route
Group
First
Choice
Performs digit manipulation

Points to the actual devices
Gateways (H.323, MGCP)

Gatekeeper
ICT
(remote Cisco CallManager)
Second
Choice
GK
Second
Choice
PSTN
CIPT1 v4.13-4
You can create external route plans based on a three-tiered architecture that allows multiple
layers of call routing as well as digit manipulation. Route patterns match external dial strings,
in which a corresponding route list will select available paths for the outbound call based on
priority. Cisco refers to these paths as route groups, which are very similar to the trunk group
concept in traditional PBX terminology. You can think of a route pattern as a static route with
multiple paths that you can prioritize. The figure shown depicts the three-tiered route plan
architecture.
In addition to facilitating multiple prioritized paths for a given dialed number, the route plan
can also provide unique digit manipulation for each path, based on the external network
requirements. Digit manipulation involves adding or subtracting digits from the original dialed
number to accommodate user dial habits and to ensure that the external network or PSTN
receives the correct digits to place a call.
3-33
Route Plan Configuration Process

MGCP-Based
Add gateway devices

and trunks.
VG200
Cisco Catalyst
6000 Gateways
2600
Build route groups from

available devices.
Build route lists from

available route groups.
Build a route pattern to

available route lists or
gateway devices.
3600
H.323-Based
All Cisco IOS Gateways
Device Protocol
H.225
Remote Cisco CallManager

Device Protocol
Intercluster Trunk
Route Group 1
Route Group 2
Remote Cisco
CallManager
Cisco Catalyst
6000 Digital
2600 (MGCP)
2600 (MGCP) Digital
3640
VG200
Route List 1
Route Group 1
Route Group 2
Route Group 3
Route List 2
Route Group 2
Route Group 3
Route Group 1
CIPT1 v4.13-5
Shown here is the general process for route plan configuration. You can construct a route plan
using this process:
Step 1
Add gateway devices: Create gateway devices using the Device menu.
Step 2
Build route groups from available devices: Select and place gateway devices in an
ordered list to build a route group.
Step 3
Build route lists from available route groups: Select and order route groups into a
route list.
Step 4
Build route pattern: Build a route pattern and associate it with an available route
list or gateway device.
The route pattern is the key component in a route plan. The route pattern matches an external
dial string and routes the outgoing call to the appropriate gateway. When the dialed digits
match a route pattern, Cisco CallManager routes the call to the assigned route list or gateway.
3-34
Route Groups
This topic describes the functions and configuration of route groups.
Route Groups Overview
User Dials External Number
723-8912
Route Pattern
723-xxxx
Route List
Route groups create a

prioritized list of voice
gateways.
First
Choice
Digital GW 1
PSTN
Route Group
Second
Choice
Digital GW 2
CIPT1 v4.13-6
Route groups and route lists work together to control and enhance external call routing. They
also help with implementing cost savings and redundancy, which are among the features of a
Cisco IP telephony network.
Route groups are a logical grouping of device gateways. Prioritizing these device gateways
allows you to send external calls out of a preferred gateway (possibly across the IP WAN for
toll savings) and keep a backup path for external calls (usually the Public Switched Telephone
Network [PSTN]) if the primary gateway is down or unable to route the call.
You may encounter a scenario that requires multiple route groups, such as multiple
long-distance carriers. Each long-distance carrier offers different rates for long-distance calls
on its network. You can use route groups to prioritize the use of the cheaper carrier over the
others and retain redundancy if the cheaper carrier cannot route the call for some reason.
3-35
Route Group Configuration
Add gateways and trunks

to route group.
CIPT1 v4.13-7
Use these steps to configure a route group:

Step 1
Choose Route Group from the Route Plan menu in the Cisco CallManager
Administration window.
Step 2
Click the Add a New Route Group link. Give the new route group a name and click
Continue.
Step 3
Choose a gateway from the Available Devices menu to add that gateway to the
route group.
Step 4
Click Add or Update when finished.
The method that you use to configure route groups depends on the gateway types that you plan
to include in the group. Each gateway is an entity; you group H.323 gateways as a whole by
device. However, you can group MGCP gateways by ports, which means that individual ports
on MGCP gateways can be entities in a route group. The Order menu allows you to control the
priority of the gateways within a route group.
You should configure route groups by function. For example, all gateways to the PSTN can
belong to one route group, all gateways to long-distance carriers can belong to another (with
the cheapest carrier having priority), and all gateways across the IP WAN can belong to another
route group. If you want to control routing by gateway instead of by group of gateways or
ports, you can set up route groups so that they can contain only one gateway.
3-36
Route Lists
The topic describes the functions and configuration of route lists.
Route List Overview

User Dials Number
First Choice
Ports 18
Analog
Gateway 1
IXC
1
Analog
Gateway 2
IXC
2
Analog
Gateway 3
IXC
3
Route Pattern
Route Group 1
First
Choice
Second Choice
Ports 14
Route List
Second
Choice
First Choice
Ports 58
Route Group 2
Route lists are a

prioritized list of route
groups.
Second Choice
Ports 18
CIPT1 v4.13-8
Route lists consist of an ordered list of route groups. Route lists expand the route group concept
and allow you to order and prioritize your route groups. Although a gateway or group of ports
on a gateway can belong to only a single route group, route groups can belong to any number of
route lists. Route groups give you more control over external call routing.
With route lists, you can implement features such as toll bypass and PSTN fallback, because
within the route list you can prioritize route groups that contain different types of gateways (IP
WAN, PSTN, and so on).
Digit manipulation is the key to making toll bypass and PSTN fallback features transparent to
your users. Digit manipulation occurs in the form of calling-party and called-party
transformations.
Use calling-party transformations to manipulate caller ID information that is presented to the
called party. Use called-party transformations to actually manipulate the digits that are dialed.
You can apply calling- and called-party transformations at five different levels of the
call-routing process: at the originating device, as part of a translation pattern, as part of a route
pattern, as part of a route list, or at the terminating device. Calling and called-party
transformations that are set at the route list level override transformations that are set at any
other level.
Note
Calling- and called-party transformations are covered in detail in the Configuring Complex
Route Plans lesson later in this module.
3-37
Route List Configuration
Add and prioritize route groups.

CIPT1 v4.13-9
Complete these steps to configure a route list:
3-38
Step 1
Choose Route List, then Route/Hunt from the Route Plan menu in the main Cisco
CallManager Administration window.
Step 2
Click the Add a New Route List link. Give the new route list a name and
description, and choose the appropriate Cisco CallManager Group. Click Insert.
Step 3
Click the Add Route Group button to add the appropriate route groups. This action
displays the Route List Detail Configuration window. You can add route groups and
set calling- and called-party transformations at this point.
Step 4
Click Insert to return to the Route List Configuration window. Click Add Route
Group again to add additional route groups.
Step 5
Use the Up and Down arrows to prioritize the route groups.
Route Patterns
This topic describes route patterns for external call routing.
Route Pattern Overview
User Dials External Number
723-8912
Route patterns match

E.164 numbers and are
commonly used for
external call routing.
Route Pattern
723-xxxx
Route List
First
Choice
PSTN
Route Group
Second
Choice
Digital_GW_1
Digital_GW_2
CIPT1 v4.13-10
In the voice over IP (VoIP) world, route patterns are the equivalent of static routes. The only
difference is that route patterns point to E.164 numbers instead of IP addresses.
This topic covers external route patterns that are used for routing off-cluster calls. External
route patterns can point to either an individual gateway or a route list. Here is the call process if
the route pattern points to a route list:
1. When a user dials a number, Cisco CallManager analyzes the dialed digits. If the set of
digits matches a registered DN, Cisco CallManager routes the call to the internal
destination.
2. If the set of digits matches an external route pattern, Cisco CallManager then parses the
route list that is associated with that route pattern. The route list contains a prioritized list of
route groups, and the route groups contain a prioritized list of voice gateways.
3. If the preferred voice gateway is unavailable to handle the call, Cisco CallManager passes
the call to the next gateway, and so on, until it either finds a gateway to route the call to or
exhausts the list of gateways in the route group.
4. If Cisco CallManager exhausts the list of gateways in the route group, it passes the call to
the preferred gateway in the next route group in the route list. This process repeats until
Cisco CallManager finds a gateway that can handle the call or until it exhausts the list of
route groups in the route list. If Cisco CallManager is unable to find a gateway that can take
the call, the call fails and the end user receives a fast busy signal.
3-39
Route Pattern: Commonly Used Wildcards

Wildcard
Description
Single digit (0-9, *, #)
North American Numbering Plan
One or more digits (0-9)
[x-y]
Generic range notation
[^x-y]
Exclusion range notation
Terminates access code
Terminates interdigit timeout
CIPT1 v4.13-11
A route pattern is a sequence of digits and other alphanumeric characters. If a route pattern
contains digits only, it is an exact route pattern match and matches only one destination. By
including nonnumeric wildcards in a route pattern, you can allow the route pattern to represent
multiple destinations. The purpose of using wildcards is to reduce the number of route patterns
that you need to configure. For example, a single route pattern of 1xxx would match all dialed
numbers from 1000 to 1999.
Wildcards
3-40
Wildcard
Description
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, *, #
Single digits that can be included in a route pattern.
[xyz]
Set of matching digits. For example, [458] matches one occurrence of

either 4, 5, or 8.
[x-y]
Range of digits. For example, [3-9] matches one occurrence of either 3,

4, 5, 6, 7, 8, or 9. You can use the range notation along with the set
notation. For example, [3-69] matches one occurrence of either 3, 4, 5,
6, or 9.
[^x-y]
If the first character after the open square bracket is a carat, the
expression matches one occurrence of any digit (including * and #)
except those specified. For example, [^1-8] matches one occurrence of
9, 0, *, or #.
<wildcard>?
A question mark that follows any wildcard or bracket expression

matches zero or more occurrences of any digit that matches the
previous wildcard. For example, 9[12]? matches the following dial
strings: 9, 91, 92, 912, 9122, 92121, and many others.
<wildcard>+
A plus sign that follows any wildcard or bracket expression matches one
or more occurrences of any digit that matches the previous wildcard. For
example, 3[1-4]+ matches 31, 3141, 3333, and many others.
Route Pattern Examples
Pattern
Result
1234
Matches 1234.
1*1x
Matches numbers between 1*10 and 1*19.
12xx
Matches numbers between 1200 and 1299.
13[25-8]6
Matches 1326, 1356, 1366, 1376, 1386.
13[^3-9]6
Matches 1306, 1316, 1326, 13*6, 13#6.
13!#
Matches any number that begins with 13, is followed

by one or more digits, and ends with #; 135# and
13579# are example matches.
CIPT1 v4.13-12
Although the examples in the figure show four-digit extensions, you do not usually use route
patterns for internal numbers. Route patterns are normally in the form of seven-digit numbers,
such as 723-xxxx, or longer.
A great example is the 9.@ route pattern. The first digit of the route pattern matches a dialed
digit 9, which users commonly use as a code to gain outside access to the PSTN. The second
digit . is used to identify the first digit as an access code and all numbers afterward as the dial
string. The third digit @ is the wildcard that is used to match the North American Numbering
Plan (NANP).
3-41
The NANP encompasses a number of dial strings, as presented in the following table.
Dial Strings
Dial String
Description
Service calls
Service calls are in the form of three- to four-digit numbers that are
used to access telephony services such as 911, 411, 611, and so on.
Local calls
Local calls are in the form of a seven-digit number (xxx-xxxx) that is

used to dial within your local calling area.
Expanded local calls
Expanded local calls are in the form of a 10-digit number (xxx-xxxxxxx) that is used to dial expanded-area local calls.
Long-distance calls
Long-distance calls are in the form of a 10-digit number (xxx-xxxxxxx) that is used to place the calls directly to a long-distance carrier.
Direct-dial long-distance calls
Direct-dial long-distance calls are in the form of an

11-digit number (1-xxx-xxx-xxxx) that is used to place a long-distance
call through a local carrier.
International calls
International calls are in the form of 01 1 xx xxxxxxxxx where xx is

the country code. The actual length of the dial string depends on
which country the user is calling.
Note
3-42
This is a just a partial list of the different dial strings that the 9.@ route pattern will match.
The NANP and the 9.@ route pattern are covered in more detail in the Configuring
Complex Route Plans lesson.
Route Pattern Configuration
Classify call
as OnNet,
OffNet, or
Allow Device
Override
Configure a route pattern and point it to a gateway or route list.
CIPT1 v4.13-13
Complete these steps to configure a route pattern:

Step 1
Choose Route /Hunt, then Route Pattern from the Route Plan menu in the Cisco
CallManager Administration window.
Step 2
Click the Add a New Route Pattern link.
Step 3
To create a route pattern, enter your route pattern (including wildcards, if necessary)
in the Route Pattern field and choose a route list or gateway from the Gateway or
Route List menu.
Step 4
If you configure a route pattern to route off-network calls to the PSTN (which most
route patterns do), make sure to check the Provide Outside Dial Tone check box.
This feature plays a second dial tone for users when they dial the outside access
code.
If Cisco CallManager receives a dial string for which multiple route patterns match, Cisco
CallManager must wait for the interdigit timeout before applying the longest-match rule and
deciding which route pattern to use. The interdigit timeout parameter is also used with route
patterns that contain the ! wildcard. The ! wildcard indicates a variable-length dial string and
forces Cisco CallManager to wait for the interdigit timeout to expire before it can determine the
actual dial string that the user wants to dial.
You can override the interdigit timeout behavior for a specific route pattern by checking the
Urgent Priority check box. When a route pattern is marked as urgent, Cisco CallManager
immediately routes any outbound calls that match the pattern. This approach avoids the
interdigit timeout issue. However, you should use this option very carefully because it can
prevent users from reaching certain destinations if it is configured incorrectly. Urgent Priority
is most often used for the 911 and 9911 route patterns.
3-43
If your route patterns point to specific gateways and not to route lists, you can set calling-party
and called-party transformations at the gateway level. If calling- and called-party
transformations are set here and the route pattern points to a route list, Cisco CallManager
overrides the gateway-level transformation settings and instead uses the transformation settings
that are configured on the route list.
Near the bottom of the Route Pattern Configuration window, you will find the ISDN
Network-Specific Facilities Information Element configuration. This feature allows you to
enter the appropriate carrier identification code (up to four digits) to route long-distance calls to
specific interexchange carriers on a route pattern-by-route pattern basis.
As of Cisco CallManager Release 4.1, you can classify a route pattern as OnNet or OffNet with
an additional option to allow the device associated with the route pattern to override the call
classification settings configured in the Route Pattern Configuration window.
If Allow Device Override is checked, the setting of the associated device classifies the outgoing
call as OnNet or OffNet. If Allow Device Override is unchecked, the Call Classification field in
the Route Pattern Configuration window classifies the outgoing call as OnNet or OffNet. This
feature is useful in cases where a route list is associated with a route pattern and the gateway or
trunk device setting (OnNet or OffNet) is considered to classify the outgoing call.
3-44
Digit Analysis
This topic explains the digit analysis behavior of Cisco CallManager.
Dialing Behavior
1000
Route Patterns
Dialed Digits
List Potential Matches
<none>
1
List Current Match
Call Setup
1XXX
10XX
1001
CIPT1 v4.13-14
Call-routing component behavior can be counterintuitive. Whenever a user places a call from a
device that is registered with Cisco CallManager, Cisco CallManager must analyze each dialed
digit to determine where to route the call. In collecting dialed digits, the call-routing component
goes through the following process:
1. Cisco CallManager compares the current sequence of dialed digits against the list of all
route patterns and determines which route patterns currently match. Then, Cisco
CallManager names the set of route patterns currentMatches.
If currentMatches is empty, the user-dialed digit string does not currently correspond
with a destination.
If currentMatches contains one or more members, the call-routing component

determines the closest match. The closest match is the route pattern in
currentMatches that matches the fewest number of route patterns. For example, the
dialed digit string 1001 matches both route pattern 1xxx and 10xx. Although there
are 1000 different dialed digit strings that match 1xxx, only 100 dialed digit strings
match 10xx. Therefore, 10xx is the closest match.
3-45
2. While performing the first step, Cisco CallManager determines whether different route
patterns might match if the user were to dial more digits. Cisco CallManager names the
condition of having potential matches for a dialed digit string potentialMatches.
3-46
If potentialMatches holds true, the call-routing component waits for the user to dial
another digit. If the user dials another digit, the sequence of events restarts at the
first step using the new digit string.
If potentialMatches no longer holds true or a dialing timeout has elapsed, then the
call-routing component selects a destination.
To select a destination, the call-routing component looks at the closest match. If

there is no closest match, the dialed digit string does not correspond with a
destination. If no more digits are forthcoming, Cisco CallManager rejects the call
attempt.
Otherwise, Cisco CallManager extends the call to the device that is associated with
the closest match.
Digit Collection
User dial string:
1111
Match!
1111
121X
Does not match
1[23]XX
Does not match
131
Does not match
13[0-4]X
Does not match
13!
Does not match
Cisco CallManager actions:

No other patterns could
match; extend call.
CIPT1 v4.13-15
This figure details a call-routing example in which one route pattern matches the dialed digits
exactly. The Cisco CallManager in this example includes the route patterns shown in the figure.
When the user goes off hook, Cisco CallManager begins its routing process. The current set of
collected digits is empty. Every route pattern that Cisco CallManager has configured is a
potential match at this point. As long as the potentialMatches condition holds true, Cisco
CallManager must wait for more digits.
The user now dials a 1. At this time, there are no current matches and every route pattern is still
a potential match. The user dials another 1. At this point, Cisco CallManager eliminates route
patterns 121x, 1[23]xx, 131, 13[0-4]x, and 13! as potential matches. The only route pattern left
is 1111. However, because there are no current matches and the potentialMatches condition is
still true, Cisco CallManager must continue to analyze digits. This requirement is in place
because the user may continue dialing and dial a string that does not match any entries.
The user dials another 1, which does not change anything. The condition currentMatches is
false, and potentialMatches is still true. The user dials 1 again. At this point, the route pattern
1111 is a match, and the currentMatches condition is true. Cisco CallManager removes the
route pattern 1111 from the potential matches table. Because there are no more route patterns in
the potential matches table, additional dialed digits will not cause Cisco CallManager to match
a different route pattern. At this point, Cisco CallManager routes the call to the dialed
destination.
3-47
Closest Match Routing
User dial string:
1111
Does not match
1211
121X
Match!
1[23]XX
Match!
Matches 10 digit strings

Select as closest match
131
Does not match
13[0-4]X
Does not match
13!
Does not match
CIPT1 v4.13-16
This figure details a closest-match call-routing example. The Cisco CallManager that is used in
this example includes the route patterns shown in the figure.
The user dials the digits 12. At this point, Cisco CallManager eliminates the route patterns
1111, 131, 13[0-4]x, and 13! as potential matches. This leaves route patterns 121x and 1[23]xx
as potential matches. Because there are no current matches and the potentialMatches condition
is true, Cisco CallManager continues to analyze digits.
The user dials another 1, which does not change anything. The condition currentMatches is
false, and potentialMatches is still true. The user dials 1 again. At this point, the route patterns
121x and 1[23]xx are current matches, and Cisco CallManager removes them from the potential
matches table. Because the potential matches table does not contain additional route patterns,
additional dialed digits will not cause Cisco CallManager to match any different route patterns.
Now, Cisco CallManager must decide where to route the call based on the route patterns that
are available in the current matches table. This is where the closest-match rule is applied. The
route pattern 121x matches 10 destinations (1210 to 1219). The route pattern 1[23]XX matches
200 destinations (1200 to 1299 and 1300 to 1399). Cisco CallManager then routes the call to
the gateway or route list that is associated with the 121x route pattern.
3-48
Interdigit Timeout
User dial string:
1111
Does not match
1311<timeout>
121X
Does not match

Select as closest match
Matches
1[23]XX
131
Match!
Does not match
13[0-4]X
Match!
13!
Match!
digit strings
CIPT1 v4.13-17
If you configure a Cisco CallManager with route patterns that contain wildcards that match
multiple digits, CallManager must often wait for the interdigit timeout to expire before routing
the call. The ! wildcard usually represents a variable-length dial string and will never be an
exact match for a group of dialed digits. (If the user presses # after dialing the last digit, Cisco
CallManager does not wait for the interdigit timeout.) The Cisco CallManager in this example
includes the route patterns shown in the figure.
In this example, the user has dialed the string 1311. This action causes Cisco CallManager to
eliminate the route patterns 1111, 121x, and 131. Cisco CallManager places the route patterns
1[23]xx, 13[0-4]x, and 13! in the current matches table. The 13! route pattern remains in the
potential matches table. The 13! route pattern ensures that the potentialMatches condition is
always true, because Cisco CallManager has no way of knowing whether the user intends to
continue dialing. For example, the user may intend to dial the number 1311555. As long as the
potentialMatches condition is true, Cisco CallManager must continue to wait for dialed digits.
In this case, the only event that allows Cisco CallManager to select a destination is an interdigit
timeout. When the interdigit timeout timer expires, Cisco CallManager knows that no more
digits are forthcoming and can now make a final routing decision. In this example, the user has
dialed 1311 and then stopped dialing digits. This action has triggered an interdigit timeout and
caused Cisco CallManager to make a final decision based on the following route patterns in the
current matches table: 1[23]xx, 13[0-4]x, and 13!. Because the dial string of 1311 matches
multiple route patterns, the closest-match rule is applied.
The route pattern 1[23]xx matches 200 destinations (1200 to 1299 and 1300 to 1399). The route
pattern 13[0-4]x matches 50 destinations (1300 to 1349). The route pattern 13! matches an
infinite number of destinations. Cisco CallManager uses this pattern only if it is the only route
pattern in the current matches table. The call is routed to the gateway or route list that is
associated with the 13[0-4]x route pattern.
3-49
Note
3-50
The system interdigit timeout defaults to 15 seconds. To change it, change the value that is
associated with the Cisco CallManager service parameter TimerT302_msec. This parameter
defines the duration of the interdigit timer in milliseconds (ms). The default is 15,000 ms.
Summary of Call Routing
This topic summarizes the call-routing process.
Simple Route Plan Example

Route pattern can match
route list or gateway.
User Dials Number

408-555-XXXX
Route
Pattern
723-XXXX
836-XXXX
868-XXXX
Local_GW
Route
Pattern
First
Choice
RL_PSTN
Route List
$0.07 per min.
RG_PSTN
PSTN
Route Group
Second
Choice
Cisco Access
Digital_GW_1
LEC
Cisco Access
Digital_GW_2
$0.10 per min.

CIPT1 v4.13-18
The figure details a simple route plan. In this scenario, the network administrator has
configured two gateways for long-distance access to the PSTN (Digital_GW1 and
Digital_GW2). Digital_GW1 connects to a carrier that offers a long-distance rate of 7 cents per
minute. Digital_GW2 connects to a carrier that offers a long-distance rate of 10 cents per
minute.
The network administrator has created a route group RG_PSTN to group these gateways and
give first priority to Digital_GW1. The route list RL_PSTN uses the route group RG_PSTN.
Currently, users need only to call long distance to one destination, which is a remote office in
San Jose, California. Therefore, the administrator has created the San Jose route pattern 408555-XXXX. This route pattern then associates directly with the RL_PSTN route list.
Users also need to dial off-cluster to the PSTN to reach destinations within the local calling
area. A separate gateway (Local_GW) connects to the local exchange carrier (LEC) for local
PSTN calls. The administrator has defined the route patterns 723-XXXX, 836-XXXX, and
868-XXXX for local calls. These route patterns point directly to the Local_GW gateway for
local PSTN access through the LEC.
3-51
Route Plan Example 2

Secondary Voice Path
Gatekeeper(s)
Prepend 1408 and send to PSTN
Users required to dial

7 digits for intersite calls
526-1111
A
PSTN
Philadelphia
San Jose
(408) 526-xxxx
5-Digit Internal Dialing
(215) 555-xxxx
5-Digit Internal Dialing
IP WAN
Primary Voice Path

Strip 52 and deliver
61111 to remote Cisco CallManager

CIPT1 v4.13-19
This figure details a more complex route plan, including features such as toll bypass and PSTN
fallback. In this example, the ABC Company has two main offices, in San Jose and
Philadelphia. The users at ABC Company dial five-digit extensions to reach users within the
same site (5xxxx in Philadelphia and 6xxxx in San Jose). As you can see in the figure, each site
has its own Cisco CallManager cluster. You can classify these types of calls as on-cluster, or
internal, calls.
The users also dial seven-digit numbers to reach users in other sites (526-xxxx to reach San Jose
and 555-xxxx to reach Philadelphia). The calls between sites are off-cluster, or external, calls
and require the configuration of a route plan. In this example, when a user in Philadelphia dials
526-1111, the local Cisco CallManager cluster analyzes the dialed digits and looks for a match.
In this case, 526-1111 matches the route pattern of 9.@ (which symbolizes the NANP).
At this point, the Cisco CallManager knows that it must route this external call to a gateway.
Cisco CallManager now looks at the route list that is associated with the 9.@ route pattern to
determine the correct gateway. In this example, Cisco CallManager uses the gateway that is
connected to the IP WAN first, for cost reasons (toll bypass). Before Cisco CallManager can
route the call across the IP WAN, it must perform digit manipulation (in the form of a
called-party transformation) so that the remote Cisco CallManager can receive the call in a
format that it understands (five-digit numbers).
If the IP WAN is down or the IP WAN does not have sufficient resources, Cisco CallManager
can route the call across the gateway that is connected to the PSTN. Because a call from
Philadelphia to San Jose across the PSTN is a long-distance call, Cisco CallManager must
perform digit manipulation (in the form of a called-party transformation) to change the dial
string of 526-1111 to 1-408-526-1111, which allows the PSTN to understand the dialed digits.
The call-routing process is transparent to the end users, and they are not able to discern whether
Cisco CallManager has routed the call over the IP WAN or the PSTN.
3-52
Basic Route Plan Summary

Cisco Gateways
First Choice
Route Pattern 9.@
Route
List
Route First Choice

Group A
Digital Gateway
$0.08 per Minute
WS-X6608-T1
Group B Second Choice $0.12 per Minute
Global Switch
or PBX
Second Choice Route
Third Choice
Route First Choice

Group C
Second Choice
WS-X6624-FXS
$0.15 per Minute
Global Switch
or PBX
Global Switch
or PBX
Route Pattern 8.@
CIPT1 v4.13-20
A basic route plan consists of voice gateways and trunks, route groups, route lists, and route
patterns.
Route patterns (required) should represent all valid digit streams. Route patterns can be
assigned directly to a gateway, or they can be assigned to a route list for more flexibility, such
as setting a digital access gateway as the first choice for the least expensive route.
Route patterns on gateway devices can be assigned to a specific port or to all ports (depending
on the gateway).
A route list (optional) sets the route group usage order. If a route list is used, you must also
configure route groups.
A route group or route groups (optional) set the access gateway device usage order. This order
can be used to select the least expensive route and allows overflow from a busy or failed device
to an alternate device.
The recommended route configuration order is to add the gateway, add a route group for the
gateway, add a route list for the route group, and add route patterns to the route list.
A route plan is required to route external, or off-cluster, calls in a Cisco IP telephony network.
By understanding the call-routing process of Cisco CallManager, you can design your route
plan to take advantage of cost considerations and redundancy.
3-53
Example: Route Plan

In the figure, the 9.@ route pattern points to the route list. The 8.@ route pattern points directly
to the Cisco WS-X6624-FXS analog gateway. The route list contains three priority-ordered
route groups: Route Group A, Route Group B, and Route Group C. Each of these route groups
has priority-ordered lists of access gateways.
When a user dials 9, followed by a valid dial string, Route Group A will first try to route calls
through the least expensive route, the digital gateway (8 cents per minute). If the digital
gateway is unavailable, then Route Group A will route calls through the WS-X6608-T1 Voice
Services module (12 cents per minute).
Route Group B consists of three gateways. Route Group B will first choose the digital gateway,
and then WS-X6608-T1. If both are busy, then Route Group B will try to route the call through
the most expensive route, WS-X6624-FXS (15 cents per minute).
Cisco CallManager will try to route calls through Route Group C only if all the resources in
Route Groups A and B are unavailable. Route Group C will try to place calls only through
WS-X6624-FXS (15 cents per minute).
When a user dials 8, followed by a valid dial string, Cisco CallManager will route the call
directly to the WS-X6624-FXS access gateway.
3-54
Summary
Summary
Cisco CallManager routes internal calls by matching
the registered DN to a destination. External calls do not
have a registered DN, and Cisco CallManager will
search for a matching pattern in the route plan.
Route groups are a logical grouping of device
gateways and trunks.
Route lists consist of an ordered list of route groups.
You use external route patterns for routing off-cluster
calls. External route patterns can point to either an
individual gateway or a route list.
Cisco CallManager uses closest-match routing.
A basic route plan consists of voice gateways and
trunks, route groups, route lists, and route patterns.
CIPT1 v4.13-21
3-55
References
Cisco Systems, Inc. Cisco CallManager System Guide, Release 4.1(3), Understanding
Route Plans.
3/ccmsys/a03rp.htm.
Cisco Systems, Inc. Cisco CallManager Administration Guide, Release 4.1(3), Route
Group Configuration, Route List Configuration, and Route Pattern Configuration.
3/ccmcfg/index.htm.
3-56
Lesson 3-3
Configuring Hunt Groups and

Call Coverage
Overview
Many businesses have sales or service support departments that work as group to handle
inbound calls from prospective and current customers. These businesses typically need several
phone lines and a method to make the lines work together so that if one representative is busy
or not available, the call will rotate to other members of the group until it is answered or
forwarded to an autoattendant or voice mail. Hunt groups are the mechanisms that help these
businesses manage inbound calls. A hunt group is a group of telephone lines that are associated
with a common number. When a call comes in to the number associated with the hunt group,
the call cycles through the group of lines until an available line is found. This process is known
as hunting.
This lesson discusses how to configure hunt groups and enable the Call Coverage feature to
ensure that the caller will receive final forwarding treatment if hunting fails (that is, when no
hunt party answers, either because the hunt has exhausted the list of hunt numbers or because it
has timed out).
Objectives
Upon completing this lesson, you will be able to create a hunt group consisting of line groups,
hunt lists, and a hunt pilot that provides call coverage if hunting exhausts. This ability includes
Define call-distribution components and algorithms
Describe how hunting differs from forwarding and how the Call Coverage feature extends
hunting to allow final forwarding if hunting exhausts
Configure line groups, hunt lists, and a hunt pilot to create a hunt group
Configure hunting with internal and external forwarding support specifications for busy, no
answer, and no call coverage
Given usage scenarios, determine the hunting and forwarding behavior that results
Call Distribution Overview
This topic defines call-distribution components (line groups, hunt lists, and hunt pilots) and
algorithms.
Call-Distribution Components
1-800-555-0111
Line groups, hunt lists, and

hunt pilots work together to
provide call-distribution
capabilities.
Hunt Pilot
Line groupDesignates the

order in which directory
numbers are chosen
Hunt List
Hunt listContains line

groups
Hunt pilotNumber
associated with a hunt list;
caller can reach someone by
dialing the hunt pilot number
Line Group 1
1000
1001
Line Group 2
1003
1004
CIPT1 v4.13-3
Line groups, hunt lists, and hunt pilots work together to provide call-distribution capabilities in
Cisco CallManager Administration. Call distribution is the ability of a caller to dial a single
number and have the call extend in an ordered manner to members of a groupfor example, an
800 number to reach a company technical support department.
A line group contains directory numbers (DNs) and designates the order in which DNs are
chosen.
A hunt list contains one or more line groups.
A hunt pilot is a number that is associated with a hunt list. The hunt pilot can be called directly
(for example, to a technical support hotline for a company), or can be reached through
forwarding (for example, a caller places a direct call to a technical support group member, and
if that member is not available, the call is forwarded to the hunt pilot number).
3-58
Line Groups
Line groups contain:
One or more members (DNs). Members can be:
IdleNot serving any call
AvailableServing an active call but can accept new calls
BusyCannot accept any calls
An algorithm for how to distribute calls to members
Ring No Answer Reversion (RNAR) timeout valueA
mechanism for how to handle calls that go unanswered
Hunt optionsThe ability to roll past members who are busy,
not available, or do not answer until the call is answered or
options are exhausted
CIPT1 v4.13-4
A line group allows you to designate the order in which DNs are chosen.
Line groups contain the following components:
Members (DNs) that are in one of these states:
Idle: Not serving any call
Available: Serving an active call but able to accept new calls
Busy: Unable to accept any calls
An algorithm for how to distribute calls to members.

Ring No Answer Reversion (RNAR) timeout value: A mechanism for determining how
to handle calls that go unanswered. The RNAR is a value, in seconds, after which Cisco
CallManager will distribute a call to the next available or idle member of this line group or
to the next line group if the call is not answered and if the first hunt option, Try Next
Member; Then, Try Next Group in Hunt List, is chosen. The RNAR timeout applies at the
line-group level to all members.
Hunt options: The ability to roll past members who are busy, not available, or do not
answer, continuing until the call is answered or options are exhausted.
Cisco CallManager distributes a call to idle or available members of a line group based on the
call-distribution algorithm and on the RNAR setting.
3-59
Call Distribution Algorithms

Top down: Idle and available
members, round robin.
(Next call to 1000.)
Line Group 1
1000
1001
Idle
10 min.
Available
1002
1003
Available, Cisco Idle

CallManager 5 min.
last extended
call
The call-distributing algorithm

is applied at the group level.
Circular: (n + 1)th member

where n is the member to
which Cisco CallManager most
recently extended call.
(Next call to 1003.)
Longest idle time: Idle
members only, from most to
least idle. (Next call to 1000.)
Broadcast: All idle and
available members
simultaneously.
(Next call to all DNs.)
CIPT1 v4.13-5
Line groups contain an algorithm that controls how calls that come in on the hunt pilot are
distributed to members, as follows:
Top down: If you choose this distribution algorithm, Cisco CallManager distributes a call
to idle or available members starting from the first idle or available member of a line group
to the last idle or available member. This method is sometimes called a round robin. In the
figure, a top-down distribution algorithm would extend the next call to 1000, then to 1001,
then to 1002, then 1003, and back to 1000.
Circular: If you choose this distribution algorithm, Cisco CallManager distributes a call to
idle or available members starting from the (n+1)th member of a line group, where the nth
member is the member to which Cisco CallManager most recently extended a call. If the
nth member is the last member of a line group, Cisco CallManager distributes a call starting
from the top of the line group. In the figure, assume that Cisco CallManager extended the
last call to 1002 (n). The next call that comes in on the hunt pilot number would go to 1003
(n + 1)
Longest idle time: If you choose this distribution algorithm, Cisco CallManager distributes
a call only to idle members, starting from the member of a line group who has been idle
longest to the member who has been idle for the shortest time. In the figure, assume that
1000 has been idle for 10 minutes and 1003 has been idle for 5 minutes. A longest idle time
distribution mechanism would extend the call to 1000, and the next incoming call would go
to 1003.
Broadcast: If you choose this distribution algorithm, Cisco CallManager distributes a call
to all idle or available members of a line group simultaneously.
Distribution algorithms are applied at the line group level in Cisco CallManager
Administration.
3-60
Hunt Options
For busy, no answer, or not available:
Try Next Member, Then, Try Next Group in Hunt List (Default)
Distributes a call to idle or available members. If no answer (or
busy or not available), try the next line group in a hunt list.
Try Next Member, but Do Not Go to Next Group
Distributes a call to idle or available members. Stops hunting
upon reaching the last member of the current line group.
Skip Remaining Members, and Go Directly to Next Group
Skips the remaining members of current line group when the
RNAR timeout value elapses for the first member (or first member
is busy or not available). Hunting proceeds to the next line group
in a hunt list.
Stop Hunting
Stops hunting after trying to distribute a call to the first member
of current line group if the member does not answer (or first busy
member or first unavailable member)
Hunt options are applied at the member level.
CIPT1 v4.13-6
Hunt options are applied at the member level and apply to members in one of the three states:
no answer, busy, or not available. For a given distribution algorithm, the hunt option specifies
where a call should be distributed next if a call is distributed to a member of a line group that is
busy, does not answer, or is not available.
Call Distribution Scenarios: Top-Down

Example
Line Group 1: Contains DNs 1000, 1001, and 1002
1-800-555-0111
Distribution algorithm: Top-down
Hunt Pilot
RNAR timeout: 10 seconds

Hunt option:
RNA = Try Next Member, Then, Try Next Group
in Hunt List
Hunt List
Busy = Try Next Member, Then, Try Next Group

in Hunt List
Not Available = Try Next Member, Then, Try Next
Group in Hunt List, RNAR timeout = 10 seconds
Line Group 1
Call flow:
Caller calls hunt pilot 1-800-555-0111.
1000 rings and is not answered
for 10 seconds (RNAR).
1000
1001
1002
1001 rings for three seconds, 1001

is answered.
CIPT1 v4.13-7
3-61
The figure shows an example of a line group (Line Group 1) with the following setup
information:
Line Group 1: Contains DNs 1000, 1001, and 1002
Distribution algorithm: Top down
RNAR timeout: 10 seconds. After 10 seconds, Cisco CallManager will distribute a call to
the next available or idle member of this line group or to the next line group if the call is
not answered and if the first hunt option, Try Next Member; Then, Try Next Group in Hunt
List, is chosen.
Hunt Option:
RNA = Try Next Member; Then, Try Next Group in Hunt List
Busy = Try Next Member; Then, Try Next Group in Hunt List
Not available = Try Next Member; Then, Try Next Group in Hunt List
The call flow is as follows:

1. Caller calls hunt pilot 1-800-555-0155
2. 1000 rings and is not answered for 10 seconds (RNAR timeout).
3. The call extends next to 1001 following the top-down algorithm and RNAR setting.
4. 1001 rings for 3 seconds.
5. 1001 is answered.
Call-Distribution Scenarios:
Circular Example
Line Group 1: Contains DNs 1000, and 1001
Distribution algorithm: Circular
1-800-555-0111
Hunt Pilot
Hunt option:
in Hunt List
in Hunt List
Hunt List
Not Available = Try Next Member, Then, Try Next Group

in Hunt List
Call flow:
Caller calls hunt pilot 1-800-555-0111: 1000 rings and

answers the call.
Caller 2 calls hunt pilot: 1001 rings and answers the call.
Line Group 1
Callers 1 and 2 hang up.

Caller 3 calls hunt pilot: 1000 rings and answers the call.
3-62
1000
1001
CIPT1 v4.13-8
The figure shows an example of a line group (Line Group 1) with the following setup
information:
Line Group 1: Contains DNs 1000 and 1001
Distribution algorithm: Circular
Hunt option:
RNA = Try Next Member; Then, Try Next Group in Hunt List
Busy = Try Next Member; Then, Try Next Group in Hunt List
Not Available = Try Next Member; Then, Try Next Group in Hunt List
The call flow is as follows:

Caller 1 calls hunt pilot 1-800-555-0155.
1000 rings and 1000 answers the call (n).
1001 rings and 1000 answers the call (n + 1).
Caller 1 and 2 hang up.
Caller 3 calls hunt pilot 1-800-555-0155
1000 rings and 1000 answers the call.
If additional line groups were defined, when a call had been extended to all members
according to the circular distribution algorithm, the next call would go to the next line
group in the next hunt group.
Call-Distribution Scenarios:
Longest-Idle Example
Distribution algorithm: Longest idle, 1001 is idle
longer than 1000
Hunt option:
in Hunt List
in Hunt List
Not Available = Try Next Member, Then, Try Next
Group in Hunt List
Call flow:
Caller 1 calls hunt pilot 1-800-555-0111:
1001 answers the call (idle longer).
Caller 2 calls hunt pilot: 1000 answers the call.
1-800-555-0111
Hunt Pilot
Hunt List
Line Group 1
1000
1001
CIPT1 v4.13-9
The figure shows an example of a line group (Line Group 1) with a longest idle distribution
algorithm.
3-63
Call Distribution Scenarios:

Broadcast Example
Distribution algorithm: Broadcast
Hunt option:
in Hunt List
in Hunt List
Not Available = Try Next Member, Then, Try
Next Group in Hunt List
Call flow:
Lines 1000 and 1001 ring.
1001 answers the call.
1000 stops ringing.
1-800-555-0111
Hunt Pilot
Hunt List
Line Group 1
1000
1001
CIPT1 v4.13-10
The figure shows an example of a line group (Line Group 1) with a broadcast distribution
algorithm.
3-64
Hunting and Forwarding
This topic discusses the difference between hunting and forwarding and introduces the Call
Coverage feature that extends hunting to allow final forwarding if hunting exhausts.
Hunting and Call Forwarding

Forwarding: Allows users to specify how calls to their
numbers can be redirected when user fails to answer a call
(CFNA) in a specified time interval or when the user is busy
(CFB).
Hunting: Allows a call to be directed to a list of line groups
where each group can independently use one of three
algorithms (broadcast, top down, or circular).
Hunting commences by calling a hunt pilot number
associated with a hunt list.
The hunt pilot can be called directly or can be reached
through forwarding.
While hunting, the forwarding fields of the hunt parties are
ignored; the determination of which phone to ring next is
determined by the line groups within the hunt list.
CIPT1 v4.13-11
Hunting differs from call forwarding, although both allow calls to be redirected. Hunting allows
Cisco CallManager to extend a call to one or more lists of numbers, where each such list can
specify a hunting order that is chosen from a configurable set of algorithms. When a call
extends to a hunt party from these lists and the party fails to answer or is busy, hunting resumes
with the next hunt party. (The next hunt party varies depending on the current hunt algorithm.)
Hunting thus ignores the Call Forward No Answer (CFNA) or Call Forward Busy (CFB)
settings for the attempted party.
Call forwarding allows detailed control as to how to extend (divert and redirect are equivalent
terms for extend) a call when a called party fails to answer or is busy and hunting is not taking
place. For example, if the CFNA setting for a line is set to a hunt pilot number, an unanswered
call to that line diverts to the hunt pilot number and thus begins a hunt.
Starting with Cisco CallManager Release 4.1, Cisco CallManager offers the ability to redirect a
call when hunting fails (that is, when hunting terminates without any hunt party answering,
either because the list of hunt numbers exhausts or because the hunt process times out). If used,
this final redirection constitutes a Call Forwarding action. Therefore, the Hunt Pilot
Configuration window in Cisco CallManager Administration (choose Route Plan >
Route/Hunt > Hunt Pilot) includes Call Forwarding configuration concepts that are similar to
those found in the Directory Number Configuration window.
In Cisco CallManager Release 4.0, hunting stops either when one of the hunt parties answers
the call or when the hunt list is exhausted. When hunting stops due to exhaustion, the caller
receives a reorder tone (or an equivalent announcement).
3-65
Basic Call Hunting Example

1. Caller dials party A
Party A
2. Forwards call
to hunting
3. Call hunts through
hunt groups
according to
distribution
algorithm
4. Hunting either:
Hunt Pilot
SucceedsHunt party
answers
ExhaustsAll hunt parties
are attempted, but none
answer
Times outMaximum hunt
timer expires before all
parties are attempted, and
none of the parties that
were attempted answer
CIPT1 v4.13-12
Although hunting differs from forwarding, hunting often originates as a call that was forwarded
to a hunt pilot number. The Call Coverage feature introduced in Cisco CallManager Release 4.1
extends hunting to allow final forwarding after hunting either exhausts or times out.
A typical call that invokes hunting can include the following phases:
1. A call extends to the original called party (Party A in the figure).
2. Party A forwards the call to hunting (a hunt pilot number); for example, because of the Call
Forward All (CFA), CFNA, or CFB setting for the original called line (Party A).
3. The call hunts through provisioned hunt groups (Cisco CallManager refers to them as line
groups) according to provisioned algorithms for each group. Algorithms include top-down,
circular, longest idle time, or broadcast.
4. Hunting either succeeds (if a hunt party answers), exhausts (if all hunt parties are
attempted, but none answer), or times out (if the time specified in the maximum hunt timer
runs out before all parties are attempted, and none of the parties that were attempted
answer).
3-66
Basic Call Hunting Example (Cont.)

4. Hunting does not
succeed
5. Final forwarding (if configured)
Or
Hunt
Forward
Settings
DN or Calling
Search Space
Personal
Treatment
External Forwarding
Support (CFB and
DN Call
CFNA)
Pickup and
Forward
Settings
Internal Forwarding
Support (CFB and
CFNA)
5. Call released (reorder tone) if final

forwarding is not configured
CIPT1 v4.13-13
For the purpose of this example, assume that hunting does not succeed in the fourth step.
5. If some form of final forwarding is configured, the call forwards to that destination;
otherwise, the call is released, and the caller receives a reorder tone.
Final Forwarding Treatment
Final forwarding specifications can be based on forwarding to a specified DN or calling search

space, or it can be based on personal treatment that is specific to the original called party
(Party A in the example). Different final forwarding treatment can be specified based on
whether hunting is exhausted because the line is busy or because there was no answer.
Forwarding provides separate configuration based on whether the originator of a call is an
internal user or an external user. This distinction applies to both CFB and CFNA cases. CFA
does not support this distinction because CFA can also be set from a phone display, and there is
no capability on a phone display to distinguish an internal CFA setting from an external one.
3-67
Configuring Line Groups, Hunt Lists, and Hunt

Pilots
This topic discusses how to configure hunting with internal and external forwarding support
specifications for busy, no answer, and no call coverage.
Configuring Line Groups, Hunt Lists,

and Hunt Pilot
1. Create line group, add DNs, and determine

distribution algorithm and hunt options.
2. Create hunt list and add line groups.
3. Create hunt pilot, associate hunt list, and
configure hunt forward settings.
CIPT1 v4.13-14
To access the line group, hunt list, and hunt pilot configuration windows in Cisco CallManager
Administration Release 4.1, choose Route Plan > Route/Hunt.
When configuring hunting, follow this general process:
Step 1
Create the line groups, add members, and configure the distribution algorithm and
hunt options.
Step 2
Create the hunt list and add the line groups.
Step 3
Create the hunt pilot, associate the hunt list with the hunt pilot, and configure hunt
forward settings.
These steps are covered in more detail on the following topics.
3-68
Configuring Line Groups
1. Assign a name to
the line group.
2. Add members to
the line group
(the DNs must
already exist).
3. Enable line group
configuration
settings.
CIPT1 v4.13-15
The general process for configuring a line group follows. The DNs that will become the
members of the line group must already exist in the database before you can complete this
procedure.
Step 1
Choose Route Plan > Route/Hunt > Line Group.
Step 2
Click Add a New Line Group.
Step 3
Enter a name in the Line Group Name field. The name can contain up to 50
alphanumeric characters and can contain any combination of spaces, periods (.),
hyphens (-), and underscore characters (_). Ensure that each line group name is
unique to the route plan.
Step 4
Configure the distribution algorithm, hunt options, and RNAR timeout as desired, or
leave them at their default values.
Step 5
Click Insert.
To add members to the line group, follow this procedure:

Step 6
If you need to locate a DN, choose a route partition from the Route Partition
drop-down list, enter a search string in the Directory Number Contains field, and
click Find. To find all DNs that belong to a partition, leave the Directory Number
Contains field blank and click Find.
A list of matching DNs is displayed in the Available DN/Route Partition pane.
Step 7
In the Available DN/Route Partition pane, select a DN to add and click Add to Line
Group to move it to the Selected DN/Route Partition pane. Repeat this step for each
member that you want to add to this line group.
Step 8
In the Selected DN/Route Partition pane, choose the order in which the new DNs
will be accessed in this line group. To change the order, click a DN and use the Up
and Down arrows to the right of the pane.
3-69
Step 9
Click Update to add the new DNs and to update the DN order for this line group.
Notice the RNA Reversion Timeout (RNAR) which defaults to 10 seconds. This is the time, in
seconds, after which Cisco CallManager will distribute a call to the next available or idle
member of a line group or to the next line group if the call is not answered and if the first hunt
option, Try next member; then, try next group in Hunt List, is chosen.
Configuring Hunt Lists
1. Assign a name
to the hunt list.
2. Add line
groups to the
hunt list.
Hunt lists can contain only line groups in Cisco CallManager Release 4.1.
CIPT1 v4.13-16
To add a hunt list in Cisco CallManager Administration 4.1, follow these steps:
Step 1
Choose Route Plan > Route/Hunt > Hunt List.
Step 2
Click Add a New Hunt List.
Step 3
In the Hunt List Name field, enter a name. The name can comprise up to 50
alphanumeric characters and can contain any combination of spaces, periods (.),
hyphens (-), and underscore characters (_). Ensure that each hunt list name is unique
to the route plan.
Step 4
Choose a Cisco CallManager group from the drop-down list. The group must
already exist in the database; you cannot create a new group from this window.
Step 5
To add this hunt list, click Insert.
Note
Step 6
3-70
A popup message reminds you that you must add at least one line group to this hunt list for
it to accept calls.
The Hunt List window displays the newly added hunt list.
Add at least one line group to the new hunt list. To add a line group, click Add Line
Group. The Hunt List Detail Configuration window is displayed.
From the Line Group drop-down list, choose a line group to add to the hunt list.
Step 7
To add the line group, click Insert.

The line group name is displayed in the Hunt List Details list on the left side of the
window.
Step 8
To add more line groups to this list, click Add Line Group and repeat Step 6 and
Step 7.
Step 9
When you finishing adding line groups to the hunt list, click Update.
Step 10
Click Reset to reset the hunt list. When the popup windows are displayed, click OK.
Cisco CallManager accesses line groups in the order in which they are shown in the hunt list.
You change the access order of line groups by selecting a line group from the Selected Groups
pane and clicking the Up or Down arrow on the right side of the pane to move the line group up
or down in the list.
Configuring Hunt Pilots
1. Create a hunt
pilot number.
2. Associate the
hunt pilot
number with
the hunt list.
CIPT1 v4.13-17
3-71
Before you create a hunt pilot, ensure that the following items are configured in Cisco
CallManager:
Hunt list
Partition (unless you are using None)
Route filter (unless you are using None)
3-72
Step 1
Choose Route Plan > Route/Hunt > Hunt Pilot.
Step 2
Click Add a New Hunt Pilot.
Step 3
Enter the hunt pilot number in the Hunt Pilot number field.
Step 4
Assign the hunt pilot to a hunt list using the Hunt List drop-down menu.
Step 5
Assign the hunt pilot to a partition and route list and configure other settings such as
hunt forward as desired.
Configuring Final Forwarding
This topic discusses how to provide final forwarding treatment for a caller when hunting
exhausts or times out.
Configuring Hunt Pilots: Final Forwarding
Separate final forwarding for no answer and busy is possible.

Use Personal Preferences enables the CFNC settings in the Directory Number
Configuration page for the original called number that forwarded the call to this
hunt pilot.
If checked, Destination and Calling Search Space fields are ignored.
If not checked, Destination and Calling Search Space fields are used.
If no Destination or Calling Search Space fields are defined, caller receives
reorder tone (or equivalent announcement).
Maximum hunt timer specifies maximum time for hunting.
CIPT1 v4.13-18
The Hunt Forward Settings area of the Hunt Pilot Configuration window specifies the final
forwarding settings and maximum timer values, as shown in the table.
3-73
Hunt Forward Settings

Setting
Description
Forward Hunt No Answer
When the call distributed through the hunt list is not answered
within a specific period of time, this field specifies the destination
to which to forward the call. Choose from the following options:
Use Personal Preferences: Enables the Call Forward No
Coverage (CFNC) settings for the original called number that
forwarded the call to this hunt pilot.
The CFNC setting specifies a call forwarding reason that you
administer in the Directory Number Configuration window.
Calls are diverted based on the value in the
Coverage/Destination field of the DN when a call to the DN first
diverts to coverage, and coverage either exhausts or times out,
and the associated hunt pilot for coverage specifies Use
Personal Preferences for its final forwarding.
When this check box is checked, Cisco CallManager ignores
the settings in the Destination and Calling Search Space fields.
Destination: This setting indicates the DN to which calls are
forwarded.
Calling Search Space: This setting applies to all devices
that are using this DN.
Forward Hunt Busy
When the call distributed through the hunt list encounters only
busy lines for a specific period of time, this field specifies the
destination to forward the call. Choose from the following options:
Use Personal Preferences: Use this check box to enable
the CFNC settings for the original called number that
forwarded the call to this hunt pilot.
When this check box is checked, Cisco CallManager ignores
the settings in the Destination and Calling Search Space fields.
Destination: This setting indicates the DN to which calls are
forwarded.
Calling Search Space: This setting applies to all devices
that are using this DN.
Maximum Hunt Timer
3-74
Specifies the maximum time for hunting (in seconds).
Directory Number Configuration

Separate configuration
capability for Internal CFB
and External CFB
Separate configuration
capability for Internal
CFNA and External CFNA
Settings to support
forwarding to original
called party when
coverage exhausts or
times out (internal and
external)
CIPT1 v4.13-19
The Directory Number Configuration window provides configuration options for internal and
external forwarding based on whether a call is CFA or CFNA, as specified in the following
table.
3-75
Call Forward and Pickup Settings

Field
Description
Forward All
Specifies the forwarding treatment for calls to this DN if the DN is set to

forward all calls.
Voice Mail: Check this check box to use settings in the Voice Mail
Profile Configuration window.
When this check box is checked, Cisco CallManager ignores the settings
in the Coverage/Destination and Calling Search Space fields.
Coverage/Destination: This setting indicates the DN to which all calls
are forwarded. Use any dialable phone number, including an outside
destination.
Calling Search Space: This setting applies to all devices that are using
this DN.
Forward Busy Internal

Forward Busy External
Specifies the forwarding treatment for internal or external calls to this DN if

the DN is busy.
Profile Configuration window for internal calls.
Coverage/Destination: Use any dialable phone number, including an
outside destination.
this DN.
Forward No Answer
Internal
Specifies the forwarding treatment for internal or external calls to this DN if

the DN does not answer.
Forward No Answer
External
Profile Configuration window.
Coverage/Destination: This setting indicates the DN to which an
internal call is forwarded when the call is not answered. Use any
dialable phone number, including an outside destination.
this DN.
Forward No Coverage
Internal
Forward No Coverage
External
This setting applies only if you configure one of the other forwarding fields
Call Forward All (CFA), Call Forward Busy (CFB), or Call Forward No
Answer (CFNA)with a hunt pilot number in the Coverage/Destination DN
field.
For the hunt pilot settings, you must also configure the Forward Hunt No
Answer or Forward Hunt Busy fields and check the Use Personal
Preferences check box under the Hunt Forward Settings section in the Hunt
Pilot Configuration window; otherwise, the Forward No Coverage
configuration in the Directory Number Configuration window has no effect.
3-76
Hunting and Forwarding Usage Scenarios
This topic describes several usage scenarios and the resulting hunting and forwarding behavior.
Example 1: Internal and External

Forwarding (No Hunting)
Solution:
User A (DN 3000) wants:
CFB: Incoming internal and
external calls forward to 3001
when busy
CFNA: Incoming internal calls
forward to 3001 and external
calls to forward to
(303) 555-0111 when no answer

...
3000

VM
Destination
CSS
Forward All
Forward No Answer Internal
Forward No Answer External
3001
3001
3001
303 555-0111
Forward No Coverage Internal

Forward No Coverage External
CIPT1 v4.13-20
The first example is straightforward. User A at DN 3000 has the configuration shown in the
figure in the Directory Number Configuration window:
CFB: CFB is determined by the Forward Busy Internal and Forward Busy External
settings, both set to 3001. Incoming internal and external calls forward to 3001 when 3000
is busy.
CFNA: CFNA is determined by the Forward No Answer Internal and Forward No Answer
External settings. Incoming internal calls forward to 3001, and external calls to forward to
(303) 555-0111 when 3000 does not answer.
3-77

Forwarding with Hunting
User A (DN 3000)
wants:
CFB: Incoming
internal calls forward
to 3001 and external
calls forward to hunt
pilot 7000 when busy
CFNA: Incoming
internal calls forward
to 3001 and external
calls forward to hunt
pilot 7000 when no
answer
Solution:
Hunt Pilot 7000

Hunt List abc

...
3000
UPP
VM
Destination
CSS


UPP = Use Personal Preferences
Forward All
Dest.
Forward Hunt Busy
3001
7000
Hunt List abc
3001
7000
Line Group 1
3001
3002

Line Group 2
4001
4002
Hunt pilot 7000 points to hunt list abc, which has four hunt
parties in Line Group 1 and Line Group 2.
Hunt pilot 7000 has no final forwarding fields provisioned
(default).
CIPT1 v4.13-21
User A at DN 3000 has the configuration shown in the figure in the Directory Number
Configuration window:
CFB: Incoming internal calls to forward to 3001, and external calls to forward to hunt pilot
7000 when busy.
CFNA: Incoming internal calls to forward to 3001, and external forward calls to forward to
hunt pilot 7000 when there is no answer.
Assume that hunt pilot 7000 is associated with hunt list abc and has four hunt parties
distributed over Line Group 1 and Line Group 2. Hunt pilot 7000 has no final forwarding fields
provisioned (default).
Question: What behavior results when an internal caller calls 3000 and user 3000 is busy?
Answer: The call forwards to line 3001.
Q: What behavior results when an external caller calls 3000 and user 3000 does not answer?
A: The call forwards to hunt pilot 7000, which will cause hunting to lines 3001, 3002, 4001,
and 4002. If one of the hunt parties answers, the caller will be connected to that party. If no
hunt party answers, then regardless of the reason, the caller will receive a reorder tone (or an
equivalent announcement).
3-78

Hunt pilot 7000 has Solution:
Forward Hunt No
...
3000
Answer
Destination field
VM Destination
set to 3002, but all
Forward All
Forward Hunt
3001
Busy fields remain Forward
Busy External
7000
empty.
3001
Hunt Pilot 7000

Hunt List abc
UPP
Dest.
Forward Hunt Busy
CSS
3002
7000
Hunt List abc

Line Group 1
3001
3002

Line Group 2
4001
4002
CIPT1 v4.13-22
Hunt pilot 7000 has Forward Hunt No Answer Destination field set to 3002, but all Forward
Hunt Busy fields are empty.
A: The call will forward to hunt pilot 7000, which will cause hunting to lines 3001, 3002, 4001,
and 4002. If one of the hunt parties answers, the caller will be connected to that party.
Otherwise, if all hunt parties are busy, the caller will receive a reorder tone (or an equivalent
announcement).
Otherwise, if at least one hunt party is alerted (rings), the call will forward to 3002 because
3002 is the value configured for the Forward Hunt No Answer field.
Q: What if user 3000 is busy when an external call arrives?
A: In this case, the same result occurs because user 3000 forwards external calls to hunt pilot
7000 for both busy and no-answer conditions.
3-79

Extend the
previous example
by having:
The Forward Hunt Busy

Use Personal Preference
check box checked for
hunt a pilot 7000
The Forward No
Coverage Internal fields
for line 3000 set to 3005
The Forward No
Coverage External fields
for line 3000 set to (303)
555-0111
Solution:
Hunt Pilot 7000

Hunt List abc

...
3000
UPP
VM
Destination
Forward All
Dest.
Forward Hunt Busy

CSS
3002
3001
7000
Hunt List abc
3001
7000
Line Group 1
3001
3002
3005
303 555-0111
Line Group 2
4001
4002
CIPT1 v4.13-23
and 4002.
If one of the hunt parties answers, the caller will be connected to that party. If at least one party
is alerted, hunting exhausts because there was no answer, and the call will forward to 3002.
If all hunt parties are busy, the call will forward to the Forward No Coverage External setting
of the original called party (user 3000). In this case, the call will forward to the hunt pilot (303)
555-0111.
Q: What if user 3000 is busy when an external call arrives?
A: In this case, the result is the same, because user 3000 forwards external calls to hunt pilot
7000 for both busy or no-answer states.
3-80

Solution:
Extend the
previous example
by having:
The Forward No
Coverage
External fields
for line 3000
cleared
Hunt Pilot 7000

...
3000
Hunt-List abc

VM
Destination
Forward All
CSS
Dest.
UPP
Forward Hunt Busy
3001
7000
3001
7000
3005
3002
Hunt List abc

Line Group 1
3001
3002
Line Group 2
4001
4002
CIPT1 v4.13-24
and 4002.
If one of the hunt parties answers, the caller will be connected to that party. If at least one party
is alerted, hunt exhaustion occurs because there was no answer, and the call will forward to
3002.
If all hunt parties are busy, the call will forward to the Forward No Coverage External setting
of the original called party (user 3000). In this case, because no forwarding information is
configured, the caller will receive a reorder tone (or an equivalent announcement).
3-81
Example 6: Using the Maximum Hunt Timer

While Hunting
Assume RNAR
timer = 10 seconds
(default)
Q: How long before
hunting exhausts?
Assume maximum
hunt timer for hunt
pilot 7000 is 25
seconds.
Solution:
Hunt Pilot 7000

...
3000
Hunt-List abc

VM
Destination
Forward All
CSS
Dest.
UPP
Forward Hunt Busy
3001
7000
3002
3001
7000
3005
Q: What happens
when a user calls
that hunt pilot?
Hunt List abc

Line Group 1
3001
3002
Line Group 2
4001
4002
CIPT1 v4.13-25
The RNAR timer for a line group determines how long hunting will ring a hunt party before
moving to the next party in its list (assuming that the customer did not select the broadcast
algorithm). This timer has a default value of 10 seconds.
Q: In the examples of four hunt parties, how long will it take before hunting exhausts?
A: It will take 40 seconds before hunting exhausts (10 seconds RNAR x 4 hunt members).
Assume that the maximum hunt timer for hunt pilot 7000 is set to 25 seconds.
Q: What behavior results when a user calls hunt pilot 7000?
A: The call will attempt to hunt to the four parties. If no party answers within 25 seconds,
hunting will terminate and the cause will be treated as no answer. In this case, the call will
forward to 3002. Hunting would terminate after the third member was alerted for 5 seconds.
3-82
Summary
Summary (Cont.)
A hunt group enables call distribution and includes line groups,
hunt lists, and a hunt pilot number.
Hunting allows Cisco CallManager to extend a call to one or
more lists of numbers, while forwarding allows detailed control
as to how to extend a call when a called party fails to answer or
is busy and hunting is not taking place. They work together to
ensure calls are covered.
To configure a hunt group in Cisco CallManager, first create the
line group, next create the hunt list and add line groups, and
finally, create the hunt pilot and associate it with the hunt list.
Use forwarding settings on the Directory Number Configuration
and Hunt Pilot Configuration pages to provide final forwarding
and coverage.
A full range of internal and external forwarding with hunting
usage scenarios are supported using the final forwarding
settings.
CIPT1 v4.13-27
3-83
References
Route Plans.
3/ccmsys/a03rp.htm.
Cisco Systems, Inc. Cisco CallManager Administration Guide, Release 4.1(3), Line
Group Configuration, Hunt List Configuration, and Hunt Pilot Configuration.
3/ccmcfg/index.htm.
3-84
Lesson 3-4
Configuring Complex Route

Plans
Overview
Users of any phone system often need to reach a variety of destinations that include calls to
extensions located within the same site, to a different site within the same company (sometimes
with different dialing plans), and to other companies located within the same country or a
different country. Because these calls can take different paths, such as the IP WAN or a
preferred Public Switched Telephone Network (PSTN) carrier, completing these calls often
requires dialing various access codes, numbers of digits, or prefixes. At the same time, it is
often prudent to restrict certain destinations for all users, such as 900 numbers.
To require users to understand the specific dialing patterns necessary to reach these various
destinations is impractical and inconvenient. Digit manipulation, or the ability of Cisco
CallManager to add or subtract digits to comply with a specific internal dial plan or national
numbering plan, is the key to providing transparent dialing and creating a unified dialing plan.
Implementing route filters in Cisco CallManager Administration blocks access to specified area
codes.
This lesson covers route filters, discard digits instructions (DDIs), transformation and
translation patterns, and the route plan report to view all route patterns in a Cisco IP telephony
clustered solution.
Objectives
Upon completing this lesson, you will be able to use complex route plan elements to perform
functions that include blocking access to specified area codes and manipulating digits to change
the caller and calling ID number, enable a hot line, or enable transparent calling regardless of
whether the call is routed over the IP WAN or PSTN. This ability includes being able to meet
these objectives:
Configure route filters in Cisco CallManager Administration to reduce the number of route
patterns or restrict calling to undesirable locations
Modify route patterns to use access codes and discard digit instructions to convert the
dialed number to a number that is supported by a national numbering plan
Configure transformation masks to manipulate the appearance of the number of the calling
party for outgoing calls and to manipulate called numbers for PSTN compatibility
Configure translation patterns that manipulate dialed digits before routing a call to enable
users to include a uniform dialing plan between offices or to enable hot line functionality
Describe how to access route plan reports to view a listing of all the Call Park numbers,
Call Pickup numbers, conference numbers (such as Meet-Me numbers), route patterns, and
translation patterns in the system
3-86
Route Filters
This topic discusses the configuration and application of route filters in a route plan.
Route Filter Basics

The 9.@ Route Pattern
Route Pattern
9.@
North American
Numbering Plan:
9.[2-9]11
9.[2-9]XX XXXX
9.1 [2-9]XX [2-9]XX XXXX
9.011 !
Route Filter
Local Only
INTERNATIONAL-ACCESS
DOES-NOT-EXIST
AND
AREA-CODE
DOES-NOT-EXIST
Actual Routes in Cisco CallManager:
9.[2-9]11
9.[2-9]XX XXXX
The @ wildcard represents

all the routes defined in the
North American national
numbering plan.
Cisco CallManager identifies
tags in each number:
INTERNATIONALACCESS
AREA-CODE
OFFICE-NUMBER
Route filters are logical
expressions that operate
on these tags.
Useful for blocking 900,
Caribbean, international...
CIPT1 v4.13-3
You can assign route filters to route patterns with the @ route pattern (9.@) to help reduce the
number of route patterns that are required. You can accomplish this reduction by filtering what
is included in the 9.@ route pattern.
Note
Route filters can be very complex. The most common use of route filters is for local 7-digit
dialing in North America. Many areas in North America are moving to full 1 + 10 or 10-digit
E.164 dialing.
When using the 9.@ route pattern, Cisco CallManager recognizes that dialing is complete when
the user dials 1 + 10 or just dials 10 digits (local area codes without the 1). If the number dialed
does not begin with a 1, Cisco CallManager considers it a local area code and assumes that
dialing is complete after 10 digits.
In an area where seven digits are dialed for local numbers, Cisco CallManager cannot recognize
which office exchange codes (NXXs) to use for routing unless you specifically code them as
route patterns.
Note
NXX is the central office (CO) exchange code, which consists of three digits that designate a
particular CO or a block of 10,000 subscriber lines. N is any digit between 2 and 9, and X is
any digit between 0 and 9.
3-87
Generally, telephone company service providers arrange many NXXs in a given area code
contiguouslywhere you can use route pattern wildcards to assist in your configuration.
Coding these individual route patterns for NXXs can be extremely difficult. You can use a
route filter to simplify this procedure.
A route filter called seven-digit dialing is always preconfigured in Cisco CallManager. You
should assign this route filter to any 9.@ route pattern in an area that uses seven-digit dialing.
This route filter removes all local area codes. If a dialed number does not begin with a 1, then it
is a seven-digit number, and Cisco CallManager considers dialing complete after seven digits.
This situation requires you to configure local area codes specifically as separate route patterns.
Doing so is generally not an issue because the number of area codes in a geographical region is
usually small.
Route Filter Tags
3-88
Tag Name
Example Pattern
Description
AREA-CODE
1 214 555 1212
The area code in an 11-digit longdistance call
COUNTRY-CODE
011 33 123456#
The country code in an international call
END-OF-DIALING
011 33 123456#
The #, which terminates interdigit timeout

for an international call
INTERNATIONAL-ACCESS
01 1 33 123456#
The initial 01 of an international call
INTERNATIONAL-DIRECTDIAL
01 1 33 123456#
The digit that denotes the direct-dial

component of an international call
INTERNATIONAL
OPERATOR
01 0
The digit that denotes the operator

component of an international call
LOCAL-AREA-CODE
214 555 1212
The area code in a 10-digit local call
LOCAL-DIRECT-DIAL
1 555 1212
The initial 1 that is required for some

7-digit calls
LOCAL-OPERATOR
0 555 1212
The initial 0 that is required for operatorassisted local calls
LONG-DISTANCE-DIRECTDIAL
1 214 555 1212
The initial 1 that is required for longdistance direct-dialed calls
LONG-DISTANCEOPERATOR
0 214 555 1212
The initial 0 that is required for operatorassisted long-distance calls
NATIONAL-NUMBER
011 33 123456#
The national number component of an

international call
OFFICE-CODE
1 214 555 1212
The office exchange code of a North

American call
SATELLITE-SERVICE
011 88141234#
A specific value that is associated with

calls to the satellite country code
SERVICE
1 411
Access to local telephony provider

services
SUBSCRIBER
1 214 555 1212
A particular extension that is served by a

given exchange
TRANSIT-NETWORK
101 0321 1 214 555 1212
Long-distance carrier code
TRANSIT-NETWORKESCAPE
101 0321 1 214 555 1212
The escape sequence that is used for

entering a long-distance carrier code
The types of patterns that are included when a 9.@ route pattern is added are the following:
No filter
Service exists
Country code does not exist
Area code = 900
9.@ Route Pattern Without Route Filters
9 [2-9]11
9 [2-9]XX XXXX
9 [2-9]XX [2-9]XX XXXX
311, 611, 911 SERVICE

7-digit dialing by OFFICE CODE
10-digit local dialing by
LOCAL AREA CODE
11-digit long-distance dialing by

9 1 [2-9]XX [2-9]XX XXXX AREA CODE
9 011 3[0-469] !
International dialing by
COUNTRY CODE
CIPT1 v4.13-4
The figure shows the individual patterns that Cisco CallManager adds to the 9.@ route pattern
without filters.
The @ symbol wildcard matches all North American Numbering Plan (NANP) numbers. The
following route patterns are examples of NANP numbers that are included in the @ wildcard:
0
1411
19725550134
101028819725550134
01133123456789
3-89
Configuring Route Filters
Operator
Description
NOT-SELECTED
Do not filter calls based on the dialed digit string

associated with this tag.
EXISTS
Filter calls when the dialed digit string associated

with this tag is found.
DOES-NOT-EXIST

with this tag is not found.
==

with this tag matches the specified value.
CIPT1 v4.13-5
You can configure a route filter using the Cisco CallManager Administration window.
Step 1
Choose the Route Plan menu.
Step 2
Choose Route Filter from the menu bar.
Step 3
Choose NANP from the Dial Plan menu.
Step 4
Enter a name in the Route Filter Name field. The name can consist of up to 50
alphanumeric characters, and can contain any combination of spaces, periods (.),
hyphens (-), and underscore characters (_). Each route filter name must be unique to
the route plan.
The tag operators in the route filter determine whether Cisco CallManager will filter a call
based on the existence of the dialed digit string that is associated with that tag or based on the
actual contents of that dialed digit string. The route filter operators EXISTS and DOES-NOTEXIST check for the existence of that part of the dialed digit string. The operator = = matches
the actual dialed digits with the specified value or pattern.
The following are route filter examples:
A route filter that uses the tag AREA-CODE and the operator DOES-NOT-EXIST selects
all dialed digit strings that do not include an area code.
A route filter that uses the tag AREA-CODE, the operator = =, and the entry 515 selects all
dialed digit strings that include the 515 area code.
A route filter that uses the tag AREA-CODE, the operator = =, and the entry 5[2-9]X
selects all dialed digit strings that include area codes in the range of 520 through 599.
A route filter that uses the tag TRANSIT-NETWORK, the operator = =, and the entry
0288, along with the tag TRANSIT-NETWORK-ESCAPE, the operator = =, and the entry
101, selects all dialed digit strings with the carrier access code 1010288.
3-90
9.@ with Route Filter

AREA CODE == 900
9 [2-9]11
Not added: no AREA-CODE
9 [2-9]XX XXXX
9 [2-9]XX [2-9]XX XXXX Not added: no AREA-CODE

(It contains LOCAL-AREA-CODE)
9 1 [2-9]XX
900 [2-9]XX XXXX Added: AREA-CODE constrained to 900
9 011 3[0-469] !
CIPT1 v4.13-6
The figure shows the patterns that Cisco CallManager adds when you apply the AREA-CODE
= = 900 filter to the 9.@ route pattern. A route filter that uses the tag AREA-CODE, the
operator = =, and the entry 900 selects all dialed digit strings that include the 900 area code.
After you apply the route filter to the route pattern, you are given the configuration option to
route this pattern or block this pattern. By choosing the Route This Pattern radio button in the
Route Pattern/Hunt Pilot Configuration window, you would allow all calls where
AREA-CODE = 900, while denying all other route patterns. Generally, this result is not
desired. Instead, choose the Block This Pattern radio button to prevent all calls where
AREA-CODE = 900 but allow all other route patterns.
3-91
This topic discusses the discard digits instructions (DDIs) that are available in Cisco
CallManager.

If the pattern is 9.5@
Instructions
Discarded Digits
Used for
PreDot
95 1 214 555 1212
Access codes
PreAt
95 1 214 555 1212
Access codes
11D/10D@7D
95 1 214 555 1212
Toll bypass
11D@10D
95 1 214 555 1212
Toll bypass
IntlTollBypass
95 011 33 1234 #
Toll bypass
10-10-Dialing
95 1010321 1 214 555 1212
Suppressing carrier
selection
Trailing-#
95 1010321 011 33 1234 #
PSTN compatibility
CIPT1 v4.13-7
DDIs allow conversions of a dialed number specific to a national numbering plan. In general,
DDIs apply only to route patterns that contain the @ wildcard; however, you can use the DDI
PreDot with route patterns that use the . wildcard even if the route patterns do not contain the
@ wildcard. Cisco CallManager applies DDIs to the called-party transformation masks at the
route pattern, the route details of a route list, or a translation pattern. DDI identifiers, shown in
the figure, are additive. The DDI PreDot 10-10-Dialing combines the effects of each individual
identifier.
3-92
Using PreDot Discard Digits Instructions

Use DDIs to strip
initial digits.
Cisco CallManager
Match: 9.8XXX
Discard: PreDot
Use only NoDigits or

PreDot unless the
pattern contains
an @ wildcard.
Called Party: 8123
User Dials: 98123
PBX
CIPT1 v4.13-8
Cisco CallManager applies the PreDot DDI to the 9.8xxx route pattern, strips the 9 from the
dialed digits, and sends only the 8123 to the PBX.
In Cisco CallManager Administration, you can access the Discard Digits menu shown in the
figure by choosing Route Plan > Translation Pattern.
Using Compound Discard Digits

Instructions
Cisco
CallManager
Use DDIs to discard

whole sections of the
dialed number.
All DDIs are available.
Match: 9.@
Discard:
PreDot 10-10-Dialing
Called Party:
12145551212
User Dials:
9101028812145551212
PSTN
CIPT1 v4.13-9
Cisco CallManager applies the PreDot 10-10-Dialing DDI to the 9.@ route pattern, strips the
91010288 from the dialed digits, and sends only 1214555112 to the gateway device.
3-93
This topic discusses transformation masks in a route plan.
About Transformation Masks
Modify either the

calling number or
called number
(dialed digits)
Can contain digits
0-9, *, #, and X
Applied to a number
to extend or
truncate it
An X in a mask
lets digits pass
through.
45000
Mask
808236XXX
8082365000
Digits in masks
replace number
digits.
Blanks block
number digits.
Mask
8082365000
45XXX
_____ 45000
CIPT1 v4.13-10
Dialing transformations allow the call-routing component to modify either the calling number
or the dialed digits of a call. Transformations that modify the calling number are calling-party
transformations; transformations that modify the dialed digits are called-party transformations.
Calling-party transformation settings allow you to manipulate the appearance of the callingparty number for outgoing calls. A common application of a calling-party transformation is to
use the company external phone number of a calling station in place of the directory number
(DN) for outgoing calls. The calling-party number is used for Calling Line Identification
(CLID). During an outgoing call, the CLID is passed to each PBX, CO, and interexchange
carrier (IXC) as the call progresses. The CLID is also delivered to the calling party when the
call is completed.
Called-party transformation settings allow you to manipulate the dialed digits, or called-party
number, for outgoing calls. Examples of manipulating called numbers include appending or
removing prefix digits (outgoing calls), appending area codes to calls that are dialed as
seven-digit numbers, appending area codes and office codes to interoffice calls that are dialed
as four- or five-digit extensions, and suppressing carrier access codes for equal-access calls.
A mask operation allows the suppression of leading digits, the change of some digits while
leaving others unmodified, and the insertion of leading digits.
A mask operation requires two pieces of information: the number that you wish to mask and the
mask itself.
3-94
In the mask operator, Cisco CallManager overlays and aligns the number with the mask so that
the last character of the mask aligns with the last digit of the number. Cisco CallManager uses
the corresponding digit of the number wherever the mask contains an X. If the number is longer
than the mask, the mask obscures the extra digits.
Note
Cisco CallManager also uses a concept called translation patterns, which rely heavily on
dialing transformations to operate. Cisco CallManager uses translation patterns to
manipulate dialed digits before routing a call. Translation patterns and dialing
transformations are separate concepts. A dialing transformation is a general concept that
refers to any setting in Cisco CallManager that can change the calling number or dialed
digits. Dialing transformations appear not only in the Transformation Pattern Configuration
window but also in the Route Pattern/Hunt Pilot Configuration window, in numerous gateway
configuration windows, and in service parameters.
Calling-Party Transformation Order

Directory Number
Apply the external

phone number mask.
Apply the calling party
transformation mask.
External Phone
Number Mask
Calling-Party
Transformation
Mask
Caller ID
35062
21471XXXXX
2147135062
40885XX000
4088535000
CIPT1 v4.13-11
The example in the figure shows the applicable settings for calling-party transformations and
the order in which Cisco CallManager processes those instructions. You can configure three
types of calling-party transformations in the call-routing component and on route lists:
Use the external phone number mask, which instructs the call-routing component to use the
external phone number of a calling station rather than its DN or the caller ID information.
You can apply the external phone number mask on a line-by-line basis through the DN
configuration screen on the device.
The calling-party transformation mask allows the suppression of leading digits, leaves other
digits unmodified, and inserts leading digits.
Prefix digits allow the prepending of specified digits to the calling number.
Cisco CallManager applies the transformations in the order that is presented in the example.
3-95
Called-Party Transformation Order
Apply DDIs.
Apply the called-party
transformation mask.
Apply prefix digits.
Dialed
Number
9 1010321 18085551221
DDIs
10-10-Dialing
9 18085551221
Called-Party
Transformation
Mask
XXXXXXXXXX
8085551221
Prefix Digits
Called Number
88085551221
CIPT1 v4.13-12
The example in the figure shows the applicable settings for called-party transformations and the
order in which Cisco CallManager processes those instructions. You can configure the
following three types of called-party transformations in the call-routing component and on
route lists:
DDIs allow the discarding of subsections of numbers in the NANP. Such instructions are
critical for implementing toll-bypass solutions. This need arises when Cisco CallManager
must convert the long-distance number that the calling party has dialed into a local number.
This number allows Cisco CallManager to pass the digits to the PSTN. You can also use
DDIs to discard PSTN access codes, such as 9.
The called-party transformation allows the suppression of leading digits, changes the
existing digits while leaving others unmodified, and inserts leading digits.
Prefix digits allow the prepending of one or more digits to the called number.
Cisco CallManager applies the transformation in the order that is presented in the example.
3-96
Configuring Transformation Masks

Transformation
masks are
configured from:
Route pattern
configuration
Route list
configuration
Transformation
masks configured
at route list level
have priority over
those configured
at route pattern
level.
CIPT1 v4.13-13
The calling party transformation setting that is used in route lists applies to the individual route
groups that make up the list rather than to the entire route list. The calling-party transformation
settings that are assigned to the route groups in a route list override any calling-party
transformation settings that are assigned to a route pattern that is associated with that route list.
To access calling- and called-party transformation settings, choose Route Plan > Translation
Pattern.
Because you can be more specific, network administrators usually apply transformation masks
at the route list level. In this way, you can assign a different transformation mask for each route
group in the route list.
For example, a network administrator has two route groups created: the PSTN route group and
the IP WAN route group. Both of these route groups contain multiple gateways that connect to
their respective networks. When Cisco CallManager forwards a call to a gateway in the PSTN
route group, the network administrator applies a mask that transforms the number into an
E.164-compliant phone number. However, when Cisco CallManager uses a gateway from the
IP WAN route group, Cisco CallManager leaves the number as a four-digit extension.
3-97
Transformation Example
1
Users
User Dial
Numbers
A - 5062
A - 91234
B - 5063
B - 91324
C - 5064
C - 91432
Wildcards allow all

dialed numbers to match
one route pattern.
Route Pattern
DDI
9.1XXX
Discard 9
User Dialed
Numbers
6
To: 1000
From: 5000
Extension 1000
Rings
A 1000
B 1000
C 1000
X000
User Dialed
Numbers
Transform
Called Number
Caller ID
A 5000
B 5000
C 5000
User DNs
A 1234
B 1324
C 1432
4
X000
Transform
Calling Number
CIPT1 v4.13-14
The figure summarizes how transformations to the called-party (dialed digits) and to the
calling-party numbers are made within Cisco CallManager. In this figure, a user dials a number
to which Cisco CallManager first applies a calling-party transformation (calling party refers
to the person who originated the call). This action changes the caller ID number that is
displayed on the destination phone. Cisco CallManager then applies a called-party
transformation to change the number that is dialed.
The two transformations are explained in the figure and, for user A specifically, in the
following steps:
3-98
Step 1
User A has a DN of 5062. This user dials DN 91234.
Step 2
The dialed number matches the route pattern 9.1xxx.
Step 3
The DDIs contain instructions to discard the 9. The dialed number is now 1234.
Step 4
The calling number 5062 now passes through the calling-number transformation
mask, which contains instructions to change the last three digits of the calling party
number to 000. The new calling number is 5000.
Step 5
Cisco CallManager then passes the called number 1234 through the called-number
transformation mask X000, which changes this number to 1000.
Step 6
The result is a calling-party number of 5000 and a called-party number of 1000.
Translation Patterns
This topic discusses the functionality and configuration of translation patterns.
Translation Pattern
Digits
Find best match.
Digits
Applycallingcalling and calledcalled

Apply
party transformations.
transformations
party
Pattern type?
Route pattern
Extend call to destination.
CIPT1 v4.13-15
Cisco CallManager uses translation patterns to manipulate dialed digits before routing a call. In
some cases, the dialed number is not the number that is used by the system. In other cases, the
dialed number is not a number that is recognized by the PSTN.
Digit manipulation and translation patterns are used frequently in cross-geographical
distributed systems where, for instance, the office codes are not the same at all locations. In
these situations, a uniform dialing plan can be created, and translation patterns can be applied to
accommodate the unique office codes at each location. The following are additional examples
where you can use translation patterns:
Security desks and operator desks
Hot lines with a need for private line, automatic ringdown (PLAR) functionality
Extension mapping from the public to a private network
Translation patterns use the results of called-party transformations as a set of digits for a new
analysis attempt. The second analysis attempt might match a translation pattern. In this case,
Cisco CallManager applies the calling- and called-party transformations of the matching
translation pattern and uses the results as the input for another analysis attempt. To prevent
routing loops, Cisco CallManager breaks chains of translation patterns after 10 iterations.
3-99
Translation Pattern Configuration
Route
Pattern
Transformation
Settings
CIPT1 v4.13-16
Configuration of a translation pattern is similar to configuration of a route pattern. Each pattern

has calling- and called-party transformations and wildcard notation. The difference is that when
Cisco CallManager applies the translation pattern, it starts the digit analysis process over and
routes the call through a new path if necessary.
To configure a translation pattern, choose the Route Plan menu and choose Translation
Pattern. You can define the route pattern to match and the calling- or called-party
transformation settings that you would like to apply.
Common Uses of Digit Translation

Can be used to send calls to
unassigned DID
numbers to attendant or recording
Translation Pattern = XXXX

Called Party Transform Mask = 4111
Cisco CallManager uses longest
match, so XXXX will match any
nonconfigured number and get sent
to 4111 (attendant).
PSTN
Employee Attendant
Phones
(4111)
OR
Internal Extensions
4XXX
PSTN DID range does not match internal range
San Jose
Translation Pattern = 1XXX

Called-Party Transform Mask = 4XXX
3-100
PSTN DID Range

408-555-1xxx
CIPT1 v4.13-17
The figure shows an application for translation patterns. When the Direct Inward Dial (DID)
range from the CO does not match the internal DN range, you can use a translation pattern to
make the connection.
In the figure, a San Jose, California, company has a PSTN DID range of 408-555-1xxx.
However, all of the internal four-digit extensions begin with 4xxx. When the company receives
an incoming call, the company could use DDIs to remove the 555 from the beginning of the
number. However, the 1xxx extension still remains. Instead, the translation pattern could apply
a 4XXX called-party transformation mask. This mask would convert the 1xxx external DID
range to a 4xxx internal range. After Cisco CallManager applies the transformation mask, it
reanalyzes the dialed number and directs it to the correct internal extension.
3-101
Route Plan Report
This topic provides an overview of the route plan report.
Route Plan Report Overview
CIPT1 v4.13-18
The route plan report is a listing of all the Call Park numbers, Call Pickup numbers, conference
numbers (such as Meet-Me numbers), route patterns, and translation patterns in the system. The
route plan report allows you to view either a partial or full list and go directly to the associated
configuration windows. You can accomplish this by selecting a route pattern, partition, route
group, route list, Call Park number, Call Pickup number, conference number, or gateway.
The route plan report allows you to save report data into a comma-separated values (CSV) file
that you can import into other applications. The CSV file contains more detailed information
than the web pages, including DNs for phones, route patterns, and translation patterns.
3-102
Generating a Route Plan Report
Choose Route Plan Report from the Route Plan menu.

Click the View in File link to save the file to a .csv
template.
CIPT1 v4.13-19
To view a route plan report in a CSV file, follow these steps:

Step 1
Choose Route Plan > Route Plan Report.

The route plan report shows 20 items per window.
Step 2
Choose View in File. The NumPlan.csv download dialog box appears.

From this dialog box, you can either save or open the file.
Step 3
Choose Save File in the dialog box.

Another window appears that allows you to save this file to a location of your
choice.
Note
You may change the name of the file, but the filename must have a .csv extension.
Step 4
Select the location in which to save the file and click Save. The file should now be
saved to the location that you designated.
Step 5
Locate the CSV file that you just saved and double-click its icon to view it.
3-103
Summary
Summary
A route filter permits or restricts access through a
route list by using route patterns.
A DDI removes a portion of the dialed digits string
before passing the number to the adjacent system.
Calling-party transformation masks modify either the
calling-party number or called number (dialed digits).
Translation patterns manipulate dialed digits before
determining where to route the call.
The route plan report lists useful information such as
route patterns, translation patterns, and call park
numbers.
CIPT1 v4.13-20
References
Route Plans.
3/ccmsys/a03rp.htm.
Cisco Systems, Inc. Cisco CallManager Administration Guide, Release 4.1(3), Route
Filter Configuration, Translation Pattern Configuration, and Route Plan Reports.
3/ccmcfg/index.htm.
3-104
Lesson 3-5
Implementing Class of Control

Overview
An important dial plan consideration is the assignment and enforcement of calling privileges.
You might want company executives to have different calling privileges than receptionists, or
employee phones to have different calling privileges than lobby phones. You might also want
to place further restrictions on the times that these privileges are available, for example, by
allowing international calls to be placed only during business hours to prevent unauthorized use
after hours. Partitions, calling search spaces, and time-of-day routing are the primary class of
control components that enable you to assign and enforce calling privileges. This lesson
discusses how to implement partitions, calling search spaces, and time-of-day routing.
Objectives
Upon completing this lesson, you will be able configure partitions and calling search spaces to
restrict user traffic and to create a hotline, and explain how time-of-day routing enables call
routing or restrictions based on when a call is placed.
Define CoS as it relates to users of a phone system
Defines partitions and calling search spaces and identify the components of each
Configure partitions and calling search spaces in Cisco CallManager Administration to
assign calling privileges to users and devices
Define time-of-day routing and identify its uses and components
Configure time-of-day routing to control call routing based on the time of day, day of
week, and day of year when the call was made
Given a usage scenario, determine the call time-of-day routing parameters to enable
call-routing or restrictions
Class of Service
This topic defines class of service (CoS) as it relates to users of IP telephony or any other
phone system.
Class of Service
Class of
Service 1
Class of
Service 2
Class of
Service 3
Lobby
Employee
Executive
Collection of
calling permissions
you assign to
individual users
IP WAN
Long Distance
Employee
Executive
PSTN
International
CIPT1 v4.13-3
CoS is a collection of calling permissions and restrictions that you assign to individual users.
(The terms calling permissions and calling restrictions are used interchangeably in this lesson.)
Examples of class-of-service permissions are:
One class of users can place toll calls during normal business hours, but not at other times.
Lobby phone users can dial the local emergency numbers and campus extensions but not
local, long-distance, or international calls
Receptionists can dial anywhere within the company and all local area codes, but not long
distance or international
Executives can call anywhere except 900 area codes
Cisco CallManager uses partitions, calling search spaces, and time-of-day routing to implement
class-of-service restrictions.
3-106
Partitions and Calling Search Spaces Overview
This topic defines partitions and calling search spaces and identifies the components of each.
Partitions and Calling Search Spaces

What is the calling search space of
a DN that is placed in Partition A?
Partition
A
Lobby Phones
Break Room Phones
Local Area Codes
Partition B
Long-Distance
Area Codes
Partition C
International Numbers
Partition = Where you are

Consists of devices with similar
reachability characteristics
Company Employee
Extensions
Partition D
Partition E
Partition F
Local Emergency
Numbers
Calling search space = Where (what partitions) you may call

Set of rules to set call restrictions and permissions
Defines which partitions a calling device may search to reach
a dialed number
CIPT1 v4.13-4
A partition is a group of directory numbers (DNs) with similar accessibility, and a calling
search space defines which partitions are accessible to a particular device. A device can call
only the DNs located in the partitions that are part of its calling search space. A partition
comprises a logical grouping of directory numbers (DNs) and route patterns with similar
reachability characteristics. Devices that are typically placed in partitions include DNs and
route patterns. For simplicity, partition names usually reflect their characteristics, such as
NYLongDistancePT, NY911PT, and so on.
A calling search space is an ordered list of partitions that Cisco CallManager digit analysis
looks at before a telephone call is placed. Calling search spaces then determine the partitions
that calling devices, including Cisco IP Phones, Cisco IP SoftPhones, and gateways, can reach
when attempting to complete a call. If a device attempts to reach a route pattern or DN that is
not in its calling search space, it receives a fast busy signal.
Items that can be placed in partitions all have a dialable pattern, and they include phone lines,
route patterns, translation patterns, computer telephony interface (CTI) route group lines, CTI
port lines, voice-mail ports, and Meet-Me conference numbers. Conversely, items that have a
calling search space are all devices capable of dialing a call, such as telephones, telephone
lines, gateways, and applications (via their CTI route groups or voice-mail ports).
In the figure, the DNs of lobby phones and break room phones are placed into partition A.
Partitions B, C, D, E, and F contain the route patterns to reach local numbers, long-distance
numbers, international numbers, and company extensions.
The calling search space for the lobby phones includes only the partitions containing the
company extension route patterns and the local emergency numbers. Therefore, the lobby
phone located in partition A has as its calling search space partition E and can dial only
company destinations, including the break room (in other words, devices belonging to the same
partition) and emergency numbers (for example, 911 in the United States).
3-107
Configuring Partitions and Calling Search

Spaces
This topic discusses how to configure partitions and calling search spaces in Cisco
CallManager Administration to assign calling privileges to users and devices.
Partition Configuration
Assigned to DNs, route patterns, translation patterns

CIPT1 v4.13-5
To configure partitions, choose Route Plan > Class of Control > Partition. When the Find
and List Partition window appears, click the Add a New Partition link. The Partition
Configuration window that is shown in the figure appears. From here, you can add a maximum
of 75 partitions using the following syntax:
<partitionName>, <description>, as shown in the figure (LobbyPT, Lobby Directory Numbers)
Cisco CallManager Administration requires only that you enter the partition name. However,
adding a description for the partition can be useful for documentation purposes.
Example: Assigning DNs to Partitions

The network administrator at the ABC Company must allow certain individuals to call the DNs
in the 1xxx and 2xxx ranges. Before assigning the DNs to a partition, the administrator must
first configure the partitions using the Partition Configuration window in Cisco CallManager
Administration. The administrator could add the necessary partitions using the following
format:
DN_1XXX, Directory Numbers 1000-1999
DN_2XXX, Directory Numbers 2000-2999
After the administrator adds the partitions, DNs must be assigned. To do this, the administrator
must enter the configuration mode of the telephones that have the DNs, proceed to the
Directory Number Configuration window, and choose the partition from the menu.
3-108
Calling Search Space Configuration
Assigned to devices, (phones, gateways, etc.) and translation patterns

CIPT1 v4.13-6
After configuring the partitions and assigning DNs or route patterns to those partitions, you
must configure the calling search spaces that contain a prioritized list of the available partitions.
The figure here shows the Calling Search Space Configuration window in Cisco CallManager
Administration (choose Route Plan > Class of Control > Calling Search Space.)
You can use the arrows between the Available Partitions and Selected Partitions panes to
choose the partitions that you want to add to the calling search space. You can reorder
partitions by using the arrows to the right of the Selected Partitions panes. To reduce
call-processing time, place the partitions with the most frequently used numbers at the top of
the Selected Partitions list.
Example: Assigning Partitions to Calling Search Spaces

In order to restrict access to the 1XXX and 2XXX partitions, the network administrator from
the ABC Company must create a calling search space that is named 1XXX_Only and add the
DN_1XXX partition to this calling search space. The administrator then creates another calling
search space named 2XXX_Only and adds the DN_2XXX partition to this calling search
space. Finally, the administrator creates a calling search space named All_DNs and adds both
the DN_1XXX and DN_2XXX partitions to this calling search space.
After configuring the calling search spaces, the administrator assigns them to the various
network devices. For example, telephone A is assigned the 1XXX_Only calling search space,
which means that telephone A can call only the DNs that are assigned to the partition
DN_1XXX. By assigning telephone B to the 2XXX_Only calling search space, the
administrator restricts telephone B from calling any numbers outside of the DN_2XXX
partition. If the administrator assigns telephone C to the All_DNs calling search space,
telephone C can call the DNs that are assigned to both partitions DN_1XXX and DN_2XXX.
3-109
Time-of-Day Routing Overview
This topic defines time-of-day routing and identifies its applications and components.
Time-of-Day Routing and Restrictions

Overview
Time-of-day routing routes calls to different locations based
on the time of day when a call is made.
Time-of-day routing blocks calls to destinations based on the
time of day or on a specific day when a call is made.
Time-of-day settings are assigned to a partition; partitions
contained within the calling search space are active based on
time-of-day settings.
The Time-of-day feature is applied when a called number is
validated.
Cisco CallManager filters the partitions contained in the
originating devices calling search space.
The called number is validated against this filtered calling
search space.
CIPT1 v4.13-7
Time-of-day routing, introduced in Release 4.1 of Cisco CallManager, routes calls to different
locations based on the time of day when a call is made. For example, during business hours,
calls can route to an office, and after hours, calls can go directly to a voice-messaging system or
to a home number. Time-of-day routing also provides the ability to route calls based on the
time-of-day or based on a specific day, such as December 25.
Time-of-day settings are assigned to partitions. After the administrator has configured the timeof-day settings and assigned them to partitions, the time-of-day feature filters the calling search
space through time-of-day settings that are defined for each partition in the calling search
space.
The time-of-day feature is applied when a called number is validated. Cisco CallManager filters
the partitions contained in the calling search space of the originating device, and the called
number is validated against this filtered calling search space.
3-110
Time-of-Day Routing Applications

Allow international calls only during office hours
Block international calls based on local callers time
zone
Block international calls on holidays
Allow international calls only during office hours of the
callers time zone
Implement a least-cost routing system by choosing the
cheapest provider for a specific time of day
Route calls after hours to a home number or voice mail
Any application where you want to control the calling
search space based on the time of the day
CIPT1 v4.13-8
A number of applications exist for applying time-of-day routing settings to partitions, as shown
in the figure. The primary applications are in the areas of routing calls to different destinations
based on the time of day and allowing or blocking international or other toll calls to prevent toll
fraud.
3-111
Time-of-Day Routing Examples

Examples:
Route calls to office number
during business hours and to
voice mail or to home
number after hours
Route calls to office in San
Jose site 1 9:00 am1:00 pm
and office in San Jose site 2
3:00 pm5:00 pm
Route calls to office number
to home number or voice
mail number on specific days
(December 25)
9:00 am5:00 pm
6:00 pm11:00 pm
Office Phone
9:00 am1:00 pm
Home Phone
2:00 pm5:00 pm
San Jose 1
Only on
San Jose 2
25 December
Voice Mail
Office Phone
CIPT1 v4.13-9
Three time-of-day routing examples are shown in the figure, as follows:

A user wants calls to be routed to his office number during business hours (9:00 a.m. to
5:00 p.m.) and to go directly to his voice mail or to his home number after office hours.
A user wants calls to be routed to her office in San Jose site 1 between 9:00 a.m. and 1:00
p.m. and to her office in San Jose site 2 between 2:00 p.m. and 5:00 p.m.
A user wants all the calls to his office number to be routed to his home number or his
voice-mail number only on specific days (December 25).
3-112
Time Periods and Time Schedules

Time period
Time range defined by

start and end time
Repetition interval
Days of the week or
specified calendar date
Associated with time
schedules
Time schedule
Group of time periods

Assigned to partitions
Determines the partitions
that calling devices
search when they are
attempting to complete a
call during a particular
time of day
Time Periods
StartEnd
weekdayhrs_TP
weekendhrs_TP
newyears_TP
noofficehours_TP
08:0017:00
08:0017:00
00:0024:00
Time Schedule
Repetition
MF
Sat Sun
January 1
Sat Sun
Time Periods
RegEmployees_TS
weekdayhrs_TP
newyears_TP
noofficehours_TP
Partition
Time Schedule
CiscoAustin_PT
RegEmployees_TP
CIPT1 v4.13-10
Time-of-day routing comprises individual time periods that the administrator defines and
groups into time schedules.
Time Periods
A time period comprises a start time and end time. The available start times and end times are
15-minute intervals on a 24-hour clock, from 00:00 to 24:00. Additionally, a time period
requires definition of a repetition interval. Repetition intervals are the days of the week (for
example, Monday through Friday) or a day of the calendar year (for example, June 9).
The figure shows examples of four time periods, defined as follows:
Time period weekdayhrs_TP as 08:00 to 17:00 from Monday to Friday.
Time period weekendhrs_TP as 08:00 to 17:00 on Saturday and Sunday.
Time period newyears_TP as 00:00 to 24:00 on January 1.
Time period noofficehours_TP as no hours on Saturday and Sunday. For this time period,
the associated partition is not active on Saturday and Sunday.
3-113
Time Schedules
A time schedule consists of a group of defined time periods that the administrator associates
with a partition.
After the administrator selects a time period for association with a time schedule, the time
period remains available for association with other time schedules.
The figure shows an example of a time period RegEmployees_TS with time periods
weekdayhrs_TP, newyears_TP, and noofficehours_TP associated with it.
The Time Period and Time Schedule menu items are in the Route Plan menu under the Class of
Control submenu.
The administrator associates time schedules with a partition. Partitions contained within the
calling search space are available based on time-of-day settings. Cisco CallManager filters the
calling search space through the time-of-day settings defined for each of the partitions in the
calling search space.
End Users and Time-of-Day Routing

If time-of-day routing is enforced, users cannot set certain Call Forward All (CFA) numbers at
certain times. For example, the user A calling search space for forwarding includes a time-ofday-configured partition that allows international calls from 8:00 to 17:00 (5:00 p.m.). User A
wants to configure his CFA number to an international number. He can set this number only
during the 8:00 to 17:00 time period because, outside these hours, the system does not find the
international number in the partition that is used to validate the CFA number.
If the user sets the CFA during office hours when it is allowed, and the user receives a call
outside office hours, the caller hears a fast busy signal.
Users cannot reach DNs in some partitions that are configured for time-of-day routing and that
are not active during the time of call, depending upon the configuration of partitions.
Users also cannot reach the route or translation patterns in partitions configured with time-ofday routing that are not active at the time of call.
3-114
This topic discusses how to configure time-of-day routing to control call routing based on the
time of day, day of week, and day of year when the call was made.
new
1. Create the time periods.
2. Create the time schedule and assign the
time periods.
3. Assign the time schedule to a partition.
CIPT1 v4.13-11
To access the time-of-day routing configuration components, choose Route Plan > Class of
Control > Time Period or Route Plan > Class of Control > Time Schedule.
Note
Class of Control is a new submenu item under the Route Plan menu in Release 4.1 of Cisco
CallManager. The Class of Control menu also includes Partitions and Calling Search
Spaces items.
To configure time-of-day routing, follow these steps:

Step 1
Create the individual time periods.
Step 2
Create the time schedule and assign the time periods to it.
Step 3
Assign the time schedule to a partition.
3-115
Configuring Time Periods
Defines time interval:

Valid 8 a.m. to 5 p.m.
Defines repetition interval:
Valid from Monday to
Friday every week
CIPT1 v4.13-12
To add and configure a time period, follow this procedure:

Step 1
In the menu bar, choose Route Plan > Class of Control > Time Period.
Step 2
Click Add a New Time Period.
Step 3
Enter the time period name, start time, end time, and repetition interval.
Step 4
To add the new time period, click Insert.

The message Status: Insert completed appears.
Step 5
To add more time periods, click Add a New Time Period and repeat this procedure.
The figure shows an example of a time period named OfficeHours, a start time of 08:00 and
end time of 17:00, and a weekly repetition interval of every Monday through Friday.
3-116
Time Period Configuration Settings

Parameter
Description
Time Period Name
Enter a name in the Time Period Name field. The name can
include up to 50 alphanumeric characters and can contain any
combination of spaces, periods (.), hyphens (-), and underscore
characters (_). Ensure that each time period name is unique to
the plan.
Use concise and descriptive names for your time periods. The
hours_or_days format usually provides a sufficient level of detail
and is short enough to enable you to quickly and easily identify a
time period. For example, office_M_to_F identifies a time period
for the business hours of an office from Monday to Friday.
Start Time
Time when this time period starts. The available start times are
15-minute intervals throughout a 24-hour day. The default value
is No Office Hours.
No Office Hours means that the selected partition will not be
active for the defined day of year or days of week.
To start a time period at midnight, choose the 0:00 value.
End Time
Time when this time period ends. The available end times are 15minute intervals throughout a 24-hour day. The default value is
No Office Hours. To end a time period at midnight, choose the
24:00 value.
Repeat Every
Click one of the radio buttons to set a schedule:

Week From: If you click the Week From radio button, use the
drop-down menus next to From and To to choose the days of
the week during which this time period applies.
Examples: Choose a From value of Mon(day) and a To value of
Fri(day) to define a time period that applies from Monday to
Friday. Choose a From value of Sat(urday) and a To value of
Sat(urday) to define a time period that applies only on Saturdays.
Year On: If you click the Year On radio button, use the dropdown lmenus to choose the month and day of the year on
which this time period applies. To end a time period at
midnight, choose the 24:00 value.
Example: Choose the month Jan(uary) and the day 1 to define a
time period that applies yearly on New Year's Day.
3-117
Configuring Time Periods (Cont.)
Defines time interval

Defines repetition
interval:
Valid only on Dec. 25
No Office Hours is the default start time and end timethe selected partition will
not be active for the defined day of year or days of week.
CIPT1 v4.13-13
The figure shows how to create a time period using the No Office Hours time interval and a
repetition interval with a specific day of the year defined. When the No Office Hours time
interval is selected, the associated partition is not active for the defined days of the week or day
of the yearin this example, December 25.
Use the No Office Hours time interval and the Year On repetition interval for days, such as
Christmas, New Years Day, and national holidays, when for example, the company is closed,
certain departments are closed, or certain employees are on holiday.
3-118
Configuring Time Schedules
CIPT1 v4.13-14
After the time periods are created, you can create the time schedule:
Step 1
In the menu bar, choose Route Plan > Class of Control > Time Schedule.
Step 2
Click Add a New Time Schedule.
Step 3
Name the time schedule in the Time Schedule Name field.
Step 4
Choose the desired time periods from the Available Time Periods pane and use the
Down arrow to move them to the Selected Time Periods pane. Move any time
periods you do not want in the Selected Time Periods pane to the Available Time
Periods pane.
Step 5
To add the new time schedule, click Insert (or Update if the time schedule already
exists and you are changing it.)
The message Status: Insert completed appears.
Step 6
To add more time schedules, click Add a New Time Schedule and repeat this
procedure.
3-119
Assigning Time Schedules to Partition
Time
schedule
Time zone
CIPT1 v4.13-15
Associating the time schedule (collection of time periods) to a partition is the final step in
configuring time-of-day routing. A time schedule is not activated until it is assigned to a
partition. (In Cisco IOS software, this process is similar to creating an access control list (ACL)
that does not become activated until it is assigned to an interface.)
You can create a new partition from the Partition Configuration window and assign the time
schedule to it or assign the time schedule to an existing partition. The process is the same:
Step 1
From the Time Schedule drop-down menu, choose a time schedule to associate with
this partition.
Step 2
Choose either the time zone of the originating device or any specific time zone for a
time schedule. The system checks the chosen time zone against the time schedule
when the call is placed to directory numbers in this partition.
The Partition and Calling Search Space menu items have moved to the Routing > Class of
Control submenu in Release 4.1 of Cisco CallManager.
3-120
Time-of-Day Routing Settings

Subhead
Subhead
Time Schedule
From the drop-down menu, choose a time schedule to associate

with this partition. The associated time schedule specifies when
the partition is available to receive incoming calls.
The default value specifies None, which means that time-of-day
routing is not in effect and the partition remains active at all times.
In combination with the Time Zone value in the following field,
associating a partition with a time schedule configures the
partition for time-of-day routing. The system checks incoming
calls to this partition against the specified time schedule.
Time Zone
Choose one of the following options to associate a partition with a

time zone:
Originating Device: If you choose this option, the system
checks the partition against the associated time schedule
with the time zone of the calling device.
Specific Time Zone: If you choose this option, choose a time
zone from the drop-down menu. The system checks the
partition against the associated time schedule at the time
that is specified in this time zone.
These options all specify the time zone. When there is an
incoming call, the current time on the Cisco CallManager is
converted into the specific time zone that you set. This specific
time is validated against the value in the Time Schedule field.
3-121
Time-of-Day Routing Usage Scenario
This topic discusses call outcomes for one time-of-day routing usage scenario.
Example: Route Calls After Office Hours to

Home Number
A
A dials 2000
Current Time: 10:00
Current Day: Wed.
1000/CiscoSJ
CSS1: CiscoSJ,
CiscoOutside
A dials 2000
Current Time: 20:00
Current Day: Wed.
Partition CiscoSJ:
Time Schedule TS1
Specific Time Zone (EST)
Time Schedule TS1: Time Period TP1
TP1: 08:0017:00 MonFri
Cisco CallManager
extends call to
2000/CiscoSJ
2000/CiscoSJ
Cisco CallManager
extends call to
2000/CiscoOutside
2000/CiscoOutside
CFA: 9725550111
(Home Number)
Partition CiscoOutside:
Time Schedule TS2
Specific Time Zone (EST)
Time Schedule TS2: Time Period TP2, TP3
TP2: 17:0024:00 MonFri
TP3: 00:0008:00 TueSat
CIPT1 v4.13-16
The figure shows an example of how time-of-day routing can be configured to route calls after
office hours to a home number.
The setup is as follows:
Partition CiscoSJ is configured with the time schedule TS1 and the specific time zone
Eastern Standard Time (EST).
Time period TP1 is associated with time schedule TS1.
The TP1 start time is 08:00, the end time is 17:00, and the repetition interval is
Monday through Friday.
Partition CiscoOutside is configured to use time schedule TS2 and the specific time zone
EST.
Time periods TP2 and TP3 are associated with time schedule TS2.
Monday through Friday.
Tuesday through Saturday.
The user A calling search space is CSS1. CSS1 contains the CiscoSJ and CiscoOutside
partitions.
Call flow is as follows:
User A at extension 1000 calls 2000 at 10:00 a.m. Wednesday. The partition CiscoSJ is
active at that time (TP1), so the call is forwarded to 2000.
3-122
User A at extension 1000 calls 2000 at 20:00 (8:00 p.m.) Wednesday. The partition
CiscoSJ is not active at that time. However, the partition CiscoOutside is active then (TP2),
and the calling search space CSS1 contains a pattern to reach the user B home phone
number 9725550111, which enables user B to set CFA to forward incoming calls to a home
number.
Note
Time-of-day routing is covered in more detail as it relates to preventing toll fraud applications
in the Cisco IP Telephony Part 2 course Preventing Toll Fraud lesson.
3-123
Summary
Summary
Cisco CallManager implements class of service via
partitions and calling search spaces.
A partition is a group of DNs with similar
accessibility, and a calling search space defines
which partitions are accessible to a particular
device.
To configure partitions and calling search spaces,
create the partition, create the calling search space,
and then assign the partitions to the calling search
space.
CIPT1 v4.13-17
Summary (Cont.)
Time-of-day routing routes calls to different
locations based on the time of day or day of the
year when a call is made.
To configure time-of-day routing, create the time
periods, create the time schedule, assign the
time periods to the time schedule, and assign the
time schedule and time zone parameter to a
partition.
Time-of-day routing can be applied to a range of
usage scenarios to restrict or allow call routing.
3-124
CIPT1 v4.13-18
References
Cisco Systems, Inc. Cisco CallManager System Guide, Release 4.1(3), Partitions and
Calling Search Spaces and Time-of-Day Routing.
3/ccmsys/index.htm.
Cisco Systems, Inc. Cisco CallManager Administration Guide, Release 4.1(3), Partition
Configuration, Calling Search Space Configuration, Time Period Configuration, and
Time Schedule Configuration.
3/ccmcfg/index.htm.
3-125
3-126
Lesson 3-6
Implementing Multiple-Site
Deployments
Overview
Implementing multiple-site IP telephony deployments over an IP WAN requires additional

planning to ensure the quality and availability of voice calls.
When an IP WAN connects IP telephony clusters, a mechanism must exist to control the audio
quality and video quality of calls over the IP WAN link by limiting the number of calls that are
allowed on that link at the same time. Call admission control is the mechanism that ensures that
voice calls do not oversubscribe the IP WAN bandwidth and affect voice quality.
When the IP WAN bandwidth is consumed, a mechanism must exist to automatically reroute
calls over the Public Switched Telephone Network (PSTN) without requiring the caller to hang
up and redial the called party. Automated alternate routing (AAR) is a Cisco CallManager
feature that automatically reroutes calls through the PSTN or other networks when bandwidth is
insufficient in a centralized call-processing deployment.
If connectivity with Cisco CallManager is lost, Cisco IP Phones became unusable for the
duration of the failure. Cisco Survivable Remote Site Telephony (SRST) overcomes this
problem and ensures that the Cisco IP Phones offer continuous service by providing
call-handling support for Cisco IP Phones directly from the Cisco SRST router.
This lesson describes the operation and configuration of call admission control, AAR, and
SRST.
Objectives
Upon completing this lesson, you will be able to configure call admission control and AAR in a
centralized deployment and configure a Cisco IOS gatekeeper for call admission control in a
distributed deployment to prevent oversubscribing the WAN. You will also configure Cisco
SRST on a Cisco IOS gateway to provide call-processing redundancy. This ability includes
Describe why call admission control is important to maintain voice QoS across an IP WAN
Describe how the locations feature in Cisco CallManager provides call admission control
for centralized call-processing environments
Configure locations-based call admission control in a centralized call-processing
deployment to limit the number of active calls and prevent oversubscribing the bandwidth
on the IP WAN linksExplain what AAR is and how it works
Explain the requirements for configuring Cisco CallManager for AAR
Describe how a gatekeeper can reduce the number of intercluster trunks that are required in
a distributed call-processing environment
Identify the communication procedures between an H.323 gatekeeper and H.323 endpoint,
including discovery, registration, admission, and bandwidth requests
Configure gatekeeper-based call admission control in a distributed call-processing
deployment to limit the number of active calls and prevent oversubscribing the bandwidth
on the IP WAN links
Describe how SRST provides Cisco CallManager failover capabilities
Configure SRST on a supported gateway and in Cisco CallManager so that the SRST router
assumes call-processing duties should the WAN link fail
3-128
Call Admission Control Overview
This topic discusses the importance of call admission control and the types of call admission
that are possible with Cisco CallManager.
Why Call Admission Control?

Example:
WAN bandwidth can support only two calls.
What happens when the third call is attempted?
Cisco CallManager
Cisco CallManager
Call No. 1
Call No. 2
Call No. 3
IP WAN
Call No. 3
Causes poor quality for all calls
Many tools give voice priority over data.
Call admission control is about preventing voice oversubscription.
Need call admission control only for calls that traverse the IP WAN.
CIPT1 v4.13-3
Call admission control provides you with mechanisms to control the volume of calls between
two endpoints. Controlling the number of calls, or the amount of bandwidth that is required
between two endpoints, is key to maintaining quality of service (QoS) for all existing and new
calls. You can provision the network to carry a specific amount of real-time traffic. Any traffic
that exceeds the provisioned bandwidth will subject all real-time traffic to delay, jitter, and
possibly packet loss.
The coder-decoder (codec) used for the call determines the bandwidth calculations used with
call admission control.
3-129
Two Methods of Call Admission Control

Centralized call
processing:
Use locations feature
Cisco CallManager
Cluster
IP WAN
PSTN
Distributed call processing:

Use gatekeepers and
intercluster (gatekeepercontrolled) trunks
Cisco IOS
Gatekeeper
IP WAN
PSTN
CIPT1 v4.13-4
Using Cisco CallManager, the following two types of call admission are possible:
Locations call admission control: The locations feature of Cisco CallManager provides a
simplified call admission control scheme for centralized call-processing systems. A
centralized system uses a single Cisco CallManager cluster to control all of the locations.
Gatekeeper call admission control: A gatekeeper device provides call admission control
for distributed call-processing systems. In a distributed system, each site contains its own
call-processing capability.
3-130
Locations-Based Call Admission Control

Overview
This topic discusses the locations feature in Cisco CallManager for providing call admission
control.
Centralized Call Processing:

Cisco
CallManager
Cluster
Location
Bandwidth
(kbps)
San Jose
Unlimited
New York
256
Dallas
64
New York (Remote)
IP WAN
San Jose (Main)
Dallas (Remote)
Location: Defines the amount of bandwidth available

Region: Defines the compression type used
CIPT1 v4.13-5
Cisco CallManager provides a simple locations-based call admission control mechanism for
hub-and-spoke topologies, used primarily for centralized call processing.
The locations feature in Cisco CallManager lets you specify the maximum amount of audio
bandwidth (for audio calls) and video bandwidth (for video calls) that is available for calls to
and from each location. This specification limits the number of active calls and limits
oversubscription of the bandwidth on the IP WAN links.
For the purpose of calculating bandwidth for call admission control, Cisco CallManager
assumes that each call stream consumes the following amount of bandwidth:
A G.711 call uses 80 kbps.
A Global System for Mobile Communication (GSM) call uses 29 kbps.
A wideband call uses 272 kbps.
3-131
Locations work in conjunction with regions to define the characteristics of a network link.
Locations define the amount of available bandwidth for the link, and regions define the type of
compression (G.711, G.723, or G.729) that is used on the link.
Example
In the figure, three locations are specified: San Jose (unlimited bandwidth), New York
(256 kbps), and Dallas (64 kbps). Cisco CallManager continues to admit new calls to a link as
long as sufficient bandwidth is still available. Thus, if the link to the New York location in this
example has 256 kbps of available bandwidth, that link can support three G.711 calls at 80 kbps
each and ten G.723 or G.729 calls at 24 kbps each. If any additional calls are received that
would exceed the bandwidth limit, the system rejects them, the calling party receives a reorder
tone, and a text message is displayed on the phone.
Refer to the Understanding Video Telephony section in Cisco CallManager System Guide,
Release 4.1(3) for more details on video telephony across the WAN at:
http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_1/sys_ad/4_1_3/cc
msys/a08video.htm.
The Cisco IP Telephony Part 2 (CIPT2) course also covers video telephony in more detail.
3-132

Configuration
This topic discusses how to configure locations-based call admission control in Cisco
CallManager.
Location Configuration
Location is then assigned to devices.
Configure a region for each type of codec used.

Configure a separate location for each IP WAN link.
CIPT1 v4.13-6
Follow these steps to configure locations in Cisco CallManager:

Step 1
Choose System > Region to configure a region for each type of codec that is used in
your system.
Step 2
Choose System > Location to configure a separate location for each IP WAN link
to which you want to apply call admission control. Allocate the maximum available
bandwidth for calls across the link to that location.
Step 3
Choose System > Device Pools to configure the device pools for your system, and
choose the appropriate region for each.
Step 4
In the individual device configuration windows, configure the telephones and other
devices and assign each of them to the appropriate device pool and location.
3-133
AAR Overview
This topic defines AAR and describes how it works.
AAR
PSTN
WAN
CAC
Headquarters
Phone A
Branch A
Phone B
Branch B
1
2
Cisco CallManager blocks a call over the WAN.

The call is automatically rerouted over the PSTN.
CIPT1 v4.13-7
AAR allows calls to be rerouted through the PSTN by using an alternate number when Cisco
CallManager blocks a call due to insufficient location bandwidth. With AAR, the caller does
not need to hang up and redial the called party. If AAR is not configured, the user gets a reorder
tone and the IP Phone displays Not enough bandwidth. When a call is forwarded to voice
mail, the caller cannot leave a message.
AAR applies to centralized call-processing deployments. For instance, if a telephone in a
company headquarters calls a telephone in branch B and the available bandwidth for the WAN
link between the branches is insufficient (as computed by the locations mechanism), AAR can
reroute the call through the PSTN. The audio path of the call would be IP-based from the
calling phone to its local (headquarters) PSTN gateway, time-division multiplexing (TDM)based from that gateway through the PSTN to the branch B gateway, and IP-based from the
branch B gateway to the destination IP phone.
AAR is transparent to users. It can be configured so that users dial only the on-net (for
example, four-digit) directory number (DN) of the called phone and no additional user input is
required to reach the destination through the alternate network (such as the PSTN).
3-134
AAR Call Flow

Location HQ
New alternate dial string: 91-212-555-1234
PSTN
Location A
1234
WAN
CAC
2345
2345 dials 1234
Headquarters
Branch A
1.
2345 dials on-net to 1234; call admission control denies the call.
2.
The external phone number mask 212-555-XXXX is added to the internal DN

1234; the result is a fully qualified number, 215-555-1234.
3.
To access the PSTN gateway, dial the 91 prefix.
4.
9 1-215-555-1234 is the new alternate dial string.

CIPT1 v4.13-8
In the AAR process, when Cisco CallManager determines that not enough bandwidth is
available, it sends a message (Network congestion, rerouting) to the telephone and starts the
AAR process.
The AAR process collects the data to build the alternate number with the DN, the phone
number mask, and the PSTN prefix configured in the AAR group. The new number passes the
call-processing procedure again, but this time the result is that a PSTN gateway will be used.
The figure shows an example of establishing the alternate PSTN number:
Step 1
Phone A (DN = 2345) dials on-net to phone B (DN = 1234).
Step 2
Call admission control denies the call.
Step 3
The external phone number mask 215-555-XXXX is added. The result is a fully
qualified number, 215-555-1234.
Step 4
The prefix used to access the PSTN gateway is 9, and 1 is added to the string for
numbering plan compatibility. These values are configured in the AAR group.
Step 5
9-1-215-555-1234 is the new alternate dial string.
3-135
AAR Requirements
AAR requirements:
Locations-based call admission control
Originating IP phone and outgoing gateway in the same
location
Terminating IP phone and terminating gateway in the same
location
AAR will not work in these scenarios:
A call originates from one location and terminates on
another vendor IP phone device or voice-mail port at
another location
A call originates from a CTI route point
During a WAN outage; AAR does not work with SRST,
because the phones are not available
CIPT1 v4.13-9
Keep the following requirements and caveats in mind when applying AAR:
AAR requires call admission control based on locations and regions; AAR will function
only if the WAN bandwidth is consumed.
The IP Phone that originates a call should be in the same location as the gateway that routes
the call to the PSTN.
The called IP Phone and the gateway that terminates the call from the PSTN should be in
the same location.
If a call originates from a device in one location and terminates to a non-IP phone in
another location, AAR will not function. A voice-mail port on another vendor device also
does not use AAR.
If a call originates from a Cisco computer telephony integration (CTI) route point, AAR
will not function.
AAR does not work with SRST, which means that AAR will not function in the case of a
WAN failure.
3-136
AAR Configuration
This topic discusses configuring Cisco CallManager for AAR.
AAR Configuration on Cisco CallManager

Configure the locations.
Configure the regions.
Assign devices to the region and location.
Enable AAR cluster-wide.
Configure AAR groups.
Configure the calling search space for AAR.
Configure the endpoints for AAR.
CIPT1 v4.13-10
Configuring Cisco CallManager for AAR requires the following steps:

Step 1
Configure the locations. Use locations to implement call admission control in a

centralized call-processing system. Cisco CallManager requires that the locations be
arranged in a hub-and-spoke topology.
Step 2
Configure the regions. Use regions to specify the type of compression and the
amount of bandwidth used within a region and between regions.
Step 3
Assign devices to a region and location. Use device pools to define sets of common
characteristicsin this case, the region settingfor devices in a specific location.
Step 4
Enable AAR cluster-wide. Ensure that the Automated Alternate Routing Enable
service parameter is set to True.
Step 5
Configure AAR groups. For each AAR group, enter the prefix digits that are used
for AAR within the AAR group, as well as the prefix digits used for AAR between a
given AAR group and other AAR groups. Devices such as gateways, telephones (by
means of DNs), and trunks associate with AAR groups.
Step 6
Configure the calling search space for AAR. Cisco CallManager uses the AAR
calling search space to reroute calls when there is no available bandwidth on the
WAN.
3-137
Step 7
Configure the endpoints as follows:

Assign devices to the AAR group.
Assign the external line mask to the DN.
Assign devices to AAR calling search space.
The AAR configuration steps starting with Step 4 are covered in detail in the following
subtopics.
Enable AAR Enterprise Parameters

AAR Clusterwide Parameters
CAC and AAR messages in Service Parameters
CIPT1 v4.13-1
Automated Alternate Routing Enable in System Parameters

In the Service > Service Parameters window for the Cisco CallManager service, ensure that the
Automated Alternate Routing Enable service parameter is set to True (near the bottom of the
window). The default value for this service parameter is False.
Cluster-Wide Parameters
In the Service Parameters > CallManager > Cluster Wide Parameters (DevicePhone) window
are two fields used to configure the messages that appear on the phone if there is no WAN
bandwidth available or if AAR reroutes the call over the WAN.
3-138
AAR Group Configuration
Dialing area where the DN of the Cisco voice-mail

port and the gateway are located
Establishes the prefix digits that are used for AAR
within the AAR group and between groups
CIPT1 v4.13-12
If a user dials an internal number that goes to another location and the WAN is busy, the call
should be rerouted over the PSTN. To place a call over the PSTN, Cisco CallManager needs
the fully qualified number, not the internal DN, to reroute the call.
The destination number might require a prefix for an off-net access code (for example, 9) to be
routed properly by the dial plan of the origination branch. Furthermore, if the point of origin is
located in a different Numbering Plan Area (NPA, or area code), a prefix of 1 might be required
as part of the dialed string.
Cisco CallManager uses the internal DN, the external phone number mask of the called DN,
and the prefix to determine the alternate number for routing the call over the PSTN.
When configuring AAR, place the DNs in AAR groups. For each pair of AAR groups, you can
configure prefix digits to add to the DNs for calls between the two groups, including prefix
digits for calls originating and terminating within the same AAR group.
As a general rule, place DNs in the same AAR group if they share all of the following
characteristics:
A common off-net access code (for example, 9)
A common PSTN dialing structure for interarea calls (for example, 1-NPA-Nxx-xxxx in
North America)
A common external phone number mask format
For example, assume that both the San Francisco and New York sites share all of the preceding
characteristics. The DNs for San Francisco and New York can be placed into a single AAR
group, and the group can be configured such that AAR calls placed within this AAR group are
prefixed with 91. For phone A in San Francisco to reach phone B in New York (at 212-5551212), the AAR group configuration prefixes 91 to the dialed string, yielding a completed
string of 91-212-555-1212.
3-139
Adding an AAR Group in CallManager

Complete these steps to add an AAR group:
Step 1
From the menu bar, choose Route Plan > AAR Group.
Step 2
Click Add a New AAR Group.
Step 3
Enter a name in the AAR Group Name field.
Step 4
Click Continue.
Step 5
In the Prefix Digits Within field for the group being added, enter the prefix digits to
use for AAR within this AAR group.
Step 6
In the Prefix Digits Between the group being added and Other AAR Groups area,
complete the following fields:
Prefix Digits (From): Enter the prefix digits to use for AAR when routing a call
from this group to a device that belongs to another AAR group.
Note
Prefix digits that are entered in this field for the originating AAR group are also added in the
Prefix Digits (To) field of the AAR destination group.
Prefix Digits (To): Enter the prefix digits to use for AAR when you are routing
a call to this group from a device that belongs to another AAR group.
Note
Step 7
3-140
Note: Prefix digits entered in this field for the destination AAR group are also added in the
Prefix Digits (From) field of the AAR originating group.
Click Insert to add this AAR group.
Endpoint Configuration for AAR

1. Configure the phones to use the AAR calling
search space and the DN to use the AAR group.
2. Assign the external phone-number mask to
the DN.
3. Configure the gateway to use the AAR calling
search space and the AAR group.
4. Configure the voice-mail ports to use the AAR
group only.
CIPT1 v4.13-13
To configure endpoints and gateways for AAR, complete these steps:

Step 1
Configure the phones to use the AAR calling search space and the DN to use the
AAR group.
Step 2
Assign the external phone number mask to the DN.
Step 3
Configure the gateway to use the AAR calling search space and the AAR group.
Step 4
Configure the voice-mail ports to use the AAR group only.
3-141
DN Configuration for AAR Group
CIPT1 v4.13-14
Assign the DN to the AAR group in the Directory Number Configuration window. An AAR
group setting of None specifies that no rerouting of blocked calls will be attempted.
As a general rule, place DNs in the same AAR group if they share all of the following
characteristics:
A common off-net access code (for example, 9)
A common PSTN dialing structure for interarea calls (for example, 1-NPA-Nxx-xxxx in
North America)
A common external phone number mask format
3-142
External Line Mask

Establishes the fully qualified PSTN number
Added to the line
Example:
1. Phone A (DN = 2345) dials on-net to Phone B (DN = 1234):
Call admission control denies the call.
The external phone number mask 215-555-XXXX is
added.
The result is a fully qualified number, 215-555-1234.
2. The prefix must be added:
To access the PSTN gateway, dial 9.
Configure 9 in the AAR group.
9-215-555-1234 is the new alternate dial string.
CIPT1 v4.13-15
The rerouting of calls requires using a destination DN that is routable through the alternate
network (for example, the PSTN). AAR uses the dialed digits to establish the on-cluster
destination of the call and then combines them with the external phone number mask of the
called party. The combination of these two elements must yield a fully qualified number that is
routable by the alternate network.
The destination number might require a prefix for an off-net access code (for example, 9) to be
routed properly by the origination branch dial plan. Furthermore, if the point of origin is located
in a different NPA, a prefix of 1 might be required as part of the dialed string. Add these prefix
digits in the AAR Group Configuration window.
For example, assume that phone A in San Francisco (DN = 2345) dials an on-net DN (1234)
configured on phone B in New York. If locations-based call admission control denies the call,
AAR retrieves the external phone number mask of the New York phone (212-555-XXXX) and
uses it to derive the fully qualified number (212-555-1234. that is routable on the PSTN.
The PSTN routing of a call from San Francisco to New York requires a 1 as a prefix to the
phone number. It is recommended that this prefix not be included as part of the external phone
number mask because it would be displayed as part of the Calling Line Identification (CLID, or
caller ID) for any calls made by the phones to an off-net destination. Instead, it is recommended
that the 1 be added as part of the AAR group configuration.
3-143
External Line-Mask Configuration
CIPT1 v4.13-16
Configure the external phone number mask on the DN. (Choose Device > Phone, then select
the phone and select the line.)
Indicate the phone number (or mask) that is used to send caller ID information when a call is
placed from this line. A maximum of 30 numeric and X characters can be added. The Xs
represent the DN and must appear at the end of the pattern. For example, if you specify a mask
of 972813XXXX, an external call from extension 1234 displays a caller ID number of
9728131234.
3-144
AAR Calling Search Space

Is a new device-based Calling search space
Can be assigned to an IP Phone or gateway
Is used by the originating device in call processing
to select the outgoing gateway device when the
call is rerouted
Should not be used for DNs; use the AAR group
instead
CIPT1 v4.13-17
With AAR, the AAR calling search space was introduced. With this special parameter, the
caller rights can be adjusted for this special event when AAR is used. Cisco CallManager looks
at the AAR calling search space to determine whether the device has the right to call over the
PSTN. For example, if the originating calling device can reach only internal phones with the
configured calling search space, then it is possible with the AAR calling search space to allow
calls from that device to be rerouted using the PSTN.
3-145
Phone Configuration for AAR Calling

Search Space
CIPT1 v4.13-18
The AAR calling search space specifies the collection of route partitions that are searched to
determine how to route a collected (originating) number that is blocked because of insufficient
bandwidth. You can assign the AAR calling search space to the phone from the Phone
Configuration window.
Gateway Configuration for AAR Group

and AAR Calling Search Space
CIPT1 v4.13-19
The difference between configuring IP Phones for AAR and configuring gateways for AAR is
that the parameters for AAR groups and AAR calling search spaces are in the same window in
the gateway configuration, as shown in the figure.
3-146
Voice-Mail Port Configuration

for AAR Group
CIPT1 v4.13-20
With voice mail, an AAR calling search space is not needed because the voice-mail port does
not initiate calls. However, the configuration of the AAR group is important; otherwise, the
users in a branch are not able to forward their calls to the voice-mail system at the headquarters.
3-147
Gatekeeper Call Admission Control Overview

This topic discusses basic concepts of gatekeeper call admission control.
Distributed Call Processing: Gatekeeper

Call Admission Control
Gatekeeper call
admission control
reduces configuration
overhead and provides
flexibility.
Cisco CallManager
registers with the
gatekeeper using an IP
address.
Gatekeeper Zone
Gatekeeper
IP WAN
A single gatekeeper can

manage up to 100 Cisco
CallManager clusters.
CIPT1 v4.13-21
Gatekeeper call admission control reduces configuration overhead by eliminating the need to
configure separate individual intercluster trunks between clusters. A gatekeeper can determine
the IP addresses of devices that are registered with it, or you can enter the IP addresses
explicitly.
If you choose the gatekeeper method of call admission control, you will need to set up an
intercluster trunk (gatekeeper-controlled) or H.225 trunk (gatekeeper-controlled). When you
configure gatekeeper-controlled trunks, Cisco CallManager automatically creates a virtual
trunk device. The IP address of this device changes dynamically to reflect the IP address of the
remote device as determined by the gatekeeper.
A zone is a collection of H.323 nodes controlled by a single gatekeeper. You can connect up to
100 Cisco CallManager clusters to a single gatekeeper.
3-148
Gatekeeper Communication
This topic describes the communication between the gatekeeper and H.323 endpoint (Cisco
CallManager).
Gatekeeper Discovery
GRQ (1)
H.323 Endpoint
GCF/GRJ (2)
Gatekeeper
CIPT1 v4.13-22
The first process that an endpoint must go through is gatekeeper discovery. An endpoint
achieves gatekeeper discovery either manually or through autodiscovery.
Autodiscovery uses multicast to discover the gatekeeper. A gatekeeper request (GRQ) is
multicast, and any gatekeeper that can accept a registration returns a gatekeeper confirmation
(GCF). If a gatekeeper cannot accept a registration, it returns a gatekeeper reject (GRJ).
Note
This lesson provides an overview of the process and describes the basic configuration of a
Cisco IOS gatekeeper for use with Cisco CallManager. For more complete information on
configuring gatekeepers, refer to the Cisco Voice over IP (CVOICE) or Implementing
Gateways and Gatekeepers (GWGK) courses.
3-149
Gatekeeper Registration and

Unregistration
H.323 Endpoint
Registration
Gatekeeper-Initiated
Unregistration Request
Endpoint-Initiated
Unregistration Request
Gatekeeper
RRQ (1)
RCF/RRJ (2)
URQ (1)
UCF (2)
URQ (1)
UCF/URJ (2)
CIPT1 v4.13-23
A Cisco IOS gatekeeper supports two types of registration:

Full registration
Lightweight registration
An endpoint must always use a full registration during the initial registration process. An
endpoint may use lightweight registration to maintain registration. Should an endpoint become
unregistered with the gatekeeper, a full registration is required.
Full registration requires the endpoint to register any E.164 address, H.323 identifer, device
type, and other possible parameters each time that it registers. This procedure involves
additional processing load on a gatekeeper every time an endpoint registers or renews its
registration. The registration request (RRQ) includes the time between renewal of registrations
or Time to Live (TTL), and the gatekeeper may replace this value or return this value
unchanged.
Note
You can make the returned TTL value configurable with Cisco IOS Software Release
12.1.5T and later.
The lower the TTL value, the higher the load on the gatekeeper processing the registration. The
impact of a higher value is that it takes longer for the gatekeeper to become aware that an
endpoint that has lost connectivity. Use 30 to 300 seconds, depending on design requirements.
When the endpoint sends a full RRQ to the gatekeeper, the gatekeeper responds with a
registration confirmation (RCF) to accept or a registration rejection (RRJ) to refuse. The
gatekeeper may refuse the registration for many reasons, such as duplicate E.164 or H323
identifiers or ambiguous information.
3-150
An endpoint registration has a finite life. Before the TTL expires, the endpoint is required to
renew its registration by sending an RRQ. If the TTL expires and the gatekeeper has not
received an RRQ from the endpoint, the endpoint becomes unregistered.
Lightweight registration reduces the processing load on the gatekeeper during registration
renewal. The gatekeeper receives an RRQ with the keepalive bit set and the minimum required
information from the endpoint. If the gatekeeper accepts the renewal, the gatekeeper returns an
RCF to the endpoint and resets the TTL timer. If the gatekeeper rejects the renewal with an
RRJ, the endpoint becomes unregistered.
If the endpoint is unregistered, the endpoint must start the gatekeeper discovery and registration
process again.
At any time, an endpoint or a gatekeeper may cancel a registration with an unregister request
(URQ), normally used during configuration changes.
An endpoint or gatekeeper sends an unregister confirmation (UCF) in response to a URQ. If an
unregistered endpoint sends a URQ to a gatekeeper, the gatekeeper responds with an unregister
reject (URJ) to indicate the error. Cisco IOS gatekeepers, Cisco IOS gateways, and Cisco
CallManager support lightweight registration.
Admission Request
Gatekeeper
H.323 Endpoint 1
H.323 Endpoint 2
ARQ (1)
ACF/ARJ (2)
Setup (3)
Call Proceeding (4)
ARQ (5)
ACF/ARJ (6)
Alerting (7)
Connect (8)
RAS Messages
Call Signaling
CIPT1 v4.13-24
Telephony endpoints (Cisco IP Phones or Cisco IP SoftPhones) send an admission request

(ARQ) to the gatekeeper to initiate a call. The ARQ contains an H.323 identifier or the E.164
address of a destination or called party that it wishes to reach. Also contained within the ARQ
message are the call bandwidth (not including the header overhead), the source E.164 address,
and the H.323 identifier of the calling party.
Note
The call bandwidth requested will be the upper limit of both the transmitted and received bit
rate for all video and audio channels.
3-151
Note
There will always be an E.164 address with Cisco CallManager.
The gatekeeper will respond to the ARQ with either an admission confirmation (ACF) or an
admission reject (ARJ). The gatekeeper sends the ACF if the requested bandwidth is available
and the called endpoint is found. The ACF contains the IP address of the endpoint. On receipt
of an ACF from the gatekeeper, the endpoint sends a setup message directly to the other
endpoint, using the IP address returned in the ACF.
If bandwidth is unavailable or if the called endpoint is not registered, the gatekeeper sends an
ARJ.
Disengage and Bandwidth Request

H.323 Endpoint
Disengage
Bandwidth
Gatekeeper
DRQ (1)
DCF(2)
BRQ (1)
BCF/BRJ (2)
CIPT1 v4.13-25
When an endpoint terminates a call, the endpoint is required to indicate the termination to the
gatekeeper and return the used bandwidth. The endpoint sends a disengage request (DRQ) to
the gatekeeper to indicate that the call is complete. The gatekeeper responds with a disengage
confirmation (DCF) and returns the previously used bandwidth to the pool.
The gatekeeper can also clear the call by sending a DRQ to the endpoint, forcing the endpoint
to clear the call with the other endpoint and return a DCF.
If during the duration of the call the bandwidth requirement changes, because of a changing
codec or additional media channels opening or closing, the endpoint may request or release the
bandwidth by sending a bandwidth request (BRQ). The gatekeeper responds with a bandwidth
confirmation (BCF) if the bandwidth is available or with a bandwidth reject (BRJ) if the
bandwidth is not available.
3-152
Gatekeeper Call Admission Control

Configuration
This topic describes the two configuration components of gatekeeper call admission control:
gatekeeper configuration on the router and gatekeeper and trunk configuration in Cisco
CallManager.
Gatekeeper Configuration on the Router

Configure zones and bandwidth
allocations on the gatekeeper.
Cisco IOS Gatekeeper

---
CIPT1 v4.13-26
The general recommendation is to use separate Cisco routers as dedicated gatekeepers in your
network in a number appropriate for your topology. You can configure a gatekeeper with the
appropriate Cisco IOS feature set, such as the Enterprise Plus/H323 MCM feature set.
The following are the general steps for configuring call admission control using gatekeepers
and trunks:
Step 1
On the gatekeeper device, configure the appropriate zones and bandwidth allocations
for the various Cisco CallManager nodes that will route calls to it.
Step 2
Configure gatekeeper settings in Cisco CallManager Administration. Make sure that

the hostname or IP address is set the same way on each Cisco CallManager. You can
register multiple gatekeepers per Cisco CallManager cluster.
Step 3
Configure the appropriate intercluster trunks or H.225 trunks to specify gatekeeper

information. The H.225 trunk allows connectivity to H.323 Cisco IOS gateways.
The intercluster trunk provides specific Cisco functionality for calls between Cisco
CallManager clusters.
Step 4
Configure a route pattern to route calls to each gatekeeper-controlled trunk.
3-153
Example
Shown in the figure is a sample gatekeeper configuration. The commands are described in the
table.
Cisco IOS Gatekeeper Commands
Command
Description
Enters gatekeeper configuration mode.
Specifies the zone name controlled by the gatekeeper. In this

case, cisco.com is the zone controlled by gatekeeper SJGK1.
Associates the digits 408 with the local zone SJGK1.
Configures a technology prefix in the gatekeeper. Cisco

gatekeepers use technology prefixes to route calls when there
are no E.164 addresses registered (by a gateway) that match the
called number. With the default technology prefix option, the
Cisco gatekeeper assigns a default gateway or gateways for
routing unresolved call addresses. This assignment is based on
the registered technology prefix of the gateways.
Specifies the maximum bandwidth available in zone SJGK1 as

512 kbps.
---

Specifies the maximum bandwidth allowed for a session in zone

SJGK1 as 256 kbps.
Gatekeeper Configuration in Cisco

CallManager
Configure
gatekeeper
settings and
trunk in Cisco
CallManager.
CIPT1 v4.13-27
In Cisco CallManager Administration, add gatekeepers and trunks and configure settings for
each.
3-154
Gatekeeper Configuration in Cisco CallManager Administration

Field
Description
Host Name/IP Address*
Enter the IP address or hostname of the gatekeeper in this

required field.
Registration Request Time to Live
Do not change this value unless a Cisco Technical Assistance

Center (TAC) engineer instructs you to do so. The default value
specifies 60 seconds.
The Registration Request Time to Live field indicates the time
that the gatekeeper considers a registration request (RRQ) valid.
The system must send a keepalive RRQ to the gatekeeper before
the RRQ TTL expires.
Cisco CallManager sends an RRQ to the gatekeeper to register
and subsequently to maintain a connection with the gatekeeper.
The gatekeeper may confirm (RCF) or deny (RRJ) the request.
Registration Retry Timeout
Do not change this value unless a Cisco TAC engineer instructs

you to do so. Enter the time in seconds. The default value
specifies 300 seconds.
The Registration Retry Timeout field indicates the time that Cisco
CallManager waits before retrying gatekeeper registration after a
failed registration attempt.
* Indicates required item.
Trunk Configuration
Cisco CallManager supports two types of gatekeeper-controlled trunks:
H.225 trunk (Gatekeeper Controlled): In an H.323 network that uses gatekeepers, use an
H.225 trunk with gatekeeper control to configure a connection to a gatekeeper for access to
other Cisco CallManager clusters and to H.323 devices. An H.225 trunk can communicate
with any H.323 gatekeeper-controlled endpoint. When you configure an H.323 gateway
with gatekeeper control in Cisco CallManager Administration, use an H.225 trunk. To use
this method, choose Device > Trunk and then choose H.225 Trunk (Gatekeeper
Controlled).
Inter-Cluster Trunk (Gatekeeper Controlled): In a distributed call-processing network
with gatekeepers, use an intercluster trunk with gatekeeper control to configure connections
between clusters of Cisco CallManager systems. Gatekeepers provide call admission
control and address resolution for intercluster calls. A single intercluster trunk can
communicate with all remote clusters. To use this method, choose Device > Trunk and
then choose Inter-Cluster Trunk (Gatekeeper Controlled) in Cisco CallManager
Administration.
You also configure route patterns and route groups to route the calls to and from the
gatekeeper.
3-155
SRST Overview
This topic discusses the Cisco Survivable Remote Site Telephony (SRST) feature used in a
centralized call-processing deployment.
What Is SRST?
SRST:
Provides call-handling support for Cisco IP Phones when
they lose connection to remote primary, secondary, or
tertiary Cisco CallManager installations or when the WAN
connection is down
Is for centralized Cisco CallManager deployments
Licensed on number of users at remote site on Cisco IOS
PLUS software
Survivability for up to 480 users, dependent upon platform
CIPT1 v4.13-28
The SRST feature provides call-handling support on the gateway router for attached Cisco IP
Phones when a Cisco CallManager or WAN link fails. On restoration of the Cisco CallManager
or WAN link, the Cisco CallManager resumes the call-handling capabilities for the IP Phones.
The implementation of this feature is transparent to the end user (except for the notification that
a user receives on the IP Phones that it is in fallback mode.)
The SRST-enabled router supports the following:
IP Phone-to-IP Phone on-router calls
IP Phone-to-PST) calls
Multiple lines per IP Phone
Multiple line appearance across IP Phones
Call hold and pickup on a shared line
Transfer of local calls
Caller ID information
Up to 24 IP Phones supported on the Cisco 1751, 1760, 2600XM, and 3620 platforms
Up to 48 IP Phones supported on Cisco 2650XM and 2651XM platforms
Up to 480 IP Phones supported on Cisco 7200 routers NPE-400 (SRST 2.0)
3-156
Sample SRST Features

Support for rehoming of IP Phones to use call processing on local
router upon Cisco CallManager fallback
Support for IP Phones and POTS phones on the router
Extension-to-extension dialing
Extension-to-PSTN dialing
Support for on-net calling
Multiple lines on telephone
DID and DOD
Calling-party ID (caller ID/ANI) display
Calling-party name display
Last-number redial
Call transfer without consultation
Call hold and retrieve on a shared line
Dual-line mode
CIPT1 v4.13-29
In a centralized deployment model, if a WAN connection fails, remote IP phones cannot make
calls. This weakness can be a serious problem when it comes to emergency calls such as E911
calls.
A simple way of solving this problem is to provide limited call-processing capabilities in the
remote office router. IP Phone enhancements grant the ability to rehome to the call-processing
functions in the local router upon WAN failure detection. This solution is the Cisco
CallManager fallback mode.
The Cisco CallManager fallback feature is referred to as SRST. SRST telephone features
include the following:
Support for IP Phones and plain old telephone service (POTS) telephones on the router
Extension-to-extension dialing
Extension-to-PSTN dialing
Direct Inward Dial (DID) and Direct Outward Dial (DOD)
Calling Line Identification (CLID, caller ID, or Automatic Number Identification [ANI])
display
Calling party name display
Speed dialing
Last-number redial
Call transfer without consultation (local to router only)
3-157
Call hold and resume

Multiple extensions (up to six extensions per IP Phone on Cisco 7960 IP Phones)
Multiple line appearances, with up to 24 appearances per system
Distinctive ringing
Extension class of service (CoS)
Full interworking with Cisco gatekeeper functionality
Voice-mail support (only to local answering machine)
Billing support using Call Detail Records (CDRs)
Dual-line mode
SRST: Normal Operation

Central Site Call
Manager (Cisco
CallManager)
PSTN
Real-Time
Transport
Protocol
Branch Router
WAN
Headquarters
Skinny: Protocol for call setup and teardown

CIPT1 v4.13-30
Shown here is an example of how the SRST feature works.

The SRST software operates by taking advantage of the keepalive packets emanating from both
the centralized Cisco CallManager cluster and local IP Phones. During normal operations, the
Cisco CallManager receives keepalive packets from the IP Phones. Cisco CallManager
performs call setup and processing, call maintenance, and call termination.
3-158
SRST: Network Failure

Central Site Call
Manager (Cisco
CallManager)
KA to Cisco
CallManager
Real-Time
Transport
Protocol
Branch Router
KA to Cisco
CallManager
PSTN
WAN
Headquarters
Keepalive (TCP)
Skinny
CIPT1 v4.13-31
When the WAN link fails, Cisco IP Phones detect that they are no longer receiving responses to
their keepalive packets from the Cisco CallManager. The Cisco IP Phones can be configured to
register with the router as a backup call-processing source. The SRST software in the router
automatically activates and builds a local database of all Cisco IP Phones attached to it, up to
the stated maximum. The SRST router now performs all local call setup and processing, call
maintenance, and call termination.
3-159
SRST: Network Failure Repaired

Central Site
Cisco
CallManager
PSTN
Real-Time
Transport
Protocol
Branch Router 1750,

2600, 3600, 7200,
Cisco Catalyst 4224
IAD2400
WAN
Headquarters
Keepalive: Ensures communication link with Cisco CallManager
CIPT1 v4.13-32
When the WAN link resumes, the IP Phones detect keepalive responses from the central Cisco
CallManager and revert to the central Cisco CallManager for primary call setup and processing.
As IP Phones rehome to the Cisco CallManager, the SRST router purges its call-processing
database and reverts to standby mode.
SRST affects only services and call establishment. Typical voice functions continue to be under
the standard router gateway function. Calls in progress continue without interruption. IP Phones
in use during WAN link recovery rehome to the Cisco CallManager after the calls terminate.
3-160
SRST Configuration
This topic discusses configuring SRST on Cisco IOS routers and assigning an SRST reference
in Cisco CallManager.
SRST Configuration: Four Commands

SRST(config)#
Enables Cisco CallManager fallback capability and invokes a submenu.

SRST(config-cm-fallback)#
--- --
Enables router to receive Skinny messages on this particular port. The
default port is 2000.
Maximum IP Phones that will be allowed to register. Defaults to 0.

Maximum number of DNs that can be configured. Defaults to 0.

CIPT1 v4.13-33
The most common application of SRST is to maintain basic IP telephony functionality for the
IP Phones at remote branch offices when the WAN link fails or the Cisco CallManager at
headquarters is no longer available.
The remote branch router activates SRST functions and takes over communication with the IP
Phones. IP Phones are able to call each other and make off-net calls to the PSTN. In addition,
the most basic telephone functions, such as hold and transfer, are still available.
There is one global command to configure for SRST, the call-manager-fallback command,
which is a global command with a series of subcommands.
3-161
call-manager-fallback Subcommands
3-162
Command
Description
--
Defines access codes for outgoing calls
Sets a command to its defaults
Defines or disables the default destination DN for ringing on unknown

called number
Defines an E.164 telephone number prefix
Stops hunting on dial peers
-
--
Defines an IP address and port for the IP Keyswitch
Defines the keepalive timeout period to unregister IP Phones
Specifies the maximum DNs supported on the IP Keyswitch
Specifies the maximum number of IP Phones
Resets the IP Phones
Defines valid call transfer destinations
Sets the voice-mail access number called when the Messages button is
pressed
show call-manager-fallback
-
--
-

---

-

-

CIPT1 v4.13-34
The following are examples of how to use some of the subcommands.

access-code fxo 9: This command associates the outgoing digit 9 with all Foreign
Exchange Office (FXO) ports on the router. When the user dials the digit 9, one of the
available FXO ports to the PSTN is seized. The user can then dial the regular E.164 number
to access a number in the PSTN. The advantage of this command is that it allows you to
select the type of port rather than a single port. A request to a busy port rolls over to the
next available port of the same type.
default-destination 4312: This command defines a default extension for all incoming calls
that do not have an appropriate called number assigned. In this example, when an incoming
call from an FXO port is not able to match to an appropriate called number, the call routes
to extension 4312.
dial-plan pattern 1 345...: This command creates a global prefix that can be used to
expand the abbreviated extension numbers into fully qualified E.164 numbers.
transfer-pattern 525: This command allows the transfer of calls to non-IP Phone
numbers. By default, all IP Phones can be transfer targets. In this example, calls can
transfer to all non-IP Phone numbers with prefix 525. Transfer of calls to an undefined
number or prefix is blocked. You can enter a maximum of 32 transfer patterns.
voicemail 4001: This command defines a dial peer of a Foreign Exchange Station (FXS)
port to route the call when the Message button on the IP Phone is pressed. In this example,
when the user presses the Message button on the IP Phone, the call proceeds to extension
4001, which is an voice-mail system. The user can then listen to the messages.
3-163
Creating an SRST Reference in Cisco

CallManager Administration
CIPT1 v4.13-35
After you input the necessary Cisco IOS SRST gateway configuration, you must then configure
the Cisco CallManager to recognize the gateway as an SRST reference. To configure SRST
references, choose the System menu in the Cisco CallManager Administration utility and then
choose SRST. When the Find and List SRST References window appears, click the Add a
New SRST Reference link in the upper-right area of the window. A window similar to the one
shown in the figure should appear. To create a valid SRST reference, you must enter values in
the following fields:
SRST Reference Name: This value is a logical name that you can use when referencing
the SRST gateway. It does not need to match the name assigned to the gateway.
IP Address: This value is the IP address that the Cisco IP Phone should use when
contacting the SRST gateway. The IP Phone itself must be able to reach this IP address.
Port: This value is the port number that the IP Phone should use when contacting the SRST
reference. By default, this uses TCP port 2000.
The Is SRST Secure check box and the SRST Certificate Provider Port field are used for
configuring the Cisco CallManager portion of a secure SRST-enabled gateway connection.
Secure SRST allows Cisco CallManager to authenticate with a secure SRST-enabled gateway
and add the SRST-enabled gateway certificate to the Cisco CallManager database. The TFTP
server adds the SRST certificate to the phone cnf.xml file and sends the file to the phone. A
secure phone then uses a secure connection to interact with the SRST-enabled gateway.
Secure SRST must be enabled on both the gateway and in the Cisco CallManager SRST
reference configuration. Setting up secure SRST on the gateway is covered in Cisco IOS SRST
Version 3.3 System Administrator Guide at:
http://www.cisco.com/univercd/cc/td/doc/product/voice/srst/srst33/srst33ad/sr_scur1.htm.
Configuring a secure SRST reference in Cisco CallManager is covered in Cisco CallManager
Security Guide, Release 4.1(3) at:
http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_1/sec_vir/ae/sec41
3/index.htm.
3-164
Assigning SRST References
CIPT1 v4.13-36
After you create the SRST reference in Cisco CallManager, you must assign the SRST
reference to the Cisco IP Phone. Cisco CallManager creates this assignment through the device
pool. In the Device Pool Configuration window, click the SRST Reference drop-down arrow
to choose the SRST reference that the IP Phone should use. If you would like the Cisco IP
Phone to use its default gateway as the SRST reference, you can choose the Use Default
Gateway option from the menu. Using this option can simplify your SRST configuration.
3-165
Summary
This topic summarizes the key points you learned in this lesson.
Summary
Call admission control provides mechanisms to control the
volume of calls between two endpoints, which is key to
maintaining the QoS of all calls.
Cisco CallManager supports locations-based call admission
control for centralized call-processing environments.
AAR automatically reroutes calls through the PSTN or other
networks when there is insufficient bandwidth in a
centralized call-processing deployment.
Configuring AAR entails configuring AAR groups and
assigning the external phone number mask to
the DN.
Configure the available bandwidth in the Locations window
and the codec in the Regions window.
Cisco CallManager supports gatekeeper basic call admission
control for distributed environments.
CIPT1 v4.13-37
Summary (Cont.)
The procedures for call admission control depend upon
messages sent to and from the gatekeeper. These
messages allow endpoints to register, unregister,
request admission, disengage, and request bandwidth.
Configure the gatekeeper in Cisco IOS software and the
gatekeeper and trunk settings (gatekeeper-controlled)
in Cisco CallManager.
SRST provides call-handling support for IP Phones
when the Cisco CallManager or WAN link fails.
Create an SRST reference in Cisco CallManager and
assign it to a device pool. Configure SRST commands
on the Cisco IOS router.
3-166
CIPT1 v4.13-38
References
Cisco Systems, Inc. Cisco CallManager System Guide, Release 4.1(3), Call Admission
Control and Understanding Cisco CallManager Trunk Types.
3/ccmsys/index.htm.
Cisco Systems, Inc. Cisco CallManager Administration Guide, Release 4.1(3), Gatekeeper
Configuration and Trunk Configuration.
3/ccmsys/index.htm.
Cisco Systems, Inc. H.323 VoIP Gatekeeper for Cisco Access Platforms.
http://www.cisco.com/en/US/products/sw/iosswrel/ps1826/products_feature_guide09186a0
080087ac0.html#xtocid1435710.
Cisco Systems, Inc. Understanding Cisco IOS Gatekeeper Call Routing.
http://www.cisco.com/en/US/tech/tk652/tk701/technologies_tech_note09186a00800a8928.
shtml
Cisco Systems, Inc. Index page for SRST system administrator guides, command
references, and specifications.
http://www.cisco.com/univercd/cc/td/doc/product/access/ip_ph/srs/srscdc/srstph.htm.
Cisco Systems, Inc. Cisco Survivable Remote Site Telephony data sheet.
http://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_data_sheet09186a008
00888ac.html.
3-167
Module 3 Summary
Module Summary
Cisco CallManager supports MGCP and H.323 gateways to interface to
the IP WAN and to the PSTN. Cisco CallManager supports H.225
trunks, intercluster trunks with or without gatekeeper control, and SIP
trunks.
Route plan elements to enable off-net dialing include a route group,
route list, and route pattern.
Hunt group elements to enable call distribution include line groups,
hunt lists, and hunt pilots. Final forwarding to a voice-mail number or
IVR when the call is not answered is important to ensure call
coverage.
Translation patterns, external phone number masks, calling-party
transformations, access codes, DDIs, and route filters enable a variety
of important functions in a dial plan, from changing the calling- and
called-party number to enabling transparent calling routing over the IP
WAN or PSTN and blocking 900 area code numbers.
Partitions and calling search spaces enable calling permissions.
Time-of-day routing adds additional granularity.
Multiple-site deployments need to address issues of call admission
control, bandwidth oversubscription, and WAN link failures.
CIPT1 v4.13-1
This module covered the key ingredients to enable IP telephony calling to off-net destinations
across the IP WAN or to the PSTN. This module first presented the function and requirements
of the gateways and trunks in an IP telephony deployment and described how to configure the
gateways and trunks that Cisco CallManager supports. The module then discussed the basic
route plan elementsroute groups, route lists, and route patternsand the hunt group
elementsline groups, hunt lists, and hunt pilots. Several forwarding scenarios to ensure final
forwarding were presented. The module then covered translation patterns, calling-party
transformations, external phone number masks to change the appearance of the calling or called
number, DDIs to enable transparent dialing across the IP WAN or PSTN, and route filters to
block 900 area code numbers. The module then covered enabling telephony CoS, or providing
different calling permissions to different devices and users, using partitions and calling search
spaces. Finally, the module ended with a discussion of issues that multiple site deployments
need to address: call admission control over the IP WAN, temporarily addressing bandwidth
oversubscription issues using AAR, and ensuring that remote IP Phones remain operational
should the WAN or Cisco CallManager fail at the central site.
3-168
Module 3 Self-Check
solutions are found in the Module Self-Check Answer Key.
Q1)
Which interface does a voice gateway provide? (Source: Lesson 3-1, Configuring
Gateways and Trunks)
A)
B)
C)
D)
Q2)
Which is an advantage of a gatekeeper-controlled intercluster trunk? (Source: Lesson

3-1, Configuring Gateways and Trunks)
A)
B)
C)
D)
Q3)
MGCP
Non-IOS MGCP
H.323
SCCP
When configuring SIP trunks in Cisco CallManager Administration, which device must
you specify as the destination address to which Cisco CallManager forwards SIP
traffic? (Source: Lesson 3-1, Configuring Gateways and Trunks)
A)
B)
C)
D)
E)
Q6)
support for DTMF relay

support for inline power
support for multiple VLANs on single port
support for disconnect supervision
Which protocol requires you to perform the bulk of the configuration on the router
(gateway)? (Source: Lesson 3-1, Configuring Gateways and Trunks)
A)
B)
C)
D)
Q5)
server redundancy
call survivability
trunk configuration simplicity
DTMF relay support
Which is a core gateway requirement? (Source: Lesson 3-1, Configuring Gateways and
Trunks)
A)
B)
C)
D)
Q4)
X.25 to SS7
VoIP to H.323
PSTN to VoIP
PSTN to PBX
MTP device
redirect server
default gateway
SIP endpoint
proxy server
Which of the following contains a list of gateways to use in precedence order? (Source:
Lesson 3-2, Configuring Basic Route Plans)
A)
B)
C)
D)
route group
route list
translation pattern
route pattern
3-169
Q7)
What is the key to making toll bypass and PSTN fallback features transparent to your
users? (Source: Lesson 3-2, Configuring Basic Route Plans)
A)
B)
C)
D)
Q8)
Which three of the following are valid wildcards? (Choose three.) (Source: Lesson 3-2,
Configuring Basic Route Plans)
A)
B)
C)
D)
Q9)
B)
C)
D)
maximum hunt timer and RNAR timers in the Line Group configuration
window
the Call Forward No Coverage settings for the original called number that
forwarded the call to the hunt pilot
the Destination and Calling Search Space fields in the Hunt Forward Settings
section of the Hunt Pilot Configuration window
the Forward Busy and Forward No Answer settings for the original called
number that forwarded the call to the hunt pilot
Assume a line group with five members: party 1 (DN 5001), party 2 (DN 5002),
party 3 (DN 5003), party 4 (DN 5004), and party 5 (DN 5005). The circular
distribution algorithm is applied to the line group. Party 3 answered the last call that
came in on the hunt pilot. To which party will Cisco CallManager extend the next call
that comes into the hunt pilot? (Source: Lesson 3-3, Configuring Hunt Groups and Call
Coverage)
A)
B)
C)
D)
E)
3-170
route patterns
route lists
devices
route groups
In addition to checking the Use Personal Preferences check box in the Hunt Forward
Settings section of the Hunt Pilot Configuration window, what else must be configured
to enable final forwarding for a call that is forwarded to the hunt pilot? (Source: Lesson
3-3, Configuring Hunt Groups and Call Coverage)
A)
Q11)
*
!
.
$
What can be placed into a route list? (Source: Lesson 3-2, Configuring Basic Route
Plans)
A)
B)
C)
D)
Q10)
digit manipulation
10-digit dialing
route filtering
route summarization
1
2
3
4
5
Q12)
What does Cisco CallManager do when dialed digits match a translation pattern?
(Source: Lesson 3-4, Configuring Complex Route Plans)
A)
B)
C)
D)
Q13)
When DN 0111 calls and a calling transformation mask of 972555XXXX is applied,

which CLID is sent? (Source: Lesson 3-4, Configuring Complex Route Plans)
A)
B)
C)
D)
Q14)
start and end times

repetition interval
time zone
time period
time schedule
Which time period would be configured to allow access to user A during user As
weekday office hours? (Source: Lesson 3-5, Implementing Class of Control)
A)
B)
C)
D)
Q17)
98085550150
5550150
95550150
8085550150
The Partition Configuration window in Cisco CallManager Administration contains

which two parameters associated with time-of-day routing? (Choose two.) (Source:
Lesson 3-5, Implementing Class of Control)
A)
B)
C)
D)
E)
Q16)
0111
5550111
9725550111
19725550111
What are the final digits that Cisco CallManager sends when the discard digits
instruction PreDot is applied to the 9.8085550150 pattern? (Source: Lesson 3-4,
Configuring Complex Route Plans)
A)
B)
C)
D)
Q15)
extends the call to the destination

forwards the call to a route pattern
selects the closest match to that pattern
sends the transformed digits through digit analysis one more time
08:00 to 17:00 Monday to Friday and the time zone of the originating device
08:00 to 17:00 Monday to Friday and the time zone of user A
No office hours Saturday and Sunday and the time zone of the originating
device
No office hours Saturday and Sunday and the time zone of user A
Place a C next to the items that can be assigned to a calling search space and a P
next to the items that can be assigned to a partition. (Source: Lesson 3-5, Implementing
Class of Control)
_____ 1.
phones
_____ 2.
directory numbers
_____ 3.
gateways
_____ 4.
route patterns
_____ 5.
translation patterns
_____ 6.
voice-mail ports
3-171
Q18)
Which is a benefit associated with gatekeeper call admission control? (Source: Lesson
3-6, Implementing Multiple Site Deployments)
A)
B)
C)
D)
Q19)
Without call admission control, what happens to existing calls when the next call
oversubscribes the WAN? (Source: Lesson 3-6, Implementing Multiple Site
Deployments)
E)
F)
G)
H)
Q20)
D)
2
3
4
5
AAR derives the alternate dial string used to route the call over the PSTN from which
three of the following? (Choose three.) (Source: Lesson 3-6, Implementing Multiple
Site Deployments)
A)
B)
C)
D)
E)
F)
3-172
The IP Phones stop receiving keepalive packets from the SRST gateway.
The IP address is configured on the gateway and passed to the IP Phone.
The gateway IP address is specified in the SRST Reference Configuration
window.
The device pool contains the IP address reference to the SRST gateway.
Using the Cisco CallManager locations feature, how many simultaneous audio calls
can be placed over a given WAN link with 128 kbps of available bandwidth using a
G.729 codec? (Source: Lesson 3-6, Implementing Multiple Site Deployments)
A)
B)
C)
D)
Q23)
intercluster trunk to each Cisco CallManager cluster

gatekeeper-controlled trunks
maximum bandwidth determined on the Cisco CallManager
zones and bandwidth allocation configured on the gatekeeper
How do the IP Phones in a branch site know how to register to a gateway running
SRST? (Source: Lesson 3-6, Implementing Multiple Site Deployments)
A)
B)
C)
Q22)
All calls are dropped.

Voice quality on all calls degrades.
Voice calls on the last call degrades.
Nothing happens if the router is configured for QoS.
Which two characteristics are associated with the distributed call admission control
method? (Choose two.) (Source: Lesson 3-6, Implementing Multiple Site
Deployments)
A)
B)
C)
D)
Q21)
no requirement to configure Cisco IOS commands on the gatekeeper

no requirement to configure an intercluster trunk between clusters
provides emergency call-handling capability if the WAN link fails
provides call admission control over the intranet in addition to the WAN
DN
phone number mask
AAR calling search space
MAC address
PSTN prefix
transformation pattern

Q1)
Q2)
Q3)
Q4)
Q5)
Q6)
Q7)
Q8)
A, B, C
Q9)
Q10)
Q11)
Q12)
Q13)
Q14)
Q15)
C, E
Q16)
Q17)
1. C, 2. P, 3. C, 4. P, 5. P, 6. P
Q18)
Q19)
Q20)
B, D
Q21)
Q22)
Q23)
A, B, E
3-173
3-174
Module 4
Enabling Features and

Services
Overview
An IP telephony deployment offers a number of benefits over legacy phone systems, including
simplified moves, adds, and changes and the ability for the telephony and data networks to
share the same network infrastructure.
Although reducing administrative and operational costs are important, the success of an IP
telephony deployment will also depend on the experience of its users. Users need access to a
broad range of easy-to-use features that enhance their productivity and communication. Cisco
CallManager software extends enterprise telephony features and capabilities to packet
telephony networks. This module describes the features, services, and options that are available
to users in a Cisco IP telephony solution.
Module Objectives
Upon completing this module, you will be able to configure Cisco CallManager to enable
features and services for users, and you will be able to use these features. This ability includes
Configure ad hoc and Meet-Me conferencing, transcoding, and MOH
Configure and use speed dials, Call Park, Call Pickup, Cisco Call Back, Barge, Privacy,
and Cisco IP Phone Services
Use Cisco CallManager to configure users and associate devices with users, and use the
Cisco CallManager User Options web page to customize IP Phones over the web
Configure and use Cisco CallManager Extension Mobility, Call Display Restrictions,
Forced Authentication Codes, Client Matter Codes, and MCID
4-2
Lesson 4-1

Overview
Conferencing, music on hold (MOH), and informational tones and announcements are
important business phone services. Media resources provide these and other services in a Cisco
CallManager IP telephony deployment. In this lesson, you will learn how to configure and
allocate media resources to include conferencing, Media Termination Points (MTPs), the
annunciator, transcoders, and MOH within a Cisco CallManager solution.
Objectives
Upon completing this lesson, you will be able to install, configure, and manage media resources
that include the conference bridge, annunciator, transcoder, and MOH server. This ability
includes being able to meet the following objectives:
Activate all necessary Cisco CallManager services that are used in media resources
Configure conference bridge resources to enable ad hoc and Meet-Me conferencing
between IP Phones
Describe the services that MTP resources provide
Identify the Cisco CallManager resources that are required for the annunciator feature
Configure transcoder resources in Cisco CallManager and on a Cisco access gateway to
provide codec conversion
Configure audio sources for MOH and assign user and network MOH to IP Phones
Allocate media resources to devices using MRGs and MRGLs
Introduction to Media Resources
This topic describes the available media resources in Cisco CallManager and how to activate
them.
Media Resources Overview

Media Resource Manager
manages resource types:
Conferencing
Media termination
Annunciator
MRM
MRM
MRM
MRM
Transcoding
Music on hold
Media Resource
CIPT1 v4.14-3
A media resource is a software-based or hardware-based entity that performs media processing

functions on the voice streams to which it is connected. Media processing functions include
mixing multiple streams to create one output stream (conferencing), passing the stream from
one connection to another (Media Termination Point), converting the data stream from one
compression type to another (transcoding), termination of a voice stream from a time-division
multiplexing (TDM) circuit (coding and decoding), streaming audio (annunciation), and so
forth.
Every Cisco CallManager contains a software component called a Media Resource Manager
(MRM) that communicates with MRMs on other Cisco CallManager servers. The MRM locates
a media resource to connect the media streams and to complete the feature. The MRM manages
the following media resource types:
Unicast conference bridge
MTP
Annunciator
Transcoder
MOH server
4-4
Activate Services for Software Media Resources
Services
required
for media
resources
CIPT1 v4.14-4
After Cisco CallManager is installed, you must activate three Cisco CallManager services that
media resources use:
Cisco IP Voice Media Streaming Application: The Cisco IP Voice Media Streaming
Application provides voice media streaming functionality for Cisco CallManager for use
with MTP, the annunciator, conferencing, and MOH. The Cisco IP Voice Media Streaming
Application relays messages from Cisco CallManager to the IP voice media streaming
driver. The driver handles the Real-Time Transport Protocol (RTP) streaming.
Cisco Messaging Interface: The Cisco Messaging Interface allows you to connect a
Simplified Message Desk Interface (SMDI)-compliant external voice-mail system with the
Cisco CallManager. The Cisco Messaging Interface service provides the communication
between a voice-mail system and Cisco CallManager. SMDI defines a way for a telephone
system to provide a voice-mail system with the information that is needed to intelligently
process incoming calls.
Cisco MOH Audio Translator: The Cisco MOH Audio Translator service converts audio
source files into the appropriate MOH source file for various coder-decoders (codecs) so
that the MOH feature can use them.
To activate the required services in Cisco CallManager, access the administration console and
choose Application > Cisco CallManager Serviceability. In the Serviceability window,
choose Tools > Service Activation. You can activate the services on any server that you
choose.
4-5
Conference Bridge Resources
This topic examines how to install and configure software and hardware conference bridge
resources.
Conference Bridges
Software, hardware, and
videoconference resources
are available.
In an ad hoc conference, a
conference controller can
add participants to a
conference.
In a Meet-Me conference,
the conference controller
provides a bridge or
directory number for
participants to dial.
CIPT1 v4.14-5
A conference bridge is a resource that joins multiple participants into a single call. It can accept
any number of connections for a given conference, up to the maximum number of streams that
are allowed for a single conference on that device. There is a one-to-one correspondence
between media streams that are connected to a conference and participants who are connected.
The conference bridge mixes the streams together and creates a unique output stream for each
connected party. The output stream for a given party is usually the composite of the streams
from all connected parties minus its own input stream. Some conference bridges mix only the
three loudest speakers on the conference and distribute that composite stream to each
participant (minus their own input stream if they are one of the speakers).
Cisco CallManager supports both hardware and software conference bridges. Hardware and
software conference bridges can be active at the same time.
Hardware-enabled conferencing provides the ability to support voice conferences in hardware.
Digital signal processors (DSPs) convert multiple voice over IP (VoIP) packets into streams
that are mixed into a single conference call stream. The DSPs support both Meet-Me and ad
hoc conferences. Hardware conference devices provide transcoding for G.711, G.729, G.723,
Global System for Mobile Communication (GSM) Full Rate (FR), and GSM Enhanced Full
Rate (EFR) codecs.
Software conferences use the resources of Cisco CallManager. A software conference bridge is
capable of mixing G.711 audio streams and Cisco Wideband audio streams. Any combination
of Wideband or G.711 a-law and mu-law streams may be connected to the same conference.
4-6
Conference bridges enable both ad hoc and Meet-Me voice conferencing:

Ad hoc conference: A user, known as the conference controller, adds participants to a
conference by calling the new participant and pressing the Confrn softkey. Alternatively,
the conference controller can press the Select softkey and then press the Join softkey to
make it an ad hoc conference. Up to 15 established calls can be added to the ad hoc
conference (16 total). Only the conference controller can add participants to an ad hoc
conference. An ad hoc conference can continue if the conference controller hangs up, but
new participants cannot be added. When only two participants remain in conference, the
conference terminates and the two remaining participants are reconnected directly as a
point-to-point call. This action saves conference resources.
Meet-Me conference: A user, known as the conference controller, presses the MeetMe
button or softkey and establishes the conference. The administrator must configure a
directory number (DN) or range of DNs in Cisco CallManager Administration. The
conference controller provides the DN to the participants, and at the appointed time,
participants dial the DN to join the conference. Participants may leave the conference by
hanging up. If the conference controller hangs up, the conference continues if there are
least two participants on the bridge.
4-7
Conference Bridge Types

Cisco CallManager
Resource Type
Conferences
Resource
Cisco Conference
Bridge
WS-SVC-CMM
Codecs
G.711 mu-law, G.711
a-law, G.729 annex A
and annex B, and
G.723.1
Max. Participants
per Conference
8 per conference,
64 conferences per
port adapter
1 CFB32 users to
10 CFB3 users
Cisco Conference
Bridge Hardware
WS-X6608-T1
WS-X6608-E1
G.711, G.723, G.729,

GSM FR, GSM EFR
Cisco Conference
Bridge Software
Cisco IP Voice
Media
Streaming App.
G.711, Cisco
Wideband
128Meet-Me
Cisco IOS
Conference Bridge
NM-HDV
G.711, G.729
For G.711 or
G.729a: 256
streams total per
module, 32 streams
maximum per port
64Ad Hoc
CIPT1 v4.14-6
Conference Bridge Types (Cont.)
Cisco CallManager
Resource Type
Cisco IOS
Enhanced
Conference Bridge
Cisco Video
Conference Bridge
(IP/VC-35xx)
Conference
Resource
NM-HD
NM-HDV2
WS-SVC-CMMACT
IP/VC-35xx
Codecs
G.711, G.729, GSM
FR, GSM EFR
G.711, G.729, or G723
Numerous audio and
video coding
schemes
Max. Participants
per Conference
8
Varies by platform
CIPT1 v4.14-7
The figures identify the conference bridge types that exist in Cisco CallManager
Administration. For each conference bridge type, the table lists the supported product or
application, the supported codecs, and the maximum number of participants.
4-8
Brief descriptions of the conference resources follow:

WS-SVC-CMM: This conference bridge type, when configured with the ACT port
adapter, supports the Cisco Catalyst 6500 Series and Cisco 7600 Series Communication
Media Module (CMM). This conference bridge type supports up to eight parties per
conference and up to 64 conferences per port adapter. This conference bridge type supports
the following codecs: G.711 mu-law, G.711 a-law, G.729 annex A and annex B, and
G.723.1. This conference bridge type supports ad hoc conferencing.
WS-X6608-T1 and WS-X6608-E1: The WS-X6608-T1 and WS-X6608-E1 provide digital
T1 or E1 interfaces for Public Switched Telephone Network (PSTN) and PBX gateway
access, transcoding, and conference bridging.
Cisco IP Voice Media Streaming Application: The Cisco IP Voice Media Streaming
Application provides voice media streaming functionality for the Cisco CallManager for
use with MTP, conferencing, and MOH. The Cisco IP Voice Media Streaming Application
relays messages from the Cisco CallManager to the IP voice media streaming driver.
NM-HDV: The NM-HDV network modules (NMs) provide conferencing, transcoding,
voice termination, and a voice WAN interface card (VWIC) slot, and include the NMHDV-2E1-60, NM-HDV-2T1-48, NM-HDV-FARM-C36, NM-HDV-FARM-C54, and
NM-HDV-FARM-C90.
NM-HD: The NM-HD modules include the NM-HD-1V, NM-HD-2V, and NM-HD-2VE
The NM-HD-1V has one video interface card (VIC) slot and supports one analog or BRI
VIC. The NM-HD-2V has two VIC slots and supports two analog or BRI VICs (or any
combination). The NM-HD-2VE has two VIC slots and supports two analog or BRI VICs
or two digital VWICs (or any combination).
NM-HDV2: The NM-HDV2 supports up to eight voice channels of analog or BRI voice.
The NM-HDV2 supports a VIC/VWIC slot that can be fitted with either digital or analog or
BRI voice/WAN interface cards, and supports up to 60 channels of digital voice or four
channels of analog voice. The NM-HDV2-1T1/E1 adds support for one built-in T1 or E1
port and supports up to 90 channels of digital voice or 30 channels of digital voice and four
channels of analog voice. The NM-HDV2-2T1/E1 adds support for two built-in T1 or E1
ports and supports a maximum of 120 channels of digital voice or 60 channels of digital
voice and four channels of analog voice
NM-HD-2VE: The NM-HD-2VE supports analog, BRI, T1, E1, voice, and data WANs
and up to 48 channels (G.711 codec).
IP/VC-3500 Series: The Cisco IP/VC 3500 Series Video Multipoint Conference Unit is a
dual multimedia bridge that provides videoconferencing. The videoconference bridge
provides audio and videoconferencing functions for video Cisco IP Phones, H.323
endpoints, and audio-only Cisco IP Phones. The Cisco IP/VC 3500 Series includes the
Cisco IP/VC 3511, the Cisco IP/VC 3521 BRI Videoconferencing Gateway, and the IP/VC
3526 PRI Videoconferencing Gateway. For large or centralized videoconferencing
deployments, the scalable, multifunctional IP/VC 3540 Series Videoconferencing System
offers the combination of MCUs, a videoconferencing gateway, a rate matching module,
and a data collaboration server. Each product in the series supports a number of audio and
video codecs (H.261, H.263, H.263++, and H.264); these vary by platform.
Further details can be found in the product data sheets at:
http://www.cisco.com/en/US/products/hw/video/ps1870/products_data_sheets_list.html.
4-9
4-10
Note
Cisco CallManager supports hardware conferencing on the Cisco Catalyst 4000 and 4500
Access Gateway Module (part number WS-x4604-GWY). An end-of-life announcement was
made on March 1, 2004, with an end-of-sale date of September 1, 2004. View the
announcement at: http://www.cisco.com/warp/public/cc/pd/rt/4500m/prodlit/2426_pp.htm.
Note
The WS-SVC-CMM-ACT requires Cisco IOS Software Release 1.2(2)YK or Catalyst

Operating System Release 7.3(1) or later.
Note
The NM -HD and NM-HDV2 require Cisco IOS Software Release 12.3(8)T or later with the
IP voice feature set and Cisco CallManager Release 4.0(1) or later for full feature support
including MTP. Cisco CallManager Release 3.3(4) can be used when MTP support is not
needed and conferencing and transcoding support is sufficient. The NM-HD and NM-HDV2
require Cisco IOS Software Release 12.2(13)T or later with the Plus feature set for voice.
The following table provides additional detail about audio conference bridges.
Conference Type in
Cisco CallManager
Number of Participants and Bridges
Resource
Hardware
For G.711 or G.729a:
WS-X6608-T1
256 streams total per module and 32 streams

maximum per port.
WS-X6608-E1
Bridges may range from 10 bridges with 3

participants to 1 bridge with 32 participants.
For all GSM:
192 streams per module and 24 streams per port
Software (Cisco IP
Voice Media Streaming
Application)
IP Voice Media Streaming Application on a standalone

server:
Software
128 streams.
Ad hoc conference bridges may range from 42
bridges with 3 participants to 2 bridges with 64
participants.
A Meet-Me conference is 1 bridge with up to 128
participants.
IP Voice Media Streaming Application coresident with
Cisco CallManager:
48 streams.
IP Voice Media Streaming Application coresident with
Cisco CallManager:
48 streams.
Cisco IOS software
3 bridges per PVDM-12
NM-HDV
3, 6, 9, or 15 bridges per NM
Maximum of 6 participants per bridge
For information on the PVDM2-8, PVDM2-16, PVDM232, PVDM2-48, and PVDM2-64 refer to the Hardware
Resources for MTP, Conferencing, and Transcoding
section of the Cisco IP Telephony Solution Reference
Network Design (SRND) for Release 4.1 at:
http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/prod
uct/voice/c_callmg/4_1/srnd4_1/ipt4_1/ipt41dg.pdf.
Enhanced Cisco IOS
software
The total number of conference sessions is limited by

the capacity of the entire system, the Cisco
CallManager, and the codec. Further details can be
found in the Cisco Enhanced Conferencing and
Transcoding for Voice Gateway Routers data sheet
at:
http://www.cisco.com/en/US/products/ps5855/products
_data_sheet0900aecd801b97a6.html
NM-HD
NM-HDV2
4-11
Hardware Conference Bridge Configuration
WS-X6608 port MAC address needed
CIPT1 v4.14-8
To add a hardware conference device, follow these steps:

Step 1
Choose Service > Media Resource > Conference Bridge and then choose Add a
New Conference Bridge.
Step 2
Choose Cisco Conference Bridge Hardware in the Conference Bridge Type field.
Step 3
Add the MAC address of the WS-X6608 port that will be used for conferencing.
On the WS-X6608, the port must be pointed toward the Cisco TFTP server to obtain the
configuration file and a list of the Cisco CallManager servers within the Cisco IP telephony
network to use for registration. Use the set port voice interface command on Cisco Catalyst
switches running the Catalyst operating system to point the port toward the Cisco TFTP server
(usually the publisher server).
The following example disables Dynamic Host Configuration Protocol (DHCP) on port 3/1 of a
6608 port, assigns an IP address, subnet mask, VLAN number, and default gateway, and points
the port to the Cisco TFTP server (in bold):
- -

4-12
Media Termination Point Resources

This topic examines MTP resources.
Media Termination Point

Cisco CallManager
Cisco IP Voice Media Streaming Application
SW MTP
1002
H.323
Endpoint
1001
Initial Stream
Supplementary
Service Stream
Enables supplementary services for calls routed through SIP

and H.323 endpoints that do not support the H.323v2
OpenLogicalChannel and CloseLogicalChannel request features
Supplementary services are features such as:
Call Hold
Call Transfer
Call Park
Conferencing
CIPT1 v4.14-9
A Media Termination Point (MTP) is an entity that accepts two full-duplex G.711 streams. It
bridges the media streams together and allows them to be set up and torn down independently.
The streaming data received from the input stream on one connection is passed to the output
stream on the other connection, and vice versa. In addition, the MTP transcodes a-law to
mu-law, and vice versa, and adjusts packet sizes as required by the two connections.
MTPs are used to extend supplementary services to H.323 endpoints that do not support the
H.323 Version 2 (H.323v2) OpenLogicalChannel and CloseLogicalChannel request features
with the EmptyCapabilitiesSet feature. When needed, an MTP is allocated and connected into a
call on behalf of an H.323 endpoint. Once inserted, the media streams are connected between
the MTP and the H.323 device, and these connections are present for the duration of the call.
The media streams connected to the other side of the MTP can be connected and disconnected
as needed to implement features such as hold, transfer, and so forth.
SIP and MTP
Cisco CallManager requires an RFC 2833 dual-tone multifrequency (DTMF)-compliant MTP
device to make Session Initiation Protocol (SIP) calls. The current standard for SIP uses
in-band payload types to indicate DTMF tones. Cisco Architecture for Voice, Video and
Integrated Data (AVVID) components such as Skinny Client Control Protocol (SCCP, or
Skinny) IP Phones support only out-of-band payload types. Thus, an RFC 2833-compliant
MTP device monitors for payload type and acts as a translator between in-band and out-of-band
payload types.
With the MTP device, any service that requires a media change (such as call hold) happens
transparently. No need exists to send any media update signal to the SIP proxy server.
4-13
The following table provides additional detail about MTP resources.

MTP Type
Limitations
Cisco IOS Enhanced Software

Media Termination Point
This type supports Cisco 2600XM, 2691, 2811,

2821, 2851, 3660, 3725, 3745, 3825, and 3845
Access Routers and the following MTP cases:
For a software-only implementation that does
not use DSP but has the same packetization
time for devices that support G.711 to G.711
or G.729 to G.729 codecs, this implementation
can support up to 500 sessions per gateway.
For a hardware-only implementation with DSP
for devices that use G.711 codec only, 200
sessions can occur per NM-HDV2 and 48
sessions can occur per NM-HD.
Cisco IOS Software Enhanced Media Termination
Point does not support RFC 2833 (DTMF relay).
This type can support Network Address Translation
(NAT) in a service provider environment to hide the
private address.
In Cisco CallManager Administration, ensure that
you enter the same MTP name that exists in the
gateway command-line interface (CLI).
Cisco Media Termination Point

Software
A single MTP provides a default of 48 MTP (userconfigurable) resources, depending on the speed
of the network and the network interface card
(NIC). For example, a 100-MB network card/NIC
can support 48 MTP resources.
For a 10-MB network card/NIC, approximately 24
MTP resources can be provided; however, the
exact number of MTP resources that are available
depends on the resources that are being
consumed by other applications on that server, the
speed of the processor, network loading, and
various other factors.
The Cisco IP Voice Media Streaming Application
supports RFC 2833.
4-14
MTP Configuration
CIPT1 v4.14-10
To configure MTP, you must verify that these prerequisites are met:
Configure servers.
Configure a device pool.
To configure or add an MTP, choose Service > Media Resource > Media Termination Point
from the Cisco CallManager Administration console.
Note
Add only one MTP device for each MTP application.
MTP Configuration Items

Field
Description
Media Termination Point Type
Choose the MTP type, either Cisco IOS Enhanced Software

Media Termination or Cisco Media Termination Point Software.
Host Server
Choose the server to run MTP.
Media Termination Point Name
Enter an MTP name, up to 15 alphanumeric characters.
Description
Enter a description for MTP.
Device Pool
Choose the device pool with the highest priority in the Cisco
CallManager group or choose Default.
4-15
Annunciator Resources
This topic discusses annunciator resources.
Annunciator
Announcement
Plays prerecorded
.wav files and
tones
Alerts callers as
to why the call
failed
Works in
conjunction
with MLPP
Cisco IP Voice
Media Streaming
Application
1002
Your call cannot

be completed as
dialed...This is a
recording.
RTP Stream
1001
CIPT1 v4.14-11
An annunciator, which is an SCCP device that uses the Cisco IP Voice Media Streaming
Application service, enables Cisco CallManager to play prerecorded announcements (.wav
files) and tones to Cisco IP Phones, gateways, and other configurable devices. The annunciator,
which works with Cisco CallManager Multilevel Precedence Preemption (MLPP), enables
Cisco CallManager to alert callers as to why a call has failed. The annunciator can also play
tones for some transferred calls and some conferences.
In conjunction with Cisco CallManager, the annunciator device provides multiple one-way,
RTP stream connections to devices such as Cisco IP Phones and gateways.
The annunciator plays the announcement or tone to support the following conditions:
Announcement: For devices that are configured for Cisco MLPP.
Barge tone: Before a participant joins an ad hoc conference.
Ringback tone: When you transfer a call over the PSTN through a Cisco IOS gateway,
over an H.323 intercluster trunk or to the SIP client from an SCCP phone, the annunciator
plays the tone because the gateway cannot play the tone when the call is active.
To add an annunciator to the Cisco CallManager, you must activate the Cisco IP Voice Media
Streaming Application service on the server where you want the annunciator to exist in the
cluster.
4-16
Sample announcements follow in the table.

Sample Annunciator Announcements
Condition
Announcement
An equal- or higher-precedence
call is in progress.
Equal- or higher-precedence calls have prevented the

completion of your call. Please hang up and try again. This is a
recording.
A precedence access limitation

exists.
Precedence access limitation has prevented the completion of

your call. Please hang up and try again. This is a recording.
A service interruption occurred.
A service disruption has prevented the completion of your call. In

case of emergency, call your operator. This is a recording.
Example: Call Completion Failure and Announcement

In the figure, the user at extension 1001 dials extension 2503, an invalid number. The system
cannot complete the call. The annunciator device plays a one-way RTP stream to extension
1001: Your call cannot be completed as dialed. Please consult your directory and call again or
ask your operator for assistance. This is a recording.
Annunciator Capabilities
Up to 48 annunciator streams on a coresident
server where the Cisco CallManager and Cisco IP
Voice Media Streaming Application services run.
Up to 400 simultaneous announcement streams if
the annunciator runs on a standalone server.
Each annunciator can support G.711 a-law, G.711
mu-law, wideband, and G.729 codec formats.
CIPT1 v4.14-12
For a single annunciator, Cisco CallManager sets the default to 48 simultaneous streams, as
indicated in the annunciator service parameter for streaming values.
It is recommended that you not exceed 48 annunciator streams on a coresident server where the
Cisco CallManager and Cisco IP Voice Media Streaming Application services run.
If the annunciator runs on a standalone server where the Cisco CallManager service does not
run, the annunciator can support up to 255 simultaneous announcement streams.
4-17
If the standalone server has dual CPUs and a high-performance disk system, the annunciator
can support up to 400 simultaneous announcement streams.
By default, the annunciator is configured to support 48 simultaneous streams, which is the
maximum recommended for an annunciator running on the same server (coresident) with the
Cisco CallManager service. If the server has only 10-Mbps connectivity, lower the setting to 24
simultaneous streams. A standalone server without the Cisco CallManager service can support
up to 255 simultaneous announcement streams, and a high-performance server with dual CPUs
and a high-performance disk system can support up to 400 streams. You can add multiple
standalone servers to support the required number of streams.
Each annunciator can support G.711 a-law, G.711 mu-law, wideband, and G.729 codec
formats. A separate .wav file exists for each codec that is supported.
Annunciator Configuration
Configuration almost identical to MTP configuration

CIPT1 v4.14-13
When you activate the Cisco IP Voice Media Streaming Application service in Cisco
CallManager Serviceability, Cisco CallManager automatically adds the annunciator device to
the server configuration.
The annunciator configuration is almost identical to the MTP configuration. Minimally, you
must select a host server, enter the annunciator name, and assign the annunciator to a device
pool.
Each annunciator registers with only one Cisco CallManager at a time. The system may have
multiple annunciators, depending on your configuration, each of which may register with
different Cisco CallManager servers.
Each annunciator belongs to a device pool. The device pool associates the secondary (backup)
Cisco CallManager and the region settings.
To manage the media resources in the cluster, you can add the annunciator to a Media Resource
Group,(MRG) and a Media Resource Group List (MRGL).
4-18
When you update or configure the annunciator, the changes automatically occur when the
annunciator becomes idle, when no active announcements are played.
Cisco CallManager provides annunciator resource support to a conference bridge under the
following circumstances:
If the MRGL that contains the annunciator is assigned to the device pool where the
conference bridge exists
If the annunciator is configured as the default media resource, which makes it available to
all devices in the cluster
Follow these general steps to configure annunciator resources:
Step 1
Determine the number of annunciator streams that are needed and the number of
annunciators that are needed to provide these streams.
Step 2
Verify that you have activated the Cisco IP Voice Media Streaming Application
service on the server where you want the annunciator to exist.
Step 3
Perform additional annunciator configuration tasks if you want to change the default
settings.
Step 4
Add the new annunciators to the appropriate MRGs and MRGLs.
Step 5
Reset or restart the individual annunciator on all devices that belong to the MRG or
MRGL.
4-19
Transcoder Resources
This topic defines transcoder resources and examines transcoder limitations.
Transcoding Definition
XCODE
Voice Messaging
G.711
G.729
MTP
Input Stream
H.323 Endpoint
Stream for
Supplementary
Services
CIPT1 v4.14-14
A transcoder device takes the output stream of one codec and converts the voice streams from
one compression type to another compression type. For example, a transcoder can take an
output stream from a G.711 codec and convert it to a G.729 input stream that is accepted by a
G.729 codec in real time. Transcoders for Cisco CallManager convert between G.711, G.723,
G.729, and GSM codecs. A transcoder device provides additional capabilities and may be used
to enable supplementary services for H.323 endpoints.
This figure shows a transcoder device (XCODE) enabling communication between two
different codecs and providing MTP services for H.323 endpoints.
The Cisco CallManager invokes a transcoder on behalf of endpoint devices when the two
devices use different voice codecs and would normally not be able to communicate. When
inserted into a call, the transcoder converts the data streams between the two incompatible
codecs to enable communications between them. The transcoder remains invisible to either the
user or the endpoints that are involved in a call.
A transcoder provides a designated number of streaming mechanisms, each of which can
transcode data streams between different codecs and enable supplementary services, if required,
for calls to H.323 endpoints.
4-20
Transcoder Capabilities
Type in Cisco
CallManager
Resource
Cisco Media
Termination
Point
Hardware
WS-X6608T1/E1
Cisco IOS
Media
Termination
Point
NM-HDV
Cisco IOS
Enhanced
Media
Termination
Point
NM-HD
NM-HDV2
Cisco Media
Termination
Point (WSSVC-CMM)
WS-SVCCMM
Maximum Transcoder or MTP Sessions

G.711 to any other codec:
192 streams total and 24 streams per port
G.711 to G.729 or G.723 codecs: 60 per module
G.711 to GSM FR or GSM EFR codecs: 45 per module
G.711 to G.729 or GSM FR: 6 (NM-HD-V1/2), 18
(N M-HD-2VE), or 96 (NM-HDV2 with 4 PVDM2-64)
G.711 to G.729 or GSM EFR: 8, 24, or 128
G.711 to any other codec:
128 streams per port adapter
CIPT1 v4.14-15
The figure and table shown here describe the MTP and transcoder resource capabilities.
MTP and Transcoder Resource Capabilities
Resource
From Codec
To Codec
WS-X6608-T1,
WS-X6608-E1
G.723. G.729a, GSM FR, GSM EFR
G.711 a-law or mu-law
G.723. G.729a, GSM FR, GSM EFR
G.729, G.729a, G.729b, G.729ab
G.711 mu-law
G.729, G.729a, G.729b, G.729ab
G.729, G.729a, G.729b, G.729ab,

GSM FR, GSM EFR
G.729, G.729a, G.729b, G.729ab,

GSM FR, GSM EFR
NM-HDV and
NM-HDV-FARM
NM-HD and
NM-HDV2
WS-SVC-CMM
This type provides transcoding between any combination of the following

codecs:
G.711 a-law and G.711 mu-law
G.729 annex A and annex B
G.723.1
GSM (FR)
4-21
Transcoder Configuration
MAC Address of 6608 Port
CIPT1 v4.14-16
To configure or add a new transcoder, choose Service > Media Resource > Transcoder, then
follow this general procedure:
4-22
Step 1
Choose the appropriate transcoder type: Cisco Media Termination Point Hardware,
Cisco IOS Media Termination Point, Cisco IOS Enhanced Media Termination Point,
or Cisco Media Termination Point (WS-SVC-CMM).
Step 2
For Cisco Media Termination Point Hardware or Cisco Media Termination Point
(WS-SVC-CMM), enter a MAC address, which must be 12 characters.
Step 3
For Cisco Media Termination Point (WS-SVC-CMM) transcoders, choose a subunit

from the drop-down list (not shown in the figure).
Step 4
Choose a device pool. For more detailed information on the chosen device pool,
click View Details.
Step 5
Enter any special load information into the Special Load Information field or leave it
blank to use the default. Valid characters include letters, numbers, dashes, dots
(periods), and underscores.
Step 6
For Cisco Media Termination Point (WS-SVC-CMM) transcoders, choose a

maximum capacity from the drop-down list (not shown in the figure).
Music on Hold Resources
This topic examines the MOH resources that are installed and configured in Cisco
CallManager.
MOH
Types of hold:
Cisco CallManager
User hold
Network hold:
Transfer hold
Conference hold
Call Park hold
Audio sources:
Recorded audio
Live audio
Deployment types:
Coresident
Standalone
CIPT1 v4.14-17
The integrated MOH feature places on-net and off-net users on hold with music from a
streaming source. The MOH feature has two hold types:
User hold: A user presses the Hold button or Hold softkey.
Network hold: A user activates the transfer, conference, or Call Park feature, which
automatically activates the hold.
MOH is customizable so that it plays specific recordings, based on the DN that is used to place
the caller on hold or the line number that the caller has dialed. Recorded audio or a live audio
stream can also be configured as audio sources.
The MOH feature requires the use of a server that is part of a Cisco CallManager cluster. You
can configure the MOH server in either of the following ways:
Coresident deployment: In a coresident deployment, the MOH feature runs on any server
(either publisher or subscriber) in the cluster that is also running the Cisco CallManager
software. Because MOH shares server resources with Cisco CallManager in a coresident
configuration, this type of configuration drastically reduces the number of simultaneous
streams that an MOH server can send.
Standalone deployment: A standalone deployment places the MOH feature on a dedicated
server within the Cisco CallManager cluster. The sole function of this dedicated server is to
send MOH streams to devices within the network. A standalone deployment allows for the
maximum number of streams from a single MOH server.
4-23
MOH Server Capabilities

Coresident server: 20 MOH sessions
Standalone server: 50 or 250 MOH sessions
depending on platform
51 audio sources per cluster
CIPT1 v4.14-18
The figure and table provide details on the number of MOH sessions and codecs that are
supported for each server platform.
Maximum Number of MOH Sessions per Server Platform Type
Server Platform
Codecs Supported
MOH Sessions
Supported
Cisco MCS 7815
G.711 (a-law and mu-law)
Cisco MCS 782x (all models)
G.729a
Coresident server:
20 MOH sessions
Cisco MCS 7830 (all models)
Wideband audio
Standalone MOH server:

50 MOH sessions
Cisco SPE-310
Hewlett-Packard DL320
IBM xSeries 33x (all models)
G.711 (a-law and mu-law)
G.729a
Hewlett-Packard DL380
Wideband audio
Coresident server:
20 MOH sessions
Standalone MOH server:
250 MOH sessions
IBM xSeries 34x (all models)
The maximum session limits apply to unicast, multicast, or simultaneous unicast and multicast
sessions. The limits represent the recommended maximum sessions that a platform can support.
Specifically, the limit of 51 audio sources per cluster is 50 audio files and one live feed from a
sound card; however, there are exceptions to this limitation. See Using Multiple Fixed or Live
Audio Sources and Multicast MOH from Branch Router Flash in the Cisco IP Telephony
Solution Reference Network Design (SRND) for the exceptions at:
http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_1/srnd4_1/ipt4_1/i
pt41dg.pdf
4-24
Creating Audio Source File

3
New files are
automatically
detected and
processed.
MOH Master
Storage Directory
Audio Translator
Service
Audio Source Input Directory

C:\Cisco\DropMOHAudioSourceFilesHere
Start
Cisco CallManager
Administration copies
audio source files when
they are mapped.
Default MOH
TFTP Server
TFTP Path
Directory
Administrator copies
audio source into
this directory.
MOH
Server
Kernel-Mode
RTP Streaming
Driver
Hard-Coded MOH
Server Audio
Source Directory
DirectShow
Filters
CIPT1 v4.14-19
This figure shows the interactions among the audio translator, default MOH TFTP server, and
the MOH server. The large boxes in the figure represent cluster components that may reside on
a single server or on three separate servers. This figure also shows how the MOH server
processes the added audio source file.
In creating an audio source, the following sequence takes place, as shown in the figure:
Step 1
Note
The network administrator drops the audio files into the C:\Program Files\Cisco\
DropMOHAudioSourceFilesHere directory path. Most standard .wav and MP3 files
are valid input.
It takes approximately 30 seconds to convert a 3-MB MP3 file.
Step 2
Cisco CallManager automatically detects and translates the files.
Step 3
The output and source files are moved into the default MOH TFTP server holding
directory. This holding directory is the same as the default TFTPMOHFilePath with
\MOH appended.
Note
It is not recommended that the audio translator service be used during production hours
because the service will consume 100 percent of the CPU.
Step 4
The network administrator assigns an audio source number to the audio source file.
The corresponding audio source files are then copied to a directory that is one level
higher in the directory structure to make them available to the MOH servers.
Step 5
The MOH servers download the needed audio source files and store them in the
hard-coded directory C:\Program Files\Cisco\MOH.
4-25
Step 6
The MOH server then streams the files using DirectShow and the kernel-mode RTP
driver as needed or requested by Cisco CallManager.
MOH Configuration Tasks

1. Configure audio translator.
2. Configure MOH server.
3. Add and configure audio source files.
4. Set MOH service-wide settings.
5. Find and configure fixed audio source.
6. Assign audio source IDs.
CIPT1 v4.14-20
The figure lists the steps to configure MOH.
MOH Audio Translator Configuration
Input
Directory
Output
Directory
4-26
CIPT1 v4.14-21
An MOH audio translator service converts administrator-supplied audio sources to the proper
format for the MOH server to use. The audio translator uses two parameters, an input directory
and an output directory. You can configure the input directory, which defaults to C:\Program
Files\Cisco\MOH\DropMOHAudioSourceFilesHere, on a per-service basis. The output
directory, a cluster-wide parameter, contains a Universal Naming Convention (UNC) name to a
shared directory on the default MOH TFTP directory. For whichever directory is specified,
append \MOH.
To display the Service Parameters Configuration window, choose Service > Service
Parameters in Cisco CallManager Administration, choose the server that will provide MOH
(typically, the publisher if not a standalone server), and choose Cisco MOH Audio Translator
for the service.
MOH Server Configuration
CIPT1 v4.14-22
This figure shows the MOH server configuration window. The MOH server can be configured
for unicast or multicast.
Multicast MOH conserves system resources. Multicast allows multiple users to use the same
audio source stream to provide MOH. Multicast audio sources associate with an IP address.
Unicast MOH, the system default, uses a separate source stream for each user or connection.
Users connect to a specific device or stream.
Choose Service > Media Resource > Music On Hold Server to display the Music On Hold
(MOH) Server Configuration window.
4-27
Adding and Configuring Audio Source Files
CIPT1 v4.14-23
When all audio sources are added or updated (except for the fixed audio source), the changes
will affect all of the MOH servers. All of the processed audio sources will appear in the MOH
Audio Source File drop-down menu.
The Play Continuously (Repeat) check box should always be checked. If multicast capabilities
are necessary, you must check the Allow Multicasting check box. If the Play Continuously
(Repeat) and Allow Multicasting check boxes are both unchecked, the audio file stops playing
when it reaches the end and the network administrator must stop and start the server to reset the
MOH server.
The MOH Audio Source File Status window shows the conversion status and indicates whether
the audio file translated correctly or had errors.
Choose Service > Media Resource > Music On Hold Audio Source to display the Music On
Hold (MOH) Audio Source Configuration window.
4-28
MOH Service-Wide Settings
CIPT1 v4.14-24
To set the MOH service-wide settings, open the Service Parameters Configuration window,
choose an MOH server, and choose the Cisco IP Voice Media Streaming App option. The
Service Parameters Configuration window for MOH appears, as shown here.
Note
The other service parameters in this window are for MTP and software conference bridge
resources.
The Supported MOH Codecs field is set to the codecs that are supported by the MOH servers in
the cluster. This field defaults to G.711 mu-law during the installation. You can enable multiple
codecs by pressing the Ctrl key while selecting the codecs.
The Default TFTPMOH IP Address field is set to the IP address or computer name of the
default MOH TFTP server.
4-29
Finding the Fixed Audio Source Name
CIPT1 v4.14-25
The source for MOH can be an audio file that is stored on the MOH server or a fixed music
source (via a sound card). You will need the exact name of the fixed audio source device to
complete the fixed audio source configuration in Cisco CallManager.
To find the name of the fixed audio source, open the Control Panel and choose Sounds and
Multimedia. Choose the Audio tab. You can use any sound-recording device name that
appears in the Preferred Device menu.
To open the Recording Control window, click the Volume button in the Sound Recoding area.
Verify that the Line In, Microphone, or CD Audio check box is checked.
4-30
Configuring the Fixed Audio Source
CIPT1 v4.14-26
The fixed audio source name is case-sensitive and must be entered exactly as it appears in the
Sounds and Multimedia Properties window, including any spaces or symbols that appear in the
name.
If the Allow Multicasting check box is checked, and the G.729 codec is enabled, 5 to 7 percent
of the CPU resources will be consumed. This setting is global for all MOH servers. If the fixed
audio source does not exist on a server, it cannot be used.
You can override the fixed audio source name, on a per-MOH-server basis, by means of the
MOH Server Configuration window.
The selected fixed audio source that appears on the left side of the window in this figure is
available as an option.
The Fixed Audio Source option affects all of the MOH servers that have an MOH fixed audio
source device by the selected name.
Choose Service > Media Resource > Music On Hold Audio Source to display the Music On
Hold Fixed Audio Source Configuration window.
4-31
Assigning Audio Source IDs
Audio Source
IDs for User
and Network
Hold
CIPT1 v4.14-27
An audio source ID represents an audio source on the MOH server. The audio source can be
either a file on a disk or a fixed device from which a source stream obtains the streaming data.
Each audio source (represented by an audio source ID) can stream in unicast and multicast
mode.
The device that activates the hold will determine which audio source ID the caller will listen to.
Choose Device > Phone and then select the phone on which you want to assign audio source
IDs for user hold and network hold.
4-32
This topic examines media resource management within a Cisco IP telephony solution using
Media Resource Groups (MRGs) and Media Resource Group Lists (MRGLs).

HW_CFB_1
HW_CFB_2
HW_CFB_3
SW_CFB_1
SW_CFB_2
SW_CFB_3
MTP_1
MTP_2
MTP_3
MOH_1
MOH_2
MOH_3
XCODE_1
XCODE_2
XCODE_3
ANN_1
ANN_2
ANN_3
Media Resource Manager

Shares all media resources among all
Cisco CallManager nodes in the cluster
Cisco
CallManager
Cluster
CIPT1 v4.14-28
The MRM is an integral component of Cisco CallManager. The MRM controls and manages
the media resources within a cluster, allowing all Cisco CallManager servers within the cluster
to share media resources. This figure shows the MRM controlling all of the media resources
that are shared within a Cisco CallManager cluster.
The MRM enhances Cisco CallManager features by making it easier for Cisco CallManager to
deploy transcoder, annunciator, conferencing, MTP, and MOH resources. MRM distribution
throughout the Cisco CallManager cluster uses these resources to their full potential, which
makes the Cisco CallManager cluster more efficient and more economical.
The reasons that resources are shared include the following:
To enable hardware and software devices to coexist within a Cisco CallManager
To enable Cisco CallManager to share and access the resources that are available in the
cluster
To enable Cisco CallManager to perform load distribution within a group of similar
resources
To enable Cisco CallManager to allocate resources based on user preference
4-33
Media Resource Design
Similar to Route Lists and Route

Groups
Media
Resource
Manager
User Needs
Media
Resource
Assigned to Device
First
Choice
Media
Resource
Group List
Media
Resource
Group
Media Resource
1
Media Resource
2
Second
Choice
Media
Resource
Group
Media Resource
3
Media Resource
1
CIPT1 v4.14-29
Cisco CallManager MRGs and MRGLs provide a way to manage resources within a cluster.
Use these resources for conferencing, transcoding, media termination, and MOH.
MRGs define logical groupings of media servers. You can associate an MRG with a
geographical location or a site as desired. You can also form MRGs to control the usage of
servers or the type of service (unicast or multicast) that is desired.
MRGLs specify a list of prioritized MRGs. An application can select required media resources
from among the available resources according to the priority order that is defined in the MRGL.
MRGLs, which are associated with devices, provide MRG redundancy.
This figure shows the hierarchical ordering of media resources and how MRGs and MRGLs are
similar to route groups and route lists.
When a device needs a media resource, it searches its own MRGL first. If a media resource is
not available, the device searches the default list, which includes all of the media resources that
have not been assigned to an MRG. After a resource is assigned to an MRG, it is removed from
the default list.
4-34
MRG
Call 1
Call 2
Call 3
Call 4
Call 5
XCODE1
XCODE2
XCODE3
XCODE1
XCODE2
Default MRG
MOH1
MTP1
XCODE1
XCODE2
XCODE3
Call 6
Call 7
XCODE3
XCODE1
Load distribution of transcoders

All resources shared among Cisco
CallManager nodes in a cluster
CIPT1 v4.14-30
MRGs define logical groupings of media servers.

Cisco CallManager provides a default list of media resources. The default list of media
resources includes all of the media resources that have not been assigned to an MRG. If media
resources have been configured but no MRGs have been defined, all media resources are on the
default list, and all media resources are available to all Cisco CallManager servers within a
given cluster.
Example: MRG Resource Allocation

This figure shows how media resources are allocated to devices when they are listed in an
MRG. The default media resources shown for a Cisco CallManager include MOH1, MTP1,
XCODE1, XCODE2, and XCODE3. The MRM distributes the load evenly among the
transcoder resources in its default MRG for calls that require a transcoder resource. This is the
allocation order for incoming calls that require a transcoder resource:
Call 1 uses XCODE1.
Call 2 uses XCODE2.
Call 3 uses XCODE3.
Call 4 uses XCODE1.
Call 5 uses XCODE2.
Call 6 uses XCODE3.
Call 7 uses XCODE1.
4-35
MRG Configuration
CIPT1 v4.14-31
Configuring an MRG is similar to configuring a route group. Enter a name and description for
the MRG and then add the media resources.
Choose Service > Media Resource > Media Resource Group to display the Media Resource
Group Configuration window.
MRGL Configuration
CIPT1 v4.14-32
After you add the MRGs, assign them to MRGLs. Use the Media Resource Group List
Configuration window to configure MRGLs. Enter a name for the MRGL and then add the
MRGs.
4-36
Choose Service > Media Resource > Media Resource Group List to display the Media
Resource Group List Configuration window.
MRGL Selection Rules

Two levels of prioritized MRGL selection are
implemented:
The higher-priority level is device-based.
The lower-priority level is an optional parameter in

the device pool.
CIPT1 v4.14-33
There are two levels at which MRGLs can be assigned to devices. The higher-priority MRGL
level is configured at the device. For example, a Cisco IP Phone is configured in the Phone
Configuration window in Cisco CallManager Administration. The lower-priority level is an
optional parameter of the device pool. If an MRGL is not configured at the device level, it uses
the MRGL that is configured at the device pool level first, and then, if there are no resources
available, it tries to use resources in the default list. If a device does have an MRGL that is
configured at the device level, that MRGL is used first.
The last MRGL is the default MRGL. A media resource that is not assigned to an MRG is
automatically assigned to the default MRGL. The default MRGL is always searched and it is
the last resort if no resources are available in the device-based MRGL and the device pool
MRGL or if no MRGLs are configured at any level.
4-37
Group Resources by Type
Resource_List
1
I would like to have a

conference with telephone
C. Is there a conference
resource available?
Hardware MRG
XCODE1
XCODE2
HW-CONF1
HW-CONF2
Software MRG
MTP1
MTP2
SW-CONF1
SW-CONF2
MOH MRG
MOH1
MOH2
B
RTP
Result
Use all hardware conference
resources first, and then use
software conference
resources.
CIPT1 v4.14-34
This figure shows how conference resources are allocated when resources are grouped by type
and the software conference resource group is listed after the hardware conference resource
group in the MRGL.
The media resources are assigned to three MRGs:
Hardware MRG: XCODE1, XCODE2, HW-CONF1, and HW-CONF2
Software MRG: MTP1, MTP2, SW-CONF1, and SW-CONF2
MOH MRG: MOH1 and MOH2
An MRGL called Resource_List was created and the MRGs assigned to it in this order:
Hardware MRG, Software MRG, and MOH MRG.
In this arrangement, when a conference is needed, Cisco CallManager allocates the hardware
conference resources first. The software conference resources are not used until all of the
hardware conference resources have been exhausted.
4-38
Group Resources by Location

Dallas_List
SanJose_List
Dallas
Dallas_MRG
XCODE1
HW-CONF1
MOH2
Hub_MRG
SanJose_MRG
MTP1
MTP2
MOH1
SW-CONF1
SW-CONF2
SanJose_MRG
XCODE2
HW-CONF2
MOH3
1
San Jose
Hub_MRG
Result
Devices use
resources at their
location first.
XCODE2
HW-CONF2
MOH3
MTP1
MTP2
MOH1
SW-CONF1
SW-CONF2
Dallas_MRG
XCODE1
HW-CONF1
MOH2
CIPT1 v4.14-35
This figure shows media resources that are grouped by location. Devices use the media
resources in their location before using the media resources at the central site (hub).
This example is for multiple-site WAN deployments that use centralized call processing. All
Cisco CallManager and software resources are located at the central site. For devices at the
Dallas and San Jose locations, it is more efficient to use media resources that reside physically
at the location than to use a resource across the WAN.
Media resources are assigned to these three MRGs:
Hub_MRG: MTP1, MTP2, MOH1, SW-CONF1, and SW-CONF2
Dallas_MRG: XCODE1, HW-CONF1, and MOH2
SanJose_MRG: XCODE2, HW-CONF2, and MOH3
In this example, the network administrator has created a Dallas_List MRGL and assigned the
MRGs so that the resources are available in this order: local hardware resources first
(Dallas_MRG), software resources second (Hub_MRG), and distant hardware resources third
(SanJose_MRG).
The network administrator has also created a SanJose_List MRGL and assigned the MRGs so
that the resources are available in this order: local hardware resources first (SanJose_MRG),
software resources second (Hub_MRG), and distant hardware resources third (Dallas_MRG).
Lastly, the administrator has assigned an IP Phone in Dallas to use the Dallas_List MRGL and
an IP Phone in San Jose to use the SanJose_List MRGL.
With this arrangement, the IP Phone in Dallas will use the Dallas_List resources before using
the central site or the SanJose_List resources.
4-39
Restrict Access to All Media Resources
Resource_List
Software MRG
MTP1
MTP2
SW-CONF1
SW-CONF2
Hardware MRG
XCODE1
XCODE2
HW-CONF1
HW-CONF2
MOH MRG
MOH1
MOH2
No Resource_List
Dummy MRG
Dummy 1
Result
Device cannot use any
media resources.
CIPT1 v4.14-36
This figure shows how to restrict the media resources that are available to a device by assigning
an MRGL that has a dummy media resource.
To verify that a device cannot access media resources, ensure that all media resources are
assigned to an MRG. Add a dummy media resource to the dummy MRG, and add that MRG to
the NoResource_List MRGL. Assign the telephone device, IP Phone A in this example, to the
NoResource_List.
This IP Phone cannot use any media resources when it is configured this way because the only
device in the NoResource_List MRGL is a dummy media resource, which the IP Phone will
attempt to use.
4-40
Restrict Access to Conference Resources

Resource_List
1
MTP MRG
MTP1
MTP2
CONF MRG
SW-CONF1
SW-CONF2
HW-CONF1
HW-CONF2
MOH MRG
MOH1
MOH2
XCODE MRG
XCODE1
XCODE2
NO_CONF_List
1
2
3
MTP MRG
MTP1
MTP2
XCODE MRG
XCODE1
XCODE2
MOH MRG
MOH1
MOH2
Result
Device cannot
use any
conference
resources.
CIPT1 v4.14-37
This figure shows how to restrict the conference resources that are available to devices by
changing the configuration of the MRGs and MRGLs.
In this example, the network administrator has created an MRGL, Resource_List, with all of the
media resources. The administrator has also created an MRGL, NO_CONF_List, which
contains all of the media resources except for conferencing resources.
With this setup, the device cannot use conference resources. Only the MTP, XCODE, and
MOH resources are available to the device.
4-41
Media Resource Functionality Example

D_List MRGL
Dazzle_MRG
ServerD_MOH
Audio Source ID
User 1
A
Network 5
MOH Servers
ServerD_MOH
SD_List MRGL
SuperDave_MRG
ServerS_MOH
ServerD_MOH
Audio Source ID
User 1
B
Network 5
ServerS_MOH
Dazzle_MRG
ServerD_MOH
Audio Source IDs

1 Pop Music 1
5 Thank you for holding.
CIPT1 v4.14-38
This list describes the configuration setup shown in this figure:

Two MRGs
Dazzle_MRG consists of the MOH server labeled ServerD_MOH.
SuperDave_MRG consists of a prioritized list of MOH servers labeled

ServerS_MOH and ServerD_MOH.
Two MRGLs
D_List consists of the Dazzle_MRG.
SD_List consists of the SuperDave_MRG and Dazzle_MRG (prioritized order).
Two audio source IDs
Audio source ID 1 plays the Pop Music 1 audio stream.
Audio source ID 5 plays the Thank you for holding audio stream.
Two Cisco IP Phones
Cisco IP Phone A is assigned the D_List MRGL and the audio sources ID 1, Pop
Music 1 (for user hold), and ID 5, Thank you for holding (for network hold).
Cisco IP Phone B is assigned the SD_List MRGL and the audio sources ID 1, Pop
Music 1 (for user hold), and ID 5, Thank you for holding (for network hold).
The effect of the configuration in this example is that when IP Phone A places a user on hold,
pop music is streamed from audio source ID 1 on ServerD_MOH.
When IP Phone B transfers a call (network hold), the user hears Thank you for holding
streamed from ServerS_MOH audio source ID 5 because it is the first MOH server that is listed
in the SD_List MRGL. If ServerS_MOH has no resources, Cisco CallManager instructs
ServerD_MOH to play the stream.
4-42
Summary
Summary
Media resources provide services, such as transcoding, conferencing,
MOH, and media termination, which are activated on the Cisco
CallManager.
Conference bridge resources are software or hardware solutions that
allow ad hoc and Meet-Me conferences.
MTP resources provide supplementary services to H.323 endpoints that
do not support the H.323v2 OpenLogicalChannel and
CloseLogicalChannel request features.
Annuciator resources play prerecorded announcements and tones.
Transcoder resources convert an output stream from one compression
type to another to allow devices using different codecs to communicate.
MOH resources provide users on hold with music from a streaming
source. There are two types of holduser hold and network hold
which are configured in Cisco CallManager.
The MRM controls and manages the media resources within a Cisco
CallManager cluster, allowing all Cisco CallManager nodes to share
these resources.
CIPT1 v4.14-39
4-43
References
Cisco Systems, Inc. Cisco CallManager Administration Guide, Release 4.1(3),
Annunciator Configuration, Conference Bridge Configuration, Media Termination
Point Configuration, Transcoder Configuration, Media Resource Group
Configuration, and Media Resource Group List Configuration.
3/ccmcfg/index.htm
Cisco Systems, Inc. Cisco CallManager System Guide, Release 4.1(3), Media Resource
Management, Annunciator, Conference Bridges, Transcoders, Music on Hold, and
Media Termination Points.
3/ccmsys/index.htm
Cisco Systems, Inc. Cisco CallManager Features and Services Guide, Release 4.1(3),
Music on Hold.
3/ccmfeat/index.htm
4-44
Lesson 4-2
Adding Users and Customizing

User Options
Overview
Adding users and associating users with devices allows for directory searches from a Cisco IP
Phone and enables features such as Cisco Auto Attendant, Cisco IP Manager Assistant (IPMA),
and Cisco CallManager Extension Mobility. Allowing users to configure IP Phone options
increases their productivity.
This lesson teaches you how to use Cisco CallManager to configure users and to associate
devices with users. You will learn how users can customize their IP Phones using the web.
Objectives
Upon completing this lesson, you will be able to add users, associate devices with users, and
use the Cisco CallManager User Options web pages to customize Cisco IP Phones. This ability
includes being able to meet these objectives:
Use Cisco CallManager Administration to add users and associate users with a device
Log in to the Cisco CallManager User Options web page and select a device to personalize
Activate the Call Forward option in the Cisco CallManager User Options web page to
forward all calls to an associated device
Enter speed dials in the Cisco CallManager User Options web page to associate with IP
Phone buttons
Subscribe to Cisco IP Phone Services from the Cisco CallManager User Options web page
to access web services from IP Phones
Create personal address books in the Cisco CallManager User Options web page of stored
names and numbers and assign Fast Dial codes to personal address book entries to enable
users to dial those codes in place of telephone numbers
Describe how to change the way that the voice-message light on the handset works when a
user receives a voice-mail message
Describe how to change the language for the Cisco CallManager User Options web pages
or telephone
Adding a User
This topic discusses how to add a user and associate a user with a device.
User Information
Cisco CallManager
User Information
Accessed by Directory
Services, Cisco
WebAttendant, and the
User Options Web
Pages
CIPT1 v4.14-3
The User area in Cisco CallManager Administration allows you to display and maintain
information regarding Cisco CallManager users. Generally, completing user information is
optional; the devices will function whether or not you complete the user information. However,
the user information that you enter is accessed by directory services, Cisco Auto Attendant, and
the Cisco IP Phone Configuration windows. If you want to provide these features to your users,
you must complete the information in the User area for all users, including the directory
numbers (DNs). You can use user information for resources such as conference rooms, other
areas with telephones, or Cisco Auto Attendant.
After you associate users with a device and enter the name and DN of that device, users can
change their speed dials and forwarding numbers on the web.
The Global Directory for Cisco CallManager (Release 3.0 and later) contains every user in a
Cisco CallManager directory. Cisco CallManager uses Lightweight Directory Access Protocol
(LDAP) to interface with a directory that contains user information. The Global Directory is an
embedded directory that is supplied with Cisco CallManager, and its primary purpose is to
maintain the associations between users and devices. You can access the Global Directory by
using either a basic or an advanced user search.
4-46
Adding a User
CIPT1 v4.14-4
The figure shows an example of adding a user to the Cisco CallManager directory database by
using Cisco CallManager Administration. To add a user in Cisco CallManager Administration,
choose User > Add a New User.
Before adding a user, gather the following user information:
First name
Last name
User ID (username)
Telephone number or DN
Manager user ID (manager username)
Department
If the user is going to access the Cisco SoftPhone application, Cisco Auto Attendant, or any
other computer telephony integration (CTI) application, check the Enable CTI Application
Use check box.
When you are first setting up a user, assign a simple password (at least four characters) and a
personal identification number (PIN), which must be at least five digits, for the user to use on
the initial login. The user can then change the initial password and PIN from the Cisco
CallManager User Options page.
After the directory information is added, you can associate the user with a device or devices.
4-47
Device Association
Multiple
Devices and
Only One
Primary
Extension
CIPT1 v4.14-5
After you have added a user, you can associate devices over which the user will have control.
Users can control some devices, such as telephones. When users have control of a telephone,
they can control certain settings for that telephone, such as speed dialing and call forwarding.
You can associate a user with many devices; however, only one of the devices can be the
primary extension for that user. You can associate the user with multiple telephone devices or a
Cisco SoftPhone device or both.
To assign devices to a user, access the User Configuration window for that user and then
complete the following steps to assign the devices:
4-48
Step 1
In the Application Profiles pane, click Device Association.
Step 2
Limit the list of available devices by entering the search criteria in the Available
Device List Filters section, if desired, and click Select Devices.
Step 3
Check the check box of one or more devices that you want to associate with the user.
You can assign one primary extension from the devices to which the user is assigned
by clicking the radio button in the Primary Ext. column for that device.
Step 4
When you have completed the assignment, click Update Selected to assign the
devices to the user.
User Login and Device Selection
This topic discusses how users can log in and select a device from the Cisco CallManager User
Options web page.
Cisco CallManager User Options: Log On
https://<server_name or IP>/ccmuser/logon.asp
CIPT1 v4.14-6
To open the Cisco CallManager User Options web page, enter this URL:
http://<server_name>/ccmuser/logon.asp
The server name is the hostname or IP address of the Cisco CallManager server.
At the Cisco CallManager User Options page, enter the correct username and password. If this
is the first time that the user is logging on, the user should obtain the URL, username, and
password from the administrator.
From any page within Cisco CallManager User Options web pages, a user can change the
language of the page by choosing the language (locale) from the View Page In drop-down
menu, if additional locales have been configured.
4-49
Cisco CallManager User Options:

Welcome <username>
Select a Device.
CIPT1 v4.14-7
After logging on, a user can select an associated device to configure. The user can customize
multiple associated devices by choosing more than one device.
A web location allowing users to customize Cisco IP Phone settings, such as adding speed dials
and forwarding calls means that users can be more productive in their work environment. For
example, when a user is not going to be in the office to receive an important call, he or she can
access the Cisco CallManager User Options web page from home and forward calls from the
Cisco IP Phone to a cellular telephone or any other DN.
4-50
Call Forward
This topic discusses how a user can forward all calls on an associated device by using the Cisco
CallManager User Options web page.

Call Forwarding
CIPT1 v4.14-8
The figure shows the Forward Your Calls page. To display this page, click the Forward All
Calls to a Different Number link in the User Options main menu.
As shown in the figure, this user can forward all incoming calls on line 1 of a device to either
voice mail or another number.
If the user is forwarding calls to another number, the calling search space of the device using
Call Forward All (CFA) will restrict which numbers will be valid. Also, if the number is
forwarded off-net, the user must enter the number as if dialing from that telephone device.
The CFA feature can be very helpful to users. However, the Call Forward All feature can allow
users to make personal long-distance calls at company expense. To restrict access to the CFA
feature, apply a calling search space on the Directory Number Configuration page in the Call
Forward All setting.
Example: Call Forwarding

A user who wants to work from home wants all calls to the office telephone to forward to the
home number. If the user dials 92145550122 to call home from the office, the user must enter
92145550122 as the forwarding number.
4-51
Speed Dials
This topic discusses how a user can configure speed dial settings for a device using the Cisco
CallManager User Options web page.

Speed Dials
CIPT1 v4.14-9
The figure shows the Add/Update Your Speed Dials web page. To display this page, click the
Add/Update Your Speed Dials link in the User Options main menu.
Depending on the device, the number of speed dials is limited based on settings in the phone
button template. The user can enter a number and label for each available speed dial button.
Buttons are available if the user is not using them for lines or services. The speed dial number
that is entered must follow the dialing rules for the Cisco IP telephony solution.
When programming speed dials, enter the number precisely as it is dialed from the device. If
the number 9 must be dialed before the telephone number, the 9 must be part of the speed dial
number that is entered.
Example: Adding an Access Code to Speed Dial Numbers

If an access code, such as 1234, then 9, is required, the user must enter the speed dial number
using these numbers. For example, if the telephone number is 2145550199, the speed dial
number must be entered as 123492145550199.
4-52
Cisco IP Phone Services Subscription
This topic discusses how a user can subscribe to available Cisco IP Phone Services within a
Cisco IP telephony solution.

IP Phone Services
CIPT1 v4.14-10
The figure shows the Subscribe/Unsubscribe IP Phone Services web page. To display this page,
click the Configure Your Cisco IP Phone Services link in the User Options main menu.
The administrator can configure a number of services for user subscription. For example, the
administrator can configure services that store telephone numbers, meeting room availability,
traffic reports, and more. The user can use the Subscribe/Unsubscribe IP Phone Services page
in Cisco CallManager User Options to subscribe to or unsubscribe from any of the Cisco IP
Phone Services that are configured.
Example: Subscribing to a Stock Quote Service

If you have configured a service that looks up the stock price of a company, a user can
subscribe to that service from the Subscribe/Unsubscribe IP Phone Services page in
CallManager User Options. To view the stock price of a company, the user can press the
Services button on a Cisco IP Phone 7970, 7960, or 7940 and view the stock price on the IP
Phone liquid crystal display (LCD).
4-53
This topic discusses how the user can access the Personal Address Book and Fast Dial services
using Cisco CallManager User Options.

Personal Address
Book service
Allows users to
store names and
numbers
Fast Dial service
Allows users to
assign short codes
to Personal Address
Book entries and
dial those codes in
place of phone
numbers.
CIPT1 v4.14-11
The Personal Address Book service allows a user to store names and numbers for people
internal and external to the company. A user can also assign Fast Dial codes to Personal
Address Book entries and dial those codes in place of phone numbers. With the Fast Dial
service, users can assign one- or two-digit index numbers (from 1 to 99) for quick dialing from
the Cisco IP Phone. Users can assign index numbers either to Personal Address Book entries or
to directory entries that they add that do not correspond to address book entries.
Users can configure the Personal Address Book and Fast Dial features from the Personal
Address Book page in Cisco CallManager User Options. After subscribing to these services, a
user can access the Personal Address Book and Fast Dial codes from the Cisco IP Phone by
pressing the Services button.
4-54

Personal Address Book and Fast Dial (Cont.)
To set up Personal
Address Book and
Fast Dials, choose
Configure your
Cisco Personal
Address Book
from the User
Options menu.
Search for
Address
Book Entries
Add a new
Address Book
Entry
Create or Modify
Fast Dial
CIPT1 v4.14-12
The figure shows the Find/List Address Book Entries page. To display this page, choose the
Configure Your Personal Address Book link in the User Options main menu.
From the Find/List Address Book Entries page, users can add a new Personal Address Book
entry, create or modify Fast Dial codes to reach address book entries, or search for address
book entries by using either complete or partial strings.
4-55
Personal Address Book: Add a New Entry
CIPT1 v4.14-13
Adding a new Personal Address Book entry in the User Options web pages is similar to adding
a user in Cisco CallManager Administration. Items marked with an asterisk are required; all
others are optional.
Fast Dial: Add a New Entry
CIPT1 v4.14-14
To assign a Fast Dial code from the User Options web pages, choose Menu > Configure Your
Cisco Personal Address Book, click Fast Dials, and choose an index code (1 to 99).
4-56
In the Add a New Fast Dial popup window, you can do one of the following:
Click Personal Address Book Entry to assign a Fast Dial code to an existing entry.
Select the entry and a phone number from the drop-down menu.
Click Enter a Directory Number to assign a Fast Dial code to a phone number without
using your Personal Address Book.
Subscribe to Personal Address Book and

Fast Dial Services
The user
subscribes to My
address book and
My Fast Dial
services; requires
user ID and PIN.
CIPT1 v4.14-15
The Personal Address Book and Fast Dial features are separate IP Phone services in Cisco
CallManager Administration.
To subscribe to the Fast Dial service, access the User Options web pages. Then choose Main
Menu > Configure Your Cisco IP Phone Services. Choose Fast Dials from the Available
Services drop-down list, click Continue, and click Subscribe.
4-57
Message Waiting Lamp Policy
This topic discusses how the user can configure the message waiting lamp (indicator) of a
Cisco IP Phone using the Cisco CallManager User Options web page.

Message Waiting Lamp
CIPT1 v4.14-16
The figure shows the Change your Message Waiting Lamp policy page. To display this page,
click the Change the Message Waiting Lamp Policy for Your Phone link in the User
Options main menu.
A user can set the message waiting lamp policy for a device. There are three settings that the
user can configure: Use System Policy, Always Light, and Never Light. The default system
policy is set to light the lamp. To be sure that the message waiting lamp illuminates when a
voice message is left, choose the Always Light policy.
Example: Setting the Message Waiting Lamp Policy

If a user is associated with multiple devices but would like to know when voice mail is left
from only one of those devices, the user can set all other devices to Never Light. Setting the
other devices to Never Light allows the user to see an indication of a voice message from only
one device.
4-58
Personalizing Device and Web Page Locale
This topic discusses how a user can customize the language of the Cisco IP Phone LCD and
web pages by using the Cisco CallManager User Options page.

Locale for Phone
CIPT1 v4.14-17
The figure shows the Select a User Locale for you Phone page. To display this page, click the
Change the Locale for This Phone link in the User Options main menu.
The default language that is installed with Cisco CallManager is English. If other locales are
required, you can download them from the Cisco website. Supported locales include the
following:
Chinese Simplified (China)
Chinese Traditional (Taiwan)
Danish (Denmark)
Dutch (Netherlands)
Finnish (Finland)
French (France)
German (Germany)
Greek (Greece)
Hungarian (Hungary)
Italian (Italy)
Japanese (Japan)
Korean (Korea)
Norwegian (Norway)
4-59
Polish (Poland)
Portuguese (Portugal)
Russian (Russia)
Spanish (Spain)
Swedish (Sweden)
If a user locale is not selected, the system-wide locale is used.
Example: Setting the User Locale on the Phone

If a user who speaks Russian is using a telephone in Italy and the system-wide locale for
devices is Italian, the user can log in to the Cisco CallManager User Options web page and set
the locale for the device to Russia if the Russian locale has been added to the Cisco
CallManager server to which the local (Russian-speaking) user registers. The user can
configure the IP Phone to display text in the desired language without administrator
intervention.

Locale for Web Pages
CIPT1 v4.14-18
The figure shows the Select a User Locale for Your Profile page. To display this page, click the
Change the Locale for These Web Pages link in the User Options main menu.
Users can also customize the language (locale) in which they view the Cisco CallManager User
Options web pages. The default language that is installed with Cisco CallManager is English. If
other locales are required, you can download them from the Cisco website. If you download
these languages, users can customize the language of the Cisco IP Phone, and they can also
customize the Cisco CallManager User Options web pages display.
4-60
Summary
Summary
Cisco CallManager Administration allows you to
add users and associate users with specific
devices.
Users can log on to the Cisco CallManager User
Options web page and configure associated
devices.
Users can forward calls on an associated device to
voice mail or another number.
Users can configure speed dials by entering
numbers and text that allow for one-button dialing.
CIPT1 v4.14-19
Summary (Cont.)
Users can subscribe or unsubscribe to all
configured Cisco IP Phone Services.
Users can configure a Personal Address Book and
Fast Dial and access them from an IP Phone.
Users can configure the message waiting lamp on
Cisco IP Phones to use the system policy, always
to light, or never to light.
Users can customize the language (locale) of the
Cisco IP Phone LCD and the language in which
they view the Cisco CallManager User Options web
pages.
CIPT1 v4.14-20
4-61
References
Cisco Systems, Inc. Customizing Your Phone on the Web.
http://www.cisco.com/application/pdf/en/us/guest/products/ps1855/c1626/ccmigration_091
86a00801ec9b6.pdf.
Cisco Systems, Inc. Cisco IP Telephony Locale Installer documentation.
http://www.cisco.com/univercd/cc/td/doc/product/voice/locinst/index.htm.
4-62
Lesson 4-3
Configuring User Features

Part 1
Overview
Administrators need to have a working knowledge of the various options that are available for
Cisco IP Phones to ensure that all of the desired features and functions are available to users
and that they are properly configured. This lesson, the first of two parts on features, discusses
many of the Cisco IP Phone features that are available to users in a Cisco IP telephony solution.
The lesson includes a discussion of core and enhanced IP Phone features, Call Park, Call
Pickup, Cisco Call Back, Barge, Privacy, and Cisco IP Phone Services. The lesson explains the
purpose of each feature and describes how to configure and use the feature.
Objectives
Upon completing this lesson, you will be able to configure and use many IP Phone features,
including speed dials, Call Park, Call Pickup, Cisco Call Back, Barge, Privacy, and Cisco IP
Phone Services, and create a nonstandard softkey template. This ability includes being able to
Describe core Cisco IP Phone features of Cisco CallManager, including hold, redial,
transfer, speed dialing and abbreviated dialing, and Auto Answer
Describe enhanced IP Phone features of Cisco CallManager, such as multiple calls per line
appearance, Direct Transfer, Call Join, and Immediate Divert
Define standard and nonstandard softkey templates and create nonstandard softkey
templates and assign them to Cisco IP Phones.
Configure Cisco CallManager to enable Call Park, Call Pickup, and Cisco Call Back
Configure Cisco CallManager to enable Barge and Privacy on a shared line
Configure Cisco CallManager to enable users to subscribe to IP Phone Services from their
Cisco IP Phones
Core IP Phone Features
This topic discusses the core features of Cisco IP Phones.
Basic IP Phone Features
Hold
Redial
Transfer
Call Waiting
CIPT1 v4.14-3
Cisco CallManager software extends enterprise telephony features and capabilities to packet
telephony network devices such as Cisco IP Phones, media-processing devices, voice over IP
(VoIP) gateways, and multimedia applications.
Four basic IP Phone features do not require configuration in Cisco CallManager and are
activated when the user presses a softkey on the IP Phone:
Hold: Places an active call on hold. Hold requires no configuration, unless you want to use
music on hold (MOH). When you put a call on hold, the call remains active even though
you and the other party cannot hear one another. You can answer other calls while a call is
on hold. Engaging the hold feature generates music or a beeping tone.
Note
Avoid putting a conference call on hold because the music or beeping tone of the hold
feature will be heard by all conference participants.
Redial: Redials the last number dialed. To redial the most recently dialed number, press the
Redial softkey. Doing so without lifting the handset activates the speakerphone or headset.
To redial a number from a line other than your primary line, select the desired line button
and then press Redial.
Transfer: Transfers an active call to another directory number (DN) through use of the
Transf softkey.
Call Waiting: Lets users receive a second incoming call on the same line without
disconnecting the first call. When the second call arrives, the user receives a brief call
waiting indicator tone.
4-64
Speed Dial and Abbreviated Dial

Configuration
Assigns speed dials to
phone buttons
Can be used only for
abbreviated dials
Speed dial index

55 will be sent to
Cisco CallManager
when AbbrDial key
is pressed.
AbbrDial softkey
is available when
user enters digits.
CIPT1 v4.14-4
Speed dialing provides quick access to frequently dialed numbers. Abbreviated dialing,
introduced in Cisco CallManager Release 4.0, extends speed dial functionality by enabling a
user to configure up to 99 speed dial entries on a telephone. When a user starts dialing digits,
the AbbrDial softkey appears, and the user can access any speed dial entry by entering the
appropriate index, either one or two digits.
Note
This subtopic covers configuring speed dials from Cisco CallManager Administration. Users
can configure speed dial entries from the User Options web pages.
Administrators can configure speed dials or abbreviated dials in Cisco CallManager

Administration. Configure abbreviated dials just as you would configure speed dials. Users (or
administrators) can configure speed dials from the User Options web page (http://<server IP
address>/ccmuser/logon.asp).
4-65
Auto Answer Configuration

Directory Number Configuration Window
CIPT1 v4.14-5
Auto Answer is a feature that causes the speakerphone or headset to go off hook automatically
when an incoming call is received. You can program this feature on a telephone-by-telephone
basis. Choose the device that you want to enable, and then choose Auto Answer under the
Directory Number Settings. You can choose Auto Answer Off, Auto Answer with Headset, or
Auto Answer with Speakerphone.
Choose Device > Phone, then select a phone and select a line to display the Auto Answer
parameters.
4-66
Call Forward and Configurable Call Forward

Display Configuration
Directory Number Configuration Window
Call Forward
Configurable
Call Forward
Display
CIPT1 v4.14-6
Call forwarding allows a user to configure a Cisco IP Phone so that all calls that are destined
for that IP Phone ring at another telephone or go directly to voice mail.
Note
This subtopic covers the call forwarding options that the Cisco CallManager administrator
can configure in the Directory Number Configuration window. Users can forward calls in two
ways only: by using a softkey or by accessing the User Options web pages.
Forward All: The settings in this row of fields specify the forwarding treatment for calls to
this DN if the DN is set to forward all calls. Specify the following values:
Voice Mail: Check this check box to use settings in the Voice Mail Profile
Configuration window. When this check box is checked, Cisco CallManager ignores
the settings in the Coverage/Destination and Calling Search Space fields.
Coverage/Destination: This setting indicates the DN to which all calls are

forwarded. Use any dialable phone number, including an outside destination.
Calling Search Space: This setting applies to all devices that are using this DN.
Other call forwarding settings: Starting with Cisco CallManager Release 4.1, the
administrator can specify different call forwarding treatment based on whether the caller is
external or internal for no answer, busy, and no coverage conditions.
The no coverage option applies only if you configure one of the other forwarding fields in
the Directory Number Configuration window with a hunt pilot number in the
Coverage/Destination DN field. You must also configure the Forward Hunt No Answer or
Forward Hunt Busy fields and check the Use Personal Preferences check box under the
Hunt Forward Settings section in the Hunt Pilot Configuration window; otherwise, the
Forward No Coverage configuration in the Directory Number Configuration window has
no effect.
4-67
Note
Call Forward Busy, Call Forward No Answer, and Call Forward No Coverage for external
and internal calls and the interaction of the No Coverage option with the Hunt Forward
settings is covered in detail in the lesson Configuring Hunt Groups and Call Coverage.
Configurable call forwarding display: Starting with Cisco CallManager Release 4.0, the
administrator can configure call-forwarding information display options to the original
dialed number, to the redirected dialed number, or to both. The administrator can enable or
disable the caller name or caller number and present this information to the display of the
forwarded party. The display option is configured for each line appearance.
Choose Device > Phone, then select a phone and select a line to display the call forwarding
parameters shown in the figure.
4-68
Enhanced IP Phone Features
This topic discusses enhanced Cisco IP Phone features that are available starting in Cisco
CallManager Release 4.0.
Multiple Calls per Line Appearance

Cisco CallManager
Release 4.0
enhancement to
increase number of
calls per line
appearance
Directory Number Configuration Page
Configure using:
Maximum number
of calls
Busy trigger
CIPT1 v4.14-7
Cisco CallManager Release 4.0 enables multiple calls to exist on the same line. This feature
eliminates the need to create multiple instances of the same directory number in different
partitions to allow users to share a line and still be able to receive and place multiple calls out
of the same line. Cisco CallManager will now support up to 200 active calls on a single line and
one connected call per telephone at any time.
Two configuration settings enable multiple line appearances and are configured from the
Directory Number Configuration window:
Maximum Number of Calls: This setting configures the maximum number of calls
inbound or outbound per line appearance. You can configure up to 200 calls for a line on a
device, with the limiting factor being the total number of calls that are configured on the
device. As you configure the number of calls for one line, the number of calls that are
available for another line decrease. The default specifies 4. If the phone does not allow
multiple calls for each line, the default specifies 2.
Busy Trigger: This setting, which works in conjunction with Maximum Number of Calls
and Call Forward Busy (CFB), determines the maximum number of calls to be presented at
the line. If the maximum number of calls is set to 50 and the busy trigger is set to 40, then
incoming call 41 is rejected with a busy cause code (and will be forwarded if CFB is set). If
this line is shared, all the lines must be busy before incoming calls will be rejected.
4-69
Example: Configuration Settings for Multiple Calls per Line

Appearance
In the figure, the maximum number of calls is set to 4 and the busy trigger is set to 2. With this
configuration, four calls can be active at a given time. If two calls are active, and a third call
comes in, it is forwarded to the CFB destination. The user, however, can place up to two more
calls.
Choose Device > Phone, then select a phone and select a line to display the Directory Number
Direct Transfer
The DirTrfr and Select
softkeys join two
established calls into
one call and drop the
initiator from the call.
The two calls are joined
immediately and directly
(no hold), and no
conference resources
are used.
Kims Phone
CIPT1 v4.14-8
Direct Transfer, which was introduced in Cisco CallManager 4.0, joins two established calls
(defined as a call in the hold or connected state) into one call and drops the feature initiator
from the call. Direct Transfer does not initiate a consultation call and does not put the active
call on hold.
To implement Direct Transfer, the Direct Transfer initiator selects two calls at the Cisco IP
Phone and presses the DirTrfr softkey. The two calls are joined immediately and directly, and
no conference resources are inserted. The initiating user is not included in the call after the
transaction is complete, and the call is released from the IP Phone of the initiator.
4-70
Example: Direct Transfer Call

The figure and the following steps illustrate the user sequence of events in a typical Direct
Transfer call:
Step 1
Sam and Kim are participating in an active call.
Step 2
Sam asks Kim to transfer him to Mary.
Step 3
Kim puts Sam on hold.
Step 4
Kim calls Mary.
Step 5
Kim touches the line that Sam is using (Cisco IP Phone 7970 only) or uses the Select
softkey to select that line.
Step 6
Kim presses the DirTrfr key, and Sam and Mary are immediately connected.
Call Join
The Join softkey can join up to 15
established calls (16 parties) in a
conference in a single feature
request.
The user chooses an active or
held call, selects the appropriate
line, and presses the Join
softkey.
Selected calls and the join
initiator are joined into an
ad hoc conference.
The initiator can leave the
session and the conference
stays up.
CIPT1 v4.14-9
Introduced in Cisco CallManager Release 4.0, the Call Join feature enables a user to link up to
15 established calls (for a total of 16) in a conference. Call Join does not create a consultation
call (does not put the active call on hold).
To implement Call Join, the user chooses an active or held call and, using either the rocker key
(Cisco IP Phones 7960 and 7940) and the Select softkey or the touchscreen (Cisco IP Phone
7970), selects the appropriate line and then presses the Call Join softkey so that the selected
calls and the join initiator are joined in an ad hoc conference. The initiator can leave the Call
Join session at any time, and the conference stays active. Only the initiator of the Call Join
session can add participants to the conference or drop them from it.
4-71
Immediate Divert to Voice Mail
iDivert softkey diverts a

call to the voice-mail
box of the iDivert
initiator.
Initiator can be calling
party or called party.
CIPT1 v4.14-10
The Immediate Divert feature is a supplementary service that was introduced in Cisco
CallManager Release 4.0. This feature allows you to immediately divert a call to a voicemessaging system. When the call is diverted, the line becomes available to make or receive new
calls.
Immediate Divert supports an incoming call in the call-offering (ring in), call-on-hold, or callactive state. Immediate Divert supports an outgoing call in the call-on-hold or call-active state.
You can access the Immediate Divert feature by using the iDivert softkey. This softkey can be
applied to any Cisco IP Phone that can accept softkeys. Configure this softkey by using the
Softkey Template Configuration window of Cisco CallManager Administration.
Immediate Divert requires the following components:
Cisco CallManager Release 4.0 or later
Cisco IP Phones (models 7905, 7912, 7920, 7940, 7960, or 7970)
Note
4-72
Although Immediate Divert is not available to computer telephony integration (CTI)

applications, the CTI feature Transfer to Voicemail performs the same function as Immediate
Divert but does so for CTI applications that third-party developers develop.
Example: Called Party Presses iDivert Softkey

The previous figure and the following steps illustrate the user sequence of events in a typical
Immediate Divert call. The example illustrates a called party using the iDivert softkey while the
call is in the call-offering state:
Step 1
George calls Sam.
Step 2
Sam is unable to take the call.
Step 3
Sam diverts the call to voice mail by pressing the iDivert softkey.
Step 4
George hears the voice-messaging greeting of Sam.
Example: Caller Presses iDivert Softkey

The following steps illustrate a two-party call where the caller (party A) diverts a call in the
active state to voice mail. An example of when this feature might be used is when a manager
calls an assistant for information and, rather than write the information down, requests that the
assistant leave a voice message for retrieval later by the manager.
Step 1
Party A calls party B.
Step 2
Party B answers the call.
Step 3
Party A presses the iDivert softkey.
Step 4
Party B hears the outgoing voice-messaging greeting of party A.
Step 5
Party B leaves a voice message.
4-73
Working with Softkey Templates
This topic defines standard and nonstandard softkey templates and discusses how to create
nonstandard templates and assign them to Cisco IP Phones.
Softkey Templates
Five standard templates
Cannot delete or modify
standard templates Softkeys
CIPT1 v4.14-11
Softkeys extend the functions of Cisco IP Phones 7940, 7960, and 7970. Softkeys are buttons
along the side and bottom of the IP Phone liquid crystal display (LCD) that point to functions
and feature options on the LCD screen. Softkeys change depending on the status of the phone.
Cisco CallManager provides softkey templates for administrator convenience. Softkey
templates group softkeys that are used for common call-processing functions and applications.
You can assign these softkey templates to devices to provide standard softkey definitions, or
you can create custom templates.
Cisco CallManager, starting with Release 4.0, includes these five standard softkey templates:
Standard IPMA Assistant
Standard User
Standard Feature
Standard IPMA Manager
Standard IPMA Shared Mode Manager
You cannot delete or modify these standard templates. However, you can create custom
(nonstandard) templates to meet the needs of your organization.
Choose Device > Device Settings > Softkey Templates to access softkey templates.
4-74
Configuring Nonstandard Softkey

Templates
Standard Softkey
Template
Nonstandard
Softkey Template
CIPT1 v4.14-12
To create a nonstandard softkey template, you must first copy a standard template and make the
modifications desired to this copy. Choose the standard template and click the Copy button.
The Softkey Template Configuration window will display the softkey template name,
description, and applications that are associated with the template. You must rename the
template with a new descriptive name. After you have entered a unique name, click the Insert
button. The standard template is copied, and when you choose Back to Find/List Softkey
Templates, the new softkey template is displayed. After the nonstandard template is made,
application softkeys can be added or removed from the template.
Example: Nonstandard Softkey Template

In the figure, a nonstandard softkey template is created called Standard User Callback. This
template was created by copying the Standard User standard softkey template and assigning it a
new name.
4-75
Adding Application Softkeys to

Nonstandard Templates
CIPT1 v4.14-13
You can add a standard softkey template that is associated with a Cisco application (for
example, Cisco IPMA Manager or Cisco IPMA Assistant, as shown in the figure) to a
nonstandard softkey template by clicking the Add Application button. This action adds the
softkeys that are associated with the application (such as Immediate Divert [ImmDiv], Transfer
to Voice Mail [TrnsfVM], and Do Not Disturb [DND]) to the nonstandard template.
When the Add Application window is displayed, you can choose the standard softkey template
that you want to add to the nonstandard softkey template. Next, click Insert and Close, and
then click Update. This process will associate the standard template softkey configuration with
the nonstandard template.
4-76
Modifying Softkey Positions
CIPT1 v4.14-14
You can add or delete softkeys or modify softkey positions in a nonstandard softkey template to
customize the appearance of the softkeys on Cisco IP Phones. In the Softkey Templates field,
choose the template in which you want to add or delete softkeys or modify the softkey
positions. In the upper-right corner of the window, click the Configure Softkey Layout link.
The Softkey Layout Configuration window is displayed with call states on the left and the
Selected Softkeys pane on the right. You can select the softkeys that you want displayed for
each call state.
To add softkeys, select a softkey from the Unselected Softkeys pane and click the Right arrow
to move it to the Selected Softkeys pane. If the number of softkeys exceeds 16, an error
message will be displayed that states that you must remove some of the softkeys before
continuing. To delete softkeys, select a softkey from the Selected Softkeys pane and click the
Left arrow to move it to the Unselected Softkeys pane. Click Update after completing either
procedure.
To modify softkey positions, use the Up arrow and Down arrow to rearrange the positions of
the selected softkeys (the top position corresponds to the left-most softkey on the IP Phone). To
save the modifications that you have made to the template, click Update.
Note
After making modifications to softkey templates, you must restart the devices that are using
the template.
4-77
Assigning Softkey Templates to Devices
Assign softkey templates through device pools,

user device profiles, or on the device itself.
CIPT1 v4.14-15
You can assign softkey templates to devices in several ways. The template can be assigned in
the device pool settings window (System > Device Pool), through a user device profile (Device
> Device Settings > Device Profile), or on the device itself (Device > Phone).
For example, you might have a (standard or nonstandard) softkey template that you assign to a
device pool to configure the majority of phones in your cluster, a different softkey template that
you use for a feature that requires a device profile (for example, Extension Mobility), and a
different softkey template that the includes the Barge, Privacy, and Immediate Divert softkeys
that you assign to a device belonging to a manager.
The figure shows the Standard User softkey template being assigned to a device pool.
4-78
Deleting Softkey Templates
Remove the template from all devices that are using it before deleting it.
CIPT1 v4.14-16
Standard templates cannot be deleted. Only nonstandard templates can be deleted. If you want
to delete a nonstandard softkey template, the template cannot be in use by any device in the
Cisco CallManager system. If the softkey template is assigned to a device pool, user profile, or
Cisco IP Phone, you receive an error message stating that the template is in use. You must
remove the template from all devices (or reassign a different template to the devices) before the
template can be deleted.
To determine whether a softkey template is in use, click the Dependency Records link.
Dependency records are disabled by default.
Caution
Enabling the dependency records functionality causes high CPU usage. This task executes
at below-normal priority and may take time to complete because of dial plan size and
complexity, CPU speed, and the CPU requirements of other applications.
To enable dependency records, follow these steps:

Step 1
Choose System > Enterprise Parameters.
Step 2
Scroll to the CCMAdmin Parameters area of the window.
Step 3
From the Enable Dependency Records drop-down menu, choose True.

A dialog box displays a message about the consequences of enabling the
dependency records. Read the information carefully before clicking OK.
Step 4
Click OK. The field displays True.
Step 5
Click Update.
Step 6
Close the browser that you are using; then, reopen the browser. This action makes
the parameter take effect for the entire system.
4-79
To delete a softkey template, choose Device > Device Settings > Softkey Template from
Cisco CallManager Administration. Then choose the template that you want to delete and click
Delete.
4-80
Call Park, Call Pickup, and Cisco Call Back
This topic discusses how to configure Call Park, Call Pickup, and Cisco Call Back.
Call Park Configuration
Ensure that Call Park number or range is unique within the cluster
and that each Cisco CallManager that devices are registered to has
its own unique Call Park number or range.
CIPT1 v4.14-17
The Call Park feature allows you to put a call on hold so that it can be retrieved from another
telephone in the Cisco CallManager cluster. (For example, you can park a call in your office
and retrieve it in a conference room.)
If you are on an active call on your telephone, you can park the call to a Call Park extension by
pressing the Park softkey or the Call Park button. Someone (or you) on another phone in your
system can then dial the Call Park extension to retrieve the call.
A Call Park number or range must be configured for each Cisco CallManager in the cluster.
When you invoke the Call Park feature, it is assigned a Call Park code. A user uses this code to
pick up the call from another Cisco IP Phone on the same Cisco CallManager that the original
IP Phone is registered to. When you assign the Call Park number or range to a partition, you
can limit access to the Call Park feature based on the device calling search space. You should
ensure that the Call Park number or range is unique throughout the Cisco CallManager cluster.
Access the Call Park feature by choosing Feature > Call Park.
Example: Call Park Feature in Department Store

The ABC Department Store, which has an overhead paging system, is using the Call Park
feature. A call for an employee on the floor comes in to a cashier desk. The cashier can park the
call and announce the Call Park code on the overhead paging system, and the employee on the
floor can pick up the call by using the Call Park code on a nearby telephone.
4-81
Call Pickup and Group Call Pickup

Call Pickup
Pickup
Group A
Group Call Pickup
Group B
GPickup,
dials call
pickup
group
number
Group C
Call PickupAllows users to pick up incoming calls within their own

group.
Cisco CallManager automatically dials the appropriate call pickup
group number when the user presses Pickup.
Group Call PickupAllows users to pick up incoming calls in
another group.
User must dial the appropriate call pickup group number when
user presses GPickup.
CIPT1 v4.14-18
The purpose of Call Pickup is to enable a group of users who are seated near each other to
cover incoming calls as a group. When a member of the group receives a call and is not
available to answer it, any other member of the group can pick up the call from his or her own
phone.
Three types of Call Pickup exist:
Call Pickup: Enables users to pick up incoming calls on any telephone within their own
group. When the users press the Call Pickup button or PickUp softkey, Cisco CallManager
automatically dials the appropriate Call Pickup number.
Group Call Pickup: Enables users to pick up incoming calls on any telephone within their
own group or in another group. Users press the Group Call Pickup button or GpickUp
softkey and dial the appropriate group number for Call Pickup. (The reason that users
manually enter a number with Group Call Pickup but not with Call Pickup is because more
than one group can exist and Cisco CallManager needs to know which one to dial. With
Call Pickup, in effect, there is only one number corresponding to one group.)
Other Group Call Pickup: Allows users to pick up incoming calls in a group that is
associated with their own group. This type of call pickup is covered in the next subtopic.
4-82
Other Group Call Pickup

OPickup
Group B
Group A
Group C
Group C is associated
with Group A and B.
Allows users to pick up incoming calls in a group that is associated

with their own group.
Cisco CallManager automatically searches for the incoming call in
the associated groups to make the call connection when the user
activates this feature.
Use the softkey OPickup.
CIPT1 v4.14-19
Cisco CallManager Release 4.1 added support for Other Group Call Pickup. Other Group Call
Pickup allows users to pick up incoming calls in a group that is associated with their own
group. Cisco CallManager automatically searches for the incoming call in the associated groups
to make the call connection when the user activates this feature from a Cisco IP Phone. Use the
softkey OPickup for this type of Call Pickup.
When more than one associated group exists, the priority of answering calls for the associated
group goes from the first associated group to the last associated group. For example, groups A,
B, and C associate with group X, and the priority of answering calls goes to group A, then B,
and then C.
Usually, within the same group, the longest alerting call (longest ringing time) is picked up first
if multiple incoming calls occur in that group. For Other Group Call Pickup, priority takes
precedence over the ringing time if multiple associated pickup groups are configured.
Both the idle and off-hook call states make the three softkeys Pickup, GPickup, and OPickup
available.
4-83
Call Pickup Configuration
Configure a unique
Call Pickup number.
CIPT1 v4.14-20
To configure Call Pickup, you must first add and configure the Call Pickup number and then
assign the number to the desired DNs.
Follow this procedure to add a Call Pickup number and group in Cisco CallManager
Administration.
4-84
Step 1
Choose Feature > Call Pickup.
Step 2
In the upper-right corner of the window, click the Add a New Call Pickup Number
link.
Step 3
The Pickup Group Configuration window displays.
Step 4
Enter a unique pickup group name and unique pickup group number.
Step 5
Assign the pickup group to a route partition as desired.
Step 6
Click Insert to save the new call pickup group number in the database.
Call Pickup Configuration (Cont.)
Assign the Call

Pickup number
to a line or DN.
CIPT1 v4.14-21
After you add the Call Pickup group in Cisco CallManager, assign the group to the desired line
from the Directory Number Configuration window.
AutoCall Pickup
Automates Call Pickup, Group Call Pickup, and Other Group

Call Pickup by setting the service parameter Auto Call Pickup
Enabled to True.
Cisco CallManager automatically connects users to the
incoming call in their own pickup group, in another pickup
group, or in a pickup group that is associated with their own
group after users press the appropriate softkey.
CIPT1 v4.14-22
You can automate Call Pickup, Group Call Pickup and Other Group Call Pickup by setting the
service parameter Auto Call Pickup Enabled to True. (Choose Service > Service Parameters,
and choose the publisher server and Cisco CallManager for the service.)
When this parameter is enabled, Cisco CallManager automatically connects users to the
incoming call in their own pickup group, in another pickup group, or in a pickup group that is
4-85
associated with their own group after users press the appropriate softkey on the phone. This
action reduces keystrokes.
Automated Call Pickup connects the user to an incoming call in the users own group. When
the user presses the Pickup softkey on the phone, Cisco CallManager locates the incoming call
in the group and completes the call connection. If automation is not enabled, the user must
press the softkeys Pickup and Answer to make the call connection.
Automated Group Call Pickup connects the user to an incoming call in another pickup group.
The user presses the GPickup softkey on the phone, then dials the DN of the other pickup
group. Upon receiving the DN, Cisco CallManager completes the call connection. If
automation is not enabled, the user must press the softkeys GPickup and Answer and dial the
DN of the other pickup group to make the call connection.
Automated Other Group Call Pickup connects the user to an incoming call in a group that is
associated with the users own group. The user presses the OPickup softkey on the phone. The
Cisco CallManager automatically searches for the incoming call in the associated groups in the
sequence that the administrator entered in the Pickup Group Configuration window and
completes the call connection after the call is found. If automation is not enabled, the user must
press the softkeys OPickup and Answer to make the call connection.
4-86
Cisco Call Back
Receive call-back notification when a called party

becomes available
CIPT1 v4.14-23
The Cisco Call Back feature allows you to receive call-back notification on your Cisco IP
Phone when a called-party line becomes available. To receive call-back notification, a user
presses the CallBack softkey upon receiving a busy or ringback tone. You can activate
call-back notification on a line on a Cisco IP Phone within the same Cisco CallManager cluster
as your telephone. You cannot activate call-back notification if the called party has forwarded
all calls to another extension (Call Forward All [CFA] feature).
Cisco Call Back requires Cisco CallManager Release 3.3 or later and a Cisco IP Phone that
supports softkeys (Cisco IP Phone 7970, 7960 or 7940).
The telephone states that support Cisco Call Back are Busy, Call Forward Busy, or No Answer.
The No Answer state could include Call Forward No Answer to a voice-mail system or to
another extension.
To configure Cisco Call Back, choose the softkey template (for example, the Standard User
template), copy and insert the template, and name it something appropriate, such as Standard
User Callback. Next, configure the softkey layout by choosing the On Hook call state and the
CallBack option. Then, choose Ring Out, include the CallBack option by making sure that it is
at the top of the list, and click Update.
Example: Cisco Call Back

IP Phone user A calls IP Phone user B in the same cluster. If IP Phone B is busy or there is no
answer, IP Phone user A activates the Cisco Call Back feature through the CallBack softkey.
When IP Phone B becomes available, IP Phone A receives an audible alert and visual
notification that the DN is available. Cisco CallManager remembers the dialed number, so IP
Phone user A can then press the Dial softkey to reach IP Phone user B.
4-87
Barge and Privacy
This topic discusses how to configure Barge and Privacy settings.
Barge and Privacy Overview

Barge: Users can add themselves to remotely active calls
on shared line.
Barge uses built-in conference bridge; cBarge uses
shared conference bridge.
Privacy: Users can allow or disallow other users on shared
line to view call information or to use Barge or cBarge.
Barge Process
Initiator
Media
Media
Target
Other Party
1. Original two-party call

2. Initiator barges into the call
three-way call
If initiator hangs up, original call remains active.

If target hangs up, initiator and other party connect point-to-point.
If other party hangs up, original call and barged call get released.
CIPT1 v4.14-24
The Barge feature allows a user to add himself or herself to an existing call on a shared line
Two types of Barge are available in Cisco CallManager Release 4.0:
Barge using built-in conferenceBarge softkey: Barge uses the built-in conference
capability of the target IP Phone. Barge also uses the Standard User or Standard Feature
softkey template (both contain the Barge softkey). When a Barge is being set up, no media
interruption occurs and the only display change to the original call is a spinning circle that
is displayed at the right side of the prompt status message window at the target device.
Barge using shared conferencecBarge softkey: Conference Barge (cBarge) uses a
shared conference bridge. No standard softkey template includes the cBarge softkey. To
allow users to access the cBarge softkey, the administrator must add it to a nonstandard
softkey template and then assign the softkey template to a device.
When you press the cBarge softkey, a Barge call is set up by means of the shared
conference bridge, if it is available. The original call is split and then joined at the
conference bridge, which causes a brief media interruption. The call information for all
parties changes to Barge. The barged call becomes a conference call with the Barge target
device as the conference controller. The conference controller can add more parties to the
conference or can drop any party.
When only two parties are left in the conference, they experience a brief interruption and
then are reconnected as a point-to-point call, which releases the shared conference
resources.
4-88
When the initiator uses Barge to join the call, it becomes a three-way call. If the initiator hangs
up, the original call remains active. If the target hangs up, the caller who used Barge and the
other party connect in a point-to-point call. If the other party hangs up, the original call and the
barged call are released.
The Privacy feature was introduced in Cisco CallManager Release 4.0. With Privacy,
administrators can enable or disable the ability of users with telephones that share the same line
(DN) to view call status and to barge the call. Administrators enable or disable Privacy for each
telephone.
The Barge and Privacy features have some restrictions, including the following:
Built-in Barge supports a three-way Barge maximum, G.711 voice, and the Cisco IP Phone
7940, 7960, and 7970 models .
Barge and Privacy require Cisco CallManager Release 4.0.
Shared Line Appearance
Same DN on more than one device in same partition

CIPT1 v4.14-25
Barge requires a shared line appearance. Cisco CallManager considers a DN on more than one
device in the same partition to be a shared line appearance. One example of a shared line
appearance is where a DN appears on line 1 of a manager telephone and also on line 2 of an
assistant telephone. Another example of a shared line would be a single incoming 800 number
that is set up to appear as line 2 on every help desk telephone in an office.
These guidelines are helpful when using shared line appearances with Cisco CallManager:
You can create a shared line appearance by assigning the same DN and partition to
different lines on different devices.
If other devices share a line, the words Shared Line are displayed in red next to the DN in
the Directory Number Configuration window in Cisco CallManager Administration.
If you change the calling search space, call waiting, or call forward and pickup settings on
any device that uses the shared line, the changes are applied to all of the devices that use
that shared line.
4-89
To stop sharing a line appearance on a device, you can change the DN or partition number
for the line and update the device. (Deletion removes the DN on the current device only.
The deletion does not affect the other devices.)
Do not use shared line appearances on any Cisco IP Phone that will be used with the
Attendant Console.
Do not use shared line appearances on any Cisco IP Phone 7960 that requires the Auto
Answer capability.
Barge Configuration
Or
Enable at Device Level
Enable Cluster-Wide
CIPT1 v4.14-26
To configure Barge with built-in conference bridge, follow these steps:
4-90
Step 1
Assign the Standard User or Standard Feature softkey template (both contain the
Barge softkey) to each device that accesses Barge by using the built-in conference
bridge.
Step 2
To enable Barge cluster-wide for all users, choose Service > Service Parameters
for the Cisco CallManager service and set the Built-In Bridge Enable cluster-wide
service parameter to On. Alternatively, configure Barge for each telephone by
setting the Built-In Bridge field in the Phone Configuration window on the device
itself.
Step 3
Set the Party Entrance Tone to True if you desire tones when a Barge occurs.
Privacy Configuration
Enable Cluster-Wide
Enable at Device Level
Or
..
.
..
.
Privacy Disabled
Privacy Enabled
The Barge key will not appear on

the shared line.
CIPT1 v4.14-27
Recall that when Privacy is enabled, users on a shared line can enable or disable the capability
of other users on the shared line to view call status and to barge the call.
To configure Privacy, follow these steps:
Step 1
Note
Set the optional Privacy Setting cluster-wide service parameter to True.

Do not set this parameter if only a few users need access to Privacy (see Step 3).
Step 2
For each phone button template for which you want to enable Privacy, add Privacy
to one of the feature buttons.
Step 3
For each telephone user who wants to enable Privacy, choose On in the Privacy
drop-down menu in the Phone Configuration window. If you have configured
Privacy cluster-wide, you can leave the Privacy setting at Default or set it to Off to
selectively disable privacy.
Step 4
For each telephone user who wants to enable Privacy, choose the phone button
template that contains the Privacy feature button that you created in Step 2.
Shown in the figure is the phone display when the Privacy feature is assigned to a feature
button. When Privacy is enabled, the Privacy button changes displaya black circle appears
inside the Privacy field. Now, when the other user on the shared line goes off hook on the
shared line, the Barge softkey does not appear.
4-91
This topic discusses the Cisco IP Phone Services feature that is available in Cisco CallManager.

include XML
applications that display
interactive content.
Service
URL
Button
Two ways to access

services:
Button labeled
Services to access a
menu of services
Services
Button
Preconfigured phone
button to access a
specific service
CIPT1 v4.14-28
Cisco IP Phone Services include Extensible Markup Language (XML) applications that enable
the display of interactive content with text and graphics on Cisco IP Phone 7970, 7960, 7940,
7912, and 7905 models.
Note
Cisco IP Phones 7912 and 7905 support only text-based XML applications.
Using the Cisco IP Phone, you can deploy customized client services that users can interact
with from the keypad, softkeys, or a rocker key and can use to display helpful information on
the IP Phone.
A user can access a service from the supported phone model in two ways. The user can press
the button labeled Services use a preconfigured phone button. When a user presses the Services
button on a Cisco IP Phone 7940, 7960, or 7970, a session is initiated and a menu of services
that are configured for the telephone appears. When the user selects a service from the listing,
the telephone display is updated.
In addition to adding a service so that it is available to users on their telephones, you can assign
the service to a phone button that is configured as a service URL button. This option gives the
user one-button access to the service without using the Services button on the IP Phone. With
Cisco CallManager Release 4.0 or later, you can use any line or speed dial button for one-touch
access to selected XML services such as MyFastDials or to access critical XML applications
such as those that check inventory levels.
4-92
The following list provides examples of services that can be supplied to Cisco IP Phones:
Conference room scheduler
E-mail and voice-mail messages list
Daily and weekly schedule and appointments
Personal Address Book entries
Weather reports
Company news
Flight status
You can create customized Cisco IP Phone applications for your site by using the Cisco IP
Phone Services Software Development Kit (Cisco XML SDK).
Users can subscribe only to services that are configured through Cisco CallManager
Administration.
Note
For information about the Cisco XML SDK, refer to these links:
http://www.cisco.com/go/developersupport/
http://www.cisco.com/pcgi-bin/dev_support/access_level/product_support
(registered Cisco.com users)
http://www.cisco.com/warp/public/cc/pd/unco/ippps/
IP Phone Services Configuration
Update parameters to IP address if not using DNS

CIPT1 v4.14-31
You can add services to Cisco CallManager by using the Cisco IP Phone Services
Configuration window. After services are configured in Cisco CallManager Administration,
users or administrators can subscribe to these services for the devices that they have access to.
4-93
Add an IP Phone Service

To add an IP Phone Service, complete the following steps:
Step 1
Choose Feature > Cisco IP Phone Services.
Step 2
In the upper-right corner of the window, click the Add a New IP Phone Service
link.
The Cisco IP Phone Services Configuration window is displayed.
Step 3
Enter the appropriate settings. This list describes the information that must be
configured for each service:
Service name: Enter the name of the service as it will be displayed on the menu
of available services in the Cisco IP Phone User Options application. Enter up to
32 characters for the service name.
Service description (optional): Enter a description of the content that the
service provides to help users decide whether they want to subscribe to the
service. (This parameter is not shown in the figure because the service has
already been added.)
Service URL: Enter the URL of the server where the Cisco IP Phone Services
application is located. Make sure that this server remains independent of the
servers in your Cisco CallManager cluster. Do not specify a Cisco CallManager
server or any server that is associated with Cisco CallManager (such as a TFTP
server or directory database publisher server).
Character set: If you are using a language other than English for the service
name or description, choose the character set for that language.
Step 4
To add the service, click Insert.
Add the Service URL to a Phone Button

To add the service URL button to an IP Phone, follow these steps after you add the service to
Cisco CallManager:
4-94
Step 1
Customize a phone button template by configuring a Service URL button.
Step 2
Add the customized phone button template to the telephone.
Step 3
Choose Device > Phone.
Step 4
To locate a specific telephone, enter the search criteria and click Find.
Step 5
Choose the telephone to which you want to add a service URL button.
Step 6
On the upper-right side of the window, click the Add/Update Service URL Buttons
link.
Step 7
From the Service drop-down menu, choose the service that you want to add to the
telephone.
Step 8
To add the service to the telephone button, click Update, or click Update and Close
to add the service to the phone button and return to the Phone Configuration
window.
Cisco IP Phone Services Examples

Meeting Room
Scheduler
World
Clock
Weather
Yellow Pages
Lookup
Flight Status
Stock Tracker
Transit
Schedules
CIPT1 v4.14-30
Here are some examples of services that you can access from your Cisco IP Phone:
Weather check
Yellow pages telephone number lookup
Mass transit schedules
Stock ticker check
Flight status
Meeting room scheduler
World clock
4-95
Services Phone Display Examples
Menu
Text
Image
Directory
Input
Graphical
CIPT1 v4.14-29
Here is a list of typical Cisco IP Phone Services displays:

Menu: The menu enables the user to scroll through a list of menu items and make choices.
Text: The text from a web page can be delivered for the user to view.
Input: Input enables the user to enter information using the keypad.
Image: Cisco IP Phone Services can deliver images in black and white and in shades of
gray. Color images are available over Cisco IP Phones with a color display.
Directory: Cisco IP Phone Services can deliver a corporate directory to enable users to
conveniently locate and dial other employees.
Graphical: Cisco IP Phone Services can display graphics as well as text.
4-96
Summary
Summary
Cisco CallManager core features include hold,
redial, and transfer.
Cisco CallManager enhanced features include Call
Join, multiple calls per line appearance, and
Immediate Divert.
There are five standard softkey templates.
Nonstandard softkey templates can be created by
modifying one of the five standard softkey
templates.
CIPT1 v4.14-32
Summary (Cont.)
Call Park enables a call to be picked up on a
different phone than the one it came in on. Call
Pickup enables users to cover incoming calls as a
group. Cisco Call Back allows a user to receive
call-back notification when a called-party line
becomes available.
Barge adds a user to a call that is already in
progress. Privacy enables or disables the ability to
barge or view call status.
Cisco IP Phone Services enable the display of
interactive content with text and graphics on Cisco
IP Phones.
CIPT1 v4.14-33
4-97
References
Cisco Systems, Inc. Cisco CallManager Features and Services Guide, Release 4.1(3).
3/ccmfeat/index.htm
3/ccmcfg/index.htm
Cisco Systems, Inc. The Help files within Cisco CallManager Administration.
4-98
Lesson 4-4
Configuring User Features

Part 2
Overview
Administrators need to have a working knowledge of the various options that are available for
Cisco IP Phones to ensure that all of the desired features and functions are available to users
and that they are properly configured. This lesson, the second of two parts on features,
discusses many Cisco IP Phone features that are available to users in a Cisco IP telephony
solution. The lesson includes a discussion of Cisco CallManager Extension Mobility, Call
Display Restrictions, Forced Authorization Codes (FAC), Client Matter Codes (CMC),
Malicious Call Identification (MCID), and Multilevel Precedence and Preemption (MLPP)
features.
Objectives
Upon completing this lesson, you will be able to configure and use many user Cisco IP Phone
features, including Cisco CallManager Extension Mobility, Call Display Restrictions, FAC,
CMC, and MCID. This ability includes being able to meet these objectives:
Configure Cisco CallManager Extension Mobility to enable users to log in to any Cisco IP
Phone and obtain their default device profiles
Configure FAC and CMC to manage call access and accounting
Configure Call Display Restrictions to selectively allow or restrict the display of calling- or
connected-line information
Configure MCID to report a call of a malicious nature
Describe the purpose of MLPP
This topic describes how to configure the Cisco CallManager Extension Mobility feature to
enable users to log in to any Cisco IP Phone and obtain their default device profiles.

Overview
Log on to a Cisco IP Phone 7940
or 7960 in a Cisco CallManager
cluster to get extension
Device profile includes:
extension, services, class of
service restrictions applied to
IP Phone
Login modes:
Auto-logout other
IP Phones
Keep login on other IP
Phones
Logout modes:
IP Phone
Services
CRA
Server
Single
Cluster
IP LAN
User Office
IP Phone 7960
(x5000)
LDAP
Directory
7960
User Logged On to Phone
(Device Profile with x5000)
Explicit logout at IP Phone

Timed logout
CIPT1 v4.14-3
Cisco CallManager Extension Mobility is an approach to organizing work environments so that

workspaces including offices, cubicles, and desksare not permanently assigned to
individuals. Instead, employees check into an office space by performing a login process at
the Cisco IP Phone where they wish to receive their calls. Following the login, the IP Phone is
assigned the appropriate direct telephone number with all of its characteristics (ring type, speed
dialing, and so on). Environments where employees do not routinely conduct business in the
same office space every day, such as sales offices, commonly use Cisco CallManager
Extension Mobility. It is often referred to as hoteling.
Cisco CallManager provides a standard login service. The login service may be expanded by
using a set of Extensible Markup Language (XML) requests over HTTP. Third parties
(including customers and integrators) can replace the login user interface with one of their own
design. For example, capabilities may be added to the standard login service such as
authenticating via smart card readers or automating the login process according to a desk
sharing web application.
The Cisco CallManager Extension Mobility feature provides a configuration parameter that
defines how the system behaves when a user tries to log in to two devices at the same time. For
example, the system may not allow the second login, or the system may allow the second login
after the first login is automatically logged out.
Because Cisco CallManager Extension Mobility is enabled by XML-based services, it is
available only on Cisco IP Phones.
4-100

Example
ADP000011112222
Terry
7000
1111
Autogenerated
Device Profile
7001
Logout
Login
SEP000011112222
Terry logs in to device SEP000011112222:

When a login is executed, the current configuration of a device is
replaced by a particular user device profile.
When a logout is executed, the current configuration of a device
(the user device profile) is replaced by the default device profile.
CIPT1 v4.14-4
Shown in the figure is an Cisco CallManager Extension Mobility example.

Terry has configured a user device profile called Terry. This profile has a line appearance with
a directory number (DN) of 7000 and another with a DN of 7001. Terry is logging into device
SEP000011112222, which has an autogenerated device profile, ADP000011112222, as its
default device profile. The default device profile is configured with a single-line appearance
with the DN of 1111.
When Terry logs in, the device restarts and displays lines 7000 and 7001. It no longer has line
1111 assigned to it. All of the speed dials and services configured on Terry replace those that
are normally on SEP000011112222.
When Terry logs out, the device restarts and loads the autogenerated device profile.
4-101
Extension Mobility Configuration Overview

1. Set the Extension Mobility Service parameters.
2. Add Device Profile Default for a Cisco IP Phone
model.
3. Add a device profile for a user.
4. Add a new user.
CIPT1 v4.14-5
Using the Cisco CallManager Serviceability tool Service Activation, activate the Cisco
CallManager Extension Mobility service.
Using the Tomcat Manager window, stop and start the Cisco CallManager Extension Mobility
service at http://<Cisco Extension Mobility server>/manager/list, where Cisco Extension
Mobility server specifies the IP address of the server that has the Cisco CallManager Extension
Mobility service running on it.
When the service is activated, configure the following elements to enable Cisco CallManager
Extension Mobility:
Cisco CallManager Extension Mobility service parameters
A device profile for a Cisco IP Phone model
A device profile for a Cisco IP Phone user
A new user
To avoid problems with deploying Cisco CallManager Extension Mobility, be sure to follow
these configuration guidelines:
Configure a device profile default for each Cisco IP Phone model in a cluster that you want
to support Cisco CallManager Extension Mobility.
If you want to enable all IP Phones within a Cisco CallManager cluster with Cisco
CallManager Extension Mobility, do not allow the users to control these telephones.
4-102
In this scenario, when users go to their Cisco CallManager User Options web page
to change their services, they must choose Device Profiles from the Select a Device
to Configure drop-down list. They cannot control an individual IP Phone or modify
the settings for an individual IP Phone.
As administrator, you can change the services for an IP Phone by using Cisco
CallManager Administration. After making the changes, if you update the
configuration using the main menu (not the popup menu), you must reset the IP
Phone for the changes to take effect. This action ensures that the new snapshot is
stored as the logout profile.
If a particular user controls a device, for example, the users office telephone, do not allow
anyone else to log in to that device.

Service Parameters Configuration
CIPT1 v4.14-6
The figure shows the service parameters for the Cisco CallManager Extension Mobility service.
To access this window, choose Service > Service Parameters and from the Service drop-down
menu, choose Cisco Extension Mobility. The following table defines the settings in the
Service Parameters Configuration window.
4-103
Service Parameters
Parameter
Description
Enforce Maximum Login Time
When set to True, this parameter enforces a maximum login

time. If set to False, no time limit is set on logins.
Maximum Login Time

(Hours:Minutes)
This parameter is the maximum amount of time a user is

allowed to remain logged in to a device. The maximum
allowable value is 168:00, entered as HHH:MM. Note that :MM
is also an acceptable format for durations under 1 hour. This
parameter is ignored if the Maximum Login Time parameter is
set to False.
Maximum Concurrent Request
This parameter specifies the maximum number of login or

logout operations that can occur simultaneously. This maximum
prevents the Cisco CallManager Extension Mobility service from
consuming excessive system resources.
Multiple Login Behavior
This parameter specifies the behavior for multiple attempted

logins by the same user on different devices. The choices are to
allow, not to allow, and to cause a previous login to
automatically log out.
Alphanumeric User ID
Choose True to allow Cisco CallManager to accept

alphanumeric Cisco CallManager Extension Mobility logins or
False to force numeric logins only.
Remember the Last User Logged In
When set to True, this parameter remembers the last user to

log in.
Device Profile Default Configuration for the

Cisco IP Phone 7960
CIPT1 v4.14-7
The figure shows a configuration example of the device profile default for the Cisco IP Phone
7960.
4-104
The device profile default is a cluster-wide default used for each Cisco IP Phone that will be
supported by Cisco CallManager Extension Mobility. The IP Phone takes on the device profile
default whenever a user logs in to an IP Phone model for which the user has no device profile.
To access this window, from the Cisco CallManager Administration, choose Device > Device
Settings > Device Profile Default. From the left column, click the device profile, or if adding a
new profile, click Add a New Device Profile Default.
If you do not choose an audio source in the User Hold Audio Source field, Cisco CallManager
uses the audio source that is defined in the device pool. If the device pool does not specify an
audio source ID, the system default is used.
The User Locale field identifies a set of detailed information to support users, including
language and font. Cisco CallManager makes this field available only for IP Phone models that
support localization.
The phone button template determines the configuration of the softkeys on Cisco IP Phones.
User Device Profile Creation
CIPT1 v4.14-8
The user device profile must be configured for use with Cisco CallManager Extension
Mobility. The user device profile contains attributes such as name, description, phone button
template, expansion modules, directory number, subscribed services, and speed-dial
information.
To access this window from Cisco CallManager Administration, choose Device > Device
Settings > Device Profile. To add a new user device profile, choose Add a New User Device
Profile.
4-105
New User Configuration
CIPT1 v4.14-9
New users must be configured before they can use Cisco CallManager Extension Mobility. To
add a new user for Cisco CallManager Extension Mobility, follow these steps:
4-106
Step 1
In Cisco CallManager Administration, choose User > Add a New User.
Step 2
In the Add A New User window, enter the first name, last name, and username.
Step 3
In the User Password and Confirm Password fields, enter a password.
Step 4
In the PIN field, enter a numeric personal identification number (PIN). Confirm the
PIN.
Step 5
Enter the user telephone number.
Step 6
Check the check boxes for Enable CTI Application Use, Call Park Retrieval
Allowed, and Enable Calling Party Number Modification if you want to enable
those features. See the User Configuration Settings table that follows for more
information.
Step 7
Click Insert, and the window refreshes. From the left pane, choose Cisco Extension
Mobility.
User Configuration Settings

Field
Description
Enable CTI Application Use
Configures users so they can use computer telephony integration

(CTI) applications.
Call Park Retrieval Allowed
Configures users so they can retrieve parked calls.
Enable Calling Party Number

Modification
Choose this field to allow an application such as Cisco Emergency

Responder to change the calling number when initiating a feature
request from an application programming interface (API). Refer to
the Cisco Emergency Responder documentation for more
information.
4-107
Client Matter Codes and Forced Authentication

Codes
This topic discusses the uses, operation, and configuration of the Client Matter Codes (CMC)
and Forced Authentication Codes (FAC) features.
Client Matter Codes and

Forced Authorization Codes
CMC: Forces the user to enter a code to
specify that the call relates to a specific
client matter
Allows for billing and tracking of
calls made
Generates Call Detail Records
FAC: Forces the user to enter a valid
authorization code before the call
completes
Prevents unauthorized user from
making toll calls
Can be combined with time-of-day
routing to require an authorization
code for call completion between
certain times
CIPT1 v4.14-10
FAC and CMC allow you to manage call access and accounting. (Client matter codes are often
referred to as account codes.) CMC assists with call accounting and billing for billable clients,
while FAC regulates the types of calls that certain users can place.
The CMC feature benefits law offices, accounting firms, consulting firms, and other businesses
or organizations that need to track the length of the call for each client. To use the CMC
feature, users must enter a client matter code to reach certain dialed numbers.
You can use FAC for colleges, universities, or any business or organization when limiting
access to specific classes of calls proves beneficial. Likewise, when you assign unique
authorization codes, you can determine which users placed calls.
4-108
Forced Authorization Code Basic Call

Route Pattern
9.5622XXX
Require
Authorization Code
1. Dial number that goes to a

FAC-enabled route pattern
2. Cisco Cisco CallManager tells

phone to play tone
Authorization Level
3. User enters authorization

code plus #
4. Call extended to the route
pattern
5. Generate CDR
User A
CIPT1 v4.14-11
For each user, you specify an authorization code, then you enable FAC for relevant route
patterns by checking the appropriate check box and specifying the minimum authorization level
for calls through that route pattern.
When you enable FAC through route patterns in Cisco CallManager Administration, users must
enter an authorization code to reach the intended recipient of the call. When a user dials a
number that is routed through a FAC-enabled route pattern, the system plays a tone that
prompts for the authorization code.
In Cisco CallManager Administration, you can configure various levels of authorization. If the
user authorization code does not meet the level of authorization that is specified to route the
dialed number, the user receives a reorder tone. If the authorization is accepted, the call is
placed. The name of the authorization writes to Call Detail Records (CDRs), so you can
organize the information by using CDR Analysis and Reporting (CAR), which generates
reports for accounting and billing.
To implement FAC, you must devise a list of authorization levels and corresponding
descriptions to define the levels. You must specify authorization levels in the range of 0 to 255.
Cisco allows authorization levels to be arbitrary, so you define what the numbers mean for your
organization. For example, you could configure authorization levels as follows:
Configure an authorization level of 10 for interstate long-distance calls in North America.
Because intrastate calls often cost more than interstate calls, configure an authorization
level of 20 for intrastate long-distance calls in North America.
Configure an authorization level of 30 for international calls.
Note
FAC primarily relates to preventing toll fraud and is covered in more detail in the Securing
IP Telephony module of the Cisco IP Telephony Part 2 (CIPT2) course.
4-109
CMC Basic Call: Call Completion

Route Pattern
8.@
Require Client
Matter Code
Code
1234
1. Dial number that goes to

CMC-enabled route pattern
2. Cisco CallManager tells
phone to play tone to invoke
CMC
3. User enters code number
4. Call extended
5. Generate CDR for billing
User A
CIPT1 v4.14-12
You enable or disable CMC through route patterns, and you can configure multiple client
matter codes. When a user dials a number that is routed through a CMC-enabled route pattern,
a tone prompts the user for the client matter code. When the user enters a valid code, the call is
placed; if the user enters an invalid code, a reorder tone is played. CMC writes to the CDR, so
you can collect the information by using CAR, which generates reports for client accounting
and billing.
The figure shows a basic CMC call where the route pattern 8.@ is configured to require the
user to enter a client matter code.
Step 1
When the user dials 8-214-555-0134, the dialed string matches the 8.@ route
pattern.
Step 2
Cisco CallManager plays a zip-zip tone to prompt the user to enter the client
matter code associated with the dialed string, in this example, 1234.
Step 3
If the user enters 1234, the call is extended to the voice gateway. If the user does not
enter a code or enters the wrong code, the user hears a reorder tone, and the call is
not extended.
Note
4-110
The pound sign (#) at the end of the client matter code cancels the interdigit timeout. If users
do not append the # to the authorization code or client matter code, the system waits for the
T302 timer to extend the call (System > Service Parameters for the Cisco CallManager
service). The default for the T302 timer is 15 seconds.
Step 4
Because the user entered a valid code, Cisco CallManager extends the call to the
voice gateway for call completion.
Step 5
Cisco CallManager generates a CDR with the associated client matter code for
client-tracking and reporting purposes.
CMC and FAC can be implemented together for a given route pattern. For example, you can
allow only certain users to have authorization to place certain long-distance calls, and then
require the user to enter a CMC for that call. The tones for CMC and FAC sound the same to
the user, so the feature tells the user to enter the authorization code after the first tone and enter
the account code after the second tone.
CMC Basic Call: Call Failure

Route Pattern
8.@
Require Client
Matter Code
Code
1234
1. Dial number that goes to a

CMC-enabled route pattern
2. Cisco CallManager tells phone
to play tone to invoke CMC
3. User enters invalid CMC
number
4. User receives reorder tone
User A
CIPT1 v4.14-14
Shown in the figure is an example where the client matter code is 1234, but the user enters
5555#. Because 5555# is not a valid code, Cisco CallManager rejects the call and the user
receives a reorder tone. If the user did not enter any code, CallManager would reject the call
and play a reorder tone after a 15-second timeout.
4-111
CMC Configuration
1. Document a list of client matters that you want to
track.
2. Insert the codes by using Cisco CallManager
Administration or by using Cisco Bulk
Administration Tool (BAT).
3. To enable FAC or CMC, add or update route
patterns in Cisco CallManager Administration.
4. Update dial-plan documents as necessary.
5. Provide codes to users and explain how the
feature works.
CIPT1 v4.14-15
To implement CMC, follow this procedure:

Step 1
Create a document with a list of client matter codes and associated client names that
you want to track.
Step 2
Insert the codes by using Cisco CallManager Administration or by using Cisco Bulk
Administration Tool (BAT).
Step 3
To enable FAC or CMC, add or update route patterns in Cisco CallManager

Administration.
Step 4
Update dial plan documents as necessary.
Step 5
Provide information to users and explain how the feature works; for example:
Provide the codes and client associations to users.
Inform users that dialing a number produces a tone that prompts for the codes.
Advise users of the types of calls that users can place without dialing a code.
Inform users that they can start entering the code before the tone ends.
Tell users to press # after entering the code to immediately route the call.
Note
4-112
Tell users that the IP Phone plays a reorder tone when the user enters an invalid code. If a
user misdials the code, the user must hang up and try the call again. If the reorder tone
persists, the user should notify the telephone or system administrator that a problem may
exist with the code.
Inserting Codes Using Cisco CallManager

Administration
CIPT1 v4.14-16
Complete the following steps to add client matter codes in Cisco CallManager Administration:
Step 1
In Cisco CallManager Administration, choose Feature > Client Matter Code.
Step 2
In the upper-right corner of the window, click the Add a New Client Matter Code
link.
Step 3
In the Client Matter Code field, enter a unique code of no more than 16 digits that
users will enter when placing a call. The client matter code displays in the CDRs for
calls that use this code.
Step 4
In the Description field, enter a name of no more than 50 characters. This optional
field associates a client code with a client.
Step 5
Click Insert.
Step 6
Repeat Step 2 through Step 4 to add all codes.
Step 7
After you add all client matter codes, enable the client matter codes for route
patterns.
4-113
Enabling CMC for Route Patterns

Route Pattern Configuration Window
Requires User
to Enter Client
Matter Code
When Dialing
This Route
Pattern
CIPT1 v4.14-17
Perform the following steps to enable client matter codes for route patterns:
Step 1
In Cisco CallManager Administration, choose Route Plan > Route/Hunt > Route
Pattern.
Step 2
Perform one of the following tasks:

To update an existing route pattern, enter search criteria in the Find and List
Route Pattern window, as described in Route Pattern Configuration in the
Cisco CallManager Administration Guide.
To add a new route pattern, refer to Route Pattern Configuration in the Cisco
CallManager Administration Guide.
Step 3
In the Route Pattern Configuration window, check the Require Client Matter Code
check box.
Step 4
Perform one of the following tasks:

If you updated the route pattern, click Update.
If you added a new route pattern, click Insert.
Step 5
4-114
Repeat Step 2 through Step 4 for all route patterns that require a client matter code.
CMC Restrictions and Interactions

Calls that are forwarded to a FAC- or CMC-enabled
route pattern fail because no user is present to
enter the code.
The FAC and CMC tones can be played only on

SCCP phones, TAPI/JTAPI ports, and MGCP FXS
ports.
If users do not end the FAC or CMC with #, the
system waits for the T302 timer to extend the call.
Users must reenter codes when pressing the Redial
softkey if the number is routed through a FAC- or
CMC-enabled route pattern.
FAC or CMC cannot be configured for speed-dial
buttons.
CIPT1 v4.14-18
Following are a few restrictions and interactions that you should be aware of. For a complete
list, review the Interactions and Restrictions section of the Cisco CallManager Features and
Services Guide, Release 4.1(3) at:
http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_1/sys_ad/4_1_3/cc
mfeat/fsfaccmc.htm#wp1046253
The CMC and FAC features work with all Cisco IP Phone models and Media Gateway
Control Protocol (MGCP)-controlled analog gateways.
Calls that are forwarded to a FAC- or CMC-enabled route pattern fail because no user is
present to enter the code. This limitation applies to call forwarding that is configured in
Cisco CallManager Administration or the Cisco CallManager User Options web pages.
You can configure call forwarding, but all calls that are forwarded to a FAC- or
CMC-enabled route pattern result in reorder. When a user presses the CFwdALL softkey
and enters a number that has FAC or CMC enabled on the route pattern, the user hears a
reorder tone, and call forwarding fails. Test a number before you configure call forwarding
to that number. If you dial a number and are prompted for an FAC or CMC, do not
configure call forwarding to that number. Advise users of this issue to reduce the number of
complaints that result from forwarded calls that do not reach the intended destination.
The FAC and CMC tones can be played only on Skinny Client Control Protocol (SCCP, or
Skinny) phones, Telephony Application Programming Interface/ Java Telephony
Application Programming Interface (TAPI/JTAPI) ports, and MGCP Foreign Exchange
Station (FXS) ports.
H.323 analog gateways do not support FAC or CMC because these gateways cannot play
tones. An IP Phone that routes calls through an H.323 gateway does not face this limitation,
which applies to analog phones.
If you do not append the # to the FAC or CMC, the system waits for the T302 timer to
extend the call.
4-115
When you press the Redial softkey on the IP Phone, you must enter the authorization code
or client matter code when the number that you dialed is routed through a FAC- or
CMC-enabled route pattern. Cisco CallManager does not save the code that you entered for
the previous call.
You cannot configure authorization codes or client matter codes for speed-dial buttons.
You must enter the code when the system prompts you to do so.
4-116
This topic discusses how to configure the Call Display Restrictions feature to selectively
display or restrict calling or connected line display information.
Selectively display or
restrict the line
display for the
originating party or
the called party
Hotel environment
frequently requires
this functionality
Requires Cisco
CallManager 4.1 or
later
Calls Between
Name and
Number Display
Room and front desk
Both
Room and room
Neither
Room and clubhouse Room sees

clubhouse only
External from PSTN
caller to front desk
Honor settings
of caller
CIPT1 v4.14-19
The Call Display Restrictions feature allows you to selectively display or restrict the calling
and connected (called party) line information. A hotel environment frequently requires this
functionality and might have the following needs,:
For calls between a guest room and the front desk, both the room and the front desk should
see the call information display of the other displayed.
For calls between guest rooms, the rooms should not see the call information of other
rooms displayed.
For calls between guest rooms and other hotel extensions (such as a clubhouse), only the
rooms should see the call information displayed.
For external calls from the public switched telephone network (PSTN) to the front desk or
guest rooms, the call information of the caller should not be displayed if the display settings
are restricted.
For all calls to the front desk, the call information of internal calls should be displayed.
In Cisco CallManager Release 4.0 and later, the calling-party and connected-party presentation
can be controlled by the configuration at the translation pattern level. Starting with Cisco
CallManager Release 4.1, this functionality was extended by adding a new setting at the device
level that enables the device to ignore the presentation settings of the other party for internal
calls.
4-117
Enabling Call Display Restrictions

Translation Pattern Parameters
Allows or restricts the
display of the calling
partys number and name
Allows or restricts the
display of the called partys
number or name
Phone Configuration or User
Device Profile Parameter
Ignores the presentation
restrictions of the remote
party for internal calls only
CIPT1 v4.14-20
To use Call Display Restrictions, perform the following Cisco CallManager configurations:
Step 1
Configure partitions and calling search spaces before you add a translation pattern.
Step 2
Configure translation patterns with different levels of display restrictions.
Step 3
Check the Ignore Presentation Restriction (Internal Calls Only) check box for IP
Phones such as lobby phones when you want to ensure that the call information
display for internal calls is always visible.
Step 4
Configure individual, associated translation patterns for each individual Call Park
directory number to work with the Call Park feature.
Calling Line ID Presentation

Cisco CallManager uses the Calling Line ID Presentation field information as a supplementary
service to allow or restrict display of the telephone number of the originating caller on a callby-call basis. Choose one of the following options to allow or restrict the display of the
telephone number of the calling party on the IP Phone display of the called party for this
translation pattern:
Default: This option does not change the presentation of the calling-party identification
information.
Allowed: Cisco CallManager allows the display of the calling-party number.
Restricted: Cisco CallManager blocks the display of the calling-party number.
If the incoming call goes through a translation pattern or route pattern and the Calling Line ID
Presentation setting is allowed or restricted, the system modifies the calling-line presentation
with the translation or route pattern setting.
4-118
Connected Line ID Presentation

Cisco CallManager uses the Connected Line ID Presentation field information as a
supplementary service to allow or restrict the display of the telephone number of the called
party on a per-call basis. Choose one of the following options to allow or restrict the display of
the telephone number of the connected party on the telephone of the calling party for this
translation pattern:
Default: This option does not change the presentation of the connected-line identification
information.
Allowed: Cisco CallManager allows the display of the connected-party number.
Restricted: Cisco CallManager blocks the display of the connected-party number.
If the incoming call goes through a translation or route pattern and the Connected Line ID
Presentation field is set to Allowed or Restricted, the system modifies the connected-line
presentation indicator with the translation or route pattern setting.
Ignore Presentation Indicators (Internal Calls Only)

To complete the configuration of the Call Display Restrictions feature, check the Ignore
Presentation Indicators (Internal Calls Only) check box from the Cisco CallManager
Administration Phone Configuration window.
For use with Cisco CallManager Extension Mobility, also configure this setting from the Cisco
CallManager Administration User Device Profile window.
When you set the Ignore Presentation Indicators (Internal Calls Only) option, the following
apply:
Cisco CallManager always displays the call information of the remote party if the other
party is internal.
Cisco CallManager does not display the call information of the remote party if the other
party is external and the display presentation is restricted.
4-119
Sample Configuration
Translation Pattern TP1:2XX
P_CallsFromRoomToRoom
CSS_Room {P_Room}
Calling Name/Line ID Restricted
Connected Name/Line ID Restricted
Room 1, 221
Translation Pattern TP2:0

P_CallsFromRoomToFrontDesk
CSS_FrontDesk {P_FrontDesk}
Connected Name/Line ID Allowed
Room 2, 222
P_Room
CSS_FromRoom
{P_CallsFromRoomToFrontDesk,
P_CallsFromRoomToRoom}
Front Desk, 100

P_FrontDesk
CSS_FromFrontDesk
{P_CallsFromFrontDeskToRoom}
CIPT1 v4.14-21
The functionality of the Call Display Restrictions feature is based on calls being routed through
different translation patterns before the calls are extended to the actual device. This process is
accomplished by creating various partitions and calling search spaces. A rule of thumb is that,
in the example of the hotel, all of the parties connected to a room will get the information as
restricted.
Shown in the figure is the sample configuration that will be used in the next three examples.
The setup for the examples is as follows:
Two translation patterns have been created, TP1 and TP2. TP1 is 2XX and covers dialing
the three-digit room extensions starting with 2. TP2 is 0 and covers dialing the front desk.
The following information pertains to TP1 (2XX):
TP1 is assigned to partition P_CallsFromRoomToRoom.
Calling search space CSS_Room contains partition P_Room.
The Calling Name Presentation and Calling Line ID Presentation options are set to
Restricted.
The Connected Name Presentation and Connected Line ID Presentation options are
set to Restricted.
The following information pertains to TP2 (0):
4-120
TP2 is assigned to partition P_CallsFromRoomToFrontDesk.
CSS_FrontDesk contains partition P_FrontDesk.
The Calling Name Presentation and Calling Line ID Presentation options are set to
Restricted.
The Connected Name Presentation and Connected Line ID Presentation options are
set to Allowed.
The following information pertains to room 1 at extension 221 and room 2 at extension
222:
Both belong to partition P_Room and calling search space CSS_FromRoom.
CSS_FromRoom contains partitions P_CallsFromRoomToFrontDesk and

P_CallsFromRoomToRoom.
The following information pertains to the front desk at extension 100:
The front desk belongs to partition P_FrontDesk and calling search space
CSS_FromFrontDesk.
CSS_FromFrontDesk contains partition P_CallsFromFrontDeskToRoom.
Example 1: Room Calling Room

TP1:2XX
P_CallsFromRoomToRoom
CSS_Room {P_Room}
Connected Name/Line ID Restricted
To Private
(Unknown Number)
Room 1, 221
Room 1
Dials 222
P_Room/221
CSS_FromRoom
From Private
(Unknown Number)
Room 2, 222
P_Room/222
CSS_FromRoom
Configure the calling line ID presentation and the connected line ID

presentation on the room-to-room translation pattern to Restricted to
ensure that the call information does not display.
CIPT1 v4.14-22
The figure shows an example where one room calls another room.
Step 1
Room 1 dials 222.
Step 2
Room 1 can access only P_CallsFromRoomToRoom (because of CSS_FromRoom).
Step 3
P_CallsFromRoomToRoom does not have 222 (room 2) but only 2XX.
Step 4
The call is routed to TP1:2XX, where the display of identification information is

restricted.
Step 5
TP1:2XX has access to P_Room (by virtue of CSS_Room).
Step 6
CSS_Room contains 222 (Room 2).
Step 7
The call reaches room 2, but TP1:2XX restricts the display of identification
information.
4-121
Example 2: Room Calling Front Desk

To Front Desk
(100)
Room 221
TP2: 0
P_CallsFromRoomToFrontDesk
CSS_FrontDesk {P_FrontDesk}
Connected Name/Line ID Allowed
221 Dials 0
P_Room/221
CSS_FromRoom
From Room 1
(221)
Front Desk
P_FrontDesk
CSS_FromFrontDesk
Set Ignore Presentation Indicators (Internal Calls Only) on

the front desk phone to override the room display
restrictions.
Enables the front desk to see the calling information of
internal calls.
CIPT1 v4.14-23
The figure shows an example where one room calls the front desk.
4-122
Step 1
Room 1 dials 0.
Step 2
Room 1 can access only P_CallsFromRoomToRoom (because of CSS_FromRoom).
Step 3
The call is routed to TP2:0, where the display of identification information is

restricted for the called party.
Step 4
TP2:0 has access to P_FrontDesk (by virtue of CSS_FrontDesk).
Step 5
CSS_FrontDesk contains 100 (the front desk).
Step 6
The call reaches the front desk.
Step 7
Although display of the originator identification information is set to Restricted,

because the Ignore Presentation Indicators (Internal Calls Only) check box was
checked on the front desk IP Phone and because the caller is internal, the front desk
can see the caller information.
Example 3: Call from PSTN to Front Desk

Calls Hotel over
the PSTN
External Caller
From Private
(Unknown Number)
P_FrontDesk
CSS_FromFrontDesk
"Ignore Presentation
Indicators (Internal Calls
Only) Enabled
Cisco CallManager does not display the remote party's

call information if the other party is external and the
display presentation is restricted.
CIPT1 v4.14-24
The figure shows an example of a call from the PSTN to the front desk.
A restricted call from the PSTN (off-net) reaches the front desk.
Even though the Ignore Presentation Indicators (Internal Calls Only) check box was checked,
because the originator is an off-net device (not internal) and has restricted the calling
information display, the front desk cannot see the caller information.
4-123
Malicious Call Identification
This topic discusses how to configure the Malicious Call Identification (MCID) feature in
Cisco CallManager so that users can report calls of a malicious nature.
MCID Overview
Allows a user who has
received a malicious
call from another
network to initiate a
sequence of events:
Notifies the on-net
personnel
Flags the on-net CDR

Notifies the off-net
(PSTN) system of the
malicious call
Cisco
CallManager
Cluster
Victim receives a call

from malicious caller and
invokes MCID feature.
Victim
Cisco
IOS
Gateway
Malicious
Caller
PSTN
CIPT1 v4.14-27
MCID, available starting with Cisco CallManager Release 4.0, is an internetwork service that
allows users to initiate a sequence of events when they receive calls with a malicious intent
from another network (typically, the PSTN). The user who receives a disturbing call can invoke
the MCID feature by using a softkey or feature code while connected to the call. The MCID
service immediately flags the call as a malicious call with an alarm notification to the Cisco
CallManager administrator. The MCID service flags the CDR with the MCID notice and sends
a notification to the off-net PSTN that a malicious call is in progress.
4-124
MCID Overview (Cont.)

The MCID service is a PRI
service consisting of two
parts:
Cisco
CallManager
Cluster
MCID-O: McidRequest
Invoke Component
MCID-O: an originating
function
MCID-T: a terminating
function
Cisco CallManager
supports only the
origination component at
this time.
Cisco IOS
Gateway
Malicious
Caller
PSTN
MCID-T: McidRequest
Return Result/Error
Component
CIPT1 v4.14-28
The system supports the MCID service, which is an ISDN PRI service, when using PRI
connections to the PSTN. The MCID service includes two components:
MCID-O: An originating component that invokes the feature at the request of the user
(victim) and that sends the invocation request to the connected network
MCID-T: A terminating component that receives the invocation request from the
connected network and responds with a success or failure message that indicates whether
the service can be performed
Typically, each function runs in separate network entities, and the two service components
communicate with each other to allow two networks to identify a call as malicious.
Cisco CallManager supports only the originating component at this time.
4-125
Configuring MCID
1. Ensure that the CDR flag is set to True.
2. Configure the alarm.
3. Configure a softkey template with the Malicious
Call Trace softkey.
4. Assign the MCID softkey template to an IP Phone.
5. Notify users that the MCID feature is available.
CIPT1 v4.14-29
MCID, which is a system feature, comes standard with Cisco CallManager software. MCID
does not require special installation or activation.
To configure MCID, follow these general procedures.
4-126
Step 1
Ensure that the CDR flag is set to True.
Step 2
Configure the alarm.
Step 3
Configure a softkey template with the Malicious Call Trace softkey.
Step 4
Assign the MCID softkey template to an IP Phone.
Step 5
Notify users that the MCID feature is available.
Configuring MCID: Enable CDR
Set CDR
Enabled Flag
to True.
CIPT1 v4.14-30
To enable Cisco CallManager to flag a CDR with the MCID indicator, you must enable the
CDR flag. Use the following procedure in Cisco CallManager Administration to enable the
CDR flag:
Step 1
From the drop-down list, choose Service > Service Parameters.
Step 2
Choose the Cisco CallManager server name.
Step 3
In the Service field, choose Cisco CallManager. The Service Parameters

Configuration window appears.
Step 4
In the System area, set the CDR Flag Enabled field to True if it is not already
enabled.
Step 5
If you have made a change, click Update.
4-127
Configuring MCID: Configure Alarms
Set Alarm
Event Level to
Informational.
CIPT1 v4.14-31
To provide for the MCID alarm information to appear in the Event Viewer, you need to enable
the alarm event level. Use Cisco CallManager Serviceability and the following procedure to
activate alarms for MCID:
4-128
Step 1
Choose Application > Serviceability. The Cisco CallManager Serviceability

application opens.
Step 2
Choose Alarm > Configuration. The Alarm Configuration window is displayed.
Step 3
From the list, choose the Cisco CallManager server.
Step 4
In the Configured Services drop-down list, choose Cisco CallManager. The Alarm
Configuration window updates with configuration fields.
Step 5
Under Event Viewer, in the Alarm Event Level drop-down list, choose
Informational.
Step 6
Under Event Viewer, check the Enable Alarm check box.
Step 7
If you want to enable the alarm for all nodes in the cluster, check the Apply to All
Nodes check box.
Step 8
Click Update to turn on the informational alarm.
Configuring MCID: Configure MCID Softkey
1.
Create a nonstandard softkey template based on

Standard User.
2.
Name the new template (example: MCID Standard User).
3.
Configure the softkey layout and select the Connected call state.
4.
Select the MCID softkey and move to the Selected Softkeys pane.
5.
Assign MCID softkey to an IP Phone or device pool.
CIPT1 v4.14-32
Use this procedure in Cisco CallManager Administration to add the Malicious Call softkey to a
template.
Step 1
Choose Device > Device Settings > Softkey Template. The Find and List Softkey
Templates window appears.
Step 2
In the upper-right corner of the window, click the Add a New Softkey Template
link. The Softkey Template Configuration window appears.
Step 3
In the Creating a Softkey Template Based On field, choose Standard User.
Step 4
Click Copy. The Softkey Template Configuration window refreshes with new fields.
Step 5
In the Softkey Template Name field, enter a name that indicates that this is an MCID
softkey template.
Step 6
In the Description field, enter a description that indicates that this is an MCID
softkey template.
Step 7
Click Insert. The Softkey Template Configuration window refreshes with

configuration fields.
Step 8
In the upper-right corner of the window, click the Configure Softkey Layout link.
The Softkey Layout Configuration window appears.
Step 9
In the Call States area on the left, choose Connected. The list in the Unselected
Softkeys pane changes to display the available softkeys for this call state.
Step 10
In the Unselected Softkeys pane, choose Toggle Malicious Call Trace.
Step 11
To move the softkey to the Selected keys pane, click the right arrow.
Step 12
Click Update to ensure that the softkey template is configured.
4-129
This topic discusses the purpose and primary uses of the Multilevel Precedence and Preemption
(MLPP) feature.

Allows placement of
priority calls
Phone A
Allows authenticated users

to preempt lowerprecedence calls
Works with annunciator
feature to advise users that
they have a highprecedence call
Phone B
CIPT1 v4.14-33
Most telephone systems are designed to accommodate busy-hour traffic. However, should an
emergency occur, chances are that everyone would attempt to make a telephone call at the same
time, and this behavior could overwhelm the system. In a national emergency or when network
performance has degraded, an organization might want to give certain individuals calling
precedence over others to implement emergency plans.
The MLPP feature, introduced in Cisco CallManager Release 4.0, allows placement of priority
calls. Precedence is the priority level that is associated with a call. Preemption is the process
that terminates existing calls of lower precedence and extends a call of higher precedence to or
through (in the case of a gateway) the target device.
Cisco CallManager provides indication signals (tones and displays) to MLPP-enabled devices
to ensure that the calling and called parties are aware of an MLPP call. MLPP-indicationenabled devices can play preemption tones and receive MLPP preemption announcements that
the announcement server (annunciator) generates when there is a high-precedence call. The
precedence ringback and ringer have a different cadence than the regular ringback and ringer.
MLPP indication settings are configured in the device windows in Cisco CallManager
Administration.
The six MLPP precedence levels that are presented in the following table are available in the
Translation Pattern Configuration window of Cisco CallManager Administration (Route Plan >
Translation Pattern).
4-130
MLPP Precedence Levels

MLPP Precedence Setting
Precedence
Highest
Executive Override
Starting in Cisco CallManager Release 4.1, Executive Override is
the highest precedence level and has a precedence setting of 0.
Six precedence levels are available, 0 through 5.
Second highest
Flash Override
(In Cisco CallManager Release 4.0, Flash Override is the highest
precedence level and has a precedence setting of 0. Five
precedence levels are available in Release 4.0, 0 through 4.)
Third highest
Flash
Fourth highest
Immediate
Fifth highest
Priority
Sixth highest
Routine
Does not override the incoming

precedence level but rather lets it
pass unchanged
Default
Calls with a precedence level higher than Routine are considered precedence calls.
Example: MLPP Call

In the figure, Phone B (extension 3116) is on a call with no precedence. Phone A (extension
3101) attempts to place a call to phone B. Because phone B is on a call, the call is forwarded to
voice mail. Phone A hangs up and dials a Flash Override code of 555+3116. This action causes
a preemption tone to play on phone B. Phone B hangs up and hears the precedence ring. Phone
B picks up the call from phone A, and a precedence call is established.
4-131
Summary
Summary
Cisco CallMananger Extension Mobility enables users to
temporarily access their Cisco IP Phone configuration, such
as their line appearances, services, and speed dials, from
other Cisco IP Phones.
CMC and FAC allow you to manage call access and
accounting.
MCID allows users to invoke a softkey to initiate a series of
events when they receive a threatening call.
Call Display Restrictions allow you to selectively display or
restrict the calling and connected line display information.
MLPP allows placement of higher-priority calls and
terminating lower-priority calls if necessary.
4-132
CIPT1 v4.14-34
References
Cisco Systems, Inc. Cisco CallManager Features and Services Guide, Release 4.1(3).
3/ccmfeat/index.htm
3/ccmcfg/index.htm
4-133
Module 4 Summary
Module Summary
Cisco CallManager media resources enable
important services including conferencing,
transcoding, and MOH.
End users can use the User Options web page to
customize IP Phones over the web.
Cisco CallManager features include Call Park, Call
Pickup, Cisco Call Back, Barge, Privacy, and Cisco IP
Phone Services.
Cisco CallManager features also include Cisco
CallManager Extension Mobility, Call Display
Restrictions, FAC, CMC, and MCID.
CIPT1 v4.14-1
This module covered the features, services, and options that are available to users in a Cisco IP
telephony solution. The module first presented the media resources that Cisco CallManager
provides to enable important business services such as conferencing, MOH, and informational
tones and announcements that provide feedback to users during call setup or when calls cannot
be completed. The module then discussed the User Options web pages, a simple-to-use
application that provides users with web-based ability to configure their own speed dials,
forward calls to different number, and create Personal Address Books. The module then
presented two lessons covering numerous dialing and phone features, including softkey
templates, hold, redial, Call Park, Call Pickup, Barge and Privacy, IP Phone Services, Cisco
Extension Mobility, CMC and FAC, and Call Display Restrictions.
4-134
Module 4 Self-Check
Q1)
Which of these statements best describes MRGLs? (Source: Lesson 4-1, Configuring
Media Resources)
A)
B)
C)
D)
Q2)
The Media Resource Manager manages which two resource types? (Choose two.)
(Source: Lesson 4-1, Configuring Media Resources)
A)
B)
C)
D)
Q3)

Cisco Messaging Interface
Cisco CDR Insert
Cisco TFTP
What are two requirements for users to be able to view weather reports, airline arrival
and departure times, stock quotes, or other Cisco IP Phone Services that the system
administrator has made available to them? (Choose two.) (Source: Lesson 4-2, Adding
Users and Customizing User Options)
A)
B)
C)
D)
Q6)
MAC address
IP address
port address
Meet-Me number
directory number
Annunciator resources require that which service be activated? (Source: Lesson 4-1,
Configuring Media Resources)
A)
B)
C)
D)
E)
Q5)
call dispatcher service

media streaming application server
transcoder
multiplexer
Which of the following is needed to configure a hardware conference bridge? (Source:

Lesson 4-1, Configuring Media Resources)
A)
B)
C)
D)
E)
Q4)
an ordered list of media resources

an ordered list of media gateways
an ordered list of Media Resource Groups
an ordered list of media servers
subscribe to the service in the User Options pages

enable CTI Application Use
go to http://<server_name>/Services.asp
press the Services button on the IP Phone
How do users of a Cisco IP Phone 7960 add entries to their Personal Address Book and
Fast Dials? (Source: Lesson 4-2, Adding Users and Customizing User Options)
A)
B)
C)
D)
E)
access the user partition of the LDAP directory

go to http://<server_name>/ccmuser/logon.asp
press the Services button on the IP Phone
press the softkey button next to the icon of an address book
use the Navigation button on the IP Phone for option 21
4-135
Q7)
Which three of these areas can you use to assign a softkey template to a device?
(Choose three.) (Source: Lesson 4-3, Configuring User Features Part 1)
A)
B)
C)
D)
E)
F)
Q8)
Which phone feature requires no administrator configuration? (Source: Lesson 4-3,

Configuring User Features Part 1)
A)
B)
C)
D)
E)
Q9)
the device profile associated with the physical port

an automatically generated device setting
a temporary default phone button template
the device profile associated with the user
Which two of the following are requirements to implement the MCID feature in a
Cisco CallManager deployment? (Choose two.) (Source: Lesson 4-4, Configuring User
Features Part 2)
A)
B)
C)
D)
E)
4-136
Privacy
shared line appearance
Attendant Console
Standard User softkey template
Cisco IP Phone 7960
When a user logs in to a Cisco IP Phone using the Cisco CallManager Extension
Mobility feature, what is pushed to the IP Phone? (Source: Lesson 4-4, Configuring
User Features Part 2)
A)
B)
C)
D)
Q12)
DirTrfr
Barge
cBarge
Join
Barge requires which of the following? (Source: Lesson 4-3, Configuring User
Features Part 1)
A)
B)
C)
D)
E)
Q11)
Call Forward
Call Park
Transfer
Barge
Privacy
For which softkey is the initiating user NOT included in the call after the transaction is
completed? (Source: Lesson 4-3, Configuring User Features Part 1)
A)
B)
C)
D)
Q10)
location
device defaults
device pools
user profile
region
device
PRI service
Critical alarm level
MCID-T
Cisco Emergency Responder Service
Defense Switched Network
Q13)
What should you instruct users to do if they receive a fast-busy tone after accidentally
entering an invalid client matter code? (Source: Lesson 4-4, Configuring User Features
Part 2)
A)
B)
C)
D)
E)
F)
Q14)
wait for the prompt and rekey the correct code

call technical support
enter the correct code within 3 seconds
enter the authorization code first
press the Speed Dial button
hang up and try the call again
Which four configuration items would enable a user (user A) in a hotel guest room to
view the name and number of a caller and prevent the caller from viewing the user A
call display? (Choose four.) (Source: Lesson 4-4, Configuring User Features Part 2)
A)
B)
C)
D)
E)
F)
G)
H)
Connected Line ID Presentation Restricted

Connected Line ID Presentation Allowed
Connected Name Presentation Restricted
Connected Name Presentation Allowed
Calling Line ID Presentation Restricted
Calling Line ID Presentation Allowed
Calling Name Presentation Restricted
Calling Name Presentation Allowed
4-137
4-138
Q1)
Q2)
B, C
Q3)
Q4)
Q5)
A, D
Q6)
Q7)
B, C, F
Q8)
Q9)
Q10)
Q11)
Q12)
A, C
Q13)
Q14)
B, D, E, G
Module 5
Configuring Cisco
CallManager Applications
Overview
Cisco CallManager software is shipped with a suite of integrated voice applications and
utilities, including the Cisco CallManager Attendant Consolea software-only manual
attendant console, and Cisco IP Manager Assistant (IPMA)an application that presents the
manager and assistant with job-specific tools for more efficiently managing calls.
This module discusses the features, functions, and configuration of the Cisco CallManager
Attendant Console and Cisco IPMA.
Module Objectives
Upon completing this module, you will be able to configure Cisco CallManager and the client
PC to enable the Cisco Attendant Console and Cisco IPMA applications. This ability includes
Install, configure, and use the Cisco CallManager Attendant Console application
Install, configure, and use the Cisco IPMA application
5-2
Lesson 5-1
Configuring Cisco
CallManager Attendant
Console
Overview
Enterprises today may choose to route inbound telephone calls through numerous methods.
These methods are either completely automated, manually directed, or some hybrid of
automated and manual operation. An automated operation uses an application that can accept
inbound calls, query the caller for destination information, and rapidly dispatch the call without
operator intervention. A manual operation handles each inbound caller through a specially
trained and equipped operator who assesses the purpose of the call and intended destination and
uses tools to dispatch the call.
There are benefits associated with each method. Handling each inbound caller through an
operator can lead to a heightened sense of customer satisfaction and, in many cases, a more
reliably dispatched call. Automation of inbound call dispatch is efficient and affordable.
Cisco CallManager Attendant Console can accept inbound calls, query the caller for destination
information, and rapidly dispatch the call without operator intervention. For businesses that
desire operator intervention, Cisco CallManager Attendant Console is designed to more
efficiently automate both the user operations and the administrative operations of a manual
attendant function. Cisco CallManager Attendant Console has an additional benefit over
traditional consoles and line extenders because each user line is monitored, as opposed to
monitoring only a select few in a time-division multiplexing (TDM)-based system.
This lesson covers the features, operation, installation, and configuration of Cisco CallManager
Attendant Console on both Cisco CallManager and on the attendant console station.
Objectives
Upon completing this lesson, you will be able to configure and use Cisco CallManager
Attendant Console. This ability includes being able to meet these objectives:
Explain the features and function of Cisco CallManager Attendant Console
Define the key Cisco CallManager Attendant Console components and explain their
operation
Explain the basic operation of call routing and call queuing as it relates to Cisco
CallManager Attendant Console
Describe the Cisco CallManager Attendant Console redundancy process
Configure the server portion of Cisco CallManager Attendant Console
Install and configure the client portion of Cisco CallManager Attendant Console
Use the user and administrative features of Cisco CallManager Attendant Console
5-4
Introduction to Cisco CallManager Attendant

Console
This topic explains the features and function of Cisco CallManager Attendant Console.

Attendant Console
Client-server application
Installs on a PC
Graphical user interface
Speed-dial button capable
Directory access phone number lookup
Line-status monitor
Works with Cisco IP Phone
Multiple attendant consoles on a single Cisco
CallManager
CIPT2 v4.15-3
Cisco CallManager Attendant Console, a client-server application, allows you to set up Cisco
IP Phones as attendant consoles. Employing a graphical user interface, the attendant console
uses speed-dial buttons and quick directory access to look up telephone numbers, monitor line
status, and direct calls. A receptionist or administrative assistant can use the attendant console
to handle calls for a department or company, or another employee can use it to manage his or
her own telephone calls.
The attendant console installs on a PC with IP connectivity to the Cisco CallManager system.
The attendant console works with a Cisco IP Phone that is registered to a Cisco CallManager
system. Multiple attendant consoles can connect to a single Cisco CallManager system. When a
server fails, the attendant console automatically connects to another server in the cluster.
5-5
Cisco CallManager Attendant Console

Client
Bundled with Cisco CallManager

Download client plugin from Applications > Install Plugins
CIPT2 v4.15-4
Shown in the figure is the Cisco CallManager Attendant Console client application. The client
is downloadable from the Cisco CallManager plug-in web page. (Choose Applications >
Install Plugins, and click Cisco CallManager Attendant Console.) The client installs on
end-user systems running Microsoft Windows 2000 and Windows XP. The installation
program places a Cisco CallManager Attendant Console icon on the attendant desktop and can
be also be accessed using Start >Programs.
5-6

Components
This topic defines the key Cisco CallManager Attendant Console components and discusses
their operation.
Terms and Definitions

Cisco CallManager Attendant Console clientClient application;
browser user interface; maximum of 96 per cluster
Cisco CallManager Attendant Console userCisco CallManager
database entry that represents the Cisco CallManager Attendant
Console client; one per client
Cisco Telephony Call DispatcherServer application; distributes
calls, monitors line state, and performs call control; one per Cisco
CallManager
Hunt groupOrdered list of members to which calls are distributed
by Cisco TCD according to distribution algorithm; maximum of 32
per cluster
Pilot point or pilot numberVirtual directory number; Cisco TCD
receives calls that are made to the pilot number and directs calls to
a list of destinations in a hunt group; one per hunt group
Hunt group memberEither a directory number (extension) or
user-line pair; maximum of 16 per hunt group
CIPT2 v4.15-5
The figure and following table define some of the terminology used for the Cisco CallManager
Attendant Console application.
Cisco CallManager Attendant Console Terms and Definitions
Term
Definition
Cisco CallManager Attendant Console client
Client application; web browser user interface;

maximum of 96 clients per Cisco CallManager cluster
Cisco CallManager Attendant Console user
Cisco CallManager database entry; represents the

Cisco CallManager Attendant Console client; one per
client
Server application; distributes calls, monitors line

state, and performs call control; one per Cisco
CallManager
Hunt group
Ordered list of directory numbers (DNs) to which Cisco

TCD distributes calls; maximum of 32 per Cisco
CallManager cluster
Pilot number or pilot point
DN that points to a hunt group; one per hunt group
Hunt group member
Either a DN (extension) or user-line pair; maximum of

16 per hunt group
5-7
Cisco TCD, Directory, and Client

Cisco TCDDispatches
calls, monitors line states,
interfaces to the directory
Directory
Attendant
Console
Client 1
Attendant
Console
Client 2
Attendant console
user configuration, user
and line configuration
Attendant console client
Associated with IP Phone;
must be registered to Cisco
TCD on same Cisco
CallManager server as IP
Phone
TCD
Database/
Directory
Cisco
CallManager
Server
CIPT2 v4.15-6
The figure and the following text provide additional detail about Cisco TCD, the directory, and
the Cisco CallManager Attendant Console client.

The attendant console application registers with and receives call-dispatching services from
Cisco TCD. Cisco TCD, a Cisco CallManager service, provides communication among Cisco
CallManager servers, attendant consoles, and the Cisco IP Phones that are used with the
attendant consoles.
Cisco TCD handles attendant console requests for the following items:
Call dispatching from pilot point to the appropriate hunt group destination
Line status (unknown, available, on hook, or off hook)
User directory information (Cisco TCD stores and periodically updates directory
information for fast lookup by the attendant console.)
Note
5-8
Cisco TCD monitors the status of internal devices and telephones only. An attendant
console user cannot see the line state for a telephone that is connected to a gateway.
Cisco CallManager Attendant Console Directory

The attendant console server reads and caches directory entries at startup. After an initial
handshake determines whether the directory entries have changed since the previous login, the
attendant console downloads the directory user list. The attendant console also downloads the
user list when the interval in the Directory Reload Interval field in the Attendant Settings dialog
box expires or when the user clicks the Reload button in the Directory window.
The attendant console searches the following files (in order) for the user list:
The user list file that is specified in the Path Name of Local Directory File field in the
Attendant Settings dialog box on the attendant PC
The CorporateDirectory.txt file in the user list directory on the Cisco CallManager
Attendant Console server. You can create the CorporateDirectory.txt file if your user list is
located on a directory server that is separate from the Cisco CallManager server.
Note
For information about creating a CorporateDirectory.txt file, see the "Creating the
CorporateDirectory.txt File" section at:
http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_1/sys_ad/4_1_3/
ccmfeat/fsccmac.htm#wp1162566
The AutoGenerated.txt file that is generated by the Cisco TCD service and stored in the
user list directory on the Cisco CallManager Attendant Console server. If the Directory
Sync Period service parameter does not equal zero, Cisco TCD generates the
AutoGenerated.txt file when the Cisco TCD service starts and when the directory
synchronization period expires.
To modify the Directory Sync Period service parameter, choose Service > Service
Parameters. Choose the appropriate server from the Server drop-down list and choose the
Cisco Telephony Call Dispatcher Service from the Service drop-down list.
The user list file is in comma-separated values (CSV) format and contains the following
information:
Last name
First name
Telephone number
Department
Cisco CallManager Attendant Console Client

The attendant console works in conjunction with a Cisco IP Phone. Configure the attendant
console to connect the Cisco IP Phone to its registered Cisco CallManager server. This server
must have the Cisco TCD service running.
5-9
Pilot Points and Hunt Groups

Pilot pointA virtual directory number that Cisco TCD
uses to receive and direct calls to hunt group members
according to a distribution algorithm
First Available Hunt Group
Longest Idle Hunt Group
Circular hunting
Broadcast hunting
Hunt groupA list of destinations that determine the
call-redirection order
CIPT2 v4.15-7
The figure and the following text provide additional detail about the pilot point and hunt group.
A pilot point, a virtual DN that is never busy, alerts Cisco TCD to receive and direct calls to
hunt group members. A hunt group consists of a list of destinations that determine the call
redirection order.
For Cisco TCD to function properly, make sure that the pilot point number is unique
throughout the system (it cannot be a shared line appearance). When configuring the pilot
point, you must choose one of the following routing options:
First Available Hunt Group Member: Cisco TCD goes through the members in the hunt
group in order until it finds the first available destination for routing the call. (You can
choose this routing option from the Pilot Point Configuration window in Cisco
CallManager Administration.)
Longest Idle Hunt Group Member: This feature arranges the members of a hunt group in
order from longest to shortest idle time. Cisco TCD finds the member with the longest idle
time and, if available, routes the call. If not, Cisco TCD continues to search through the
group. This feature evenly distributes the incoming call load among the members of the
hunt group. (You can choose this routing option from the Pilot Point Configuration window
in Cisco CallManager Administration.)
Circular Hunting: Cisco TCD maintains a record of the last hunt group member to receive
a call. When a new call arrives, Cisco TCD routes the call to the next member in the hunt
group. (You can choose this option from the Attendant Console Configuration tool.)
Broadcast Hunting: When a call arrives at the pilot point, Cisco TCD answers the call,
places the call on hold, adds the call to the queue, and displays the call in the Broadcast
Calls window on attendant PCs. While on hold, the caller receives music on hold (MOH), if
it is configured. Any attendant can answer the call from the Broadcast Calls window. (You
can choose this option from the Attendant Console Configuration tool.)
5-10
Call Routing and Queuing
This topic discusses the basic operation of call routing and call queuing as they relate to Cisco
CallManager Attendant Console.
Basic Call Routing Example

1
Incoming
Call to
Support
Number
4000
Cisco TCD Directs

to Pilot Point 4000
Cisco TCD
Cisco
CallManager
Support Pilot
Point
4000
First Available
Hunt Group
Member
Cisco TCD Checks

Members, Routes Call
to 1027
Hunt Group Members
for Support Pilot Point
1024 (DN) Busy

1025 (DN) Not Online
1026 (DN) Available
5060 (VM) Not Checked
Server
Cisco CallManager
Attendant Console Client
and IP Phone
CIPT2 v4.15-8
The figure shows the interaction of the Cisco CallManager Attendant Console components in a
basic call-routing example when a call is made to a number that is configured as a pilot point
and associated with a hunt group. In this example, 4000 is a support number associated with a
support hot line.
1. Cisco TCD receives a call and directs it to the pilot point, DN 4000.
2. Because 4000 is a pilot point and First Available Hunt Group Member is specified as the
call-routing option, the Cisco TCD that is associated with the pilot point checks the
members of the hunt group in order, beginning with the first member, to determine where
to route the call. DN 1024 is busy, DN 1025 is busy, and DN 1026 is available.
3. Cisco TCD routes the call to the first available DN, which is 1026. Because 1026 is
available, Cisco TCD never checks the 5060 voice-mail number.
5-11
Call Queuing
1
Incoming
Call
All Members
Are Busy
Send Call to
Queue
Route Call to
Member
Support Pilot
Point
Hunt Group Members
4000
1024 Busy
1025 Busy
1026 Busy
1024 Available
Queue size (number of calls allowed in queue) and hold

time (maximum time a call remains in the queue)
configurable in the Attendant Console Configuration Tool
If the queue is full or hold time expires, TCD routes calls
to always route hunt group member if configured in
Hunt Group Configuration window
CIPT2 v4.15-9
You can configure a pilot point to support call queuing so that when a call comes to a pilot
point and all hunt groups members are busy, Cisco CallManager Attendant Console sends calls
to a queue. While in the queue, callers hear MOH if you have chosen an audio source from the
Network Hold Audio Source and the User Hold MOH Audio Source drop-down lists in the
Device Pool window. The attendants cannot view the queued calls. When a hunt group member
becomes available, Cisco TCD redirects the call to that hunt group member. This sequence of
events is reflected in the figure.
You enable queuing for a pilot point using the Cisco CallManager Attendant Console
Configuration Tool. You also use the tool to configure the queue size, which is the number of
calls that are allowed in the queue, and the hold time, which is the maximum time (in seconds)
that Cisco TCD keeps a call in the queue. Configuring the Cisco CallManager Attendant
Console Configuration Tool is covered later in this lesson.
If the queue is full, Cisco TCD routes calls to the always route hunt group member that is
specified in the Hunt Group Configuration window. If you do not specify an always-route
member, Cisco TCD drops the call when the queue size limit is reached. If the call is in the
queue for longer than the hold time, the call is redirected to the always-route member. If an
always-route member is not configured, no action occurs. Configuring the Always Route option
in the Hunt Group Configuration window is covered later in the lesson.
5-12

Redundancy
This topic describes the Cisco CallManager Attendant Console redundancy process.
Redundancy
Client 1
Client 1
Cisco TCD
Cisco TCD
Cisco TCD
Cisco TCD
CCM
CCM
CCM
CCM
Server1
Server2
Cisco TCD
Database Database
Directory Directory
Server1
CCM
CCM
Server3
Server3
Database
Directory
Server2
Cisco TCD
Database
Directory
CCM = CallManager
CIPT2 v4.15-10
This sequence of events outlines the redundancy process used by the Cisco CallManager
Attendant Console.
Sequence one: Normal operation
Cisco CallManager Attendant Console client 1 registers with the TCD component on
server 2. IP Phone 2, associated with the Cisco CallManager Attendant Console, is
also registered to server 2.
Sequence two: Cisco CallManager failure
Server 2 fails, and IP Phone 2 now registers with server 1.
Client 1 searches Cisco TCD on servers 1 and 3 for the presence of IP Phone 2.
Client 1 finds IP Phone 2 on server 1.
Client 1 registers to Cisco TCD 1 automatically.
The Cisco CallManager Attendant Console always registers to Cisco TCD on the same Cisco
CallManager server that registers the associated IP Phone.
5-13
To ensure redundancy for the Cisco CallManager Attendant Console application, perform one
of the following tasks:
In default configurations where Cisco CTIManager and Cisco TCD are running on all
nodes in the Cisco CallManager cluster, enter the IP address of one server that is running
Cisco TCD in the Attendant Settings dialog box on the attendant PC.
If Cisco TCD and CTIManager are not running on all nodes in the cluster, enter a CSV list
of the IP addresses of servers in the cluster that have an active CTIManager in the Call
Processing Server Host Names or IP Addresses field on the Advanced Tab of the Attendant
Settings dialog box on the attendant PC.
5-14
Server and Administration Configuration
This topic describes configuring the server portion of the Cisco CallManager Attendant
Console.
Attendant Console Server Configuration

Steps
1. Add attendant console users.
2. Configure pilot points.
3. Configure hunt groups.
4. Create the ac user and associate all pilot point devices
with the user.
5. Verify that the Cisco TCD service is activated on all
servers that are running the Cisco CallManager
service.
Verify that the Cisco CTIManager service is activated
on one server in the cluster.
6. Use the Attendant Console Configuration Tool to
minimally change default ac username and password.
CIPT2 v4.15-11
Follow this procedure to configure the Cisco CallManager server to support the Cisco
CallManager Attendant Console:
Step 1
Add Cisco CallManager Attendant Console users. These individual users will use
the Cisco CallManager Attendant Console application. They are not the same as
directory users that you configure in the User area of the Cisco CallManager
Administration window.
Step 2
Configure the pilot point for the Cisco CallManager Attendant Console. The pilot
point is a DN that provides access to Cisco CallManager Attendant Console users
indirectly through hunt groups. The pilot point usually maps to the general company
number (switchboard number), but it can use a DN outside of the Direct Inward Dial
(DID) range.
Step 3
Configure hunt groups. Hunt groups consist of Cisco CallManager Attendant

Console users or DNs. When adding a Cisco CallManager Attendant Console user
with multiple line numbers to the hunt group, you must specify which line to use.
Step 4
Create the ac user and associate all pilot point devices with the user. You must
configure one user named ac and associate the attendant IP Phones and the pilot
points with the user. If you do not configure this user, the attendant console cannot
interact with Cisco CTIManager, and the attendant cannot receive calls.
Step 5
Activate Cisco TCD and CTIManager services. Verify that the Cisco TCD service
activates and runs on all servers that are running the Cisco CallManager service.
Verify that the Cisco CTIManager service activates and runs on at least one server in
the cluster.
5-15
Step 6
Access the Attendant Console Configuration tool. Use the tool to, at a minimum,
change the default username and password and, optionally, configure queuing and
assess other hunting options not available directly from the Pilot Point Configuration
window in Cisco CallManager Administration.
Adding Attendant Console Users
CIPT2 v4.15-12
You must add users through the Cisco CallManager Attendant Console User Configuration
window and assign them a password before they can log in to a Cisco CallManager Attendant
Console client. Complete the following procedure to add a user:
5-16
Step 1
Open the Cisco CallManager Attendant Console User Configuration window and
choose Service > Cisco CM Attendant Console > Cisco CallManager Attendant
Console User.
Step 2
In the upper-right corner of the window, click the Add a New Attendant Console
User link.
Step 3
Create user accounts for each Cisco CallManager Attendant Console user by
entering the appropriate user ID (username) and password for each account.
Step 4
ac User Configuration
CIPT2 v4.15-15
You must create one generic user, the ac user, and associate the attendant Cisco IP Phones and
the pilot points with the ac user. When you configure the ac user, the Cisco CallManager
Attendant Console can then interact with the Cisco CTIManager service on the Cisco
CallManager server. Perform the following procedure to configure the ac user:
Step 1
Choose User > Add a New User in the Cisco CallManager Administration window.
Step 2
Enter ac in the First Name and Last Name fields.
Step 3
Enter ac in the User ID field.
Step 4
Enter 12345 in the User Password field.
Step 5
Enter 12345 in the Confirm Password field.
Note
ac and 12345 are mandatory default settings when first configuring the Attendant
Console user.
Step 6
Enter a personal identification number (PIN) and telephone number.
Step 7
Check the Enable CTI Application Use check box. You must check this box for the
Cisco CallManager Attendant Console to interact with Cisco CTIManager.
Step 8
Check the Call Park Retrieval Allowed check box.
Step 9
Click Insert.
Step 10
Associate all attendant Cisco IP Phones and pilot points with the ac user.
Note
Use the Cisco CallManager Attendant Console Configuration Tool to change the attendant
console username and password from their default values to enhance the security of your
deployment.
5-17
Pilot Point Configuration
Route calls to either longest-idle hunt group member or first

available hunt group member.
CIPT2 v4.15-13
You must configure pilot points and hunt groups through the Cisco CallManager
Administration window before Cisco TCD can route calls.
In Cisco CallManager Administration, choose Service > Cisco CM Attendant Console > Pilot
Point and in the upper-right corner, click the Add a New Pilot Point link to open the Pilot
Point Configuration window.
The Pilot Point Configuration Fields table defines the settings in the Pilot Point Configuration
window.
5-18
Pilot Point Configuration Fields

Field
Description
Pilot Name
Enter up to 50 alphanumeric characters, including spaces, to

specify a descriptive name for the pilot point.
Device Pool
Assign the pilot point to a device pool. The device pool has the
Cisco CallManager whose Cisco TCD service will service this
pilot point.
Partition
Choose the partition to which the pilot point belongs. Make sure
that the pilot point that you enter in the Pilot Number field is
unique within the partition that you choose. If you do not want to
restrict access to the pilot number, choose None for the partition.
Calling Search Space
To designate the partitions that the pilot point searches when it

attempts to route a call, choose a calling search space from the
drop-down list.
Pilot Number
Enter a DN into this field to designate a DN for this pilot point.

Verify that this number is unique throughout the system; it cannot
be a shared line appearance.
Route Calls To
Choose the mechanism to distribute calls to hunt group

members:
Choose the First Available Hunt Group Member option to
route incoming calls to the first available member of a hunt
group. This is the default setting.
Choose the Longest Idle Hunt Group Member option to
order members based on the length of time that each DN or
line has remained idle.
If the voice-mail number is the longest-idle member of the group,
Cisco TCD will route the call to voice mail without first checking
the other members of the group.
If you want to use the Circular Hunting or Broadcast Hunting
routing options, use the Attendant Console Configuration Tool.
Note
If the pilot point is not the main or general telephone number, the main number can go to a
translation pattern that is transformed to the pilot number.
5-19
Hunt Group Configuration
Last member should

always be a directory
number, voice mail, or
IP IVR/Auto Attendant.
The Always Route
Member check box is
checked.
CIPT2 v4.15-14
After you configure the pilot point, you must configure the hunt group. A hunt group consists
of a list of destinations (either DNs, or Cisco CallManager Attendant Console user or line
numbers) that determine the call-redirection order.
In Cisco CallManager Administration, choose Service > Cisco CM Attendant Console >
Hunt Group. The Hunt Group Configuration window appears. In the shaded column on the
left, click the pilot point for which you want to add hunt group members.
The Hunt Group Configuration Fields table defines the settings in the Hunt Group
Configuration window shown in the figure.
If you have configured queuing, and the queue is full, Cisco TCD routes calls to the
always-route hunt group member that is specified in the Hunt Group Configuration window. If
you do not specify an always-route member, Cisco TCD drops the call when the queue size
limit is reached. If the call is in the queue for longer than the hold time, the call is redirected to
the always-route member. If the always-route member is not configured, no action occurs.
5-20
Hunt Group Configuration Fields

Field
Description
Partition
If a hunt group member is a DN, you can click the drop-down

arrow to view the values for the Partition field and then choose
the appropriate option. Enter the DN in the Directory Number field
in the Device Member Information section.
The partition designates the route partition to which the DN
belongs.
If the DN for this hunt group member is in a partition, you must
choose a partition.
If the DN is not in a partition, choose None.
Directory Number
Enter the DN of the hunt group member device in this field. When
the DN is not in the specified partition, an error dialog box
appears.
Always Route Member
Always Route Member is an optional check box that applies to

DNs only. If this check box is checked, Cisco TCD always routes
the call to this hunt group member, whether it is busy or not.
Cisco TCD does not check whether the line is available before
routing the call.
To manage overflow conditions, check this check box for voicemessaging or autoattendant numbers that handle multiple
simultaneous calls.
User Name
If the hunt group member is a user and line number, fill in only the
User Name and Line Number fields in the User Member
Information section.
From the drop-down list, choose attendant console users that will
serve as hunt group members.
Only attendant console users that are added in the Cisco
CallManager Attendant Console User Configuration window
appear in this list.
Line Number
From the drop-down list, choose the appropriate line numbers for
the hunt group.
You can add the same user to the same line only once within a
single hunt group. For example, you cannot add Mary Brown,
Line 1, more than once in the hunt group.
5-21
Cisco TCD and CTIManager Service

Activation
Services
Required for
Attendant
Console
CIPT2 v4.15-16
To activate the Cisco TCD and CTIManager services, follow this procedure:
Step 1
In the Cisco CallManager Administration window, choose Application > Cisco

CallManager Serviceability. The Cisco CallManager Serviceability window
appears.
Step 2
Choose Tools > Service Activation. The Service Activation window displays the
list of servers.
Step 3
From the Servers list, choose the server where Cisco CallManager is running.
The window displays the service names for the server that you chose and the activation status
of the services. Verify that the status of the Cisco TCD and CTIManager services is Activated,
or follow the remaining steps to activate them.
5-22
Step 4
Check the check boxes next to the services that you want to activate.
Step 5
Click Update.
Attendant Console Configuration Tool:

Basic Tab
Change Default ac Username

Change Default 12345 Password
CIPT2 v4.15-17
You can use the Attendant Console Configuration Tool to perform these tasks:
Change the Java Telephony Application Interface (JTAPI) username and password from
the default values of ac and 12345, respectively (Basic tab).
Set the directory values (Advanced tab).
Enable call queuing for a pilot point and specify the queue size and hold time. The
hold-time value 0, which keeps calls in the queue until an attendant becomes available, is
the default (Advanced tab).
Configure circular hunt groups and broadcast hunt groups (Advanced tab).
Note
Before you can create circular or broadcast hunt groups, you must first create the pilot
points.
To use the Attendant Console Configuration Tool, follow this general procedure:
Step 1
Open the acconfig.bat file, which is located in the C:\Program

Files\Cisco\CallManagerAttendant\bin directory on the Cisco CallManager
Attendant Console server.
Step 2
Enter the desired values.
Step 3
Click Save and then click Close.
Changing the Default JTAPI Username and Password

The default settings for the attendant console JTAPI username and password are ac and 12345,
respectively. To maximize security for your application, change the default values for both of
these settings using the Attendant Console Configuration Tool. The JTAPI Username and
JTAPI Password fields are located in the Basic tab.
5-23
Attendant Console Configuration Tool:

Advanced Tab
Access circular and

broadcast hunting
options.
Enable
queuing on
the pilot
point
number.
Set the
maximum time
for calls to be in
queue.
CIPT2 v4.15-18
The Advanced tab enables you to access additional hunting options not available in the Hunt
Group Configuration window, enable queuing, change the queue size (the default is 32 calls),
and change the hold time (the default is 0, which keeps calls in the queue until an attendant
becomes available).
Enabling Broadcast or Circular Hunting

You can enable longest idle or first available hunting from within Cisco CallManager
Administration by choosing Service > Cisco CM Attendant Console > Hunt Group. To
enable circular or broadcast hunting, use the Attendant Console Configuration Tool.
To enable circular or broadcast hunting, click the Advanced tab and choose the routing option
that you want to use for the pilot point that you choose in the Pilot Points drop-down list (also
located on the Advanced tab).
The routing option that you chose when you configured the pilot point, either longest idle or
first available, is also displayed in the drop-down list.
5-24
Installing and Configuring the Client
This topic describes the installation and configuration of the Cisco CallManager Attendant
Console on the client machine.
Attendant Console Client

Configuration Steps
1. Verify Windows 2000 or
XP and network
connectivity to Cisco
CallManager.
2. Install the Attendant
Console plug-in.
3. Specify the IP address
of the Cisco CD and
the DN associated with
attendant IP Phone.
4. Start the application.
CIPT2 v4.15-19
After you activate Cisco TCD and CTIManager services and configure the Cisco CallManager
Attendant Console in Cisco CallManager Administration, you are ready to install and configure
the Cisco CallManager Attendant Console plug-in on each attendant PC.
The following steps provide the PC requirements for the attendant console:
Step 1
Verify that the PC is running Microsoft Windows 2000 or Windows XP and has
network connectivity to the Cisco CallManager.
Step 2
Install the Cisco CallManager Attendant Console plug-in on each attendant PC.
1. Download the Cisco CallManager Attendant Console plug-in by choosing
Application > Install Plugins in the Cisco CallManager Administration
window.
2. Save the CiscoAttendantConsoleClient.exe file to the local machine.
3. Launch the CiscoAttendantConsoleClient.exe file.
Step 3
Configure the Cisco CallManager Attendant Console settings on the attendant PC.
4. Specify the IP address of the Cisco CallManager TCD server and the DN of the
associated IP Phone, and click Save.
5. Provide the username and password.
5-25
Note
Verify that you have the latest Microsoft Critical Updates and service packs installed on the
PC before installing the Cisco CallManager Attendant Console application.
After you install the Cisco CallManager Attendant Console, the user is ready to start the
application. After opening the Cisco CallManager Attendant Console application, the user will
have to log in and then go online. The user is then ready to answer calls.
To launch the application on the PC where the attendant console is installed, choose Start >
Programs > Cisco CallManager > Cisco CallManager Attendant Console or click the Cisco
CallManager Attendant Console icon on the desktop; then, and then click Yes to launch the
attendant console.
5-26
Cisco CallManager Attendant Console Features
This topic introduces the user and administrative features of the Cisco CallManager Attendant
Console.
Client Menu Options
File
Edit
View
Actions
Help
CIPT2 v4.15-20
The features of the Cisco CallManager Attendant Console are menu-driven. You can use the
associated shortcut keys to access all of the menu functions.
File menu: From the File menu, you can go online or offline, log out, and exit the program.
Edit menu: From the Edit menu, you can create your own keyboard shortcuts. You can
also add, modify, and delete speed-dial entries or groups and view or revise settings, which
is an optional task.
View menu: From the View menu, you can change the size of the text in the windows or
the color on the console.
Actions menu: You perform call-control tasks through the Actions menu or the Action
Key shortcuts shown in the figure. This menu includes many feature options, such as
answering calls, transferring calls, parking calls, and enabling other features on the system.
Help menu: Cisco CallManager Attendant Console provides online help and easy access to
the latest Cisco CallManager Attendant Console plug-in for an upgrade.
5-27

Interface
1
Invoke Features
Drag and Drop
10
11
12
Call Control Toolbar
Keyboard
Shortcuts
CIPT2 v4.15-21
The Cisco CallManager Attendant Console efficiently automates the user and the
administrative operations of a manual attendant function. It has an intuitive and configurable
GUI to handle calls and monitor line state.
In a system with hundreds or thousands of users, a Cisco CallManager Attendant Console
operator can accept calls and perform a directory lookup by selecting the field title in the
Directory section and typing in the first few characters of the last name, first name, or
department of the user. A directory search returns information that matches the query.
An operator can view the status of a user line (busy, idle, or ringing) and advise the caller of the
line state. The operator can then transfer the call to the user by either initiating a traditional
transfer sequence through the Transfer icon or dragging and dropping the call from the selected
loop to the desired user record.
5-28
Shown in the figure is the Cisco CallManager Attendant Console Call Control toolbar. This
toolbar displays a set of buttons for the most common call-control tasks that the attendant
performs. The attendant console enables buttons on the Call Control toolbar only when you can
perform call-control tasks with them. Clicking a button automatically enables the
corresponding menu options on the menu bar or context-sensitive menu. The call-control
buttons are as follows:
Offline/Online
Dial
Answer
Hang Up
Hold/Resume
Transfer
Consult Transfer
Direct Transfer
Join
Park/Revert Park
Conference
Forward a Call to Voice Mail
From top to bottom, on the keyboard shortcuts (Ctrl-Underscore to display shortcuts menu),
they represent:
Dial
Answer
Hang up
Hold
Dial digits
Transfer
Consult transfer
Direct transfer
Join
Park
Conference
Voice mail
5-29
User features include the following:

Loop keys, which provide simultaneous management of all lines available on associated
telephones
Line states, such as idle, active, ringing, and unknown
User label per line monitor key for easy reference to user
Query, which searches by last name, first name, extension, or department
Sort, which sorts by last name, first name, extension, or department
Broadcast calls to all configured and busy attendants and automatic redirect to the attendant
who answers the call
Direct transfer, to merge two independent calls into one single call
Join, to merge a group of calls, including the attendant, into a conference call
Administrative features include the following:
Remote system and device installation and configuration through a web browser
Simultaneous line monitor by multiple operators, which provides simultaneous viewing of
the line state of any line from the console user interface
Call distribution from a single pilot number to multiple DNs or user-line pairs
Call queuing for inbound calls when all hunt group members are busy
Simultaneous monitoring of inbound calls from multiple operator positions
Creation of up to 16 pilot numbers or distribution groups
5-30

Client GUI: Call Control
CIPT2 v4.15-22
The Call Control window has the following two components:

Call Details pane: This component includes the line status, the DN of the incoming call,
the name of the person (if available), the operator DN, and the elapsed time display.
Operator Line buttons: This component includes the line status and the DN of the
attendant Cisco IP Phone, displayed in the upper-right corner of the window.
The Call Details pane displays the lines on the Cisco IP Phone that the Cisco CallManager
Attendant Console controls. The number of lines configured depends on the type of
configuration. For example, if you have a Cisco IP Phone 7960 with two attachments of the
Cisco IP Phone 7914 Expansion Module, and you associate a DN with each line, then a total of
34 lines can be displayed.
5-31

Client GUI: Customized Speed Dials
Speed dial with user label and
line state monitor
Configured by dragging user
entry from Directory section
CIPT2 v4.15-23
The Speed Dial pane is located in the upper-right corner of the screen and contains DNs and
labels. By clicking a speed-dial button, you place a call from the currently selected attendant
line to the associated DN.

Client GUI: Directory Lookup
Line state
Access to all users in LDAP
directory
Sortable columns; column
header character string entry
queries LDAP/local directory
CIPT2 v4.15-24
The Directory Dial pane is located in the lower-right corner of the screen. By clicking a
displayed directory entry, you place a call from the currently selected attendant line to the
associated DN.
5-32

Client GUI: Parked Calls
List all calls that are parked
by all attendants
Attendant can use Revert
Park for parked calls
CIPT2 v4.15-25
From the Parked Call window, you can view and pick up all calls that have been parked by all
attendants that are connected to the attendant server. If the call is not answered, you can revert
the parked calls in these ways:
Right-click the call that you want to park, then choose Revert Park from the contextsensitive menu.
Click the call that you want to park, then click the Revert Park button on the Call Control
toolbar.
Click the call that you want to park, then choose Revert Park from the Actions menu.
On the PC keyboard, press Ctrl-P.
5-33

Client GUI: Broadcast Calls
List all calls that arrive at the
broadcast hunting pilot point
Broadcast the call to all
available attendants
CIPT2 v4.15-26
Broadcast hunting enables Cisco CallManager Attendant Console to answer calls and place
them in a queue. The attendant console displays the queued calls to all available attendants after
inserting the calls into the queue.
Any attendant in the hunt group that is online can answer the queued calls. Cisco TCD does not
automatically send the calls to an attendant. When an attendant answers a call, Cisco TCD
removes the call from the Broadcast Calls window and displays it in the Call Control window
of the attendant who answered the call.
5-34
Summary
Summary
Cisco CallManager Attendant Console is a client-server
application that allows you to set up Cisco IP Phones as
attendant consoles.
Key Cisco CallManager Attendant Console components
include Cisco TCD, Cisco CallManager Attendant Console
client, Cisco CallManager Attendant Console user, a hunt
group, and a pilot point.
Cisco TCD provides call routing for incoming calls to the
pilot point. The pilot point can be configured for queuing.
Automatic failover occurs if the Cisco TCD component
(Cisco CallManager) fails or is inaccessible.
Configuring the server requires adding the attendant console
users, configuring the pilot points and hunt groups, creating
the ac user, and activating Cisco TCD and CTIManager
services.
CIPT2 v4.15-27
Summary (Cont.)
Configuring the client includes installing the
attendant console plug-in on the attendant PC and
specifying the attendant server IP address and
attendant DN.
Cisco CallManager Attendant Console user

features include a GUI, line-state monitors,
drag-and-drop capability, and access to directories.
administrative features include call distribution
from a single pilot number, call queuing,
simultaneous monitoring of line state and inbound
calls from multiple operators, and 16 pilot numbers
or distribution groups.
CIPT2 v4.15-28
5-35
References
Cisco CallManager Attendant Console.
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/4_1/sys_ad/4_1_3/ccmfe
at/fsccmac.htm#wp29392.
Cisco Systems, Inc. Cisco CallManager Attendant Console user guides, keyboard shortcut
references, and other resources.
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/attendnt/call_att/.
5-36
Lesson 5-2
Configuring Cisco IP Manager

Assistant
Overview
Senior managers frequently employ assistants who have as one of their duties the management
of telephone activities for the manager or for a group of managers. The assistant normally sets
up conferences for the manager and also places, answers, and transfers calls. This assistant (and
to some extent, the managers) need a different set of features than other users. In addition to the
ability to handle the call activities of the manager, the assistant needs to be able to monitor that
call activity when the manager is on a call, in a meeting, or does not want to be disturbed; to
communicate with the manager using an intercom; and to change features and settings for the
manager.
Cisco IP Manager Assistant (IPMA) is an application that provides these capabilities to
managers and assistants. This lesson discusses the features and functions of Cisco IPMA, how
to configure the feature, and the end-user applications that constitute the applicationManager
Configuration and Assistant Console.
Objectives
Upon completing this lesson, you will be able to configure and use the Cisco IPMA feature in
shared-line mode. This ability includes being able to meet these objectives:
Describe the features of Cisco IPMA and its two modes
Explain the function of the components that make up the Cisco IPMA architecture
Configure Cisco IPMA for shared-line mode
Configure the manager divert target for call forwarding
Use the Assistant Console interface to place and receive calls
Cisco IP Manager Assistant Overview

This topic discusses the features of Cisco IPMA and its two modes.
Cisco IPMA Overview

Allows managers and assistants to work together more
effectively
ManagerUser whose incoming calls are intercepted
by the routing service and routed appropriately
AssistantUser who handles calls on behalf
of a manager
Comprises enhancements to phone capabilities
for the manager, assistant (primarily), and desktop
interfaces
Supports two modes of operation
Proxy lineCalls to managers are intercepted and
routed to selected targets based on preconfigured
call filters.
Shared lineCalls to managers are presented
both to the manager and the assistant.
Supported on Cisco IP Phone 7970, 7960, and 7940
CIPT1 v4.14-3
Cisco IPMA enables managers and their assistants to work together more effectively.
Cisco CallManager users are managers and assistants. An assistant user handles calls on behalf
of a manager. Cisco IPMA provides features for managers and features for assistants.
The feature consists of enhancements to IP Phone capabilities for the manager and desktop
interfaces that are primarily used by the assistant.
Cisco IPMA supports two modes of operation: proxy-line support (Cisco CallManager Release
3.3 or later) and shared-line support (Cisco CallManager Release 4.0 or later). The Cisco IPMA
service supports both proxy-line and shared-line support in a given cluster.
For Cisco IPMA with proxy-line support, the service intercepts calls that are made to managers
and routes them to selected assistants, to managers, or to other targets based on preconfigured
call filters.
Cisco IPMA is supported on Cisco IP Phone 7970, 7960, and 7940 models.
5-38
Cisco IPMA with Proxy-Line Support

Intercepts manager
calls on a proxy line
Requires partitions,
calling search spaces,
route points, and
Uses Cisco IPMA
Configuration Wizard
Uses Standard IPMA
Manager softkey
template
CIPT1 v4.14-5
Cisco IPMA with proxy-line support intercepts calls that are made to managers and routes them
to the assistant or to preconfigured targets that are based on preconfigured call filters. Because
the Cisco IPMA service intercepts calls that are made to managers who are using proxy-line
mode, it requires configuration of partitions, calling search spaces, route points, and translation
patterns.
The Cisco IPMA Configuration Wizard enables you to automatically create the partitions,
calling search spaces, route points, and translation patterns that are required for proxy-line
mode. The wizard also creates Bulk Administration Tool (BAT) templates for the Cisco IPMA
manager telephone, the Cisco IPMA assistant telephone, and all other user telephones. The
Cisco IPMA Configuration Wizard can be run only one time; however, you can make
corrections and additions manually in Cisco CallManager Administration.
Cisco CallManager Release 4.0 supports the existing proxy-line configuration in earlier
versions of Cisco CallManager, but Release 4.0 features such as Barge, Privacy, Call Join,
Direct Transfer, and multiple calls per line require the shared-line mode.
The manager telephone uses the Standard IPMA Manager softkey template.
In the proxy-line mode, a manager can be assisted by only one assistant at a time.
5-39
Cisco IPMA with Shared-Line Support

Assistants share primary line of
manager
No call routing
Cisco IPMA Wizard need not
be used
DND
State
No route points, partitions,

calling search spaces, or
Manager Display
Support for new features

Multiple calls per line, Direct
Transfer, Call Join
Uses Standard IPMA Shared
Mode Manager softkey template
CIPT1 v4.14-6
Cisco IPMA with shared-line support enables the assistant to share the primary line of the
manager. (The assistant and the manager have the same DN configured on one line).
There is no call routing in shared-line mode. Calls for the manager ring on both the manager
line and the assistant line.
The Cisco IPMA Configuration Wizard is not used in Cisco IPMA with shared-line mode
because there is no need to configure route points, partitions, calling search spaces, or
translation patterns.
Cisco IPMA in shared-line mode supports Cisco CallManager features such as multiple calls
per line, Call Join, Direct Transfer, Privacy, and Barge.
The manager telephone uses the softkey template called Standard IPMA Shared Mode
Manager. This template has the following the softkeys:
DND: Do not disturb; turns the ringer off. The manager telephone displays the DND state.
ImmDiv: Immediate Divert; diverts the selected call to a preconfigured target.
TransferToVM: Transfer to voice mail; redirects the selected call to the voice mail of the
manager.
A dedicated incoming intercom line can be administered on the manager telephone (optional).
Speed dials are administered on the manager IP Phone for all the assistants for which the
manager is configured.
One manager can be configured to have 10 assistants.
Cisco IP Phone Services are not supported in shared-line mode for managers.
5-40
Shared-Line and Proxy-Line Modes

Compared
Feature
Number of Managers
per Assistant
Number of Assistants
per Manager
IP Phone Services
Support on Manager
Phone
Barge, Privacy, Join,
Direct Transfer, and
Multiple Calls Per Line
Configuration
Shared
Proxy
33
33
10
One at a time
No
Yes
Yes
No
Simpler
Requires route
points, partitions,
calling search
space, etc.
CIPT1 v4.14-7
The figure summarizes key differences between Cisco IPMA shared-line and proxy-line mode.
Which mode you choose for a given deployment, or even for a given user, will largely depend
on the features that you require. Another consideration is whether you prefer to standardize on
a single mode throughout the cluster for simplicity of administration and end-user support.
5-41
Cisco IP Manager Assistant Architecture
This topic explains the function of the components that make up the Cisco IPMA architecture.
Overview of the Cisco IPMA Architecture

IPMA Service
Browser
HTTP
Tomcat
IIS
Assistant Console
Applications,
Applications
TCP/IP
MA Servlet
HTTP
Cisco
Cisco
CallManager CallManager
Directory
Database
Softkey
Display
Cisco
CTIManager
Cisco
CallManager
Assistant
IP Phone
Manager
IP Phone
Cisco
CallManager
CIPT1 v4.14-8
The Cisco IPMA feature architecture comprises the Cisco IPMA service, the desktop
interfaces, and the Cisco IP Phone interfaces.
Cisco IPMA service: Cisco Tomcat loads the Cisco IPMA service, a servlet. Cisco
Tomcat, a Microsoft Windows NT service, is installed as part of the Cisco CallManager
installation. The Cisco IPMA service performs the following tasks:
Hosts the web pages that the manager uses for configuration.
Communicates to a Cisco CallManager cluster through Cisco CTIManager for

third-party call control. Cisco IPMA requires only one computer telephony
integration (CTI) connection for all users in a cluster.
Accesses data from the database and directory.
Supports the Assistant Console application.
Desktop interface: Cisco IPMA supports the following desktop interfaces for managers
and assistants:
Assistant Console: Used for call control, login, assistant preferences, monitoring the
call activity of managers, and keyboard shortcuts
Manager Configuration: Used for configuring the Immediate Divert target and to
configure the Send All Calls target and filters (proxy-line mode only)
Cisco IP Phone interface: Assistants and managers use softkeys to access Cisco IPMA
features.
Note
5-42
A Cisco IP Phone 7960 that is running Cisco IPMA may be equipped with a Cisco IP Phone
7914 Expansion Module.
Configuring Cisco IPMA for Shared-Line Support

This topic discusses how to configure Cisco IPMA for shared-line support.
Cisco IPMA Manager Configuration

1. Activate the Cisco IPMA service.
2. Configure service parameters.
3. Restart the Cisco IPMA service.
4. Configure a Cisco IPMA manager and assign an
assistant.
5. Access Manager Configuration
(users or administrator).
CIPT1 v4.14-9
Follow these steps to configure Cisco IPMA:

Step 1
Activate the Cisco IPMA service.
Step 2
Configure the appropriate service parameters.
Step 3
Restart the Cisco IPMA service from the Tomcat web page.
Step 4
Configure a Cisco IPMA manager and assign an assistant.
Step 5
Access Manager Configuration to set a divert target for calls.
5-43
Activate the Cisco IPMA Service

Service Activation
Cisco IPMA service is preinstalled on Cisco CallManager.
CIPT1 v4.14-10
The Cisco IPMA service is installed on all Cisco CallManager systems. Administrators need to
activate the service on the servers that they want to use IPMA on. One active and one backup
IPMA server in a cluster is supported.
To activate the Cisco IPMA service, follow these steps:
Step 1
In the Cisco CallManager Administration window, choose Application > Cisco

CallManager Serviceability.
The Cisco CallManager Serviceability window is displayed.
Step 2
Choose Tools > Service Activation.

The Service Activation window displays the list of servers.
Step 3
From the Servers pane, choose the server on which you want to activate Cisco
IPMA.
Step 4
Check the Cisco IP Manager Assistant check box and click Update.
The window displays the services that you chose with an activation status of Activated.
5-44
Configuring Service Parameters
Insert IP address of
Cisco CTIManager
Insert IP address of
primary and backup
Cisco IPMA server
..
.
Softkey templates
preselected
CIPT1 v4.14-11
Configuring the Cisco IPMA-related service parameters enables automatic configuration of

some IP Phone features for the managers and assistants telephones. These features are the
softkey template and Auto Answer with speakerphone for the intercom line.
Service parameters for the Cisco IPMA service consist of two categories: general and
cluster-wide. Specify cluster-wide parameters once for all Cisco IPMA services. Specify
general parameters for each Cisco IPMA service that is installed.
Set the Cisco IPMA service parameters by first using Cisco CallManager Administration to
access them at Service > Service Parameters. Next, choose the server where the Cisco IPMA
application resides, and then choose the Cisco IPMA service.
Cisco IPMA includes the following service parameters that must be configured:
The general parameters include the following:
Cisco CTIManager (Primary) IP Address: No default. Enter the IP address of the

primary Cisco CTIManager that will be used for call control.
Cisco CTIManager (Backup) IP Address: No default. The administrator must

manually enter this IP address.
Route Point Device Name for Proxy Mode: No default. Choose the Cisco IPMA
route point device name (which you configure by using Device > CTI Route Point).
5-45
The cluster-wide parameters include the following:
Cisco IPMA Server (Primary) IP Address: No default. The administrator must

Cisco IPMA Server (Backup) IP Address: No default. The administrator must

Cisco IPMA RNA (Ring No Answer) Forwarding Flag: The default specifies
False. If the parameter is set to True, an assistant telephone that is not answered
forwards to another assistant telephone.
Cisco IPMA RNA Timeout: The default specifies 10 seconds. RNA timeout
determines how long an assistant telephone can go unanswered before the call is
forwarded to another assistant telephone. If Call Forward No Answer (CFNA) and
RNA timeout are both configured, the first timeout to occur takes precedence.
Desktop Heartbeat Interval: The default specifies 30 seconds. This interval timer
specifies how long it takes for failover to occur on the assistant desktop.
Cisco IPMA includes the following softkey template parameters that must be configured as
cluster-wide parameters if you want to use Cisco IPMA automatic configuration for managers
and assistants:
Assistant Softkey Template: The default specifies the Standard IPMA Assistant softkey
template. This parameter specifies the softkey template that is assigned to the assistant
device during Cisco IPMA assistant automatic configuration.
Manager Softkey Template for Shared Mode: The default specifies Standard IPMA
Shared Mode Manager softkey template.
Note
5-46
For proxy-mode configuration, use the Standard IPMA Manager softkey template in place of
the Standard IPMA Shared Mode Manager softkey template.
Stopping and Starting Cisco IPMA Service
IPMA
Service
http://<IPMA server>/manager/list
CIPT1 v4.14-12
The Cisco IPMA service runs as an application on Cisco Tomcat. To start or stop the Cisco
IPMA service, log in to the Tomcat Web Application Manager window by using administrator
privileges. The URL of the Tomcat Web Application Manager web page is http://<IPMA
server>/manager/list, where <IPMA server> specifies the IP address of the server that has the
IPMA service running on it.
The Tomcat Web Application Manager requires Cisco CallManager Release 4.0 or later. It
enables you to start or stop an existing application without having to shut down and restart
Tomcat, which restarts all applications that rely on Tomcat. If you have prior versions of Cisco
CallManager, you will need to stop and then start Tomcat by choosing Start > Programs >
Administrative Tools > Services > Cisco Tomcat. Right-click on Cisco Tomcat and choose
Restart.
5-47
Configuring a Manager and Assigning an

AssistantPart 1
Click Cisco IPMA

from Application
Profiles list.
Choose Continue
to configure a
manager.
CIPT1 v4.14-13
Configure Cisco IPMA manager information before configuring Cisco IPMA information for
an assistant.
Perform the following procedure to configure a Cisco IPMA manager and assign an assistant to
the manager. Before performing these steps, the managers and assistants must already exist in
the Cisco CallManager directory, be associated with their respective devices, and have a shared
line appearance.
Step 1
Choose User > Global Directory.
Step 2
To find the user who will be the Cisco IPMA manager, click the Search button or
enter the username in the field and click the Search button.
Step 3
To display user information for the chosen manager, click the username.
The User Configuration window is displayed.
Step 4
To configure Cisco IPMA information for the manager, click Cisco IPMA from the
Application Profiles menu.
If this is the first time that this user is being configured for Cisco IPMA, the User
Configuration window displays a message to continue configuration for a manager
or to cancel if the user being configured is not a manager. Click the Continue
button.
The User Configuration window is displayed again and this time contains manager
configuration information, such as device name and profile, Cisco IPMA-controlled
lines, and intercom line.
5-48

AssistantPart 2
Check
Automatic
Configuration.
Check Uses
Shared Lines.
Assign
assistants.
Choose intercom
line.
Choose shared
line.
CIPT1 v4.14-14
Follow these steps to configure manager information in the User Configuration window:
Step 1
Check the Uses Shared Lines check box.
Step 2
To assign an assistant to the manager, click the Add/Delete Assistants link.

The Assign Assistants window is displayed. (Assigning assistants is covered in the
next set of steps.)
Step 3
Note
To associate a device name or device profile with a manager, choose the device
name or device profile from the Device Name/Profile drop-down list.
If the manager telecommutes, check the Mobile Manager check box and optionally choose
Device Profile.
Step 4
From the Intercom Line drop-down list, choose the intercom line appearance for the
manager, if applicable.
Step 5
From the Available Lines pane, select a line that you want to be controlled by Cisco
IPMA and click the right arrow. The line appears in the Selected Lines pane.
Configure up to five Cisco IPMA-controlled lines.
Note
Step 6
The Cisco IPMA-controlled lines (selected) must always be the shared-line DN.
To automatically configure the softkey template and Auto Answer with

Speakerphone for the intercom line of the manager telephone, check the Automatic
Configuration check box. Automatic configuration configures the softkey template
and intercom line on the manager telephone or device profile.
5-49

AssistantPart 3
CIPT1 v4.14-15
In the User Configuration window, click the Add/Delete Assistants link. The Assign
Assistants window is displayed. Follow these steps to assign an assistant to a manager:
Step 1
To find an assistant, click the Search button or enter the specific name (either the
full name or partial string) or user ID of the assistant in the search field.
A list of available assistants is displayed in the window.
Step 2
Note
Step 3
Check the check box next to the name of the assistant that you want to assign to the
manager.
A manager can have a maximum of 10 assigned assistants.
To save and continue, click the Insert button; otherwise, to return to the Cisco
IPMA Manager Configuration window, click the Insert and Close button.
The User Configuration window displays the manager configuration, and the
assistant that you configured is displayed in the Assigned Assistants list.
5-50
This topic discusses using the Manager Configuration tool to set a destination for calls that the
manager diverts.
Accessing Manager Configuration Features

Access Cisco
IPMA Manager
Configuration at:
http://<ipma-serverip>/ma/desktop/maLogin.jsp
Set a divert target

(must be a DN).
CIPT1 v4.14-16
Both managers and assistants can modify manager preferences from the Manager Configuration
window at http://<ipma-server-address>/ma/desktop/maLogin.jsp.
Managers can access this window from a website; assistants can access it from the Assistant
Console (Manager > Configuration).
Managers using Cisco IPMA in shared-line mode can set up a divert target and forward calls as
they come in by using the ImmDiv softkey. The divert screen is automatically displayed when
you access the Manager Configuration URL that has been provided here. By default, the divert
target is the active assistant for the manager. Managers and assistants can change this target by
entering a valid telephone number in the Directory Number field. Enter the number exactly as
you would dial it from the managers office telephone.
5-51
Assistant Console
This topic discusses using the Assistant Console interface to place and receive calls.
Using Assistant Console

Menu Bar
Call Control
Buttons
My Calls
Panel
Speed Dials
Panel
Directory
Panel
My Managers
Panel
Status
Bar
CIPT1 v4.14-17
The Assistant Console application includes the following features:

Menu bar: The menu bar is located along the top of the Assistant Console. You can use
the menu bar as follows:
File: Go online or offline, log in or log out, and exit the console
Edit: Create and edit speed dials, personalize keyboard shortcuts, change the
Immediate Divert target, set preferences, and access administrator settings
View: Specify text size and color schemes and refresh the default layout
Call: Dial, answer, hang up, place on hold, transfer, divert, or add conference
participants to a call
Manager: Place an intercom call to a manager, access the Manager Configuration

window, and enable or disable features for a manager
Help: Access online help
Call control buttons: Call control buttons are the row of icons that are located along the
top or side of the console. Roll your mouse over a call control button to see a description of
its function. You can use the call control buttons to perform numerous tasks, such as hold,
resume, transfer, join a call, hold a conference, Immediate Divert, and so on.
5-52
My Calls panel: The Assistant Console displays calls for the assistant and managers in the
My Calls panel. Each telephone line is displayed beneath one of the following headings:
My Lines: Displays any currently active call that the assistant placed or received
using the assistants own telephone line
Manager Lines: Displays active calls that the assistant is handling or can handle on
behalf of the manager
Intercom: Displays the status of intercom lines, if applicable
My Managers panel: Assistants can use the My Managers panel in the Assistant Console
to monitor call activity and feature status for each manager. Assistants can also enable and
disable manager features from this panel.
Speed Dials panel: The speed-dial feature allows assistants to set up a personal phone
book on the Assistant Console and to place calls and perform other call-handling tasks
using speed-dial numbers.
Directory panel: Use the directory to search for a coworker, and then use the search results
to place and handle calls.
Status bar: The status bar is located along the bottom of the Assistant Console screen and
displays the following system information:
Connected or Not Connected: Indicates the status of the assistants connection to

the Cisco IPMA server
Online or Offline: Indicates the availability of the assistant to managers
Call Control Up or Call Control Down: Indicates the availability of call-handling

features
Filtering Down: Indicates the availability of call-filtering features (proxy mode)
5-53
Summary
Summary
Cisco IPMA supports proxy-line mode and
shared-line mode.
The Cisco IPMA architecture comprises the Cisco IPMA
service, the desktop interfaces, and the Cisco IP Phone
interfaces.
Configuring Cisco IPMA consists of configuring service
parameters, configuring a Cisco IPMA manager, and
assigning an assistant.
The Manager Configuration window allows the manager,
assistant, or administrator to set a divert target.
The Assistant Console is the end-user application for
assistants and managers to work together more
effectively.
5-54
CIPT1 v4.14-18
References
Cisco IP Manager Assistant with Proxy Line Support and Cisco IP Manager Assistant
with Shared Line Support.
3/ccmfeat/index.htm
Cisco Systems, Inc. Cisco IP Manager Assistant User Guide for Cisco CallManager 4.1(2).
http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/ipma/user/4_1/in
dex.htm.
5-55
Module 5 Summary
Module Summary
Cisco CallManager Attendant Console is a clientserver application a client-server application, that
allows you to set up Cisco IP Phones as attendant
consoles and manage them from a GUI on the
attendants PC.
Cisco IPMA enables managers and assists to work
together more effectively and includes
enhancements to phone capabilities for the
manager, assistant (primarily), and desktop
interfaces.
CIPT1 v4.15-1
This module covered two user applications that are bundled with Cisco CallManager. The
module first presented the Cisco CallManager Attendant Console, a client-server application
that allows you to set up Cisco IP Phones as attendant consoles and manage them from a GUI
on the attendant PC. The module then covered Cisco IPMA, an application that enables
managers and assistants to work together more effectively using enhancements to the IP Phone
capabilities for the manager, assistant (primarily), and desktop interfaces.
5-56
Module 5 Self-Check
Q1)
Q2)
Match the Cisco CallManager Attendant Console terms on the left with the answer
choice on the right that is most closely associated with the term. (Source: Lesson 5-1,
Configuring Cisco CallManager Attendant Console)
_____ 1.
pilot point
A. first available hunt group member
_____ 2.
hunt group
B. dispatches calls
_____ 3.
queue
C. list of ordered destinations
_____ 4.
distribution algorithm
D. virtual number
_____ 5.
Cisco TCD
E. holding place
When you configure Cisco CallManager Attendant Console server in Cisco

CallManager Administration, what should you do to prevent calls from being dropped
when the queue is full? (Source: Lesson 5-1, Configuring Cisco CallManager
Attendant Console)
A)
B)
C)
D)
Q3)
Which two services must be activated for Cisco CallManager Attendant Console to
function properly? (Choose two.) (Source: Lesson 5-1, Configuring Cisco CallManager
Attendant Console)
A)
B)
C)
D)
E)
Q4)
Configure the queue size limit to 1024.

Configure an always-route member.
Configure a hold time.
Configure a pilot point.

Cisco CTL Provider
Cisco TCD
Cisco CTIManager
Which items can be configured from the Pilot Point Configuration window in Cisco
CallManager Administration? (Source: Lesson 5-1, Configuring Cisco CallManager
Attendant Console)
A)
B)
C)
D)
2005 Cisco Systems, Inc.
queue size
hold time
longest-idle distribution algorithm
circular distribution algorithm
5-57
Q5)
What two steps enable redundancy for the Cisco CallManager Attendant Console
application? (Choose two.) (Source: Lesson 5-1, Configuring Cisco CallManager
Attendant Console)
A)
B)
C)
D)
Q6)
Managers can do which of the following when they access Cisco IPMA Manager
Configuration in shared-line mode? (Source: Lesson 5-2, Configuring Cisco IP
Manager Assistant)
A)
B)
C)
D)
Q7)
intercom
assistants primary
shared DN
proxy
speed dial
Which statement is most closely associated with Cisco IPMA shared-line mode?
(Source: Lesson 5-2, Configuring Cisco IP Manager Assistant)
A)
B)
C)
D)
5-58
configure speed dials

change the divert target
assign an assistant
subscribe to services
When you configure Cisco IPMA in shared-line mode, the Cisco IPMA-controlled line
must always be which line? (Source: Lesson 5-2, Configuring Cisco IP Manager
Assistant)
A)
B)
C)
D)
E)
Q8)
Run Cisco CTIManager on all servers in the cluster and the Cisco TCD service
on at least one server in the Cisco CallManager cluster.
Run the Cisco TCD service on all servers in the Cisco CallManager cluster and
Cisco CTIManager on at least one server in the cluster.
Enter the IP address of one server that is running Cisco TCD on the attendant
PC.
Enter the IP address of one server that is running Cisco CTIManager on the
attendant PC.
supports newer features such as Call Join, Privacy, and Direct Transfer
uses call filters and partitions to route calls to the assistant
uses the Standard IPMA Manager softkey template
uses Cisco Tomcat to load the Cisco IPMA service

Q1)
1. D, 2. C., 3. E, 4. A, 5. B
Q2)
Q3)
C, E
Q4)
Q5)
B, C
Q6)
Q7)
Q8)
5-59
5-60
CIPT1
Cisco IP Telephony
Part 1
Version 4.1
Lab Guide
CLS Production Services: 08.18.05
Copyright
2005, Cisco Systems, Inc. All rights reserved.
Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax
numbers are listed on the Cisco Website at www.cisco.com/go/offices.
Argentina Australia Austria Belgium Brazil Bulgaria Canada Chile China PRC Colombia Costa Rica
Croatia Cyprus Czech Republic Denmark Dubai, UAE Finland France Germany Greece
Hong Kong SAR Hungary India Indonesia Ireland Israel Italy Japan Korea Luxembourg Malaysia
Mexico The Netherlands New Zealand Norway Peru Philippines Poland Portugal Puerto Rico Romania
Russia Saudi Arabia Scotland Singapore Slovakia Slovenia South Africa Spain Sweden Switzerland
Taiwan Thailand Turkey Ukraine United Kingdom United States Venezuela Vietnam Zimbabwe
Copyright 2005 Cisco Systems, Inc. All rights reserved. CCSP, the Cisco Square Bridge logo, Follow
Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live,
Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, ASIST,
BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo,
Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Empowering
the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive,
GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard,
LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar,
Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, StrataView
Plus, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are
registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of
the word partner does not imply a partnership relationship between Cisco and any other company. (0501R)
DISCLAIMER WARRANTY: THIS CONTENT IS BEING PROVIDED AS IS. CISCO MAKES AND YOU RECEIVE NO
WARRANTIES IN CONNECTION WITH THE CONTENT PROVIDED HEREUNDER, EXPRESS, IMPLIED, STATUTORY
OR IN ANY OTHER PROVISION OF THIS CONTENT OR COMMUNICATION BETWEEN CISCO AND YOU. CISCO
SPECIFICALLY DISCLAIMS ALL IMPLIED WARRANTIES, INCLUDING WARRANTIES OF MERCHANTABILITY,
NON-INFRINGEMENT AND FITNESS FOR A PARTICULAR PURPOSE, OR ARISING FROM A COURSE OF DEALING,
USAGE OR TRADE PRACTICE. This learning product may contain early release content, and while Cisco believes it to be
accurate, it falls subject to the disclaimer above.
CIPT1
Lab Guide
Overview
This guide presents the instructions and other information concerning the lab activities for this
course.
Outline
This guide includes these activities:
Lab 1-1: Performing Cisco CallManager Postinstallation Tasks
Lab 2-1: Configuring Cisco CallManager to Support Cisco IP Phones
Lab 2-2: Configuring Auxiliary or Voice VLANs
Lab 2-3: Configuring Cisco IP Communicator
Lab 2-4: Using the Bulk Administration Tool
Lab 3-1: Configuring Gateways and Intercluster Trunks
Lab 3-2: Configuring Basic Route Plans
Lab 3-3: Configuring Hunt Groups and Call Coverage
Lab 3-4: Configuring Complex Route Plans
Lab 3-5: Implementing Class of Control
Lab 3-6: Configuring Call Admission Control
Lab 3-7: Configuring SRST
Lab 4-1: Configuring Media Resources
Lab 4-2: Adding Users and Customizing User Options
Lab 4-3: Configuring User Features Part 1
Lab 4-4: Configuring Cisco CallManager Extension Mobility
Lab 5-1: Configuring Cisco CallManager Attendant Console
Lab 5-2: Configuring Cisco IPMA
Answer Key
Lab Topology
This figure illustrates the logical view of your pod and how it interconnects with the rest of the
class lab topology.
CIPT1 Lab Topology

Pod
Cisco CallManager Cluster

Publisher
Subscriber
Cisco
Catalyst 6500
Chassis
DSP Resources
(Conference and Transcoder)
PSTN
6348 Inline
Cisco 2600
Power Module
Voice
Gateway with
SRST
(To Another Cluster)

6608 Voice T1
or E1 Services
Module
Cisco 7960 IP
Phones
Analog Phone
WAN
(To Another Cluster)

Core WAN Router
and Gatekeeper
CIPT1 v4.11
This figure illustrates a more detailed physical view of the overall lab topology.
CIPT Lab Topology: Detail

East 2 Cluster
EAST2A
172.16.20.5
EAST2B
172.16.20.6
East2-default-gw
172.16.20.1
Dot1Q
Trunk
East 3 Cluster
East3-default-gw
Analog Trunks 172.16.30.1
1/1/0 FXO
1/0/0 FXS
1/0/0 FXS
1/1/0 FXO
Cisco Catalyst 6500
EASTt3A
172.16.30.5
Dot1Q
Trunk
172.16.1.3
Cisco 7960 IP Phone
EAST3B
172.16.30.6
Cisco 7960 IP Phone
GK/WAN
Router
East 1 Cluster
EAST1A
172.16.10.5
Dot1Q
Trunk
Cisco 7960 IP Phone
East 4 Cluster
172.20.1.1
EAST1B
172.16.10.6
EAST4A
172.16.40.5
Dot1Q
Trunk
Analog Trunks
1/1/0 FXO
1/0/0 FXS
1/0/0 FXS
1/1/0 FXO
East1-default-gw
172.16.10.1
EAST4B
172.16.40.6
East4-default-gw
172.16.40.1
Cisco 7960 IP Phone
CIPT1 v4.12
Lab Guide
Lab 1-1: Performing Cisco CallManager

Postinstallation Tasks
Complete this lab activity to practice what you learned in the related module.
Activity Objective
In this activity, you will perform Cisco CallManager postinstallation tasks on a supported Cisco
IP telephony server. After completing this activity, you will be able to meet these objectives:
Activate appropriate services
Stop unnecessary services
Back up the Cisco CallManager publisher database
Visual Objective
The figure illustrates what you will accomplish in this activity.
Visual Objective for Lab 1-1: Performing

Cisco CallManager Postinstallation Tasks
Cluster
172.16.x0.5
Publisher
Connect to the
publisher.
Activate services.
Stop unnecessary
services.
Back up publisher.
172.16.x0.6
Subscriber
CIPT1 v4.13
In this activity, you will connect to Cisco CallManager Administration using a browser and
Remote Desktop Connection. You will activate all services on the publisher and subscriber,
turn off unnecessary services, and back up the publisher database.
Required Resources
These are the resources and equipment required to complete this activity:
Supported Cisco IP telephony server platform with monitor, keyboard, and mouse
Cisco Catalyst switch (6000, 4000, 3500, or 2900 Series)
RJ-45 straight-through Ethernet cables
Job Aids
These job aids are available to help you complete the lab activity.
Data for Task 1
Cluster Name
Publisher
Subscriber
Time Zone
Default
Gateway
IP Address
Computer
Name
IP Address
Computer
Name
IP Address
East 1
EAST1A
172.16.10.5
EAST1B
172.16.10.6
Eastern
172.16.10.1
East 2
EAST2A
172.16.20.5
EAST2B
172.16.20.6
Eastern
172.16.20.1
East 3
EAST3A
172.16.30.5
EAST3B
172.16.30.6
Eastern
172.16.30.1
East 4
EAST4A
172.16.40.5
EAST4B
172.16.40.6
Eastern
172.16.40.1
West 1
WEST1A
172.32.10.5
WEST1B
172.32.10.6
Pacific
172.32.10.1
West 2
WEST2A
172.32.20.5
WEST2B
172.32.20.6
Pacific
172.32.20.1
West 3
WEST3A
172.32.30.5
WEST3B
172.32.30.6
Pacific
172.32.30.1
West 4
WEST4A
172.32.40.5
WEST4B
172.32.40.6
Pacific
172.32.40.1
Note
The data in the Configuration Data Sheet for the Cisco IP Telephony Server table that
follows was used during the Cisco CallManager installation process for this Lab Guide and is
provided for your reference.
Lab Guide
Configuration Data Sheet for the Cisco IP Telephony Server

Operating System
Configuration
Your Entry Data
Cisco product key
BTOO VQES CCJU IEBI
Username
Administrator
Name of your organization
cisco
Computer name
DNS domain suffix
dal-trn.cisco.com
Workgroup
CIPT
Current time zone, date, and time

DHCP Parameters
(It is recommended that you program a fixed IP address in TCP/IP Properties for the server instead of
using DHCP.)
TCP/IP properties (required if DHCP is not
used):
IP address
Subnet mask
Default gateway
IP address:
Subnet mask:
255.255.255.0
Default gateway:
DNS servers (optional)
None
LMHOSTS information
IP Address
Server Name
Publisher information
Subscriber information
Cisco CallManager Installation
Database server
Password of publisher
cisco
Backup
New system administrator password
cisco
sa password?
cisco
Private password phrase
cisco
DC-Directory
cisco
Task 1: Connect to Cisco CallManager

The Cisco CallManager application and operating system software has been installed on your
publisher and subscriber servers.
In this task, you will use Microsoft Internet Explorer and Windows Terminal Services to
connect remotely to Cisco CallManager Administration. The preferred remote connection
method is to use Microsoft Internet Explorer, but from time to time you will use Remote
Desktop Connection for certain tasks.
Activity Procedure
Complete these steps:
Step 1
To access Cisco CallManager Administration from your browser, launch Internet

Explorer and enter https://<publisher IP address>/CCMAdmin in the address
field (see the configuration data for Task 1 for your publisher IP address).
Step 2
Choose Yes when the Security Alert dialog box appears.
Step 3
At the popup window, enter the username Administrator and the password cisco.
The CallManager Administration main window appears.
Step 4
To access Remote Desktop Connection, choose Start > Programs > Accessories >
Communications > Remote Desktop Connection.
A connection window opens.
Step 5
Choose the publisher IP address from the drop-down list and click Connect. (Enter
the publisher IP address if it is not present in the drop-down list.)
Step 6
If the Windows login screen appears, enter the username Administrator and the
password cisco.
The Windows desktop appears.
Step 7
Choose Start > Programs > Cisco CallManager 4.1 > CallManager
Administration.
Step 8
Choose Yes when the Security Alert dialog box appears.

The CallManager Administration main window appears.
Step 9
Log in to Cisco CallManager Administration using Administrator for the username

and cisco for the password.
Step 10
To log out, choose Start > Shutdown and then choose Logoff Administrator. Do
not choose Shutdown or Restart. Upon logging out, you are returned to your
desktop.
Note
Remote Desktop Connection will log you out after several minutes of inactivity; however, it is
advisable to always manually log out of Cisco CallManager when you have finished using
Remote Desktop Connection.
Lab Guide
Activity Verification
You have completed this task when you attain this result:
You can log in to your publisher using both remote connection methods.
Task 2: Activate Cisco CallManager Services

In this task, you will activate Cisco CallManager services.
Activity Procedure
Step 1
From the Cisco CallManager Administration window, choose Application > Cisco
CallManager Serviceability.
The Cisco CallManager Release 4.1 Serviceability main window appears.
Step 2
Choose Tools > Service Activation.

The Service Activation window appears.
Step 3
Choose the publisher server from the list of servers on the left side of the Service
Activation window.
Step 4
Check all the services, and click Update.
Step 5
Repeat Steps 3 and 4 for the subscriber server.
All of the services are active on both the publisher and the subscriber.
Task 3: Stop Unnecessary Services

In this task, you will stop unnecessary services on the publisher and subscriber.
Activity Procedure
Step 1
From your laptop, use Remote Desktop Connection to connect to your publisher.
Step 2
Choose Start > Programs > Administrative Tools > Services.

The Services window opens.
Step 3
Stop the services that are listed on the publisher and on the subscriber. To stop a
service, right-click the service and choose Properties. In the Startup Type field,
choose Manual and then stop the service. Click Apply and then click OK. These
are the specific services that you should stop:
Computer browser
DHCP client
License logging service
Note
For this lab activity, you will leave the IIS Admin Service and World Wide Web Publishing
Service enabled on the subscriber. It is recommended that you also stop these services in a
live Cisco CallManager deployment.
The services specified are stopped on both the publisher and the subscriber.
Task 4: Back Up the Publisher

In this task, you will install the Cisco IP Telephony Backup and Restore System (BARS) on the
publisher, designate the publisher as the backup server (the device that performs the backup),
and back up the publisher Cisco CallManager application.
Activity Procedure
Install BARS
Your instructor has downloaded the BARS utility and placed it on the publisher desktop in a
folder named Apps_Tools. You will first need to install BARS. You cannot use terminal
services to install BARS. You must have a console connection to Cisco CallManager.
Step 4
From the publisher desktop, locate and open the Apps_Tools > BARS folder.
Step 5
Double-click the MCSBackupSystem.4-0-7.exe file to start the BARS installation

wizard.
Step 6
Click Next.
Step 7
Accept the license agreement and click Next.
Step 8
Choose Backup Server. Click Next.

The BackAdmin Password window appears.
Step 9
Enter cisco in the BackAdmin Private Password Phrase field and click Next.
Step 10
Follow the instructions on the screen and complete the installation process.
Step 11
When the process is complete, reboot the server. When the publisher is restarted,
you may proceed to the next task.
Lab Guide
Back Up the Cisco CallManager Publisher Database

Next, you will add a data source server (where the data that you want to back up currently
resides) and choose Cisco CallManager as the application to back up.
Step 1
After BARS has been installed, access the BARS administration web interface by
using Remote Desktop Connection to connect to the publisher. When you are
connected, choose Start > Programs > Cisco BARS > BARSAdmin.
Step 2
Enter administrator for the username and cisco for the password.
The Backup and Restore System main window appears.
Note
You can also access the BARS administration web interface from anywhere on the network
by entering http://<backup server IP address>/BARS/BARSmain.asp.
Step 3
From the Backup and Restore System main window, choose Backup > Data Source
Servers.
Step 4
In the DNS/IP Address field, enter the publisher IP address.
Step 5
In the Description field, enter <publisher name_Publisher> (example:

EAST1A_Publisher).
Step 6
Click Next.
Step 7
Choose CCM as the application that you want to back up on the data source server.
Step 8
Click Finish.
The Data Source Server Summary Configuration window opens.
Step 9
View the backup schedule. What is the current (default) backup schedule?
_______________________________________________
Step 10
Click Modify Schedule if you wish to change the backup schedule. You can
configure any days that you wish as long as the time is after class hours.
Step 11
Click Modify Backup Storage Location to establish the path where the backup
files will be backed up.
Step 12
Click the Local Directory radio button (if it is not already enabled) and enter
C:\Backup to create a folder where the backup files will be placed.
Step 13
Click Update.
Caution
10
In normal operation, you should send the backup to a network drive or a tape drive (if the
server has one) and not to the servers own hard drive from which you are backing up the
data. For the lab activity only, you will send the backup to the local publisher C: drive
Step 14
To create the folder, read the next two windows and then click OK.
Step 15
Choose Backup > Backup Now. Click Start Backup Now.
The backup begins, and the current status window is displayed. When the backup is
complete, the status window automatically closes.
Step 16
Was the backup successful? ______ How did you verify the outcome of the backup?
__________________________________________________________________
Step 17
The backup process creates a backup log file with the following format: Backupmmdd-yy.txt, where mm specifies the month, dd specifies the day, and yy specifies the
year. BARS puts this file in the following location on the backup server: C:\Program
Files\Common Files\Cisco\Logs\BARS\Backup.
Navigate to the backup log file, open it, and view the contents.
Backup files have the following format: Backupmm-dd-yy. Go to the backup folder on the
publisher (C:\Backup) and verify that a backup file was created with the current date in the
filename.
Answers to Lab Questions

The answers to the lab questions are as follows:
Step 18
Answer to Task 4, Step 9.
Step 19
Answer to Task 4, Step 16.
Lab Guide
11
Lab 2-1: Configuring Cisco CallManager to

Support Cisco IP Phones
Activity Objective
In this activity, you will add and register Cisco IP Phones to an IP telephony cluster. After
completing this activity, you will be able to meet these objectives:
Configure a DHCP scope on the publisher or default gateway router to provide IP addresses
and other options to network devices
Configure system parameters, including the Cisco CallManager server, Cisco CallManager
group, and device pools, to prepare the Cisco CallManager cluster to auto-register
telephones
Manually configure an IP Phone and DN
Visual Objective
This figure illustrates what you will accomplish in this activity.
Visual Objective for Lab 2-1: Configuring Cisco

CallManager to Support Cisco IP Phones
Cluster
x000
Publisher
Subscriber
IP Phones register
with Cisco
CallManager.
x001
Cisco Catalyst
Switch Inline
Power Module
Cisco 2600
Default Gateway
x002
3
IP Phones can call one
another within the cluster.
1
DHCP router provides
IP address, default
gateway, and TFTP
server to IP Phones.
CIPT1 v4.14
In this activity, you will configure DHCP on the default gateway to provide an IP address,
default gateway IP address, and TFTP server IP address to the IP Phones. The IP Phones then
contact their TFTP server (publisher) to obtain their load and a prioritized list of Cisco
CallManager servers. The IP Phones will then register with the Cisco CallManager servers and
obtain a DN (if not manually assigned) and other configuration information. You will then be
able to place calls to other IP Phones within your cluster.
12
Required Resources
Cisco CallManager cluster
Cisco IP Phones (such as 7910, 7940, or 7960)
RJ-45 straight-through Ethernet cables
Cisco Catalyst switch
DHCP server (use publisher server or default gateway)
Command List
The table describes the commands that are used in this activity.
Cisco Router IOS Commands
Command
Description
To enter privileged EXEC mode, or any other security level set by a

system administrator, use the enable EXEC command.
Enters global configuration mode.

--
Specifies the IP addresses that the DHCP server should not assign
to DHCP clients.
Creates a name for the DHCP server address pool and places you
in DHCP pool configuration mode (identified by the config-dhcp#
prompt).
Specifies the subnet network number and mask of the DHCP

address pool.
Specifies the IP address of the default router for a DHCP client.

One IP address is required, although you can specify up to eight
addresses in one command line.
--
DHCP provides a framework for passing configuration information

to hosts on a TCP/IP network. Configuration parameters and other
control information are carried in tagged data items that are stored
in the Options field of the DHCP message. The data items
themselves are also called options.
--
Enables to remotely access systems.
Saves the router configuration to NVRAM.
Lab Guide
13
Job Aids
DHCP Addressing and Scope Information for Cisco IOS Router
Cluster
Name
Pool
Type
Pool Name
Network and Mask
Default
Router
Option 150
Excluded
Addresses,
Start and
End
East 1
Voice
EAST1-Voice
10.16.10.0 255.255.255.0
10.16.10.1
172.16.10.5
Data
EAST1-Data
172.16.10.0 255.255.255.0
172.16.10.1
10.16.10.1 to
10.16.10.10
Voice
EAST2-Voice
10.16.20.0 255.255.255.0
10.16.20.1
Data
EAST2-Data
172.16.20.0 255.255.255.0
172.16.20.1
Voice
EAST3-Voice
10.16.30.0 255.255.255.0
10.16.30.1
Data
EAST3-Data
172.16.30.0 255.255.255.0
172.16.30.1
Voice
EAST4-Voice
10.16.40.0 255.255.255.0
10.16.40.1
Data
EAST4-Data
172.16.40.0 255.255.255.0
172.16.40.1
Voice
WEST1-Voice
10.32.10.0 255.255.255.0
10.32.10.1
Data
WEST1-Data
172.32.10.0 255.255.255.0
172.32.10.1
Voice
WEST2-Voice
10.32.20.0 255.255.255.0
10.32.20.1
Data
WEST2-Data
172.32.20.0 255.255.255.0
172.32.20.1
Voice
WEST3-Voice
10.32.30.0 255.255.255.0
10.32.30.1
Data
WEST3-Data
172.32.30.0 255.255.255.0
172.32.30.1
Voice
WEST4-Voice
10.32.40.0 255.255.255.0
10.32.40.1
Data
WEST4-Data
172.32.40.0 255.255.255.0
172.32.40.1
East 2
East 3
East 4
West 1
West 2
West 3
West 4
14
172.16.10.1
to
172.16.10.10
172.16.20.5
10.16.20.1 to
10.16.20.10
172.16.20.1
to
172.16.20.10
172.16.30.5
10.16.30.1 to
10.16.30.10
172.16.30.1
to
172.16.30.10
172.16.40.5
10.16.40.1 to
10.16.40.10
172.16.40.1
to
172.16.40.10
172.32.10.5
10.32.10.1 to
10.32.10.10
172.32.10.1
to
172.32.10.10
172.32.20.5
10.32.20.1 to
10.32.20.10
172.32.20.1
to
172.32.20.10
172.32.30.5
10.32.30.1 to
10.32.30.10
172.32.30.1
to
172.32.30.10
172.32.40.5
10.32.40.1 to
10.32.40.10
172.32.40.1
to
172.32.40.10
DHCP Scope Options for Windows 2000 Server

Cluster
Name
East 1
East 2
East 3
East 4
West 1
West 2
West 3
West 4
Pool
Type
Scope Name
Start IP
Address
End IP
Address
Subnet Mask
Default
Router
Voice
EAST1-Voice
10.16.10.10
10.16.10.30
255.255.255.0
10.16.10.1
Data
EAST1-Data
172.16.10.10
172.16.10.30
255.255.255.0
172.16.10.1
Voice
EAST2-Voice
10.16.20.10
10.16.20.30
255.255.255.0
10.16.20.1
Data
EAST2-Data
172.16.20.10
172.16.20.30
255.255.255.0
172.16.20.1
Voice
EAST3-Voice
10.16.30.10
10.16.30.30
255.255.255.0
10.16.30.1
Data
EAST3-Data
172.16.30.10
172.16.30.30
255.255.255.0
172.16.30.1
Voice
EAST4-Voice
10.16.40.10
10.16.40.30
255.255.255.0
10.16.40.1
Data
EAST4-Data
172.16.40.10
172.16.40.30
255.255.255.0
172.16.40.1
Voice
WEST1-Voice
10.32.10.10
10.32.10.30
255.255.255.0
10.32.10.1
Data
WEST1-Data
172.32.10.10
172.32.10.30
255.255.255.0
172.32.10.1
Voice
WEST2-Voice
10.32.20.10
10.32.20.30
255.255.255.0
10.32.20.1
Data
WEST2-Data
172.32.20.10
172.32.20.30
255.255.255.0
172.32.20.1
Voice
WEST3-Voice
10.32.30.10
10.32.30.30
255.255.255.0
10.32.30.1
Data
WEST3-Data
172.32.30.10
172.32.30.30
255.255.255.0
172.32.30.1
Voice
WEST4-Voice
10.32.40.10
10.32.40.30
255.255.255.0
10.32.40.1
Data
WEST4-Data
172.32.40.10
172.32.40.30
255.255.255.0
172.32.40.1
Option 150
172.16.10.5
172.16.20.5
172.16.30.5
172.16.40.5
172.32.10.5
172.32.20.5
172.32.30.5
172.32.40.5
Cisco CallManager Configuration

Cluster
Name
Publisher
Cisco
CallManager
Name
IP Address
East 1
EAST1A
East 2
Subscriber
Cisco
CallManager
Name
IP Address
Start
End
172.16.10.5
EAST1B
172.16.10.6
1000
1999
EAST2A
172.16.20.5
EAST2B
172.16.20.6
2000
2999
East 3
EAST3A
172.16.30.5
EAST3B
172.16.30.6
3000
3999
East 4
EAST4A
172.16.40.5
EAST4B
172.16.40.6
4000
4999
West 1
WEST1A
172.32.10.5
WEST1B
172.32.10.6
1000
1999
West 2
WEST2A
172.32.20.5
WEST2B
172.32.20.6
2000
2999
West 3
WEST3A
172.32.30.5
WEST3B
172.32.30.6
3000
3999
West 4
WEST4A
172.32.40.5
WEST4B
172.32.40.6
4000
4999
Server
Function
AutoRegistration
DN Range
Server
Function
Lab Guide
15
Task 1: Configure the DHCP Service

You will configure the DHCP service on either the default router or the publisher server (not
both) to provide the IP address and other scope options to network devices.
Activity Procedure
DHCP on a Router
You will configure an IP DHCP pool on the default router for your cluster.
Step 1
Refer to the DHCP Addressing and Scope Information for Cisco IOS Router table
in the Job Aids section of this lab activity. Refer to the Default Router column.
Write down the 172.xx.xx.x IP address of your default router:__________________
Step 2
From your laptop, establish a Telnet session to your default router. (Choose Start >
Run and enter telnet <default router IP address>.) Enter cisco for the password.
Step 3
After connecting to the router, you will be in user mode. To enter enable mode (also
known as privileged mode), enter enable and enter the password cisco.
Step 4
From enable mode, enter configuration mode by entering the configure terminal or
config t command.
Step 5
Exclude IP addresses from the DHCP pool. Refer to the Excluded Addresses, Start
and End column of the DHCP Addressing and Scope Information for Cisco IOS
Router table. Enter the following command twice, once for the data pool and once
for the voice pool:
-- - -- --
Step 6
Refer to the DHCP Addressing and Scope Information for Cisco IOS Router table.
Configure an IP DHCP pool for voice by entering the following commands:

- -- - -

- --
Step 7
Refer to the DHCP Addressing and Scope Information for Cisco IOS Router table.
Configure a DHCP pool for data by using the following commands:

- -- - -

- --
Step 8
Save the router configuration. Press Ctrl-Z and then enter the following command:
-
16
DHCP on the Publisher

You will configure the DHCP service to run on the publisher. Do not complete this task if you
have already configured DHCP on the router.
Step 1
On the publisher, choose Start > Programs > Administrative Tools > Services to
open the services.
Step 2
Scroll down to the DHCP Server service, and right-click Properties.
Step 3
Set the Startup Type to Automatic, and click Apply. Click Start to start the service,
and click OK.
Step 4
Open the DHCP server service by choosing Start > Programs > Administrative
Tools > DHCP.
Step 5
Click the plus (+) symbol next to Server Name [IP Address] to view the Server
Options folder.
Step 6
Right-click Server Name [IP Address], and choose Set Predefined Options.
Step 7
When the Predefined Options and Values box opens, click Add.
Step 8
For the name, enter Cisco TFTP; for the data type, choose IP Address; for the
code, enter 150; and for the description, enter Cisco TFTP server IP address.
Step 9
Click OK.
Step 10
In the Predefined Options and Value box, enter the IP address of the publisher server
for the value, and click OK.
Step 11
Right-click the Server Name [IP Address] option, and choose New Scope.
Step 12
When the New Scope Wizard opens, click Next.
Step 13
Enter the scope name for the data pool from the DHCP Addressing and Scope
Information for Cisco IOS Router table. Enter Network devices not phones for the
description, and click Next.
Step 14
Using the information in the DHCP Scope Options for Windows 2000 Server
table (from the Job Aids section of this lab), enter the starting IP address, ending IP
address, and subnet mask, and click Next.
Step 15
In the Add Exclusions window, click Next.
Step 16
In the Lease Duration window, click Next.
Step 17
In the Configure DHCP Options window, ensure that the Yes, I Want to Configure
These Options Now option is selected, and click Next.
Step 18
Enter the default router IP address for the data scope from the DHCP Scope
Options for Windows 2000 Server table in the Job Aids section of this lab, and
click Add. Click Next.
Step 19
In the Domain Name and DNS Servers window, click Next.
Step 20
In the WINS Servers window, click Next.
Lab Guide
17
Step 21
In the Activate Scope window, ensure that the Yes, I Want to Activate This Scope
Now option is selected, and click Next.
Step 22
Click Finish.
Step 23
Next to the Scope[IP Address] <scope name> folder, click the plus (+) sign to
expand the directory.
Step 24
Right-click the Scope Options folder, and choose Configure Options to add option
150 to this scope.
Step 25
Scroll down to check the Option Code 150 check box, and ensure that the IP
address shown is the IP address of the publisher server (where the Cisco TFTP
service is running).
Step 26
Click Apply, and then click OK.
Step 27
Repeat Steps 15 through 26 to add a scope for the IP Phones (voice).
Verification of this activity will be a part of the last task of this lab.
Task 2: Configure System Configuration Parameters

In this task, you will configure the Cisco CallManager server in your cluster to prepare it before
connecting devices.
Activity Procedure
Step 1
From your laptop, browse to the publisher server at http://<publisher IP

address>/CCMAdmin.
Step 2
In Cisco CallManager Administration, choose System > Server to open the Find
and List Servers window.
Step 3
Click Find.
Step 4
Obtain the IP addresses of your servers from the Cisco CallManager

Configuration table in the Job Aids section of this lab.
In Cisco CallManager Administration, select one of the servers from the list. Change
the name of the server to the IP address of that server by deleting the name that
appears in the DNS/IP Address field and replacing it with the IP address for that
server.
Step 5
Obtain your cluster name and server function from the Cisco CallManager
Configuration table in the Job Aids section of this lab.
In Cisco CallManager Administration, enter <Cluster Name_Server Function> in
the Description field (example: East 1_Subscriber/Primary Call Handler).
18
Step 6
Click Update.
Step 7
Click Back to Find/List Servers.
Step 8
Repeat Steps 5 through 7 for the other server.
Cisco CallManager Configuration

You will now select the publisher server in the cluster, edit the Cisco CallManager name, and
fill in the description with the function of the server from the Cisco CallManager
Configuration table.
Step 1
Choose System > Cisco CallManager to open the Cisco CallManager

Step 2
Click Find. Choose the name of the publisher server.
Step 3
Do not change the name of the publisher. Enter the function of the server in the
cluster into the Description field (example, Publisher/Backup Call Handler).
(Refer to the Cisco CallManager Configuration table in the Job Aids section of
this lab activity.)
Step 4
Enter the appropriate starting and ending DN from the Cisco CallManager
Configuration table. The system will automatically uncheck the Auto-Registration
Disabled on This Cisco CallManager check box.
Step 5
Click Update.
You will now select the subscriber server in the cluster, edit the Cisco CallManager
name, fill in the description with the function of the server, and set up autoregistration.
Step 6
Click the Back to Find/List Cisco CallManagers link at the top right side of the
window.
Step 7
Choose the name of the subscriber server.
Step 8
Do not change the name of the subscriber. Enter the function of the server in the
cluster in the Description field.
Step 9
Enter the starting and ending DN. (Refer to the Cisco CallManager Configuration
table in the Job Aids section of this lab activity.)
Step 10
Click Update.
Cisco CallManager Groups

Step 11
Choose System > Cisco CallManager Group to open the Cisco CallManager
Group Configuration window.
Step 12
Choose the name Default in the Cisco CallManager Group field. (Click Find if the
Default group is not displayed.)
Step 13
Rename the Default group BA_CMG.
Step 14
In the Cisco CallManager Group Members area, the A Cisco CallManager

(EAST1A, for example) should already be in the Selected Cisco CallManagers pane.
Highlight the B server (EAST1B, for example) in the Available Cisco
CallManagers pane. Use the arrow between the two boxes to move the B server to
the Selected Cisco CallManagers pane.
Step 15
Use the Up arrow and Down arrow to place the B Cisco CallManager at the top of
the list, making it the primary Cisco CallManager for the group.
Lab Guide
19
Step 16
Click Update and click OK. Verify that the BA_CMG Cisco CallManager group is
shown above the Status: Update completed line at the top of the window.
Note
The Cisco CallManager groups are named to indicate their primary Cisco CallManager.
Configure Device Pools

In this task, you will create device pools that are named to reflect their Cisco CallManager
group, date and time group, and region. A device pool is named BA_Default_CMLocal_DP if it
uses the BA_CMG CallManager group, the default region, and the CMLocal date and time
group.
Step 17
Choose System > Device Pool to open the Find and List Device Pools window.
Click Find.
Step 18
Click Default under the Device Pool Name heading.
Step 19
Change the Device Pool Name field from Default to BA_Default_CMLocal_DP.
Step 20
Use the drop-down lists to ensure that the following characteristics are selected:
Cisco CallManager Group: BA_CMG
Date/Time Group: CMLocal (use the Cisco CallManager internal clock)
Region: Default (G.711) (default)
Softkey Template: Standard User (default)
SRST Reference: Disable (default)
Step 21
Click Update.
In Cisco CallManager Administration, choose System > Device Pool and select the device
pool. The name should reflect the device pool settings.
Task 3: Manually Add and Configure an IP Phone

In this task, you will manually add a single Cisco IP Phone and assign a DN. The other
telephones will be configured through auto-registration.
Activity Procedure
20
Step 1
From Cisco CallManager Administration, choose Device > Add a New Device.
Step 2
From the Device type drop-down list, choose Phone. Click Next.
Step 3
From the Phone type drop-down list, choose Cisco 7960. Click Next.
Step 4
Obtain the MAC address from one of your IP Phones and enter it in the MAC
Address field. One way to obtain the MAC address is to look on the bar code that is
located on the bottom back of the Cisco IP Phone.
Step 5
Enter Smith, Tom x000 in the Description field (where x = your pod number).
Step 6
Choose BA_Default_CMLocal_DP from the Device Pool drop-down list.
Step 7
Scroll down to the Phone Button Template drop-down list and choose Standard
7960.
Step 8
Click Insert. (You will configure additional parameters later in the course.) Click
OK to continue to configure line 1. The Directory Number Configuration window
appears.
Step 9
Enter x000 (where x = your pod number) in the Directory Number field.
Step 10
Click Add. (You will configure additional parameters later in the course.)
A popup window appears, indicating that the number has been assigned.
Step 11
Click OK to return to the Phone Configuration window.
Step 12
From the table here, determine the correct switch ports for your pod. Insert an
Ethernet cable into one of the free switch ports and into the other end of the IP
Phone that you just configured.
Cisco Catalyst Switch Ports for IP Phones

Cluster
Ports
East 1
2/32/11
East 2
2/152/23
East 3
2/272/35
East 4
2/392/47
Step 13
Observe the IP Phone cycle through the registration process. When the telephone has
successfully registered, it displays the date, time, and DN.
You have completed this activity when you attain these results:
The Cisco IP Phone obtains the DN that you specified on line 1.
Verification that you can place calls will be part of the next task of this exercise.
Lab Guide
21
Task 4: Plug the Cisco IP Phone into the Network

In a previous task, you configured auto-registration of the Cisco CallManager group and
assigned a DN range that this group can provide when the telephone auto-registers. In this task,
you will plug the remaining Cisco IP Phones into the network, and the IP Phones will
auto-register, getting the DN from the Cisco CallManager Configuration window and then
registering to the appropriate Cisco CallManager group that was assigned by the device pool on
the Default Devices Configuration window.
Activity Procedure
Step 1
Determine the correct switch ports for your pod. Insert an Ethernet cable into one of
those ports and insert the other end into the IP Phone. Do this step for both
remaining IP Phones in your cluster.
Step 2
Observe the IP Phones cycle through the registration process. When the IP Phones
have successfully registered, they will display the date, time, and DN.
Step 3
On a registered IP Phone, press the Settings key, and then press the 3 button on your
keypad to view the network settings in the telephone. Press 21 to view the Cisco
CallManager settings.
The IP address of the Cisco CallManager that is designated as the primary
CallManager is displayed first with the word active to the right. The IP address of
the backup (secondary) Cisco CallManager is displayed next with the word
standby to the right. The subscriber (172.xx.xx.6) should be active. The publisher
(172.xx.xx.5) should be on standby.
Step 4
In Cisco CallManager Administration, choose Device > Phone and click Find
without changing any parameters. A list of all configured IP Phones is displayed.
The telephone device pool and IP address of the Cisco CallManager to which the IP
Phone is currently registered is displayed. The IP address of the Cisco CallManager
is listed under the Status column. Note that the Description field is different for
the IP Phone that was manually configured compared to the one that auto-registered.
The Cisco IP Phones have DNs and you are able to call from one IP Phone to another
within the cluster.
22
Lab 2-2: Configuring Auxiliary or Voice VLANs

Activity Objective
In this activity, you will configure auxiliary or voice VLANs to distinguish between voice and
data traffic. After completing this activity, you will be able to meet this objective:
Configure auxiliary or voice VLANs on the provided Cisco Catalyst switch
Visual Objective
Visual Objective for Lab 2-2: Configuring

Auxiliary or Voice VLANs
Cluster
Publisher
Subscriber
IP Phones register
with Cisco
CallManager.
Switch sends
VLAN information
to IP Phone.
x000
x001
x002
4
IP Phones can call one
another within the cluster.
Cisco Catalyst
Switch Inline
Power Module
2
DHCP router provides
IP address, default
gateway, and TFTP
server to IP Phones.
Cisco 2600
Default Gateway
CIPT1 v4.15
In this activity, you will configure auxiliary or voice VLANs on the Cisco Catalyst switch.
Now when the telephone resets, the switch will send a Cisco Discovery Protocol packet to the
IP Phone with voice VLAN information.
Required Resources
Cisco IP Phones
Cisco Catalyst switch (6500, 4500, or 3560, or 3570 Series)
Lab Guide
23
Command List
The tables describe the commands that are used in this activity.
Cisco Catalyst Series Switch Commands: Cisco IOS CLI
Command
Description
To enter privileged EXEC mode, or any other security level that

is set by a system administrator, use the enable EXEC
command.
Begins interface configuration for the Catalyst 3500 Series

Switch.
- --
Configures the switchport to be an access (non-trunkjng) port
Configures the Cisco IP Phone to transmit voice traffic in 802.1Q

frames, tagged with the voice VLAN ID and a Layer 2 CoS value
(the default is 5). Valid VLAN IDs are from 1 to 4094. The switch
puts the 802.1Q voice traffic into the voice VLAN.
- --
Configure the interface as a static access port with the access

VLAN ID (262 in this example); the range is 1 to 4094.
- -
Spanning-tree PortFast causes a port to enter the spanning-tree

forwarding state immediately and bypass the listening and
learning states.
Cisco Catalyst Series Switch Commands: Cisco CatOS CLI

Command
Description

has been set by a system administrator, use the enable EXEC
command.
Creates the VLAN and assigns a name to it.
Configures the VLAN that is sending and receiving untagged

traffic on the trunk port.
Valid IDs are from 1 to 1001.
24
Assigns ports to the data VLAN.
Job Aids
This job aid is available to help you complete the lab activity.
VLAN Information
Cluster Name
Voice VLAN
East 1
10
East 2
20
East 3
30
East 4
40
West 1
50
West 2
60
West 3
70
West 4
80
Task 1: Configure Auxiliary or Voice VLANs

In this task, you will configure auxiliary, or voice, VLANs on the Cisco Catalyst switch.
Activity Procedure
Step 1
Document the type of switch that you are working on and whether it is supports
Cisco CatOS command line interface (CLI) or Cisco IOS CLI .
Step 2
Configure voice and data VLANs on the switch ports. The configuration commands
for the Cisco Catalyst series switches follow. Go to the section for the type of switch
that you are configuring, and enter the configuration commands, using your pod
number for x in the command.
Cisco Catalyst Series Switches: Cisco IOS CLI
1. From configuration mode, enter the following commands to configure voice and
data VLANs on a Cisco Catalyst Series switch running Cisco IOS, using your
pod number to replace x:
-
- --
- --
- -
Cisco Catalyst Series Switches: Cisco CatOS CLI

1. Establish a Telnet session to the Cisco Catalyst switch using the IP address
172.16.1.3. There is no password. At the password prompt, simply press Enter.
Lab Guide
25
2. Enter enable. There is no password. At the password prompt, simply press

Enter.
3. Your instructor has already configured the data VLANs. Enter the following
command to create voice (auxiliary) VLANs on a Cisco Catalyst 6000 switch:
- -
(where x = your pod number and XXXXN = your cluster name [example:
EAST1])
4. Enter the following commands to assign voice (auxiliary) VLANs to the
Ethernet ports. For [module/port] you can configure a single port or a range or
ports. For example, to configure a range of ports on a module, enter 5/1-5/48.
-
- --
- --
- --
- --
Caution
The Cisco CallManagers are on ports 1, 2, 13, 14, 25, 26, 37, and 38. Ports 12, 24, 36, and
48 are trunking ports. Do not assign an auxiliary VLAN to any of these ports. PCs are
assigned to ports 3, 15, 27, and 39. It is acceptable to assign an auxiliary VLAN to the PC
ports; however, you will lose your Telnet session to the switch and will need to establish
another session.
Note
Your instructor has already configured the data VLANs. The following command is for
reference only:
set vlan x5 [module/port]
<East 1
<East 2
<East 3
<East 4
26
was assigned
was assigned
was assigned
was assigned
to ports 2/1-2/11>
to ports 2/13-2/23>
to ports 2/25-2/35>
to ports 2/37-2/47>
You have completed this task when you attain these results:
On an IP Phone in your cluster, press the Settings button and then press 3 to view the
Network Configuration menu. Use the rocker key to scroll down to verify that the Cisco IP
Phone obtains an IP address within the subnet configured in the DHCP scope (line 6 should
show IP address 10.x.x.x) that is consistent with the auxiliary or voice VLAN that is
configured on the switch (line 19 should show vlan x0), where x = your pod number.
Verify that the operational VLAN is x0 (where x = your pod number). The operational
VLAN ID indicates the auxiliary VLAN that is configured on a Cisco Catalyst switch in
which the telephone is a member. If the telephone has not received an auxiliary VLAN, this
field reflects the administrative VLAN.
Lab Guide
27
Lab 2-3: Configuring Cisco IP Communicator

Activity Objective
In this activity, you will configure Cisco IP Communicator in Cisco CallManager and on your
PC to place and receive calls using your PC. After completing this activity, you will be able to
Configure Cisco CallManager Administration for Cisco IP Communicator, including
adding the device, running the Cisco IP Communicator Administration Tool, and installing
the Cisco IP Communicator phone load
Install Cisco IP Communicator on your PC or laptop and modify settings in Cisco
CallManager to manually assign a DN to the device
Visual Objective

Cluster
x000
Publisher
x001
Subscriber
x002
x010
CIPT1 v4.16
In this activity, you will configure Cisco IP Communicator so that you can make IP Phone calls
from your PC. First, you will add a user to the Cisco CallManager directory that will be
associated with Cisco IP Communicator. Then, you will add the Cisco IP Communicator device
to Cisco CallManager, run the Cisco IP Communicator Administration Tool to enable
automated software updates, and install the phone load package to apply a default software load
for Cisco IP Communicator devices that register to Cisco CallManager. Finally, you will install
Cisco IP Communicator software on your computer, perform some initial tuning tasks, and then
assign a permanent DN for the Cisco IP Communicator device in Cisco CallManager.
28
Required Resources
Cisco CallManager server with Cisco CallManager Release 4.0(1) Service Release (SR) 2
or later
Note
Cisco IP Communicator requires Cisco CallManager Release 3.3(3) SR 3 or later. To set up

Cisco IP Communicator in Cisco CallManager Release 4.x, Cisco CallManager Release
4.0(1) SR2 is required.
Cisco IP Communicator Release 1.1(3) (file download name is cipc-Admin-fmr.1-1-3.zip

from Cisco.com for users with software privileges)
PC or laptop with the following requirements:
Microsoft Windows 2000 Professional with SP 3.0 or later or Windows XP

Professional with SP 1.0 or later
Minimum of a 450-MHz Pentium III or equivalent and minimum of 128 MB of

RAM for Windows 2000 or 192 MB for Windows XP
Note
Cisco IP Communicator has additional hardware requirements, including a minimum of

100 MB of free disk space. Consult the Preparing to Deploy Cisco IP Communicator
chapter of Cisco IP Communicator Administration Guide (1.1) for details at:
http://www.cisco.com/en/US/partner/products/sw/voicesw/ps5475/products_administration_g
uide_book09186a00801e8bd2.html.
Microsoft Internet Explorer 4.01 or later

IP Phone
Command List
There are no commands used in this activity.
Job Aids
There are no job aids for this activity.
Lab Guide
29
Task 1: Prepare and Configure Cisco CallManager for Cisco IP

Communicator
In this task, you will add a user that will be associated with Cisco IP Communicator, run the
Cisco IP Communicator Administration Tool to enable automatic updates, and install the latest
Cisco IP Communicator phone load for devices that register to Cisco CallManager.
Activity Procedure
Add the User
Step 1
From Cisco CallManager Administration, choose User > Add a New User.
Step 2
Enter the following information:

First Name: Kim
Last Name: Wong
User ID: kwong
User Password: cisco
Confirm Password: cisco
PIN: 12345
Confirm PIN: 12345
Step 3
Click Insert.
Prepare and Configure Cisco CallManager for IP Communicator

Step 4
You will need the MAC address of the NIC where Cisco IP Communicator is to be
installed. Write down the MAC address of your PC. __________________
Note
30
Follow these instructions to obtain the MAC address. From your PC, get a command prompt
(choose Start > Run and enter cmd in the Open field, and click OK). From the command
prompt, enter ipconfig /all. The Physical Address field under the Ethernet adapter Local
Area Connection heading is the MAC address. When you have finished, close the command
prompt window.
Step 5
Cisco IP Communicator for Cisco CallManager 4.x requires Cisco CallManager

Release 4.0(1) SR2 or later. To check your Cisco CallManager version, connect to
your publisher using Remote Desktop Connection. Choose Help > About Cisco
CallManager from the Cisco CallManager Administration main menu, and then
click Details.
Step 6
From the Cisco CallManager Administration main menu, choose Device > Phone.
Click the Add a New Phone link at the top right of the window.
Step 7
Choose Cisco IP Communicator from the Phone Type drop-down list. Click Next.
The Phone Configuration window appears.
Step 8
Fill in the following details in the Phone Configuration window:
MAC Address: From Step 4
Description: Kwong_CIPC (for Cisco IP Communicator)
Owner User ID: kwong
Device Pool: BA_Default_CMLocal_DP.
Step 9
Click Insert and OK to display the Directory Number Configuration window.
Step 10
Enter x001, where x = your pod number, in the Directory Number field. Click Add
and OK.
Run the Cisco IP Communicator Administration Tool

Step 11
Your instructor has placed the Cisco IP Communicator Administration tool on the
publisher desktop in a folder called Apps_Tools > IP Communicator. Using Remote
Desktop Connection, navigate to this folder. Right-click the file cipc-Admin-fmr.11-3.zip and choose Extract to Here.
Step 12
From the unzipped contents, double-click the file named

CiscoIPCommunicatorAdminToolSetup.
Step 13
Click Next when the InstallShield Wizard appears.
Step 14
Accept the license agreement. Click Next.
Step 15
Enable HTTP access for AutoUpdate (default) and click Install.
Step 16
Uncheck the Launch the Directory Wizard and View the ReadMe File check
boxes. Click Finish.
Note
To allow searches against corporate directories via the Directories button on the Cisco IP
Communicator interface, integrate Cisco CallManager with a directory server such as
Microsoft Active Directory. If you want to set up Quick Search to access a personal or
corporate directory that exists on the Cisco CallManager server, use the Directory Wizard.
Install Phone Load Package

Step 17
From Cisco CallManager Administration, choose System > Device Defaults to open
the Device Defaults Configuration window.
Step 18
Scroll down to the Cisco IP Communicator Device Type line. Note that the Load
Information field is blank. You will need to install the Cisco IP Communicator
phone load on the publisher (the device that is performing Cisco TFTP server
functions.)
Step 19
Your instructor has placed the Cisco IP Communicator phone load on the publisher
desktop in a folder called Apps_Tools > Cisco IP Communicator. Close the browser
window to CallManager Administration.
Step 20
Locate the phone load patch cmterm-Communicator-sccp.1-1-3-0. This load

enables automatic update of Cisco IP Communicator via the TFTP server of the
Cisco CallManager. Double-click the executable file, start the InstallShield Wizard,
accept the license agreement, and complete the installation.
Lab Guide
31
Step 21
When the phone load installation is complete, log back in to Cisco CallManager
Administration and navigate to the Device Defaults window (choose System >
Device Defaults or maximize the Cisco CallManager Administration window).You
should see CIPC-1-1-3-0 in the Load Information field for Cisco IP
Communicator.
Note
Step 22
If the Load Information field is blank for Cisco IP Communicator after you have installed the
phone load, it is probably because you did not close the Cisco CallManager browser
window. Close your browser and open a new browser window to Cisco CallManager
Administration, and you should now see CIPC-1-1-3-0 in the Load Information field.
Log out of Cisco CallManager. Choose Start > Log Off Administrator and click
Yes.
The user and the Cisco IP Communicator device has been added to Cisco CallManager,
HTTP access is enabled for automatic updates, and the Device Defaults window Load
Information field displays the correct Cisco IP Communicator load.
Task 2: Install Cisco IP Communicator on a PC and Modify

Cisco CallManager Settings
In this task, you will install Cisco IP Communicator on the PC and change an auto-registered
DN in Cisco CallManager.
Activity Procedure
Install Cisco IP Communicator
Step 1
Your instructor has placed Cisco IP Communicator on the desktop of your PC in a
folder called IP Communicator. Navigate to this folder and double-click the file
named CiscoIPCommunicatorSetup.exe.
Step 2
Click Next when the Cisco IP Communicator InstallShield Wizard appears.
Step 3
Accept the license agreement, click Next, and follow the on-screen prompts to
complete the installation.
Step 4
When the InstallShield Wizard Completed window appears, check the Launch the
Program check box and click Finish. The Audio Tuning Wizard screen appears.
Step 5
Read the Audio Tuning Wizard window and click Next to open the Audio Tuning
WizardSelect Audio Devices window.
Step 6
Choose the appropriate devices from the drop-down lists. If no additional audio
devices have been installed, you can accept the default values. Click Next.
Note
32
If multiple audio devices are installed, such as a USB handset device, then choose the
desired device from the drop-down lists.
Step 7
Follow the on-screen instructions to adjust the listening volume, and then click
Next. The Adjust the Microphone Volume window appears.
Step 8
Follow the on-screen instructions to adjust the microphone volume, and then click
Next. The last window appears.
Step 9
Click Finish. The Cisco IP Communicator launch window appears on your PC

desktop, and Cisco IP Communicator registers with Cisco CallManager with the DN
displayed. What method of adding Cisco IP Communicator was used? __________
Modify Settings in Cisco CallManager

Step 10
Log in to Cisco CallManager Administration.
Step 11
Choose Device > Phone and click Find.
Step 12
Cisco CallManager automatically discovered the MAC address of the device

running Cisco IP Communicator. Write down the MAC address. ____________
Auto-registration was used to add and register the Cisco IP Communicator to the
Cisco CallManager database. Auto-registration is useful to quickly submit devices to
the Cisco CallManager database. You can then modify settings from Cisco
CallManager or move auto-registered devices to new locations and assign them to
different device pools without affecting their DNs.
Step 13
Change the DN to this device to x010, where x = your pod number. Click Update
and click Reset Devices.
Step 14
Notice the DN change on Cisco IP Communicator.
Step 15
Make calls to other extensions in your pod using Cisco IP Communicator and call
the extension associated with Cisco IP Communicator from an IP Phone in your pod.
Step 16
Place your cursor over the phone and right-click to experiment with settings, such as
changing the phone skin.
The Cisco IP Communicator launch window appears on your PC desktop with the DN
displayed.
You can make and receive calls using your PC.
Lab Guide
33
Lab 2-4: Using the Bulk Administration Tool

Activity Objective
In this activity, you will use BAT to bulk-add Cisco IP Phones and users to an IP telephony
network. After completing this activity, you will be able to meet these objectives:
Install the BAT application
Create an IP Phone template to use with BAT
Create a CSV file using the BAT spreadsheet
Validate the IP Phone template and CSV file to check for errors
Insert the IP Phones and users into the Cisco CallManager database
Visual Objective
Visual Objective for Lab 2-4: Using the Bulk

Administration Tool
BAT Spreadsheet
CSV File
Phones and Users
Publisher
CIPT1 v4.17
In this activity, you will install the BAT plug-in and create an IP Phone template to define
common settings for Cisco IP Phone 7960 telephones inserted in Cisco CallManager. Then, you
will use the BAT spreadsheet that has been populated with sample users and telephones to
create a CSV file. Finally, you will bulk-insert the IP Phones and users into the Cisco
34
Required Resources
Cisco IP telephony server cluster (two Cisco CallManager servers)
Three Cisco IP Phones
BAT.xlt spreadsheet
Command List
Job Aids
Task 1: Install the BAT Application

In this task, you will install the BAT plug-in.
Activity Procedure
Step 1
You cannot install or upgrade BAT by using Windows Terminal Services. You must
install BAT directly from the Cisco CallManager server.
Step 2
Choose Application > Install Plugins. The Install Plugins window is displayed.
Step 3
Locate Cisco Bulk Administration Tool, and click the Setup icon. A standard
Windows dialog box appears.
Step 4
Choose Open to run the setup program from the current location.
Step 5
Click Next when the InstallShield Welcome window appears. The InstallShield
window begins installing BAT.
Step 6
When prompted, click Finish to exit the wizard.
BAT is visible in the Application menu in Cisco CallManager Administration. If BAT is
not visible in the Application menu, refresh your browser.
Lab Guide
35
Task 2: Create an IP Phone Template to Use with BAT

In this task, you will create a Cisco IP Phone template to define common attributes.
Activity Procedure
Step 1
Use Remote Desktop Connection to connect to the publisher. Enter administrator

for the username, and cisco for the password.
Step 2
Launch Cisco CallManager Administration. Enter administrator for the username,

and cisco for the password.
Step 3
Choose Application > BAT to access the BAT main window.
Step 4
Choose Configure > Phones to open the Phone Options window of the BAT
wizard.
Step 5
Choose Insert Phones with Users and click Next to open the Steps to Insert Phone
Users window.
Step 6
Choose Step 1: Create a new phone template and click Next to open the Phone
Template Configuration window. Click Next.
Note
Step 7
After a new phone template has been created, Step 1 of the BAT Wizard changes to Step
1: Add, view, or modify phone templates.
Enter the following information, and, when prompted for the username and
password (after you select the device type), enter administrator and cisco.
Phone Template Name: BAT 7960
Device Type: Cisco 7960
Device Pool: BA_Default_CMLocal_DP
Phone Button Template: Standard 7960
Leave all other settings at their default values.
Step 8
Click Insert and click OK.
Step 9
Click the Back button at the bottom of the window to go back to the Steps to Insert
Phone Users window.
Step 10
Choose Step 2: Create the CSV data file. Click Next.
Step 11
Read the available options.

In the next task, you will be using the BAT spreadsheet to create the CSV data file,
and you will return this screen later to continue using the BAT Wizard.
36
Task 3: Create the CSV File Using the BAT Spreadsheet

In this task, you will use the BAT spreadsheet to add lines and DNs, and you will export the
Excel spreadsheet to a CSV file for use with BAT.
Activity Procedure
Step 1
Note
Your instructor has placed a BAT spreadsheet with sample data on the publisher
desktop in the folder Apps_Tools and subdirectory BAT Sample. This spreadsheet
was created using the BAT.xlt Excel spreadsheet file that the BAT installation
program places on the publisher desktop. The path is
C:\CiscoWebs\BAT\ExcelTemplate.
If you encounter errors when you are creating the BAT spreadsheet, you can revert to the
original BAT.xlt spreadsheet that you saved on the desktop.
Step 2
Navigate to the Apps_Tools folder and subdirectory BAT Sample. Create a backup
copy of the BAT_41_Sample file and paste it to the publisher desktop.
Step 3
Open the BAT_41_Sample file that you placed on the desktop. Choose Enable
Macros when you are prompted.
Step 4
Choose the Phones-Users tab and view the contents. You are going to add two lines,
four speed dials, and DNs.
Step 5
Scroll to the right to Column M and click the Create File Title button.
Step 6
Choose Directory Number under Line Fields and use the Arrow key to move it
under Selected Line Fields. This action adds a Directory Number field to the BAT
spreadsheet. When you are finished, click Create and Yes to overwrite the CSV
format.
Step 7
In column O of the spreadsheet, set the number of telephone lines to 2 and click any
other cell to update the spreadsheet. Set the number of speed dials to 4 (now located
in column P) and click in any other cell. Check the Dummy MAC Address check
box in column X.
Step 8
In cell M2 (the column heading should be Directory Number 1), enter any DNs
that you wish for lines 2 through 30.
Note
A fast way to enter the DNs is to insert xx00 in cell M2, where x = your pod number. Fill the
remaining cells with data by clicking and holding the lower right corner of cell M2 and
dragging until you reach line 30.
Step 9
In the Directory Number 2 column (column N), enter any DNs that you wish for
lines 2 through 30 (for example: xx30 to xx58, where x = your pod number).
Step 10
In column J, enter 2 for the number of lines. Do this for lines 2 through 30.
Step 11
Scroll right to column X and click the Export to BAT Format button.
Lab Guide
37
Step 12
By default, the system saves the file to C:\XLSDataFiles with the filename
<tabname><timestamp>.txt. Navigate to C:\BatFiles\PhonesUsers. Click OK and
append bat1 to the path. Click OK to export to the CSV file and save the file to the
location specified.
Step 13
Click OK.
Task 4: Validate the IP Phone Template and CSV File

In this task, you will enable BAT to run a validation routing to check the CSV file that you
created in Task 3 and the IP Phone template that you created in Task 2 to ensure that all fields
are populated.
Activity Procedure
Step 1
Return to BAT. You should still be on Step 2 of 4 in the BAT Wizard: Create the
CSV data file. Click Back. (Alternatively, from BAT, choose Configure > Phones
> Insert Phones with Users, and click Next.)
Step 2
Choose Step 3: Validate phones with users records and click Next.
Step 3
Choose bat1.txt from the File Name menu. Choose BAT 7960 from the Phone
Template Name menu. Click View File to view the CSV file that you created, and
close the window when finished.
Step 4
Click Validate. Was the validation successful? ______ Why do you think the
validation failed? Hint: Click View Latest Log File. ________________________
Close the log file.
Step 5
You need to add two lines to the BAT template to match the number of lines on the
CSV file. Click the Back button at the bottom of the window.
Step 6
Choose Step 1: Add, view, or modify phone templates and click Next to open the
Phone Template Configuration window.
Step 7
Choose BAT 7960 from the Phone Templates area on the left.
Step 8
Scroll down to the Line Details section at the bottom of the window and click Add
Line 1. Click Insert and Close. Scroll down and click Add Line 2. Click Insert
and Close.
Step 9
Click the Back button at the bottom of the window. Choose Step 3: Validate
phones with users records and click Next. Repeat Steps 3 and 4 to run the
validation again.
The validation status is Validate Completed, and when you click View Latest Log File, the
Result Summary message reads Validate for 29 Phones passed. Validate for 0 Phones
failed.
38
Cleanup
Close the log file window and click the Back button to return to Steps to Insert Phones with
Users.
Answer to Lab Question

The answer to the lab question is as follows:
Step 4: The validation was not successful. You created a CVS file with two lines but did
not add any lines to the telephone template that you created. These must match.
Task 5: Insert Phones and Users into the Cisco CallManager

Database
In this task, you will complete the last step in the BAT process by inserting the telephones and
users into the Cisco CallManager database.
Activity Procedure
Step 1
You should be at the Steps to Insert Phones with Users window. If you are not, click
the Back button. (The full path is Configure > Phones > Insert Phones with Users
and click Next.)
Step 2
Choose Step 4: Insert phones with users and click Next.
Step 3
Choose bat1.txt for the File Name. Choose BAT 7960 for the Phone Template
Name
Step 4
Check the Create Dummy MAC Address check box. This field needs to be added
because you checked this check box in the BAT spreadsheet.
Step 5
Click Insert and OK.
Step 6
Click Show Latest Status.
Step 7
Click View Latest Log File. A total of 29 telephones and 29 users should be
inserted.
Step 8
Go back to BAT. From BAT, choose Application > Cisco CallManager

Administration. Enter administrator for the username and cisco for the password.
From Cisco CallManager Administration, when you choose User > Global Directory and
click the Search button, you are able to view the users that you bulk-added (29 total).
When you choose Device > Phone and click Find, you see the telephones that you
bulk-added. Notice that the telephones added with BAT all start with BAT followed by a
dummy MAC address in the Device Name field. Click one of the device names and view
the results. You can customize any of these fields on a per-telephone basis.
Lab Guide
39
Cleanup
To prepare for future labs, complete these steps:
40
Step 1
Delete the BAT telephones that were added using BAT. Choose Device > Phone
and click Find.
Step 2
Check the Device Name check boxes of each telephone with a name that starts with
BAT.Click Delete Selected.
Step 3
Place a check mark on an individual basis next to the remaining telephones with
names that start with BAT and click Delete Selected. The only telephones that
remain should be the three active telephones in your cluster (those starting with
SEP).
Lab 3-1: Configuring Gateways and Intercluster

Trunks
Activity Objective
In this activity, you will configure access gateways in Cisco CallManager Administration. After
Configure intercluster trunks
Configure a non-IOS MGCP gateway (T1 or E1 ports)
Configure a Cisco IOS MGCP gateway
Configure an H.323 gateway
Visual Objective

Gateways and Intercluster Trunks
East 2
Voice GW
1/0/1
1/1/0
x051
Cisco Catalyst
6000 PRI
Port
Type
GW
1/0/0
FXS
H.323
1/1/0
FX0
MGCP
1/0/1
FSX
MGCP
1/0/0
1/0/1
1/1/0
x051
Cisco Catalyst
6000 PRI
IP WAN
PSTN
PSTN
Cisco Catalyst
6000 PRI
East 1
Cisco Catalyst
6000 PRI
Intercluster
Trunks
Voice GW
x051
East 4
Voice GW
1/0/0
1/0/1
East 3
Voice GW
Gateway Information
1/0/0
1/0/0
1/1/0
1/1/0
1/0/1
x051
CIPT1 v4.18
In this activity, you will add and configure an intercluster trunk to enable calling to a remote
cluster over the IP WAN (calling will not be fully enabled until you add a route pattern to the
remote cluster in the next lab activity). Then you will configure a non-IOS MGCP gateway
(Cisco Catalyst 6000 Series WS-6608-T1) as a digital PRI to emulate PSTN calling to a remote
cluster (again, calling will be enabled after you add a route pattern to the remote cluster in the
next lab activity). Next, you will configure the Cisco 2600 Series router FXS port as an MGCP
endpoint to enable calling to an analog telephone in your cluster. Finally, you will configure an
H.323 gateway that uses the other FXS port on the Cisco 2600 Series router (after you add a
route pattern to the gateway in the next lab activity).
Lab Guide
41
Required Resources
Cisco Catalyst 6000 Series switch with a T1 or E1 Voice Services Module (WS-X6608-T1
or WS-6608-E1)
Remote Cisco CallManager cluster
Cisco IOS MGCP gateway (for example, Cisco VG200 Series gateways or Cisco 2600,
2800, 3700, and 3800 Series routers)
H.323 gateway (for example, Cisco 2600, 2800, 3700, or 3800 Series routers)
Gatekeeper device (for example, Cisco 2600, 2800, 3700, or 3800 Series routers)
Command List
The tables describe the commands that are used in this activity.
Cisco Catalyst 6000 Series Switch Commands
Command
Description

command.
Displays the attributes of the module or the port on the module.
Cisco IOS MGCP Gateway Commands
42
Command
Description
To enter privileged EXEC mode, or any other security level

that is set by a system administrator, use the enable EXEC
command.
Enables the MGCP application on the gateway.

--
Identifies the primary Cisco CallManager for the gateway.
Relays digits through the IP network.
Specifies how the gateway behaves if the primary server

becomes unavailable and later becomes available again.
With the graceful keyword, the gateway completes all
outstanding calls before returning the gateway to the
control of the primary Cisco CallManager server.
-
--
Identifies the secondary or tertiary Cisco CallManager for

the gateway.
Identifies that the Cisco CallManager is using the MGCP

application.
Configures a POTS dial peer on the gateway.
Configures the dial peer to use the MGCP application.
Specifies the voice port that is used with the configured dial
peer.
H.323 Gateway Commands

Command
Description

command.
--
Creates an H.323 voice class that is used to configure a TCP

timeout duration.

-- --
Configures the H.225 TCP timeout duration in seconds.
-
-
Configures the destination pattern for the configured dial peer.
Identifies the priority order of the dial peers.
Specifies the voice port that is used with the configured dial peer.
---
--
Specifies the IP address of the Cisco CallManager to send the

call to when the destination pattern is matched.
Configures a VoIP dial peer on the gateway.
Displays the router or switch (if using Cisco IOS software)

current configuration
Job Aids
Default Gateway IP Address
Cluster Number
Default Gateway IP Address
172.16.10.1
172.16.20.1
172.16.30.1
172.16.40.1
172.32.10.1
172.32.20.1
172.32.30.1
172.32.40.1
Lab Guide
43
Intercluster Trunk Information

Cluster Name
Remote IP Address
Device Name
Description
East 1
172.16.30.6
E3_ICT
Intercluster to E3
E4_ICT
Intercluster to E4
E1_ICT
Intercluster to E1
E2_ICT
Intercluster to E2
W3_ICT
Intercluster to W3
W4_ICT
Intercluster to W4
W1_ICT
Intercluster to W1
W2_ICT
Intercluster to W2
172.16.30.5
East 2
172.16.40.6
172.16.40.5
East 3
172.16.10.6
172.16.10.5
East 4
172.16.20.6
172.16.20.5
West 1
172.32.30.6
172.32.30.5
West 2
172.32.40.6
172.32.40.5
West 3
172.32.10.6
172.32.10.5
West 4
172.32.20.6
172.32.20.5
44
MGCP Gateway Information

MGCP Gateway CLI Configuration
Cluster Name
Call Agent
Redundant Host
East 1
172.16.10.6
172.16.10.5
East 2
172.16.20.6
172.16.20.5
East 3
172.16.30.6
172.16.30.5
East 4
172.16.40.6
172.16.40.5
West 1
172.32.10.6
172.32.10.5
West 2
172.32.20.6
172.32.20.5
West 3
172.32.30.6
172.32.30.5
West 4
172.32.40.6
172.32.40.5
Cisco CallManager Administration Configuration

Parameter
Data
Network Module
NM-2V
Subunit 0
VIC-2FXS
Subunit 1
VIC-2FXO
FXS Endpoint Identifier
1/0/1
FXO Endpoint Identifier
1/1/0
Num Digits
Expected Digits
Directory Number DN
1/0/1 = x051, where x = your pod number
Display
<XXXXNB> Conf Room 51 (for example, EAST1A)
Port Direction
Bothways
Lab Guide
45
H.323 Gateway Information

H.323 Gateway CLI Configuration
Cluster Name
Session Targets
POTS Destination Pattern
Preference 0
Preference 1
Number 1
Number 2
East 1
172.16.10.6
172.16.10.5
East 2
172.16.20.6
172.16.20.5
East 3
172.16.30.6
172.16.30.5
East 4
172.16.40.6
172.16.40.5
West 1
172.32.10.6
172.32.10.5
West 2
172.32.20.6
172.32.20.5
West 3
172.32.30.6
172.32.30.5
West 4
172.32.40.6
172.32.40.5
Cisco CallManager Administration Configuration

Parameter
Data
Device Name
IP address of gateway, either 172.16.x0.1 or 176.32.x0.1
Description
H.323 Gateway
Device Pool
BA_Default_CMLocal_DP
Calling Line ID
Presentation
Allowed
Task 1: Configure Intercluster Trunks

In this task, you will use the IP address of the Cisco CallManager nodes in the remote cluster to
add an intercluster trunk in Cisco CallManager Administration. East 1 will connect to East 3,
and East 2 will connect to East 4, and so on, as outlined in the Intercluster Trunk Information
table in the Job Aids section of this lab activity.
Activity Procedure
46
Step 1
In Cisco CallManager Administration, choose Device > Trunk.
Step 2
Choose the Add a New Trunk link in the Find and List Trunks window.
Step 3
Choose Inter-Cluster Trunk (Non-Gatekeeper Controlled) from the Trunk type

drop-down list. Click Next.
Step 4
Enter the device name for the intercluster trunk and a description from the
Intercluster Trunk Information table in the Job Aids section of this lab activity.
Step 5
Choose BA_Default_CMLocal_DP for the device pool.
Step 6
Choose Allowed for the calling line ID presentation. Cisco CallManager uses calling
line ID presentation as a supplementary service to control the display of the calling
party number on the called party IP Phone screen. Choosing Allowed displays the
calling number information.
Step 7
Enter the IP address for the remote cluster subscriber in the Server 1 IP
Address/Host Name field. (Refer to the Intercluster Trunk Information table in
this lab activity.)
Step 8
Enter the IP address of the remote cluster publisher in the Server 2 IP Address/Host
Name field. (Refer to the Intercluster Trunk Information table.)
Step 9
Click Insert, and then click OK.
Step 10
Click Reset Trunk, and click Reset from the dialog box. Click OK.
The intercluster trunks appear as a trunk when you choose Device > Trunk and then Find in
Cisco CallManager Administration.
Task 2: Configure a Non-IOS MGCP Gateway

In this task, you will configure the Cisco Catalyst T1 or E1 port in the Cisco CallManager
Administration utility.
Activity Procedure
Step 1
Choose Start > Run, and enter telnet 172.16.1.3 to establish a Telnet session to the
Cisco Catalyst 6000.
Step 2
There is no password configured on the Cisco Catalyst 6000. Press the Enter key at
the password prompt.
Step 3
Enter enable and press the Enter key to enter global configuration mode.
Step 4
T1 crossover cables have been connected between the ports on the Cisco Catalyst
6500 Series T1 Voice Services Module (WS-X6608-T1) to emulate a digital PSTN
connection as follows:
East 1 on port 3/1 to East 2 on port 3/4
East 3 on port 3/7 to East 4 on port 4/2
Enter show port [mod/port] to get the MAC address of the T1 or E1 port that you
are going to configure in Cisco CallManager. Write the MAC address here:
Port:
MAC:
Step 5
In Cisco CallManager Administration, choose Device > Add a New Device to select
a device type to configure.
Step 6
Use the menu to choose Gateway, and click Next.
Step 7
Choose Cisco Catalyst 6000 T1 (or E1) VoIP Gateway for the gateway type. The
Device Protocol field automatically populates with Digital Access PRI. Click
Next.
Step 8
For the MAC address, enter the MAC address from Step 4.
Lab Guide
47
Step 9
Enter the IP address, module, and port number for the description so that it looks
like the following:
172.16.1.3 <mod/port>
Note
Step 10
Step 11
If you are working in an even-numbered group, choose User for the protocol side. If
you are working in an odd-numbered group, choose Network for the protocol side.
Step 12
If you are working in an even-numbered group, choose Network for the clock
reference. If you are working in an odd-numbered group, choose Internal for the
clock reference.
Note
48
In a production network, a better description would be the actual circuit number to the T1
circuit.
Steps 11 and 12 are necessary because the T1 or E1 ports are connected back-to-back.
The protocol side setting specifies whether the gateway connects to a central office network
device or to a user device. Make sure that the two ends of the PRI connection use opposite
settings. For example, if you connect to a PBX and the PBX uses User as its protocol side,
choose Network for this device. Typically, use User for this option for central office
connections.
Step 13
Click Insert, and click OK.
Step 14
Click Reset Gateway, and click Reset in the dialog box. Click OK. This action
sends the configuration to the TFTP server.
Step 15
Establish a Telnet session to the Cisco Catalyst switch (172.16.1.3) and issue the
reset [mod/port] command. This action causes the switch to contact the TFTP server
for its configuration. (In this case, it will be configured as a PRI port.)
Step 16
Using a T1 crossover cable, connect your port to the port of your partner, if this has
not already been done for you. (Group 1 connects to group 2, and group 3 connects
to group 4.)
Caution
Older versions of the Cisco Catalyst operating system (Catalyst software) may not allow the
reset of individual ports. In such cases, you must reset the module with the reset
mod_number command. This action will cause all ports to reset. Use caution with this
command in a production network because it will cause all calls to drop.
The non-IOS MGCP gateway registers with Cisco CallManager, and your Cisco Catalyst
port is configured for T1 (or E1). Follow these steps to verify the activity:
Step 1
In Cisco CallManager Administration, choose Device > Gateway and click Find to
refresh the Find and List Gateways window. Choose the T1 or E1 gateway. The
Registration field at the top of the window should show Registered with Cisco
CallManager <subscriber IP address>.
Step 2
Establish a Telnet session to the Cisco Catalyst switch and enter show port
[mod/port]. The status should be connected, the speed should be 1.544 Mbps,
and the type should be T1 (or E1). Your subscriber IP address should be listed
as the primary (*) Cisco CallManager and the CallManagerState should be
registered.
Task 3: Configure a Cisco IOS MGCP Gateway

In this task, you will enable MGCP on a Cisco IOS MGCP gateway and configure Cisco
CallManager Administration to set up the Cisco IOS MGCP gateway.
Activity Procedure
Step 1
Refer to the Default Gateway IP Address table from the Job Aids section of this
lab. Write down the MGCP gateway IP address and port information here:
IP Address
Type (2600 or VG200)
FXS Port: 1/0/1

FXO Port: 1/1/0
Note
Use the command show voice port summary from the router in enable mode to verify the
location of the voice ports.
Step 2
Establish a Telnet session to the MGCP gateway and enter cisco as the password.
Enter enable and the password cisco to enter enable mode.
Step 3
Enter the command configure terminal or config t to enter configuration mode.
Step 4
To configure the primary Cisco CallManager in the MGCP gateway, enter the
following in global configuration mode:
- --

Step 5
Configure Cisco CallManager redundancy in the MGCP gateway. Enter the

following in configuration mode:
- - --

Lab Guide
49
Step 6
Note
Configure the dial peer and the physical port so that the port uses the MGCP
application. Enter the following commands in configuration mode, replacing x
with your cluster number (MGCAPP is case-sensitive):
A tag number is a unique number that separates dial peers on the same router. Replace x
with your cluster number.
You have just configured one FXS port (1/0/1) and one FXO (1/1/0) port.
Step 7
Enter end or press Ctrl-Z to exit configuration mode.
Step 8
Enter copy run start to save the running configuration.
Step 9
Enter show run to view the running configuration file. Scroll down until you see the
command line beginning with hostname. This is the name of the router that
appears before the enable prompt (#). Write down the hostname of the MGCP
gateway here:
Hostname:
50
Step 10
In Cisco CallManager Administration, choose Device > Add a New Device to select
a device type.
Step 11
From the drop-down list, choose Gateway, and click Next.
Step 12
Choose 26xx or VG200 (depending on your gateway) as the type of gateway, and
click Next.
Step 13
Enter the hostname (from Step 9) of the device for the domain name. (The hostname
is case-sensitive.) Enter MGCP Gateway in the Description field.
Step 14
Choose BA_CMG for the Cisco CallManager group.
Step 15
From the Module in Slot 1 menu, choose NM-2V for the type of network module
(network module with two VIC slots).
Step 16
Click Update.
Step 17
From the Subunit (0 and 1) menu, choose the type of VIC using the MGCP
Gateway Information table in the Job Aids section of this lab activity. Click
Update and click OK.
Step 18
Choose the FXS endpoint identifier 1/0/1.
Step 19
Step 20
Enter 4 in the Num Digits field, and enter 4 in the Expected Digits field.
Step 21
Step 22
Click Add DN, which is in the left column next to the endpoint identifier that you
just configured. Enter x051 for the DN (where x = your pod number).
Step 23
Leave the other DN settings as they are. Enter <Cluster name> Conf Room 51 in
the Display (Internal Caller ID) field under Line Settings for This Device. This
information is displayed on the called telephone when the call is between telephones
within a Cisco CallManager cluster.
Step 24
Click Add and OK.
Step 25
Click Reset Gateway, Reset, and OK for the changes to take effect.
Step 26
Plug an analog telephone into the FXS port 1/0/1 if this has not already been done
for you.
Configure the FXO Port

Step 27
Configure the FXO port endpoint identifier by choosing 1/1/0 from the left column.
Step 28
Choose Loop Start for the port type.
Step 29
Configure gateway information by choosing BA_Default_CMLocal_DP for the

device pool. Leave the other settings at their default values.
Step 30
Enter x000 (where x = your cluster number) for the attendant DN. For FXO ports,
this specifies the DN to which you want incoming calls routed; for example, zero or
a DN for an attendant.
Step 31
Step 32
Reset the gateway for the changes to take effect.
Step 33
In Cisco CallManager Administration, choose Back to Find/List Gateways to view

the gateways that have been added. If the gateways are not listed, click Find to list
all the gateways.
FXS port verification: Place a call from a Cisco IP Phone to the analog telephone x051,
where x = your pod number(port 1/0/1). Place a call from the analog telephone to an IP
Phone in your cluster.
FXO port verification: In Cisco CallManager Administration, choose Device > Gateway
and click Find. Choose the MGCP gateway. Click the 1/1/0 endpoint identifier. View the
registration status at the top of the window. It should show Registered with the IP address
of your subscriber server.
If the gateways have not registered to Cisco CallManager, establish a Telnet session to your
gateway, enter global configuration mode (config t). Enter no mgcp and press the Enter
key. Enter mgcp and press the Enter key. This action forces the MGCP gateway to contact
the TFTP server to download its configuration and then register with the primary Cisco
CallManager.
Lab Guide
51
Task 4: Configure an H.323 Gateway

In this task, you will add Cisco IOS statements in your default gateway configuration (Cisco
2600) and configuration information in Cisco CallManager Administration to create an H.323
gateway.
Activity Procedure
Step 1
Establish a Telnet session to your default gateway (172.16.x0.1 or 172.32.x0.1)

(where x = your pod number) and enter cisco as the password. Enter enable and
when prompted for the password, enter cisco to enter enable mode.
Step 2
Use the command configuration terminal or config t to enter configuration mode.
Step 3
Configure the H.225 TCP timeout interval by using the following commands and
using your data VLAN number for the tag, where x = your pod number
--
--
Step 4
Refer to the POTS Destination Pattern column of the H.323 Gateway

Information table in the Job Aids section of this lab activity to obtain the values for
Number 1 and Number 2. Write down the values for Number 1:________ and
Number 2:_________
Step 5
Enter the following commands to configure FXS port 1/0/0 :

-
-

-

Note
Step 6
The x2 pots dial peer is used in Lab 3-3, Configuring Complex Route Plans.
Enter the following commands to shut down and then enable the voice ports that you
have just configured:

-
-
52
Step 7
Configure the dial peer that allows the analog telephone to call Cisco IP Phones that
are registered in the cluster. You will also be configuring redundancy on the
gateway so that if one Cisco CallManager is not available, the other can be used.
Use your pod number for x when you are issuing the following commands in
configuration mode:

-
-- - --

--

-
-- - --

--
(where x = your pod number)

Step 8
Save your configuration. Enter end or press Ctrl-Z to exit configuration mode, and
then enter copy run start.
Configure the H.323 Gateway in Cisco CallManager Administration

Step 9
Write down the IP address of the H.323 gateway here:
IP address:
Step 10
In Cisco CallManager Administration, choose Device > Add a New Device to open
the Add a New Device window.
Step 11
Use the drop-down list to choose Gateway, and click Next.
Step 12
Choose H.323 Gateway for the gateway type and H.225 for the device protocol.
Click Next.
Step 13
Enter the H.323 gateway IP address for the device name.
Step 14
Enter H.323 Gateway for the description.
Step 15
Step 16
Choose Allowed for the calling party presentation. (The system default is to send
calling line ID information, so by choosing Allowed, you are simply making the
parameter explicit.)
Step 17
Step 18
Reset the gateway.
Lab Guide
53
You are able to place calls from the analog telephone that is connected to the FXS port
1/0/0 of the H.323 gateway to other telephones in your cluster. (Move the analog telephone
to port 1/0/0 from port 1/0/1 if you have only one analog telephone.)
You will not be able to dial the H.323 FXS port until you configure a route pattern to the
H.323 gateway in the next lab activity.
54
Lab 3-2: Configuring Basic Route Plans
Activity Objective
In this activity, you will build basic route plans to place calls over the IP WAN and PSTN and
calls to analog devices that are attached to access gateways. After completing this activity, you
will be able to meet these objectives:
Configure a route pattern to the H.323 gateway to ring the analog telephone that is
connected to the FXS port
Create a route pattern that is directed to a non-IOS MGCP gateway that allows calls to
another cluster
Place the MGCP (FXO) and H.323 (FXS) gateways into a route group, place the route
group into a route list, and then create a route pattern to the route list that allows calls to
another cluster
Configure the intercluster trunk gateways in route groups, place the route group into a route
list, and then create a route pattern that is directed to the route list that allows calls to
another cluster
Visual Objective

Basic Route Plans
East 2
2XXX
Voice GW
1/0/1
x051
Cisco Catalyst
6000 PRI
1xxx
1/0/0 FXS H.323
1/0/0 FXS H.323
1/1/0 FXO MGCP
4xxx
East 3
3XXX
Voice GW
Analog Trunks
1/1/0 FXO MGCP
1/0/1
1xxx
IP WAN
4xxx
PSTN
Cisco Catalyst
6000 PRI
East 1
1XXX
x051
Cisco Catalyst
6000 PRI
PSTN
2xxx
Voice GW
1/0/1
2xxx
Intercluster
Trunks
3xxx
H323_MGCP_RL
x051
1/1/0 FXO MGCP
1/0/0 FXS H.323
1/0/0 FXS H.323
1/1/0 FXO MGCP
Cisco Catalyst
6000 PRI
East 4
4XXX
Voice GW
Analog Trunks
H323_MGCP_RG
3xxx
1/0/1
x051
H323 GW FSX 1/0/0

MGCP GW FX0 1/1/0
CIPT1 v4.19
Lab Guide
55
In this activity, you will configure a route plan that enables you to call the other clusters in the
classroom over different route groups or gateways. First, you will configure a route pattern to
the H.323 gateway that enables you to dial the analog telephone attached to the FSX port of the
H.323 gateway. Then, you will configure a route pattern that points to the non-IOS MGCP
gateway (Cisco Catalyst 6000 T1 or E1 Voice Services card) that will enable you to dial
another cluster over a simulated PRI. Then, you will add the MGCP and H.323 gateway ports
to a route group so that you can dial a different cluster over a simulated analog trunk. Finally,
you will add the intercluster trunk to a route group and point a route pattern to the trunk that
will enable dialing over the IP WAN.
Required Resources
Cisco IP telephony servers (two)
Remote Cisco CallManager clusters
Gateway devices (intercluster trunks, non-IOS MGCP, and Cisco IOS MGCP [FXS, FXO],
H.323 [FXS, FXO])
56
Job Aids
Route Groups and Route Lists
Cluster Name
ICT_RG
Name
H.323_MGCP_RG
Name
H.323_
MGCP_RG
Gateway Order
H.323_MGCP_RL
Name
East 1
E3_ICT_RG
E4_H323_MGCP_RG
H323-FXS
E4_H323_MGCP_RL
MGCP-FXO
East 2
E4_ICT_RG
E3_H323_MGCP_RG
H323-FXS
E3_H323_MGCP_RL
MGCP-FXO
East 3
E1_ICT_RG
E2_H323_MGCP_RG
H323-FXS
E2_H323_MGCP_RL
MGCP-FXO
East 4
E2_ICT_RG
E1_H323_MGCP_RG
H323-FXS
E1_H323_MGCP_RL
MGCP-FXO
West 1
W3_ICT_RG
W4_H323_MGCP_RG
H323-FXS
W4_H323_MGCP_RL
MGCP-FXO
West 2
W4_ICT_RG
W3_H323_MGCP_RG
H323-FXS
W3_H323_MGCP_RL
MGCP-FXO
West 3
W1_ICT_RG
W2_H323_MGCP_RG
H323-FXS
W2_H323_MGCP_RL
MGCP-FXO
West 4
W2_ICT_RG
W1_H323_MGCP_RG
H323-FXS
W1_H323_MGCP_RL
MGCP-FXO
Route Patterns for Gateways

Cluster Name
H.323 Gateway
Port 1/0/0
Non-IOS MGCP
Gateway
ICT_RL
H.323_MGCP_RL
East 1
4000
2XXX
3XXX
4XXX
East 2
3000
1XXX
4XXX
3XXX
East 3
2000
4XXX
1XXX
2XXX
East 4
1000
3XXX
2XXX
1XXX
West 1
4000
2XXX
3XXX
4XXX
West 2
3000
1XXX
4XXX
3XXX
West 3
2000
4XXX
1XXX
2XXX
West 4
1000
3XXX
2XXX
1XXX
Lab Guide
57
Task 1: Configure a Route Pattern to the H.323 Gateway

This is the simplest route plan to configure. You are going to create a route pattern to the H.323
gateway that is already added in the Cisco CallManager database.
Activity Procedure
Step 1
Pattern, and then click Add a New Route Pattern to open the Route Pattern
Step 2
In the Route Pattern/Hunt Pilot field, enter the route pattern for the H.323 gateway
from the H.323 Gateway Port 1/0/0 column of the Route Patterns for Gateways
table in the Job Aids section of this lab activity.
Step 3
Choose the H.323 gateway IP address from the Gateway or Route List menu (either
172.16.x0.1 or 172.32.x0.1, where x = your pod number).
Step 4
Uncheck the Provide Outside Dial Tone check box.
Step 5
Click Insert.
From a Cisco IP Phone in your pod, you can dial the route pattern that you just configured
to ring the analog telephone that is plugged into the FXS port of the H.323 gateway.
Task 2: Configure a Route Pattern to the Non-IOS MGCP

Gateway
In this task, you will create a simple route pattern that points to the digital gateway (non-IOS
MGCP) that is already added in the Cisco CallManager database.
Activity Procedure
58
Step 1
Pattern, and click Add a New Route Pattern to open the Route Pattern
Step 2
Refer to the Non-IOS MGCP Gateway column of the Route Patterns for
Gateways table in the Job Aids section of this lab activity. Enter the route pattern
for your pod, exactly as it appears in the table, in the Route Pattern field. Do not
substitute your pod number for X. This X is a wildcard character.
Step 3
Choose the non-IOS MGCP gateway (6608 T1 port) from the Gateway or Route List
menu. The name should look similar to this: S0/DS1-0@SDA0002FCE08264.
Step 4
Scroll down and verify that the order of the gateways is correct.
Step 5
Step 6
Click Insert.
Check whether the other group is ready and get a valid DN for that group. Dial the DN. It
should match the route pattern that you configured and route the call to the Cisco
CallManager of the other cluster to ring the telephone.
Task 3: Configure a Route Plan that Includes a Route Group,

Route List, and Route Pattern Using the H.323 and MGCP
Gateways
In this task, East 1 will connect to East 4 and East 2 will connect to East 3 via the analog
trunks.
Activity Procedure
Pre-Lab Task: Remove the Route Pattern Pointing to the H.323 Gateway
You cannot have both a route pattern pointing directly to a gateway and a route group that
points to that gateway, so you will remove the route pattern that is pointing to the H.323
gateway.
Step 1
Pattern and click Find.
Step 2
Check the check box next to the route pattern that points to the H.323 gateway (the
gateway that is identified by the IP address 172.16.x0.1 or 172.32.x0.1, where x =
your pod number) Click Delete Selected.
Add a New Route Group

Step 3
Group.
Step 4
Click Add a New Route Group to open the Route Group Configuration window.
Step 5
Refer to the H.323_MGCP_RG Name column of the Route Groups and Route
Lists table in the Job Aids section of this lab activity. Enter the H.323_MGCP_RG
name for the Route Group Name field.
Step 6
Choose Top Down for the distribution algorithm.
Step 7
From the Available devices section, highlight the H.323 gateway (IP address
172.16.x0.1 or 172.32.x0.1, where x = your pod number) and click Add to Route
Group.
Step 8
Choose the MGCP gateway (AALN/S1/SU1/0@<hostname>), and click Add to

Route Group.
Step 9
Click Insert.
Lab Guide
59
Configure a Route List

Step 10
List.
Step 11
Click Add a New Route List to open the Route List Configuration window.
Step 12
Refer to the H.323_MGCP_RL Name column of the Route Groups and Route
Lists table in the Job Aids section of this lab activity. Enter the H.323_MGCP_RL
name in the Route List Name field.
Step 13
Enter H323 and MGCP to <Name of Remote Cluster> for the description.
Step 14
Choose BA_CMG for the Cisco CallManager Group.
Step 15
Step 16
Click Add Route Group to open the Route List Detail Configuration window.
Step 17
Choose YY_H323_MGCP_RG-[NON-QSIG] from the Route Group drop-down

list (where YY = the designator for the remote pod; for example, East 4 will use E1,
East 1 will use E4, and so on).
Step 18
Leave the remaining Route Details Configuration window parameters as is. This
window is used for transformation information.
Step 19
Click Insert and click OK. Click Reset and OK to reset the route/hunt list. Click
OK.
Add a Route Pattern

Step 20
Pattern.
Step 21
Click Add a New Route Pattern to open the Route Pattern Configuration window.
Step 22
Refer to the H.323_MGCP_RL column of the Route Patterns for Gateways

table in the Job Aids section of this lab activity. Enter the route pattern for your pod
in the Route Pattern field.
Step 23
Choose YY_H323_MGCP_RL from the Gateway or Route List drop-down list

(where YY = the designator for your partner pod, for example, E1).
Step 24
Step 25
Click Insert.
Step 26
Your instructor has connected an RJ-11 cable from the FXS port (1/0/0) of your
H.323 gateway to the FXO port (1/1/0) of the MGCP gateway as listed here:
Pod 1 FXS 1/0/0 to Pod 4 FXO 1/1/0
60
Place a test call to one of the telephones in the cluster that is connected via analog trunks.
East 1 will be able to call East 4 and vice versa. East 2 will be able to call East 3 and vice
versa.
Note
The call will be routed to the H.323 gateway. Because of the dial-peer statements, the H.323
gateway will send the call out the FXS port 1/0/0, which is physically connected to the FXO
port 1/1/0 of the remote cluster. The remote-side FXO port 1/1/0 will contact Cisco
CallManager MGCP and tell it to ring the attendant DN (x000). This action will take place
regardless of which number you dial to reach the remote cluster.
Task 4: Configure a Route Plan of Route Group, Route List, and

Route Pattern Using the Intercluster Trunks
In this task, you will add intercluster trunks to a route group, and then add that route group to a
route list, and finally, build a route pattern that is directed at the route list to allow calls to
another cluster via an intercluster trunk.
Activity Procedure
Step 1
Group, and click Add a New Route Group to open the Route Group Configuration
window.
Step 2
Refer to the ICT_RG Name column of the Route Groups and Route Lists table
in the Job Aids section of this lab activity. Enter the information for your pod in the
Route Group Name field.
Step 3
From the Available devices section, highlight the intercluster trunk that you
previously created to the remote-cluster Cisco CallManager nodes (YY_ICT) and
click Add to Route Group.
Step 4
Click Insert.
Configure a Route List

Step 5
List.
Step 6
Step 7
Enter ICT_RL for the route list name, and enter Intercluster to <Remote Cluster
Name> for the description.
Step 8
Choose BA_CMG for the Cisco CallManager group.
Step 9
Click Insert and click OK.
Lab Guide
61
Step 10
Click Add Route Group to open the Route List Details Configuration window.
Step 11
Choose YY_ICT_RG-[NON-QSIG] for the route group and click Insert and OK.
Step 12
Leave the remaining Route Details Configuration window parameters as they are.
This window is used for transformation information.
Step 13
Click Insert and OK to reset the route list.
Add a Route Pattern

Step 14
Pattern.
Step 15
Click Add a New Route Pattern to open the Route Pattern Configuration window.
Step 16
Enter the ICT_RL route pattern from the Route Patterns for Gateways table (in the
Job Aids section of this lab activity) in the Route Pattern field.
Step 17
Choose ICT_RL from the Gateway or Route List drop-down menu.
Step 18
Step 19
Click Insert.
You get a valid DN to reach the cluster to which you just configured an intercluster trunk
and dial the DN to successfully call that cluster.
62
Lab 3-3: Configuring Hunt Groups and Call

Coverage
Activity Objective
In this activity, you will create a hunt group that includes line groups, hunt lists, and a hunt
pilot and provides final forwarding if hunting exhausts. After completing this activity, you will
be able to meet these objectives:
Create a line group and add members
Create a hunt list and add line groups
Create a hunt pilot number and associate it with a hunt list
Configure final forwarding on the hunt pilot number for busy and no-answer conditions
Configure call coverage so that calls that are forwarded to a hunt group and are not
answered will receive final forwarding treatment
Visual Objective

Hunt Groups and Call Coverage
External
Call
Internal
Call
Hunt Pilot
x111
Hunt List
1stHL
Line Groups
1stLG
x001
x000
RNAR: 5 seconds
Try Next Member; Then,
Try Next Group in Hunt
List
x051
2ndLG
x002
CIPT1 v4.110
Lab Guide
63
In this task, you will configure hunt groups that consist of line groups, hunt lists, and a hunt
pilot number with internal and external forwarding support specifications for busy, no-answer,
and no-call-coverage conditions. First, you will create two line groups and add members to the
line groups. Next, you will create a hunt list and add the line groups. Next, you will create a
hunt pilot number and associate it with the hunt list. Next, you will configure the hunt pilot so
that internal and external calls to the hunt list that are not answered because of busy or noanswer conditions will receive a final forwarding treatment. Finally, you will configure call
coverage so that if a member of the hunt group is called and does not answer, the caller will
receive a final forwarding treatment.
Required Resources
Cisco IP telephony servers (two)
Remote Cisco CallManager cluster
Three IP Phones
Analog telephone
Command List
Job Aids
Task 1: Create the Line Group and Add Members

In this task, you will create two line groups and add members to the new line groups. You will
create a 1stLG line group and add DN x000 and x001 to it and a 2ndLG line group with
DN x002 assigned to it (x = your pod number).
Activity Procedure
64
Step 1
Choose Route Plan > Route/Hunt > Line Group.
Step 2
Click Add a New Line Group.
Step 3
Enter 1stLG in the Line Group Name field.
Step 4
For now, leave the distribution algorithm at the default (longest idle time). Leave the
hunt options for busy, no answer, and not available at their default values (Try Next
Member; Then, Try Next Group in Hunt List).
Step 5
Change the RNAR timeout from its default value of 10 seconds to 5 seconds. This
value might not be appropriate in a call center environment, however, in a classroom
or test environment, a shorter timeout enables you to more quickly validate calldistribution behavior.
Add Members to the Line Group

Step 6
Add the x000 and x001 DNs to the line group. In the Available DN/Route Partition
pane, choose x000 and click Add to Line Group to move it to the Selected
DN/Route Partition pane. Repeats this step to add x001 to this line group.
Step 7
The order of the DNs in the Selected DN/Route Partition pane determines the order
in which the DNs are accessed in this line group. Change the order of the line group
members so that x001 is the first member and x000 is the second member. To
change the order, click a DN and use the Up and Down arrows to the right of the
pane to change the order of DNs, or choose Reverse Order of Selected DNs.
Step 8
Click Insert to add the new DNs to the line group.
Step 9
Repeat steps 2 through 7 to create a second line group named 2ndLG with the
third DN in your pod, x002, as its only member.
Two line groups have been added to Cisco CallManager with their respective members.
Task 2: Create a Hunt List and Add Line Groups

In this task, you will create a hunt list called 1stHL and add the 1stLG and 2ndLG line groups
to it.
Activity Procedure
Step 1
Choose Route Plan > Route/Hunt > Hunt List.
Step 2
Click Add a New Hunt List.
Step 3
In the Hunt List Name field, enter the name 1stHL.
Step 4
Choose BA_CMG for Cisco CallManager group from the drop-down list.
Step 5
To add this hunt list, click Insert.
Note
Step 6
A popup message reminds you that you must add at least one line group to this hunt list for
it to accept calls.
The Hunt List Configuration window displays the newly added hunt list.
Add both line groups to the new hunt list. To add a line group, click Add Line
Group.
The Hunt List Detail Configuration window appears.
Step 7
From the Line Group drop-down list, choose the 1stLG line group to add to the hunt
list.
Step 8
To add the line group, click Insert.

The line group name displays in the Hunt List Details list on the left side of the
window.
Lab Guide
65
Step 9
Click Add Line Group and repeat Steps 17 and 18 to add the remaining line group,
2ndLG, to the hunt list.
Step 10
When you finishing adding line groups to the hunt list, click Update.
Step 11
Click Reset to reset the hunt list. When the popup windows appear, click OK.
Note
Cisco CallManager accesses line groups in the order in which they appear in the hunt list.
You change the access order of line groups by choosing a line group from the Selected
Groups list and clicking the Up or Down arrows on the right side of the pane to move the line
group up or down in the list.
One hunt list that contains two line groups has been added to Cisco CallManager.
Task 3: Create a Hunt Pilot Number and Associate It with a

Hunt List
In this task, you will create a hunt pilot number, x111, and assign it to the 1stHL hunt list.
Activity Procedure
Complete these steps
Step 1
Step 2
Click Add a New Hunt Pilot.
Step 3
Enter x111 (where x = your pod number) for the hunt pilot number in the Hunt Pilot
number field.
Step 4
Assign the hunt pilot to the 1stHL hunt list using the Hunt List field drop-down
menu.
Step 5
Click Insert.
You created a hunt pilot number x111 and assigned it to the hunt list.
66
Task 4: Test Call Distribution

In this task, you will test and validate the call-distribution behavior to ensure that it performs as
you expect.
Activity Procedure
Step 1
From the analog telephone at x051, call the hunt pilot number x111 and observe the
call distribution behavior. The call should first ring on x001. Answer the call when it
rings on x001.
DN x000 should now be the member with the longest-idle time and should be the
telephone that rings first when a call comes in to the hunt pilot number.
Step 2
Call x111 again and validate this hypothesis, but this time, do not answer the call.
Observe the call hunt to x001 after x000 does not answer for 5 seconds (RNAR
timeout). When x000 does not answer, the call will then hunt to x002 in the second
line group (2ndLG), because the hunt option specified is Try Next Member; Then
Try Next Group in Hunt List.
Step 3
To test call-distribution behavior for busy conditions in a classroom or lab

environment, set the maximum number of calls for the line to 1 and the busy trigger
to 1 for each DN from the Directory Number Configuration window. This action
disables call waiting, allowing a DN to receive only one call at a time. Any
additional calls receive a busy signal. (To reach the Directory Number Configuration
window, choose Device > Phone, click the device name, click the line, and scroll
down to Multiple Call/Call Waiting Settings. Change the value of the Maximum
Number of Calls and Busy Trigger fields to 1. Click Update.)
Step 4
Remove the handsets on x000 and x001, making both telephones appear to be busy.
Do not answer the call on x002. What do you expect will happen when you call the
hunt pilot? Test your hypothesis. The answer is at the end of the lab.
_______________________________________________________________
Step 5
Hang up telephones x000 and x001. Spend a few moments experimenting with other
distribution algorithms (Circular, Broadcast, or Top-Down) and other hunt options
(Stop Hunting; Skip Remaining Members, and Go Directly to Next Group; and Try
Next Member, but Do Not Go to the Next Group).
Step 6
For the next task, set the call-distribution algorithm to Top Down and Try Next
Member; Then, Try Next Group in Hunt List.
Step 7
Refer to Step 3and change the Maximum Number of Calls and Busy Trigger fields
back to their default values (4 and 2, respectively).
Calls to the hunt pilot or to a specific DN in the hunt group will hunt and to achieve call
distribution according to the behavior outlined for each lab task.
Lab Guide
67
Task 5: Configure Final Forwarding for Busy and No-Answer

Conditions
In this task, you will configure final forwarding on the hunt pilot number so that a call
forwarded to the hunt pilot that is not answered (because of no-answer or busy conditions) is
forwarded to a destination DN (presumably, in a production network, to a designated number in
the hunt group or an autoattendant that is always available as backup to the hunt group.)
Activity Procedure
Step 1
Step 2
Click x111 to go to the Hunt Pilot Configuration window (where x = your pod
number).
Step 3
In the Hunt Forward Settings section, configure the following final forwarding
settings:
Forward Hunt No Answer Destination: x000
Forward Hunt Busy Destination: x000
Maximum Timer: 12 seconds
Step 4
Click Update.
Step 5
Call the hunt pilot number x111 and do not answer the call. What do you expect will
be the call-distribution and final forwarding behavior? Test your hypothesis and
write it in the space provided here. The answer is at the end of the lab.
________________________________________________________________
Step 6
Go off hook on all three telephones. Call the hunt pilot number x111. What do you
expect will be the call-distribution and final forwarding behavior? Test your
hypothesis and write it in the space provided here. The answer is at the end of the
lab.
________________________________________________________________
Calls to the hunt pilot receive final forwarding to a DN where the call will be answered
by an individual, autoattendant, or voice mail (in a production network).
68
Task 6: Configure Internal and External Forwarding with

Hunting
In this task, you apply separate final forwarding settings on a specific DN in the hunt group
(x000) based on whether the caller was internal or external.
Activity Procedure
Step 1
On the Directory Number Configuration window for x000, configure the following
internal and external forwarding settings (where x = your pod number):
Forward Busy Internal Destination: x001
Forward Busy External Destination: x111
Forward No Answer Internal Destination: x002
Forward No Answer External Destination: x111
Step 2
Place an internal call from x051 to x000 but do not answer the call. Where does the
call forward?
Step 3
So that you can test external call-distribution and forwarding behavior, have your
partner pod members connected via digital PRI place a call from their pod to x000.
Test the forwarding behavior when x000 receives an external call and does not
answer. Allow the hunting to exhaust. Why did the caller receive a reorder tone?
______________________________________________________________
Calls to a specific DN in the hunt group are forwarded differently based on whether the
caller was internal or external.
Task 7: Configure Call Coverage

In this task, you add no-coverage settings to the specific DN in the hunt group and enable the
Use Personal Preferences option on the hunt pilot. Now, when a call comes into a specific DN
(x001), is forwarded to the hunt pilot, and is not answered after hunting exhausts, the caller will
not receive a reorder tone as before but will receive final forwarding.
Activity Procedure
Step 1
Configure final forwarding on the hunt pilot number for no-answer conditions.
To configure the Forward Hunt No Answer option, choose Route Plan >
Route/Hunt > Hunt Pilot, then choose the hunt pilot number. Scroll down to the
Hunt Forward Settings section. Check the Use Personal Preferences check box.
Step 2
Configure call coverage on the DN x000 as follows:

Forward No Coverage Internal Destination: Leave blank
Forward No Coverage External Destination: x001
Lab Guide
69
Step 3
Place an internal call to x000 from x051 and do not answer the call. The call should
forward to x002 as determined by the Forward No Answer Internal option setting.
Step 4
Have a partner pod member place a call from the partner pod to your DN x000.
Because this is an external call and x000 does not answer, the call will forward to
hunt pilot x111, as determined by the Forward No Answer External option setting.
This action causes hunting to x001 and x002. If not answered, the call will forward
to the setting specified in the Forward No Coverage External parameter of the
original called number (that is, x000), in this case, x001. The caller does not receive
a reorder tone as before when hunting exhausts.
A call destined for a specific DN (x001) in the hunt group that is forwarded to the hunt
pilot results in the caller receiving final forwarding if hunting exhausts.
Cleanup
To prepare for future labs, remove the hunt groups, line groups, and hunt pilot numbers. The
order in which you delete these items must be the reverse of the order in which you configured
them.
Step 1
Delete the hunt pilot number (choose Route Plan > Route/Hunt > Hunt Pilot).
Step 2
Delete the hunt list (choose Route Plan > Route/Hunt > Hunt List).
Step 3
Delete the line groups (choose Route Plan > Route/Hunt > Line Group).
Answers to Lab Questions

The answers to the lab questions are as follows:
Answer to Task 4, Step 4 question: The call should hunt directly to DN x002 because the
hunt option for ring, no-answer, and not-available conditions is Try Next Member; Then,
Try Next Group in Hunt List. Hunting exhausts because no final forwarding is configured
Answer to Task 5, Step 5 question: The call will forward to x000 because x001 and x002
are not answered. (In a production network, the final forwarding number would probably
be a voice-mail or autoattendant number).
Answer to Task 5, Step 6 question: The call will hunt for 12 seconds and will forward to
x000 because the line is busy.
Answer to Task 6, Step 3 question: The caller receives a reorder tone because DN x000
has not set forwarding specifications for no coverage conditions. As a result, when the
external caller dials x000 and x000 does not answer, x000 forwards the call to the hunt
pilot x111 as specified in the Forward No Answer External Destination setting in the
Directory Number Configuration window for x000. This causes hunting to x001, x000, and
x002. After the maximum hunting timer expires, the caller receives a reorder tone.
Enabling the Call Forward No Coverage settings for the original called number and the Use
Personal Preferences setting on the hunt pilot number prevents the caller from receiving a
reorder tone for no coverage conditions.
70
Lab 3-4: Configuring Complex Route Plans

Activity Objective
In this activity, you will be able to apply complex route plan concepts to simple route plans.
After completing this activity, you will be able to meet these objectives:
Configure translation patterns to handle all DNs within the DID range of the cluster
Configure the external phone number mask on Cisco IP Phones and apply the calling-party
transformation settings in the route pattern or in the route details of the Route List
Configuration window
Modify route patterns by adding an access code (using the . wildcard) and DDIs
Configure a route pattern that has a route filter to block 900 area-code numbers
Visual Objective

Complex Route Plans
Visual from East 1 Perspective
East 2
East 3
IP WAN
ICT
1
94000#,
when
primary
path is
available
PSTN
3
3000
East 1 92000#
1/0/1 FXS MGCP
1/1/1 FXO H.323

1/0/1 FXS MGCP
92000#, when
primary path is
not available
East 4
1/1/1 FXO H.323
2 94000#, when primary path is not available

9.XXXX#
PSTN_RL
Digital GW_RG
H323_MGCP_RG
Cat 6000 PRI GW

H323 GW
MGCP GW
CIPT1 v4.111
In this activity, you will create a new route list called PSTN_RL and a new route group called
Digital GW_RG that contains the Cisco Catalyst 6000 6608 port acting as a digital PRI
gateway. The PRI gateway will be the first-choice gateway in the route list. The
H323_MGCP_RG route group will be added to the new PSTN_RL as a second-choice gateway
in the route list. You will create a new route pattern 9.XXXX# that points to the PSTN_RL.
Lab Guide
71
The H323_MGCP_RG contains the H.323 and MGCP gateways that you created in a previous
lab. In this lab, you will create dial peers for the FXO 1/1/1 ports of the gateway. These dial
peers route calls out the FXO port to the MGCP FSX port 1/0/1 of the partner pod, connected
back-to-back. Because MGCP is not a peer-to-peer protocol like H.323, no dial peers need to
be created on the FSX ports. When an incoming call arrives, the MGCP port sends the call to
Cisco CallManager for call routing.
You will then test call flows when the primary path over the digital PRI gateway is available
and when it is not available. When the primary path is not available and 92000# is dialed, from
the perspective of East 1, the call goes to the East 1 H323 gateway port 1/1/1 and comes into
the East 4 MGCP port 1/0/1, which forwards the call to Cisco CallManager. Cisco CallManager
determines that calls matching the 2XXX route pattern should be sent out the intercluster trunk
and routes the call accordingly to East 2. The call is connected to an IP Phone in East 2.
Required Resources
Two Cisco IP telephony servers
Remote Cisco CallManager clusters
Gateway devices (intercluster trunks, non-IOS MGCP, and Cisco IOS MGCP [FXS, FXO]
and H.323 [FXS, FXO])
Command List
72
Command
Description
To enter privileged EXEC mode, or any other security level that is

set by a system administrator, use the enable EXEC command.
-
-
Configures the destination pattern for the configured dial peer.
When a called number is received and matched to a POTS dial

peer, the default router behavior is to strip matched digits and
forward the remaining digits to the voice interface. The no form of
this command disables digit stripping.
Specifies the voice port that is used with the configured dial peer.
Job Aids
Cluster Name
External Phone Number Mask
East 1
555341XXXX
East 2
555412XXXX
East 3
555123XXXX
East 4
555234XXXX
West 1
777341XXXX
West 2
777412XXXX
West 3
777123XXXX
West 4
777234XXXX
Route Groups
Cluster
H.323_MGCP_RG Name
H.323_MGCP_RG Gateway Order
East 1
E4_H323_MGCP_RG
H323-FXS
MGCP-FXO
East 2
E3_H323_MGCP_RG
H323-FXS
MGCP-FXO
East 3
E2_H323_MGCP_RG
H323-FXS
MGCP-FXO
East 4
E1_H323_MGCP_RG
H323-FXS
MGCP-FXO
West 1
W4_H323_MGCP_RG
H323-FXS
MGCP-FXO
West 2
W3_H323_MGCP_RG
H323-FXS
MGCP-FXO
West 3
W2_H323_MGCP_RG
H323-FXS
MGCP-FXO
West 4
W1_H323_MGCP_RG
H323-FXS
MGCP-FXO
Lab Guide
73
Destination Patterns for H.323 FXO Ports

Cluster Name
Number 1
Number 2
East 1
East 2
East 3
East 4
West 1
West 2
West 3
West 4
Route Filter Called-Party Transformation Settings

Cluster Name
9.@ with Filter
9.@ Without Filter
East 1
3000
2000
East 2
4000
1000
East 3
1000
4000
East 4
2000
3000
West 1
3000
2000
West 2
4000
1000
West 3
1000
4000
West 4
2000
3000
Task 1: Configure a Translation Pattern

To ensure that a company does not miss dialed calls, in this task, you will configure a
translation pattern to send all calls with the given DID range to a known DN, typically an
attendant.
Activity Procedure
74
Step 1
In Cisco CallManager Administration, choose Route Plan > Translation Pattern.
Step 2
Click Add a New Translation Pattern to open the Translation Pattern

Step 3
Enter xXXX for the translation pattern (where the lowercase x = your pod number).
Step 4
Step 5
Enter x000 for the called-party (not calling-party) transformation mask (where x =
your pod number).
Step 6
Click Insert.
From a telephone other than DN x000, call an unassigned DN in your cluster; it should ring
the x000 DN that you configured in Step 5.
Check with another cluster to see whether it has configured its translation pattern, and then
call an unassigned DN in that cluster; it should ring the DN that the cluster configured in
Step 5.
Task 2: Configure Transformation Masks

In this task, you will configure an external phone number mask on Cisco IP Phones and on the
MGCP FXS port and apply calling transformation settings to change the calling party DN.
Activity Procedure
Step 1
In Cisco CallManager Administration, choose Device > Phone and click Find to list
the telephones in the cluster.
Step 2
Choose the first active telephone from the list to access the Phone Configuration
window for that telephone.
Step 3
From the Phone Configuration window for the selected telephone, click Line 1 to
open the Directory Number Configuration window.
Step 4
Scroll down to the Line Settings for this Device section, and enter the external phone
number mask from the Transformation Masks table in the Job Aids section of this
lab activity.
Step 5
Click Update.
Step 6
Repeat Steps 1 though 5 for the other telephones in your cluster.
Apply the External Phone Number Mask to the FXS Endpoint (1/0/1) of the MGCP Gateway
Step 7
In Cisco CallManager Administration, choose Device > Gateway and click Find to
list the gateways in the cluster.
Step 8
Choose the MGCP gateway.
Step 9
Choose the FXS endpoint identifier 1/0/1.
Step 10
Choose DN #051 from the left column.
Step 11
Scroll down to the Line Settings for this Device section, and enter the external phone
number mask from the Transformation Masks table in the Job Aids section of this
lab activity.
Step 12
Click Update.
Step 13
Click Reset Devices, click OK, and then click OK again.
Step 14
Pattern and click Find.
Lab Guide
75
Step 15
Click the route pattern that is pointing to the non-IOS MGCP gateway (the one that
starts with S0/DS1-0) to open the Route Pattern/Hunt Pilot Configuration window.
Step 16
In the Calling Party Transformations section, check the Use Calling Partys
External Phone Number Mask check box.
Step 17
Click Update.
From an IP Phone in your cluster, dial the DN of an IP Phone in the cluster that is
connected via the non-IOS MGCP gateway (the one that starts with S0/DS1-0@). The
receiving telephone will see the external phone number mask applied to the DN of the
calling telephone.
From the analog telephone that is plugged into the MGCP FXS port, dial the DN of an IP
Phone in the cluster that is connected via the non-IOS MGCP gateway The receiving
telephone will see the external phone number mask applied to the DN of the calling
telephone.
Task 3: Modify Route Patterns to Use Access Codes and DDIs

In this task, you will use the route patterns that are already in the Cisco CallManager database,
modify those route patterns to use an outside line access code, and apply the DDI to send the
correct expected digits to the next call-processing agent.
Activity Procedure
Delete Route Patterns and Route Lists
Step 1
Pattern and click Find to list the route patterns that are configured in the cluster.
Step 2
Check the check box of the route pattern next to the non-IOS MGCP gateway (starts
with S0/DS1-0@).
Step 3
Click Delete Selected, and click OK to delete the route patterns.
Modify the Route Group

Step 4
Choose Route Plan > Route/Hunt > Route Group.
76
Step 5
Choose the Add New Route Group link at the top right of the Route Group
Step 6
Enter Digital GW_RG for the route group name.
Step 7
Choose the non-IOS MGCP gateway (S0/DS1-0@SDA<MAC_Address>) from the

Available Devices. Click Add to Route Group.
Step 8
Click Insert.
Step 9
List.
Step 10
Step 11
Enter PSTN_RL for the route list name, enter Digital H.323 MGCP gws for the
description, and choose BA_CMG for the Cisco CallManager group. Click Insert
and OK.
Step 12
Click Add Route Group to add a route group to the route list.
Step 13
Choose route group Digital GW_RG-[NON-QSIG] and click Insert and OK.
Step 14
Click Add Route Group.
Step 15
Choose YY_H323_MGCP_RG [Non-QSIG] for the Route Group and click Insert
and OK.
Step 16
Reset the route list.
Configure Dial Peers on H.323 and MGCP Gateways

Step 17
Establish a Telnet session to the H.323 gateway and enter cisco as the password.
Enter enable and the password cisco to enter enable mode.
Step 18
Enter the command configuration terminal or config t to enter configuration mode.
Step 19
Enter the following commands to configure the FXO port 1/1/1 information (where
x = your pod number). Refer to the Destination Patterns for H.323 FXO Ports
table in the Job Aids section of this lab activity for the Number 1 and Number 2
destination patterns.
-
-

-
-

The dial peers configured have preference 0 configured (by default), so they take
precedence over the dial peers that you created earlier with precedence 1 to the same
destinations. In this lab, the Number 2 destination pattern is (finally) used to
complete call routing to the Number 2 pod.
Step 20
Disconnect the analog telephone that is plugged into the FXS port of the MGCP
gateway. Connect an RJ-11 cable from the FXS port (1/0/1) of the MGCP gateway
of to the FXO port (1/1/1) of your H.323 gateway to your partner pod as listed here:
Lab Guide
77
Configure a Route Pattern

Step 21
Pattern, and click Add a New Route Pattern to open the Route Pattern
Step 22
Enter 9.XXXX# for the route pattern (literally, 9.XXXX#).
Step 23
Choose PSTN_RL from the Gateway/Route List menu.
Step 24
Ensure that the Provide Outside Dial Tone check box is checked.
Step 25
In the Calling Party Transformations section, check the Use Calling Partys
External Phone Number Mask check box.
Step 26
In the Called Party Transformation section, click PreDot Trailing-# for the Discard
Digits parameter. The PreDot trailing-# DDI removes the access code and the
end-of-dialing # character.
Step 27
Click Insert.
You are able to call a DN in the cluster that is connected via the intercluster trunk using the
yXXX route pattern, where y = your partner pod number.
Call a DN in the cluster that is directly connected via the H.323 and MGCP gateway by
using the 9XXXX# route pattern. Do not enter . after the 9, but be sure to enter # after
you enter the 9 plus a valid four-digit extension in the remote pod. The call route is through
the digital gateway and then through the intercluster trunks that are configured to the
cluster of the other group.
When the other group is ready, unplug the T1 crossover cable and call a DN in the cluster
that is connected via the H.323 and MGCP gateway using the 9XXXX# route pattern.
Because the primary call path (T1) is not available, the call is routed to the second choice
(H323_MGCP_RG).
With the T1 crossover cable still unplugged, call a DN in the cluster that is connected via
the digital gateway by using the 9XXXX# route pattern. The call is now routed to the Cisco
CallManager that is connected via the analog trunks and then through the intercluster trunk
to the final destination.
With the T1 crossover cable still unplugged, shut down the H.323 FXO voice ports (see the
note that follows) and call a DN in the cluster that is connected via the H.323 and MGCP
gateway using the 9XXXX# route pattern. Calls will now be routed through the H.323 FXS
port to the MGCP FXO port; however, because the MGCP FXO port is assigned an
attendant DN (y000), all calls will be routed to the attendant DN.
Note
To shut down a voice port, enter configuration mode (configure terminal), enter voice-port
[x/x/x] (FXO port <1/1/1>), and enter shutdown.
Cleanup
Reconnect all cables (T1) and enable all voice ports (no shutdown) in preparation for the next
lab activity.
78
Task 4: Configure Route Filters to Apply to Route Patterns

In this task, you will block dialing to particular area codes using a route filter that is applied to
a route pattern.
Activity Procedure
Step 1
Remove the route pattern to the ICT_RL route list. In Cisco CallManager
Administration, choose Route Plan > Route/Hunt > Route Pattern, and click Find
to list all the route patterns. Delete the route pattern that is associated with the route
list ICT_RL.
Step 2
Choose Route Plan > Route Filter, and click Add a New Route Filter to access
the Route Filter Configuration window.
Step 3
Enter Block 900 Calls for the route filter name, and click Continue.
Step 4
Choose == from the drop-down menu and enter 900 in the AREA-CODE field.
Click Insert.
Step 5
Choose Route Plan > Route/Hunt > Route Pattern, and click Add a New Route
Pattern to open the Route Pattern Configuration window.
Step 6
Enter 9.@ for the route pattern.
Step 7
Choose Block 900 Calls for the Route Filter, and choose ICT_RL for the
Gateway/Route List.
Step 8
Check the Provide Outside Dial Tone check box.
Step 9
In the Called Party Transformation section, choose PreAt for the Discard Digits
parameter, and enter the <9.@ with Filter> number in the Called Party Transform
Mask field. This number is found in the Route Filter Called-Party Transformation
Settings table in the Job Aids section of this lab activity.
Step 10
Click Insert.
Step 11
Click Add a New Route Pattern to display the Route Pattern Configuration
window.
Step 12
Enter 9.@ for the route pattern.
Step 13
Choose PSTN_RL for the Gateway/Route List.
Step 14
Leave the Provide Outside Dial Tone check box checked.
Step 15
In the Called Party Transformation section, choose PreAt for the Discard Digits
parameter and enter the <9.@ without Filter> number in the Called Party
Transform Mask field. This number is found in the Route Filter Called-Party
Transformation Settings table in the Job Aids section of this lab activity.
Step 16
Click Insert.
Lab Guide
79
Dial a telephone number without a 900 area code from a telephone within your cluster, and
you should connect to the cluster via the digital gateway (for example, 91 612 555 0112).
Dial a telephone number with a 900 area code from a telephone within your cluster, and
you should connect to the cluster via the intercluster trunk (for example, 91 900 555 0112).
At this point, you have not blocked 900 area code calling, you have just routed it to an
extension for testing. To block 900 calls, click Back to Find/List Route Patterns. Click
the 9.@ route pattern that has the Block 900 Calls route filter. Click the Block This
Pattern drop-down list, and then choose either Call Rejected or Invalid Number Format.
Click Update.
Dial a telephone number with a 900 area code from a telephone within your cluster. You
should get a fast busy signal if you selected Call Rejected or an announcement (Your call
cannot be completed as dialed.) if you selected Invalid Number Format.
Cleanup
Complete these tasks to prepare for the next lab activities:
80
Step 1
From Cisco CallManager Administration, choose Route Plan > Route/Hunt >
Route Pattern. Choose the 9.@ route pattern that blocks 900 calls for the route and
delete it.
Step 2
Choose Add a New Route Pattern.
Step 3
Enter yXXX for the route pattern, where y = the number to reach your partner pod
that is connected via intercluster trunk. (East 1 enters 3XXX, East 3 enters 1XXX,
East 2 enters 4XXX, and East 4 enters 2XXX.)
Step 4
From the Gateway or Route List drop-down list, choose ICT_RL. Uncheck the
Provide Outside Dial Tone check box. Click Insert.
Lab 3-5: Implementing Class of Control
Activity Objective
In this activity, you will configure partitions and calling search spaces to apply a class of
service for Cisco IP telephony devices.
Configure partitions in Cisco CallManager Administration
Configure calling search spaces in Cisco CallManager Administration
Assign partitions and calling search spaces to configure a telephony class of service
Assign partitions and calling search spaces to route patterns and gateways
Using calling search spaces, partitions, and a translation pattern, configure a telephone to
use the PLAR feature
Visual Objective
Visual Objective for Lab 3-5: Implementing

Class of Control
Lobby_PT
Employee_PT Executive_PT
x001
x000
x002
yXXXX
9.XXXX
To Another
Pod
ICT_PT
PSTN_PT
CIPT1 v4.112
In this activity, you will create the partitions shown in the figure, assign them to calling search
spaces, and then assign the partitions and calling search spaces to DNs and route patterns to
enable the calling privileges shown in the figure. The lobby telephone will be able to call only
the employee telephone. The employee telephone will be able to call everywhere except the
executive telephone and PSTN route pattern (9.XXXX#). The executive telephone will be able
to call everywhere.
Lab Guide
81
Required Resources
Cisco IP telephony server cluster
Gateway devices
Command List
Job Aids
These job aids are available to help you complete the lab activities.
Partitions
Partition Name
Description
Assigned to DNs and Route Patterns
Employee_PT
All Regular Employees
x000
Lobby_PT
Lobby Directory Numbers
x001
Executive_PT
Executive Employees
x002
PSTN_PT
PSTN Route Patterns
9.XXXX#
9.@ without route filter
82
ICT_PT
ICT Route Patterns
yXXX, where y = partner pod connected via

intercluster trunk
INTRA_PT
Translation Pattern
xXXX, where the lowercase x = your pod

number
Calling Search Spaces

Devices
Calling Search Space

Name
Description
Contains These
Partitions
Executive telephone
Unlimited Access_CSS
Unlimited Calling
Privileges
Employee_PT
Lobby_PT
Executive_PT
PSTN_PT
ICT_PT
INTRA_PT
Employee telephone
Company Only_CSS
Intercluster trunks
Intra- and Intercluster

Calling Only
Employee_PT
Lobby_PT
ICT_PT
INTRA_PT
Lobby telephone
Cluster Only_CSS
Non-IOS MGCP
gateway
MGCP gateway
Intracluster Calling Only
Employee_PT
Lobby_PT
INTRA_PT
H.323 gateway
Translation pattern
Task 1: Configure Partitions

In this task, you will create partitions in Cisco CallManager Administration with a partition
name and description.
Activity Procedure
Step 1
In Cisco CallManager Administration, choose Route Plan > Class of Control >
Partition, and click Add a New Partition to open the Partition Configuration
window.
Step 2
Using the partition configuration data from the Partitions table (in the Job Aids
section of this lab), enter all the partition names and the description using the
following format:
<partitionName> , <description>
Step 3
Lab Guide
83
You are able to view all the partitions that you added when you click Find from the Find
and List Partitions window in Cisco CallManager Administration.
Task 2: Configure Calling Search Spaces

In this task, you will create calling search spaces.
Activity Procedure
Step 1
Calling Search Space, and click Add a New Calling Search Space to open the
Calling Search Space Configuration window.
Step 2
Using the Calling Search Spaces table (in the Job Aids section of this lab activity),
enter a calling search space name and description.
Step 3
Using the information in the Calling Search Spaces table, choose the appropriate
partitions to add to the calling search space from the Available Partitions pane.
(Highlight a partition, and use the Down arrow below the Available Partitions pane
to move the highlighted partition to the Selected Partitions pane. Use the Shift key to
select multiple contiguous entries and the Ctrl key to select multiple noncontiguous
entries.)
Step 4
Use the Up and Down arrow keys to place the partitions in the same order as in the
Calling Search Spaces table.
Step 5
Click Insert.
Step 6
Click Add New Calling Search Space to open the Calling Search Space
Step 7
Repeat Steps 2 through 6 to create the remaining calling search spaces that are listed
in the Calling Search Spaces table.
You are able to view all calling search spaces that you have added when you click Back to
Find/List Calling Search Spaces.
84
Task 3: Assign Partitions and Calling Search Spaces to

Configure a Telephony Class of Service
In this task, you will assign partitions to DNs and route patterns and assign calling search
spaces to devices to apply a telephony CoS within a Cisco IP telephony cluster.
Activity Procedure
Step 1
In Cisco CallManager Administration choose Device > Phone.
Step 2
Set the search parameters in the Find Phones Where fields to Directory Number,
Begins With, and your pod number, as shown in the figure. Click Find to list the
telephones that are registered in the cluster by DNs.
Finding Phones by DN
Step 3
Choose the telephone with DN x000 to open the Phone Configuration window.
Step 4
Click Line 1 - x000 from the left column to access the Directory Number
Step 5
Choose Employee_PT for the partition, and click Update.
Step 6
Click Configure Device (SEP<MAC Address>) to return to the Phone

Step 7
Choose Company Only_CSS for the calling search space, click Update, and click
OK.
Step 8
Click Reset Phone, click Reset, and click OK.
Step 9
Click Back to Find/List Phones to list the telephones that are registered in the
cluster by DNs.
Step 10
Repeat Steps 3 through 9 for the other two telephones. Refer to the Partitions table
and the Calling Search Spaces table (in the Job Aids section of this lab activity)
for partition and calling search space configuration parameters for each DN.
The executive telephone (x002) is able to call both the employee (x000) and lobby (x001)
telephones.
The employee (x000) and lobby (x001) telephones can call between each other but cannot
call the executive telephone (x002).
Lab Guide
85
Task 4: Assign Partitions and Calling Search Spaces to Route

Patterns and Gateways
In this task, you will assign partitions and calling search spaces to route patterns, translation
patterns, gateways, and trunks.
Activity Procedure
Step 1
Pattern. (Click Find to list all the route patterns if none are visible.)
Step 2
Refer to the Partitions table (in the Job Aids section of this lab activity). Choose
the first route pattern from the list to access the Route Pattern Configuration window
for that route pattern.
Step 3
Choose the partition from the Partitions table that corresponds to the route pattern
that you have selected.
Step 4
Click Update.
Step 5
Click Back to Find/List Route Patterns, and repeat Steps 2 through 4 for all the
other route patterns that are identified in the Partitions and Calling Search
Spaces tables.
Step 6
In Cisco CallManager Administration, choose Route Plan > Translation Pattern,

and click Find to list all the translation patterns.
Step 7
Choose the first translation pattern from the list to access the Translation Pattern
Configuration window for that translation pattern.
Step 8
Choose the partition from the Partitions table that corresponds to the translation
pattern that you have selected.
Step 9
Choose the calling search space from the Calling Search Spaces table that
corresponds to the translation pattern that you have selected.
Step 10
Click Update.
Step 11
In Cisco CallManager Administration, choose Device > Gateway, and click Find to
list all the gateways.
Step 12
Choose the first gateway from the list to access the Gateway Configuration window
for that gateway.
Step 13
corresponds to the gateway that you have selected.
Note
86
Because each endpoint on an MGCP gateway is considered to be separate gateway, to

configure the calling search space for an MGCP gateway, you must select the endpoints.
Step 14
Click Update, and click OK.
Step 15
Click Back to Find/List Gateways, and repeat Steps 12 through 14 for all the other
gateways.
Step 16
Click Back to Find/List Gateways, and check the check box in the table header
field so that all the gateways have been selected.
Step 17
Click Reset Selected, click Reset, and click OK. This action resets multiple
gateways.
Step 18
In Cisco CallManager Administration, choose Device > Trunk and click Find.
Step 19
Choose the only trunk listed to go to the Trunk Configuration window.
Step 20
corresponds to the selected trunk.
Step 21
Click Update and then click OK.
Step 22
Reset the trunk to make the changes take effect.
From the employee telephone (x000) you are able to dial within the cluster (except for the
executive telephone) and use the intercluster trunk route pattern. You are not able to dial
the PSTN route pattern.
From the executive telephone (x002) you are able to call anywhere; however, other clusters
are not able to call the executive telephone because the gateway calling search space
(Cluster Only_CSS) does not have the executive partition listed in the selected partitions.
From the lobby telephone (x001), you are able to call x000 only.
Task 5: Configure Private Line, Automatic Ringdown

In this task, you will configure the PLAR feature using partitions, calling search spaces, and a
special use of a translation pattern.
Activity Procedure
Step 1
Partition, and click Add a New Partition to open the Partition Configuration
window.
Step 2
Create a partition with the name Hotline_PT and description PLAR Translation
Pattern:
Step 3
Step 4
Calling Search Space, and click Add a New Calling Search Space to open the
Calling Search Space Configuration window.
Step 5
Enter the new calling search space name Hotline_CSS in the Calling Search Space
Name field. Add the Hotline_PT partition to the Selected Partitions field.
Step 6
Click Insert.
Lab Guide
87
Step 7
In Cisco CallManager Administration, choose Route Plan > Translation Pattern,

and click Add a New Translation Pattern to access the Translation Pattern
Step 8
Leave the Translation Pattern field blank.
Step 9
Choose Hotline_PT for the partition, and choose Unlimited Access_CSS for the
calling search space.
Step 10
Step 11
Enter x001 (where x = your pod number) in the Called Party Transform Mask field
(not Calling Party Transform Mask).
Step 12
Click Insert.
Step 13
In Cisco CallManager Administration, choose Device > Phone and click Find to list
all the telephones in the cluster.
Step 14
Choose the executive telephone, x002. Assign the new Hotline_CSS calling search
space to the telephone, update, and reset the device.
When you lift the handset of the executive telephone (x002), it rings x001. If it does not
work, make sure that you entered the PLAR destination number in the Called Party
Transform Mask field (not the Calling Party Transform Mask field).
Note
The blank translation pattern is equal to no digits, and the called-party transformation
mask specifies the DN or route pattern to be dialed.
Cleanup
To prepare the equipment for the next lab, complete these steps:
Step 1
Assign all telephone lines (DNs) to the Employee_PT partition.
Step 2
Assign all telephones and the xXXX translation pattern to the Unlimited
Access_CSS calling search space, where the lowercase x = your pod number.
Step 3
Assign all gateways to the Unlimited Access_CSS calling search space.
Step 4
Assign all trunks to the Unlimited Access_CSS calling search space.
Step 5
Delete the PLAR translation pattern (no digits).
Step 6
Reset all telephones and gateways.
All telephones and gateways are able to dial all DNs and route patterns.
88
Lab 3-6: Configuring Call Admission Control

Activity Objective
In this activity, you will be configuring bandwidth, zone settings, and configuration information
for Cisco CallManager administration of a gatekeeper device (Cisco 2600 or 3600). After
Configure a gatekeeper for call admission control
Configure the gatekeeper and intercluster trunk in Cisco CallManager Administration Cisco
CallManager for call admission control
Configure location-based call admission control in Cisco CallManager Administration
Visual Objective
These figures illustrates what you will accomplish in this activity.
Visual Objective for Lab 3-5: Implementing

Class of Control
Zone: East2 cisco.com
Bandwidth: 256 kbps

Bandwidth: 256 kbps
Gatekeeper-Controlled
Intercluster
Trunks
128 kbps
128 kbps
Gatekeeper

Bandwidth: 256 kbps

Bandwidth: 256 kbps
Not
enough
bandwidth
CIPT1 v4.113
In Tasks 1 and 2, you will configure gatekeeper-controlled intercluster trunks in Cisco

CallManager Administration. You will also configure call admission control on the Cisco IOS
gatekeeper so that any calls that would cause the zone bandwidth to exceed the 256-kbps
maximum will be rejected.
Lab Guide
89

Call Admission Control
Cluster
Publisher
x001 hears tone on hold

instead of music on hold
because the MOH server is
configured to stream audio at
G.711 and there is not enough
bandwidth.
x000
Cisco 2600
Default Gateway
Subscriber
Play Tone on Hold
Cisco Catalyst
Switch Inline
Power Module
x001
Extension x002 dials x001 using G.729 codec

x001 places x002 on hold
56kbps/
G.729
LocationBranch1
RegionBranch1
2
x002
CIPT1 v4.114
In Tasks 3 and 4, you will configure call admission control using locations and regions in Cisco
CallManager Administration. You will create a remote location and region called Branch1 that
has 56 kbps of available bandwidth and uses the G.729 codec. An IP Phone assigned to the
Branch1 region will call an IP Phone in the default region and will be placed on hold. Because
the MOH server is set to stream audio at G.711, which requires 80 kbps of bandwidth, the
telephone in the remote region will hear only a tone on hold.
Required Resources
This is the equipment required to complete this activity:
Gatekeeper device (Cisco 2600 or 3600) for Task 1 and 2
90
Command List
Gatekeeper Commands
Command
Description

Enters gatekeeper configuration mode.
Specifies the zone that is controlled by the gatekeeper.
-
---
Configures the gatekeeper to accept discovery and registration

messages that are sent by endpoints in designated subnets.
-
---
Configures the gatekeeper to deny discovery and registration

messages that are sent by endpoints in configured subnets.
Configures the prefix or digits that are associated with a zone.
Configures the default technology.
Configures the total bandwidth that is allowed in the specified

zone.
---
-
Configures the total bandwidth that is allowed during a session

(call) in a zone.
Enables the gatekeeper.
-
-
Display the status of all registered endpoints for a gatekeeper,
- -
Displays the status of each ongoing call of which a gatekeeper is

aware.
Job Aids
Lab Guide
91
Gatekeeper-Controlled Intercluster Trunks

Zone Name (No Spaces)
ICT_RG Name
Intercluster Trunk Name
East1
E3_ICT_RG
E3_ICT_GK
East2
E4_ICT_RG
E4_ICT_GK
East3
E1_ICT_RG
E1_ICT_GK
East4
E2_ICT_RG
E2_ICT_GK
West1
W3_ICT_RG
W3_ICT_GK
West2
W4_ICT_RG
W4_ICT_GK
West3
W1_ICT_RG
W1_ICT_GK
West4
W2_ICT_RG
W2_ICT_GK
Task 1: Configure the Gatekeeper

In this task, you will configure zone, bandwidth, and Cisco CallManager information settings
on the gatekeeper and add the gatekeeper in Cisco CallManager Administration.
Activity Procedure
Step 1
Establish a Telnet session to the gatekeeper (IP address 172.20.1.1) and enter cisco
as the password. Enter enable, and when you are prompted for the password, enter
cisco.
Step 2
Enter the command configure terminal or config t to enter configuration mode.
Step 3
Use the command gatekeeper to enter gatekeeper configuration mode. The prompt
should be Gatekeeper(config-gk)#.
Step 4
Configure the gatekeeper parameters. Refer to the Gatekeeper Commands table

and the Gatekeeper-Controlled Intercluster Trunks table in the Job Aids section of
this lab activity for the zone name, and enter the following commands to configure
the gatekeeper (where x = your pod number):
-
- - --
- - --
-

---
-
Step 5
92
Save the configuration. Enter end, and in enable mode enter write mem or copy
running start to save the configuration. Enter exit to close the Telnet session.
Task 2: Configure the Gatekeeper and Intercluster Trunk in

Cisco CallManager Administration
In this task, you will add the gatekeeper device in Cisco CallManager Administration and
configure the gatekeeper-controlled intercluster trunk. You will also add the gatekeepercontrolled trunk to an existing route group and remove the nongatekeeper-controlled trunk.
Activity Procedure
Add the Gatekeeper in Cisco CallManager Administration
Step 1
In Cisco CallManager Administration, choose Device > Add a New Device.
Step 2
Choose Gatekeeper from the list of device types, and click Next.
Step 3
In the Host Name/IP Address field, enter the IP address of the gatekeeper
(172.20.1.1).
Step 4
For the description, enter Gatekeeper.
Step 5
Leave the Registration Request Time to Live and Retry Timeout fields at their
default values. Ensure that the Enable Device check box is checked.
Step 6
Click Insert.
Step 7
Click Reset Gatekeeper, Reset, and OK.
Add a Gatekeeper-Controlled Intercluster Trunk

Step 8
From Cisco CallManager Administration, choose Device > Add a New Device.
Step 9
Choose Trunk from the Device Type menu and click Next.
Step 10
Choose Inter-Cluster Trunk (Gatekeeper Controlled) for the trunk type.
Step 11
The Device Protocol field automatically populates with Inter-Cluster Trunk. Click
Next.
Step 12
In the Device Name field, enter the name of the new gatekeeper-controlled
intercluster trunk from the Intercluster Trunk Name column of the GatekeeperControlled Intercluster Trunks table in the Job Aids section of this lab activity.
Step 13
In the Description field, enter Gatekeeper Controlled ICT to <Remote Cluster

Code>.
Step 14
For the device pool, choose BA_Default_CMLocal_DP.
Step 15
For significant digits, choose 4.
Step 16
For calling search space, choose Unlimited Access_CSS.
Step 17
For calling line ID presentation, choose Allowed.
Step 18
In the Gatekeeper Information area, choose 172.20.1.1 in the Gatekeeper Name field
and Gateway in the Terminal Type field. (A terminal type of Terminal would be an
H.323 clientfor example, NetMeeting.)
Step 19
Enter 1# for the technology prefix.
Lab Guide
93
Step 20
In the Zone field, enter your zone name. (Refer to the Zone Name column of the
Gatekeeper-Controlled Intercluster Trunks table in the Job Aids section of this lab
activity.) This entry is case-sensitive and must be entered exactly as it is configured
on the gatekeeper itself.
Step 21
Click Insert and OK, and then click Reset Trunk, Reset, and OK.
Add the New Gatekeeper-Controlled Intercluster Trunk to an Existing Route Group

Step 22
In CallManager Administration, choose Route Plan > Route/Hunt > Route Group.
(Click Find to list all the route groups if none are visible.)
Step 23
Choose the YY_ICT_RG route group. (Refer to the ICT_RG Name column of the
Gatekeeper-Controlled Intercluster Trunks table in the Job Aids section of this lab
activity.)
Step 24
Choose the <Remote Cluster Code>_ICT_GK device from the Available Devices
box, and click the Add to Route Group button. Click Update.
Step 25
From the Current Route Group list, choose the nongatekeeper-controlled intercluster
trunk that was originally assigned to this route group (YY_ICT). Use the arrow to
move it to the Removed Devices pane. The <Remote Cluster Code>_ICT_GK
should be the only device in the Current Route Group Members pane.
Step 26
Click Update.
Establish a Telnet session to the gatekeeper (IP address 172.20.1.1). From the enable mode
prompt (#), enter show gatekeeper endpoints and verify that both your Cisco CallManager
and your partner pod Cisco CallManager have registered to the gatekeeper.
Place two calls from your IP Phones to the pod that is connected via the gatekeepercontrolled intercluster trunk. While the two calls are active, place a third call. The third call
should fail (fast busy). On the gatekeeper, enter show gatekeeper calls while the calls are
active to view the bandwidth that is allocated to each call.
Task 3: Configure Locations and Regions

In this task, you will configure locations and regions in Cisco CallManager Administration to
provide location-based call admission control in a centralized call-processing model.
Activity Procedure
Add a Region and Define the Codec Used
Step 1
In Cisco CallManager Administration, choose System > Location to open the Find
and List Location Configuration window.
94
Step 2
Click Add a New Location to open the Location Configuration window.
Step 3
Enter Branch1 as the location name, and enter 56 for the available audio bandwidth.
Step 4
Click Insert.
Step 5
Choose System > Region to open the Find and List Regions window.
Step 6
Click Add a New Region to open the Region Configuration window.
Step 7
In the Region Name field, enter Branch1. Change the Default Codec with Other
Regions field to G.729. Click Insert.
Step 8
Change the Audio Codec for Branch1 (Within this Region) field to G.711.
Step 9
Click Update.
Create a New Device Pool for the Remote Region

Step 10
Choose System > Device Pool.
Step 11
Click Add a New Device Pool. Name the device pool BA_CMLocal_Remote.
Step 12
Assign the following parameters to the new device pool:

Cisco CallManager Group: BA_CMG
Date/Time Group: CMLocal
Region: Branch1
Softkey Template: Standard User
SRST Reference: Disable
Step 13
Click Insert to save the configuration in the database.
Step 14
Choose Application > Cisco CallManager Administration.
Assign the Device Pool to an IP Phone

Step 15
Choose Device > Phone and click Find to list all telephones.
Step 16
Select x002 to open the Phone Configuration window. You will configure this
telephone as a remote telephone.
Step 17
Choose BA_CMLocal_Remote for the device pool and Branch1 as the location for
the telephone.
Step 18
Click Update and reset the telephone.
Place a call between the telephone that is assigned to the new region and another telephone
in your cluster. When the call is active, press the i button twice to verify that the call has
been placed using the G.729 codec. Leave the call active and continue to the next step.
Place the telephone that is in the remote region on hold. Because the MOH server is
configured to stream audio at G.711, a tone on hold (beep) will be played instead of music.
Lab Guide
95
Lab 3-7: Configuring SRST
Activity Objective
In this activity, you will configure Cisco SRST to provide call-processing redundancy during
WAN failure. After completing this activity, you will be able to meet this objective:
Configure the SRST feature on the default gateway and Cisco CallManager to provide
call-processing redundancy
Visual Objective

Cisco SRST
SRST Gateway
SRST Gateway
East 2
2XXX
East 3
3XXX
SRST Gateway
East 1
1XXX
SRST Gateway
East 4
4XXX
CIPT1 v4.115
In this activity, you will configure SRST on the default gateway and add the SRST reference in
Cisco CallManager. You will simulate the loss of IP WAN connectivity by stopping the Cisco
CallManager service. The IP Phones will fail over to the SRST gateway, and the gateways will
provide call processing until the Cisco CallManager comes back online.
Required Resources
Cisco IP telephony server cluster
Gateway device with SRST feature
96
Command List
Cisco SRST Commands
Command
Description

Enables SRST feature support and enters Cisco CallManager

fallback mode.
----
Enables the router to receive messages from the Cisco IP

Phones through the specified IP addresses and ports. The default
port number is 2000.
-
-
Configures the maximum number of Cisco IP Phones that can be

supported by the router. The default is 0. The maximum number
is platform-dependent.
Sets the maximum number of DNs or virtual voice ports that can
be supported by the router. The default is 0. The maximum
number is platform-dependent.
Displays the Cisco IP Phones that have registered to the SRST

router.
Verifies that the SRST feature is enabled.
Job Aids
Task 1: Configure Cisco SRST

In this task, you will to provide configure SRST to provide call-processing redundancy in the
event of WAN failure.
Activity Procedure
Step 1
Establish a Telnet session to your default router. The Telnet password is cisco.
Enter enable, and when you are prompted for the password, enter cisco.
Step 2
Enter config t to enter global configuration mode. Your prompt should look like
this:
-
Step 3
At the prompt, enter the call-manager-fallback command. You are now in the
call-manager-fallback configuration mode; the prompt will look like this:
-
Lab Guide
97
Step 4
Enter the following command to enable the router to receive messages from the
Cisco IP Phones through the specified IP addresses using the default port 2000:
--- --
Step 5
Enter the following command to configure the maximum number of Cisco IP

Phones that can be supported by the router. Enter 3 because you have three IP
Phones.
-
Note
Step 6
Although the Cisco 2600 router can support more than three IP Phones, it is important to
consider that for each IP Phone that is configured, the router reserves resources for SRST
that cannot be used for other functions, such as routing.
Enter the following command to set the maximum number of DNs or virtual voice
ports that can be supported by the router:

Step 7
Enter end or Ctrl-Z to exit configuration mode. Save your configuration (write
mem or copy run start).
Step 8
In Cisco CallManager Administration, choose System > Device Pool to open the
Find and List Device Pools window. (Click Find if no device pools are visible.)
Choose BA_Default_CMLocal_DP.
Step 9
In the SRST Reference field, choose Use Default Gateway.
Note
When you specify the Use Default Gateway option, if a telephone cannot reach any Cisco
CallManager servers it tries to connect to its IP gateway as an SRST gateway.
Step 10
Click Update.
Step 11
A popup window appears that indicates that x number of devices must be reset for
the changes to take effect. Click OK, and then click Reset Devices. Click OK two
more times to reset the devices.
Open a remote terminal services session to your publisher and your subscriber (first one
and then the other) and stop the Cisco CallManager service on each server. (After
connecting to the server, choose Start > Programs > Administrative Tools > Services
and then right-click Cisco CallManager and choose Stop.) After the IP Phones determine
that they cannot reach either Cisco CallManager, they will fail over to the default router
and display CM Fallback Service Operating.
Enter show ephone on the SRST router (your default gateway) to verify that the IP Phones
have registered to the SRST router. On an IP Phone in fallback mode, press Settings, 3, and
then 21. View settings 21, 22, and 23. The active Cisco CallManager is now the SRST
router.
98
Two of the IP Phones in your cluster will register to SRST and one will not because you
have assigned the SRST reference to the BA_Default_CMLocal_DP device pool and your
remote telephone is still assigned to the BA_CMLocal_Remote device pool. Follow these
steps to change the device pool assignment:
Step 1
Step 2
Select the telephone that is assigned to the BA_CMLocal_Remote device pool.
Step 3
Step 4
Change the location to None.
Step 5
Click Update and then click OK.
Step 6
Reset the telephone. The telephone will now register using SRST and display
CM Fallback Service Operating.
With neither of your Cisco CallManager servers operating, place a call within your cluster
to another IP Phone.
Start the Cisco CallManager service on both servers and observe that the telephones
rehome to their Cisco CallManager nodes.
Lab Guide
99
Lab 4-1: Configuring Media Resources
Activity Objective
In this activity, you will configure media resources (MTP, CONF, XCODE, and MOH) for
devices to use. After completing this activity, you will be able to meet these objectives:
Configure hardware media resources (CONF and XCODE) in a Cisco CallManager
database
Configure Meet-Me DNs to support Meet-Me conferences
Configure MRGs and MRGLs and assign the MRGL to devices
Configure and add new audio source files used by the MOH servers and assign the new
audio source files to devices
Visual Objective
Visual Objective for Lab 4-1:

Cluster
Conference and
Transcoder
Resources
MOH Server
All_MRGL
Hardware_MRG
Software_MRG
CFB_MRG
Publisher
Meet-Me
Conference
Number x58X
MOH_MRG
Cisco
Catalyst 6500
Chassis
6608 Voice T1
or E1 Services
Module
XCODE_MRG
NOCFB_MRGL
MOH_MRG
XCODE_MRG
MOH_MRGL
MOH_MRG
CIPT1 v4.116
In this task, you will add transcoding and hardware conferencing resources to Cisco
CallManager and configure a Meet-Me conference number for users to establish ad hoc
conferences. Then you will group like media resources into groups, add them to MRGLs, and
assign the MRGLs to devices. Only devices with access to conference resources will be able to
establish a conference call.
100
Required Resources
Cisco Catalyst 6000 switch with a T1 or E1 module (WS-X6608-T1 or WS-X6608-E1)
Audio files (.mp3 or .wav format)
Command List
Cisco Catalyst 6000 Series Switch Commands
Command
Description

This command shows the settings of a port.
Job Aids
Cluster Name
Voice VLAN
Data VLAN
East 1
10
15
East 2
20
25
East 3
30
35
East 4
40
45
West 1
50
55
West 2
60
65
West 3
70
75
West 4
80
85
Pre-Lab Task: Test Default Media Resource Availability

In this task, you will test the default media resources that are available when the IP Voice
Media Streaming Application service is selected during Cisco CallManager installation.
Step 1
Set up a call between two telephones within your cluster.
Step 2
Press the Hold softkey, and the held telephone will play the sample audio source
file.
Step 3
Press the Resume softkey to reconnect the call.
Step 4
Press the More softkey, and then press the Confrn softkey. (Audio will play on the
automatically held telephone.)
Lab Guide
101
Step 5
Dial the DN of another telephone in the cluster to set up a call. Press the Confrn
softkey to establish an ad hoc conference.
Step 6
From the telephone that set up the conference, press the More softkey. Press the
third softkey from the left (it should be labeled ConfLi..) to list the conference
participants. Highlight the last person (DN) added to the conference and press the
Remove softkey to remove that person from the conference.
Step 7
Hang up the other two telephones to end the conference.
Step 8
Delete the xXXX translation pattern (where the lowercase x = your pod number) so
that calls to invalid DNs in your pod do not forward to x000, the attendant DN
(choose Route Plan > Translation Pattern).
Call an invalid DN within your cluster. You should hear the annunciator announce
Your call cannot be completed as dialed. Please consult your directory and call
again or ask your operator for assistance. This is a recording. The annunciator is
automatically added to the Cisco CallManager database when you activate the Cisco
IP Voice Media Streaming Application service. You completed the activation of this
service in Lab 1-1, Cisco CallManager Postinstallation Tasks.
Without additional configuration, ad hoc conferencing, MOH, and the annunciator are available
by using the Cisco CallManager server system resources (referred to as software resources).
Task 1: Configure Hardware Media Resources

In this task, you will configure hardware media resources in the Cisco CallManager database.
Activity Procedure
Step 1
In Cisco CallManager Administration, choose Service > Media Resource and

choose Conference Bridge to open the Find and List Conference Bridge window.
Step 2
Click the Add a New Conference Bridge link.
Step 3
Choose Cisco Conference Bridge Hardware from the Conference Bridge Type
drop-down list.
Step 4
Leave the Cisco CallManager Administration window open (minimized). Establish a

Telnet session to the Cisco Catalyst 6000 by entering telnet 172.16.1.3 from the
command prompt. At the password prompt, press Enter (there is no password).
Enter enable mode by entering enable. At the password prompt, press Enter (there
is no password).
Note
Step 5
102
To stop periodic system messages from being displayed, enter set logging session
disable from the enable prompt.
In the Cisco Catalyst 6000, enter show port [module-number] to list the MAC
address for each individual port. Each pod will use three ports as identified in the
following table.
Port Assignments
Cluster
6608 T1 Voice Module Ports
East 1
3/13/3
East 2
3/43/6
East 3
3/7, 3/8, and 4/1
East 4
4/24/4
West 1
4/54/7
West 2
4/8, 5/1, and 5/2
West 3
5/35/5
West 4
5/65/8
Step 6
In the space here, write down the MAC addresses of the available T1 ports that your
group is assigned. You cannot use the port that you configured as a PRI.
Port number:
MAC address:
Port number:
MAC address:
Step 7
Go back to the Cisco CallManager Administration Conference Bridge Configuration

window, and enter one of the MAC addresses from Step 6.
Step 8
For the description, enter the IP address of the Cisco Catalyst switch, followed by
the module and port number, as shown here:
--
Step 9
Step 10
Click Insert.
Step 11
Reset the device from the Cisco CallManager Administration window.
Configure Transcoder
Step 12
In Cisco CallManager, choose Service > Media Resource > Transcoder to open
the Transcoder Configuration window. Click Add a New Transcoder.
Step 13
Choose Cisco Media Termination Point Hardware for the transcoder type. This
transcoder type supports the Cisco Catalyst 6500 Series WS-X6608-T1 or WSX6608-E1.
Step 14
Enter an available MAC address from Step 6. You cannot use a port that you
configured as a PRI or as a conference bridge.
Step 15
For the description, enter the IP address of the Cisco Catalyst switch, followed by
the module and port number as shown here:
<IP address> <mod/port>
Step 16
Lab Guide
103
Step 17
Click Insert.
Step 18
Reset the device from the Cisco CallManager Administration window.
Establish a Telnet session to the Cisco Catalyst 6000 switch, enter global configuration
mode, and enter the command show port mod/port (where mod/port is the port that you
assigned to the conference bridge) to view the settings of the conference resource. The type
should be Conf Bridge and the IP address of the Cisco CallManagers should be listed in
the CallManager(s) column. The CallManagerState column should show a state of
registered. Now the device is ready to be used.
In Cisco CallManager Administration, choose Service > Media Resource > Conference
Bridge, and click Find. You should see CFB<6608 MAC Address> listed as a
(hardware) conference bridge resource.
From the Cisco Catalyst 6000 switch, enter the command show port mod/port (where
mod/port is the port that you assigned to the transcoder) to view the settings of the
transcoder resource. The CallManagerState column should show a state of registered.
The type should be MTP, and the IP addresses of the Cisco CallManager servers should
be listed. Now the device is ready to be used.
Task 2: Configure Meet-Me Directory Numbers

In this task, you will configure a Meet-Me DN range to be able to use the Meet-Me Conference
feature.
Activity Procedure
Step 1
From Cisco CallManager Administration, choose Feature > Meet-Me

Number/Pattern. Click Add a New Meet-Me Number.
Note
You can also access the Meet-Me Number/Pattern Configuration window by selecting the
link at the top right of the Conference Bridge Configuration window.
Step 2
Enter x58X (where the lowercase x = your pod number and the upper-case X is the
actual character to enter), and place it in the Employee_PT partition to configure a
DN or pattern.
Step 3
Click Insert.
Initiate a Meet-Me conference using a DN within the range of the Meet-Me pattern that has
been configured.
104
Note
To initiate a Meet-Me conference, remove a telephone handset, press the More softkey,
press the MeetMe softkey, and enter a Meet-Me DN. When you initiate a Meet-Me
conference by pressing MeetMe on the telephone, Cisco CallManager considers you to be
the conference controller.
After the Meet-Me conference is established, from another telephone in your cluster, dial
the Meet-Me DN to join the Meet-Me conference. (Do not press the MeetMe softkey,
because this key can be used only by the conference controller to initiate the Meet-Me
conference.)
Task 3: Configure Media Resource Groups and Media Resource

Group Lists
In this task, you will configure MRGs and MRGLs and apply the MRGLs to devices to allow
them access to media resources.
Activity Procedure
Add and Configure MRGs
Step 1
In Cisco CallManager Administration, choose Service > Media Resource > Media
Resource Group to open the Media Resource Group Configuration window. Click
Add a New Media Resource Group.
Step 2
Enter the name Software_MRG. For the description, enter Software type media
resources. Choose all software (MTP and CFB<server name>) from the available
media resources (excluding MOH and the annunciator, and hardware conference
bridges [those named CFB<6608 MAC Address>]). Move the resources into the
Selected Media Resources pane. Click Insert.
Step 3
Click Add a New Media Resource Group. Add the following MRGs and select the
appropriate resources by using the procedure in Step 2.
MRGs
MRG Name
Resources
Hardware_MRG
All hardware resources only
MOH_MRG
MOH resources only
CFB_MRG
All conference bridges (hardware and software)
XCODE_MRG
All XCODERS (these all have MTP or XCODE in parenthesis)
Note
An annunciator is considered a media device. It can also be included in MRGs if you want to
control which annunciator resource is selected for use by telephones and gateways.
Lab Guide
105
Add and Configure MRGLs

Step 4
In Cisco CallManager Administration, choose Service > Media Resource > Media
Resource Group List to open the Media Resource Group List Configuration
window. Click Add a New Media Resource Group List.
Step 5
Enter the name All_MRGL. Add all MRGs to the Selected Media Resources Group
pane (Hardware_MRG, Software_MRG, CFB_MRG, MOH_MRG, and
XCODE_MRG). Prioritize the groups in the order provided here. Click Insert.
Note
Step 6
The approach that is provided here represents only one of many ways to organize MRGs
and MRGLs.
Add the following MRGLs by clicking Add New Media Resource Group List in
the upper-right corner of the window and assigning the appropriate MRGs.
Remember that the software and hardware MRGs both contain conference bridge
resources.
MRGLs
MRGL Name
MRGs
NOCFB_MRGL
All MRGs that do not contain conference bridges.

Hint: The Hardware_MRG and Software_MRG contain
conference bridges.
MOH_MRGL
MOH_MRG
Apply the MRGL to Devices

Step 7
In Cisco CallManager Administration, choose System > Device Pool to open the
Find and List Device Pools window.
Step 8
Step 9
Choose All_MRGL from the drop-down menu for the MRGL.
Step 10
Click Update, OK, and then Reset Devices.
Step 11
In Cisco CallManager Administration, choose Device > Phone, and then click Find
to list all configured telephones. Select one Cisco IP Phone to open the Phone
Step 12
From the Media Resource Group List drop-down menu, choose NOCFB_MRGL.
Click Update and then reset the telephone.
From the telephone that has been assigned to NOCFB_MRGL, try to establish a conference
call (either ad hoc or Meet-Me). The telephone should display No Conference Bridge.
From the telephone that has been assigned to All_MRGL, establish either an ad hoc or a
Meet-Me conference with the other telephones in your cluster.
106
Cleanup
To prepare for future labs, complete these steps:
Select the telephone that you assigned to NOCFB_MRGL and assign it to All_MRGL.
Select the third unassigned telephone and assign it to All_MRGL.
Reset all telephones.
Task 4: Configure Audio Sources for MOH

In this task, you will copy sample music files from the publisher desktop into the Cisco
CallManager MOH drop folder for conversion. Then you will select one or more of these files
to be used by a device for the MOH audio source.
Activity Procedure
Step 1
Use Remote Desktop Connection to connect to the publisher. Launch Cisco

CallManager Administration and choose Service > Media Resource > Music On
Hold Audio Source to open the Music On Hold Audio Source Configuration
window.
Step 2
Choose SampleAudioSource from the left column, and view the settings for this
audio source.
Step 3
Most standard .wav and .mp3 files serve as valid input audio source files. Your
instructor has provided some sample audio files in the Apps_Tools > Audio Files
folder that is located on the publisher desktop. Copy two or more of the .wav files,
navigate to C:\Program Files\Cisco\MOH\DropMOHAudioSourceFilesHere on the
publisher, and paste the files.
Note
Registered Cisco.com users with software download privileges can access the full set of
music and prompts for Cisco CallManager MOH at the Voice Software index page under
Cisco CallManager 3.3 at http://www.cisco.com/kobayashi/sw-center/sw-voice.shtml.
Step 4
After the files have been translated (they disappear from the folder), go back to the
Cisco CallManager Administration Music On Hold (MOH) Audio Source
Configuration window, and click <Add New MOH Audio Source> in the left
column.
Step 5
Choose a number in the MOH Audio Stream Number menu.
Step 6
Choose an audio file from the MOH Source File drop-down list.
Step 7
Check the Play Continuously check box. Click Insert.
Step 8
Repeat Steps 4 through 7 to add more audio files.
Step 9
At the bottom of the window, click Reset MOH Servers.
Lab Guide
107
Assign MOH to Device Pools

Next, you will assign an audio source for network and user hold to the device pool.
Step 10
Open the Find and List Device Pools window. (Choose System > Device Pool.)
Step 11
Choose the BA_Default_CMLocal_DP device pool.
Step 12
Choose an audio source from the drop-down menu for the network hold audio
source.
Step 13
Choose a different audio source from the menu for the user hold audio source.
Step 14
Click Update, and click Reset Devices.
Place a call to another telephone in your cluster. Place the call on hold (user hold). Verify
that the correct audio source was streamed.
Place a call to another telephone in your cluster. Press the Transfer button (network hold).
Verify that the correct audio source was streamed.
Cleanup
Choose Logoff Administrator from Remote Desktop Connection.
108
Lab 4-2: Adding Users and Customizing User

Options
Activity Objective
Use Cisco CallManager Administration to add users and associate users with a device
Configure user options by using the Cisco CallManager User Options web pages
Configure Personal Address Book entries
Visual Objective
Visual Objective for Lab 4-2: Adding Users

and Customizing User Options
Publisher
https://<server_IP>/ccmuser/logon.asp
Forward
x002 Calls
x001
Ray Perry
rperry
CIPT1 v4.117
In this task, you will add a user, Ray Perry, and associate the new user with x002 (where x =
your pod number). Then you will log in to the Cisco CallManager User Options web pages with
username rperry, configure call forwarding and speed dials, and create a Personal Address
Book and Fast Dial entries.
Required Resources
Lab Guide
109
Command List
Job Aids
Task 1: Add Users in Cisco CallManager

In a previous task, you added two users in Cisco CallManager. In this task, you will add a third
user and associate the three users with devices.
Activity Procedure
Step 1
In Cisco CallManager Administration, choose User > Add a New User to open the
User Information window.
Step 2
Use the User Configuration Data table to add the user.
User Configuration Data

Name of User
User ID
User Password
PIN
Ray Perry
rperry
cisco
12345
Step 3
Enter x002 in the Telephone Number field (where x = your pod number).
Step 4
Click Insert.
Step 5
Choose Device Association from the left column. Click Select Devices from the
Available Device List Filters section. Click OK.
Step 6
Check the check box that corresponds to the extension that you entered in Step 3.
The Primary Extension radio button is automatically selected. Click Update and
OK.
In Cisco CallManager Administration, choose User > Global Directory and click Search.
The user that was added is listed.
Task 2: Configure User Options from the User Options

Configuration Web Page
In this task, you will log in to the Cisco CallManager User Options web page and configure
options for the device that the user is associated with.
110
Activity Procedure
Step 1
Open the Cisco CallManager User Options login page by browsing to the following:
https://<server_ip_address_or_server_name>/ccmuser/logon.asp
Step 2
Enter the user ID and password of the user that you created in Task 1.
Step 3
Click Log On.
Step 4
Change the settings on the Cisco CallManager User Options page for the device that
the user is associated with (for example, adding speed dials and forwarding all calls).
Step 5
To add a speed dial, click Add/Update Your Speed Dials.
Step 6
Create a speed dial to an extension in your pod by entering x001 in the Speed Dial 1
field (where x = your pod number). Add any name that you like in the Display Text
field.
Step 7
Click Update.
Step 8
From the User Options page, click the Back button.
Step 9
Click Forward All Calls to a Different Number to go back to the User Options
main menu.
Step 10
To forward all incoming calls on x002 to extension x001, enter x001 in this Number
field.
Step 11
Click Update.
Task 3: Create a Personal Address Book and Assign Fast Dial

Entries
In this task, you will enable the Personal Address Book and Fast Dial services for users, and
you will create a personal address book and assign a Fast Dial code to reach entries in your
personal address book. You will also subscribe to and use the Personal Address Book and Fast
Dial services from your IP Phone.
Activity Procedure
Enable the Personal Address Book Service
Step 1
Browse to Cisco CallManager Administration, and then choose Feature > Cisco IP
Phone Services to open the Find and List IP Phone Services window.
Step 2
Click Add a New IP Phone Service to open the Cisco IP Phone Services
Step 3
Enter Personal Address Book in the Service Name field.
Step 4
Enter Personal Address Book in the Service Description field.
Lab Guide
111
Step 5
In the Service URL field, enter:

http://<CallManager IP address>/ccmpd/xmlAddressBookInput.asp
(where <CallManager IP address> is the IP address of the publisher).
Note
The entire URL is case-sensitive.
Caution
You should not to put Cisco IP Phone Services on any Cisco CallManager server at your
site or on any server that is associated with Cisco CallManager, such as the TFTP server or
directory database publisher server. This precaution eliminates the possibility that errors in a
Cisco IP Phone Services application will have an impact on Cisco CallManager performance
or interrupt call-processing services. For the lab activity only, you will put Cisco IP Phone
Services on the publisher server.
Step 6
Click Insert.
Step 7
Click the New button to the right of the Parameters pane.

The Configure Cisco IP Phone Service Parameter window appears.
Step 8
Add each parameter as described in the following table, beginning with User ID.
When specified, enter the parameter name exactly as it appears in the table.
Field
Definition
Definition
Parameter Name
UserID
UserPIN
(Use this exact name.)
(Use this exact name.)
Parameter Display Name
User Identification
PIN
Default Value
None, leave blank
None, leave blank
Parameter Is Required
Yes
Yes
Parameter Is a Password
No
Yes
Parameter Description
Same user identification used

with the Cisco IP Phone User
Options window
Same user PIN used with the

Cisco IP Phone User Options
window
Step 9
Click Insert to add the parameter.
Step 10
When you have added the last service parameter specified in the table in Step 11,
click Insert and Close to insert that parameter and close the window.
The Cisco IP Phone Services Configuration window appears.
Step 11
112
Click Update Subscriptions.
Note
Step 12
The following step is necessary because you are not using the Domain Name System (DNS)
in the lab activity; however, it is a Cisco CallManager best practice to change all of the
publisher hostnames to an IP address in all of the URLs on the Enterprise Parameters
window. Using IP addresses means that your IP telephony endpoints contact the Cisco
CallManager servers directly using their IP addresses instead of resolving their names
through DNS.
From Cisco CallManager Administration, choose System > Enterprise

Parameters. At the URL Services parameter (under the Phone URL Parameters
section), change the server name to the IP address of the publisher server, if this has
not already been done. Click Update.
Enable the Fast Dial Service

Step 13
Choose Feature > Cisco IP Phone Services.
Step 14
Choose Add a New IP Phone Service. The Cisco IP Phone Services Configuration
window displays.
Step 15
In the Service Name field, enter the name of the service that you want to display in
the menu of available services on the Cisco IP Phone User Options window, for
example, My Fast Dials.
Step 16
In the Service Description field, enter a description of the content provided by the
service, for example, Personal Directory-Personal Fast Dials.
Step 17
In the Service URL field, enter the URL of the server where the application for the
Personal Address Book service is located:
http://<CallManager hostname or IP address>/ccmpd/xmlFastDials.asp
(where <CallManager hostname or IP address> is the hostname or IP address of the
publisher)
Step 18
Click Insert.
Step 19
Click the New button to the right of the Parameters pane. The Configure Cisco IP
Phone Service Parameter window appears.
Step 20
Refer to the table in Step 8 and complete the configuration in the Cisco IP Phone
Service Parameter window.
Create Personal Address Book Entries and Fast Dial Codes

Step 21
From the User Options main menu, choose Configure Your Personal Address
Book. This action opens the Find/List Address Book Entries window.
Step 22
Choose Add a New Entry to open the Address Book Entry window.
Step 23
Create three address book entries, two that are associated with telephones in your
cluster and one that is associated with a telephone in a remote cluster. Suggested
values are included in the following table, or you can make up your own. Click
Insert after creating each entry.
Lab Guide
113
Parameters
Personal Address Book

Entry 1

Entry 2

Entry 3
First Name*
Linda
Grace
Wes
Last Name*
Collins
Bailey
Johnson
Work Phone
x001, (where x = your

pod number)
x000 where x = your pod

number)
y001 (where y = your

partner pod number)
Mobile Phone
555-0100
555-0101
555-0102
Step 24
When finished creating your Personal Address Book, click the Fast Dials link at the
bottom of the Address Book Entry window.
Step 25
Choose Index 1 and assign it to PAB Entry 1 (Linda Collins). Choose the work
phone number x001 (where x = your pod number) from the drop-down menu.
Choose a DN for the selected address book entry. Choose Insert.
Step 26
Return to the Find and List Personal Fast Dials window. Repeat Step 25 to assign
Index 2 and Index 3.
Subscribe to Address Book and Fast Dial Services

Step 27
Choose Return to the Menu at the bottom left of the Find and List Personal Fast
Dials window.
Step 28
Choose Configure Your Cisco IP Phone Services.
Step 29
Choose Personal Address Book from the Available Services (for a new
subscription) drop-down menu. Choose Continue.
Step 30
Enter the user ID and PIN from Task 1 (12345). Choose Subscribe.
Step 31
Choose Return to the Menu from the bottom of the window and repeat Steps 28
through 30 to subscribe to the My Fast Dial service.
Step 32
Choose Log Off from the bottom of the window
When you press the speed dial key on x002, the IP Phone dials x001.
The IP Phone display on x002 should show Forwarded to x001. When you call x002
from x000, the call should forward to x001.
You can make a Fast Dial call on your IP Phone. Choose Services > My Fast Dials. Enter
the Fast Dial index code using your keypad.
You can dial an entry using your Personal Address Book. Choose Services > My Address
Book (the service name may vary). Enter a partial or complete name using your keypad and
press the Submit softkey. Select a search result and press the Dial softkey.
Cleanup
Cancel call forwarding on IP Phone x002 by pressing the softkey CFwdALL. You can also
cancel call forwarding from the User Options web page.
114

Activity Objective
In this activity, you will configure and use the Call Park, Call Pickup, Cisco Call Back, Barge,
and Privacy features. After completing this activity, you will be able to meet these objectives:
Configure and use the Call Park feature
Configure and use the Call Pickup feature
Configure and use Cisco Call Back
Configure and use the Barge feature with a built-in conference bridge
Configure and use the Privacy feature
Configure Cisco IP Phone Services
Visual Objective

User Features Part 1
Call Park Number x66X

Call Park Number x67X
x099
x000
Support Call
Pickup Group
x685
x001
Publisher
Barge and Privacy
x099
x002
Sales Call Pickup Group x686
CIPT1 v4.118
In this activity, you will create Call Park numbers and Call Pickup numbers, configure Cisco
Call Back, create a shared line between two IP Phones and enable Barge and Privacy, and
enable IP Phones to access sample IP Phone Services.
Lab Guide
115
Required Resources
Remote Cisco IP telephony server cluster
Cisco router (default gateway)
Command List
Job Aids
Task 1: Configure Call Park

In this task, you will configure a Call Park number and then use the Call Park feature within
your cluster.
Activity Procedure
Step 1
In Cisco CallManager Administration, choose Feature > Call Park to open the Find
and List Call Park Numbers window.
Step 2
Click Add a New Call Park Number to open the Call Park Configuration window.
Step 3
Enter x66X in the Call Park Number/Range field (where the lowercase x = your pod
number). Assign it to the Employee_PT partition and choose a Cisco CallManager to
which to assign it. Click Insert.
Step 4
Click Add a New Call Park Number. Enter x67X for the Call Park Number/Range
field (where the lowercase x = your pod number). Assign it to the Employee_PT
partition, and choose the subscriber Cisco CallManager to which to assign it. Click
Insert.
Establish a call between two telephones, and park the call. (Press the More softkey, and
then press the Park softkey.) Take note of the Call Park number, go off hook on the third
telephone, and pick up the call by dialing the Call Park number.
116
Task 2: Configure Call Pickup

In this task, you will configure a Call Pickup group, assign the Call Pickup group to the
telephones in your cluster, and then use the Call Pickup feature within your cluster.
Activity Procedure
Step 1
In Cisco CallManager Administration, choose Feature > Call Pickup to open the
Find and List Call Pickup Numbers window.
Step 2
Click Add a New Call Pickup Number to open the Call Pickup Configuration
window.
Step 3
Enter Support in the Pickup Group Name field and x685 in the Pickup Group
Number field (where x = your pod number), assign it to the Employee_PT partition,
and click Insert.
Step 4
Click Add New Pickup Group to create another Call Pickup group. Enter Sales in
the Pickup Group Name field and x686 in the Call Pickup Number field, and assign
it to the Employee_PT partition. Click Insert.
Assign Call Pickup to a DN

Step 5
Step 6
Select the first telephone in the list to open the Phone Configuration window.
Step 7
Click Line 1 and scroll down to Call Forward and Pickup Settings.
Step 8
Choose Call Pickup group Support (x685) from the Call Pickup Group menu.
Step 9
Click Update and click Reset Devices.
Step 10
Repeat Steps 5 through 9 for the other two telephones in your cluster, but this time
choose Call Pickup group Sales (x686).
From the telephone that was assigned to Call Pickup group Support (x685), call one of the
other telephones in your cluster. Do not answer the telephone. From the idle telephone
(which should be in the Sales [x686] Call Pickup group), go off hook, press the More
softkey, and then press the PickUp softkey. The call should be rerouted.
From one of the two telephones that have been assigned to Call Pickup group x686, call the
telephone that was assigned to x685. Do not answer the telephone. From the idle telephone
(which should be in the x686 Call Pickup group), go off hook, press the More softkey,
press the GPickup softkey, and then enter x685. The call should be rerouted.
Note
If the telephone that you use to try to pick up a call is not in any Call Pickup group, the user
will receive an error message on the telephone and the call will not be rerouted.
Lab Guide
117
Task 3: Configure Cisco Call Back

In this task, you will configure a Cisco Call Back softkey template and assign it to a device
pool within your cluster. The Cisco Call Back feature allows you to receive call-back
notification on your Cisco IP Phone when a called-party line becomes available.
Activity Procedure
Complete these steps.
Step 1
In Cisco CallManager Administration, choose Device > Device Settings > Softkey
Template to open the Find and List Softkey Templates window. Click Find.
Step 2
Click the Copy icon next to Standard User Template to create a copy of this
template.
Step 3
Rename the template Standard CallBack User and change the Description field to
CallBack Softkey Template. Click Insert and then click OK.
Step 4
Click Configure Softkey Layout in the upper right of the window. On Hook
should be highlighted in the left column. Select Call Back (20)(CallBack) in the
Unselected Softkeys pane and use the arrows to move it to the Selected Softkeys
pane. Move Call Back (20)(CallBack) to the top of the list. Click Update and click
OK.
Note
Step 5
Note
Choose Ring Out from the Call States list on the left side of the window. Select
Call Back (20)(CallBack) in the Unselected Softkeys pane and click the arrow to
move it to the Selected Softkeys pane. Move it to the top of the list. Click Update
click OK.
The CallBack softkey in the Ring Out state is used during a call-back request when a call is
in the ringing or busy state or when the call has been forwarded to voice mail.
Step 6
From Cisco CallManager Administration, choose System > Device Pool and, if
necessary, click the Find button to bring up the list of device pools.
Step 7
Choose BA_Default_CMLocal_DP from the device pools.
Step 8
In the Softkey Template field, choose Standard CallBack User, click Update, OK,
and then Reset Devices, OK, and OK for this change to take effect on the
telephones.
Note
118
The CallBack softkey in the On Hook call state enables you to check the status of a callback request that was previously initiated or to cancel a call-back request that is no longer
desired.
If you want to enable Cisco Call Back on select telephones within a device pool, you must
assign the softkey template from the Phone Configuration window.
Take one of your IP Phones off hook. From the other IP Phone, call the busy telephone and
then press the CallBack softkey. Hang up the busy telephone. Cisco CallManager should
notify you that the line is available and offer you the option of dialing the number.
Call a DN in your cluster. While it is ringing, press the CallBack softkey. On the telephone
that you called, go off hook, then on hook again. Cisco CallManager should notify you that
the line is available and offer you the option to dial the number.
Task 4: Configure Barge with Built-In Conference Bridge

In this task, you will configure and use the Barge feature. Barge allows a user to be added to a
connected call that is made to or from another device on a shared line. To use Barge, you must
first configure a shared line appearance and enable the built-in Barge cluster-wide parameter.
Activity Procedure
Create a Shared Line
Step 1
From Cisco CallManager Administration, choose Device > Phone. Choose DN
x002.
Step 2
Click Line 2.
Step 3
For the DN for line 2, enter x099 (where x = your pod number), and then click Add
and click OK.
Step 4
Click Back to Find/List Phones to choose the telephone with the second-highest
DN (x001) and repeat Steps 2 and 3. Notice the red Shared Line indicator to the
right of the DN.
Step 5
Lift the handset of one of the IP Phones that you have just configured and press the
Line 2 telephone button. Notice that on the IP Phone that shares this line the
telephone receiver icon also goes off hook. Hang up the telephone.
Configure Barge
Step 6
Click Service > Service Parameters.
Step 7
Choose the IP address of one of your servers and choose Cisco CallManager for the
service.
Step 8
Scroll down and locate the Built-In Bridge* Enable parameter (under Clusterwide
Parameters [Device - Phone]). Change the setting to On. Read the message and click
OK.
Step 9
Scroll down and locate the Party Entrance Tone parameter (under Clusterwide
Parameters [Feature - General]). This parameter will enable or disable a tone on the
telephone of the Barge target when another user is using Barge to join the call.
Leave the setting as True.
Step 10
Scroll to the top of the window and click Update.
Lab Guide
119
Note
Both the Standard User and Standard Feature softkey templates contain the Barge softkey.
Because the Standard CallBack User softkey template that you are using is based on the
Standard User template, it also contains the Barge softkey.
From your third IP Phone (the one without the shared line appearance), dial x099. Answer
the call on one of the ringing telephones. On the other telephone with the shared line
appearance, go off hook and press line appearance 2.
Watch for the Barge softkey to appear and press the softkey to join the conversation. Listen
for the party entrance tone when the caller using Barge joins the call.
If you are the Barge target, hang up the call. The caller using Barge and the original caller
will still be connected.
When the procedure is completed, hang up both telephones.
Task 5: Configure Privacy

In this task, you will assign a Privacy button to a line so that you can invoke Privacy to prevent
other users of a shared line from viewing call information or using Barge to join the call.
Activity Procedure
Step 1
Choose Service > Service Parameters. In the Server field, choose a server in your
cluster. In the Service field, choose the Cisco CallManager service. The Service
Parameters Configuration window opens.
Step 2
Ensure that the Privacy Setting* is True (under Clusterwide Parameters [Device Phone]).
Create a New Phone Button Template

Step 3
Choose Device > Device Settings > Phone Button Template to open the Phone
Button Template window. Click Find to list all telephone button templates.
Step 4
To create a copy of the Standard 7960 phone button template, click the Copy icon
next to the Standard 7960 phone button template. Rename the template Privacy 4-1
7960.
Step 5
Change the line and speed dial settings as follows:

Button 3: Line
Button 4: Line
Button 5: Privacy
Button 6: Speed Dial
120
Step 6
Click Insert.
Step 7
Choose Device > Phone. Select one of the telephones with the shared line.
Step 8
Choose Privacy 4-1 7960 for the phone button template. Read the message about
speed dials and click OK.
Note
If you want to selectively enable Privacy on a device-by-device basis, you must choose On
from the Privacy drop-down menu. You have enabled Privacy on a cluster-wide basis, so
this setting should remain Default (meaning that the device will default to the system
parameter).
Step 9
Click Update and reset the telephone.
Step 10
Click Back to Find/List Phones.
Step 11
Select the other telephone with the shared line and repeat Steps 8 and 9.
From your third IP Phone (the one without the shared line appearance), dial x099. Answer
the call on one of the ringing telephones. On the other telephone with the shared line
appearance, go off hook and attempt to join the call using Barge. You should not be
successful. With Privacy enabled (a black circle in the middle of the Privacy icon), neither
the Barge softkey nor the calling name and number are displayed on the telephone of the
partner after the call is answered.
While the call is still active, toggle the Privacy softkey on the telephone with an active call.
This action disables Privacy on the line. Notice that the other telephone with the shared line
now shows an off-hook icon. You should now be able to join the call from that other
telephone using Barge.
Task 6: Configure Cisco IP Phone Services

In this task, you will use a sample services file to add Cisco IP Phone Services to the Cisco
Activity Procedure
Step 1
Use Remote Desktop Connection to connect to your publisher.
Step 2
On the desktop in the Apps_Tools > Sample IP Phone Services folder, you will find
a folder named Sample. Copy this folder to
C:\CiscoWebs\CiscoIPPhoneServices\CCMCIP.
Step 3
From Cisco CallManager Administration, choose Feature > Cisco IP Phone

Services to open the Find and List IP Phone Services window.
Step 4
Click Add a New IP Phone Service to open the Cisco IP Phone Services
Step 5
Enter Sample Service in the Service Name field.
Step 6
Enter Sample Service in the Service Description field.
Lab Guide
121
Step 7
In the Service URL field, enter

http://<Publisher_IP_Address>/CCMCIP/Sample/sample.asp.
Note
The URL is not case-sensitive.
Caution
You should not to put Cisco IP Phone Services on any Cisco CallManager server at your
site or on any server that is associated with Cisco CallManager, such as the TFTP server or
directory database publisher server. This precaution eliminates the possibility that errors in a
Cisco IP Phone Services application will have an impact on Cisco CallManager performance
or interrupt call-processing services. For the lab activity only, you will put Cisco IP Phone
Services on the publisher server.
Step 8
Click Insert.
Subscribe to Cisco IP Phone Services

Step 9
From Cisco CallManager Administration, choose Device > Phone. Select a
telephone to display the Phone Configuration window. (Click Find if no telephones
appear and then select a telephone.)
Step 10
Click Subscribe/Unsubscribe Services at the top right of the window.
Step 11
Choose Sample Service from the Select a Service drop-down menu, and click
Continue.
Step 12
The service name is the name that will be displayed on your telephone. Change the
service name to <Cluster Code> Sample. Click Subscribe and close the dialog
box.
Step 13
Reset the telephone.
On the IP Phone on which you configured the sample services, press the Services button.
Press the Select softkey and choose the <Cluster Code> Sample service.
A menu of services is displayed, and you are able to access the services.
122
Lab 4-4: Configuring Cisco CallManager

Extension Mobility
Activity Objective
In this activity, you will configure and use the Cisco CallManager Extension Mobility feature.
Add the Cisco CallManager Extension Mobility service
Set the Cisco CallManager Extension Mobility service parameters
Create the device profile default for the Cisco IP Phone 7960
Create the device profile for a user
Associate a user device profile with a user
Subscribe Cisco IP Phones to Cisco CallManager Extension Mobility
Visual Objective

1
Device Profile Default: Cisco 7960
User Device Profile: rperry_EM, x555
x002

feature is enabled on x002.
Publisher
User presses Services button and

selects Extension Mobility service
User logs in to phone as rperry
User device profile appears and phone

display changes to x555
CIPT1 v4.119
In this task, you create the device profiles for the Cisco CallManager Extension Mobility
service in Cisco CallManager and associate the user device profile with the username rperry.
Then, you will log in as user rperry to an IP Phone that has subscribed to the Cisco
CallManager Extension Mobility service, and the IP Phone will assume the user device profile.
Lab Guide
123
Required Resources
There are no resources required to complete this activity.
Command List
Job Aids
Task 1: Add the Cisco CallManager Extension Mobility Service

In this task, you will configure the Cisco CallManager Extension Mobility service.
Activity Procedure
Step 1
From Cisco CallManager Administration, choose Feature > Cisco IP Phone

Services. In the upper-right corner of the Find and List IP Phone Services window,
click the Add a New IP Phone Service link.
Step 2
The Cisco IP Phone Service Configuration window opens. In the Service Name
field, enter Extension Mobility for the name of the service. This name is displayed
on the IP Phone when the user presses the Services button.
Step 3
In the Service Description field, enter Extension Mobility.
Step 4
In the Service URL field, enter the IP address of the Cisco CallManager publisher
server:
http://<IPAddrOFCM>/emapp/EMAppServlet?device=#DEVICENAME#
Note
IPAddrOFCM is the IP address of the Cisco CallManager where Cisco CallManager

Extension Mobility is running. For the purposes of this lab only, use the publisher IP
address. This URL is case-sensitive, so make sure that you enter it exactly as described.
Step 5
From the Character Set menu, choose the language of the information that the user
will see displayed on the IP Phone.
Step 6
Click Insert.
Step 7
The Cisco IP Phone Service Configuration window appears. Click Update.
You can verify that the Cisco CallManager Extension Mobility service is listed in the IP
Phone Services configuration window when you click Feature > IP Phone Services and
then click Find.
124
Task 2: Set the Cisco CallManager Extension Mobility Service

Parameters
In this task, you will set the service parameters in the CallManager Service Parameters
Configuration window to accomplish these objectives:
Define a system-wide maximum login time
Define the multilogin behaviorthat is, whether you allow the user to log in to more than
one device at a time
Activity Procedure
Step 1
From Cisco CallManager Administration, choose Service > Service Parameters.

The Service Parameters Configuration window appears.
Step 2
From the Server drop-down menu, choose the publisher server address of your Cisco
CallManager.
Step 3
From the Services drop-down menu, choose Cisco Extension Mobility. A new
Service Parameters Configuration window displays.
Step 4
At the Enforce Maximum Login Time, choose True to specify a system-wide

maximum time for logins. After the specified time, the system automatically logs
out the device. (Choosing False means that no system-wide maximum time for
logins exists.)
Step 5
Specify a maximum login time of 1 minute. (Enter 1 minute as 0:01.)
Note
In a production deployment, you would normally set a maximum login time that corresponds
to a normal workday, such as 9 or 10 hours.
Step 6
In the Multi Login Behavior field, choose Auto Logout. The automatic logout
behavior specifies that after a user logs in to a second device, Cisco CallManager
automatically logs the user out of the first device.
Step 7
Click Update.
You can view the Cisco Extension Mobility Service Parameters window.
Task 3: Create the Device Profile Default for the Cisco IP Phone
7960
In this task, you will add a device profile for the Cisco IP Phone 7960.
Lab Guide
125
Activity Procedure
Step 1
From Cisco CallManager Administration, go to Device > Device Settings > Device
Profile Default. The Device Profile Default Configuration window appears.
Step 2
Click the Add a New Device Profile Default link on the left. From the Device Type
drop-down list, choose Cisco 7960 as the device, for which the profile is created.
Step 3
Leave the User Hold Audio Source field as None. If you do not choose an audio
source, Cisco CallManager uses the audio source that is defined in the device pool
or, if the device pool does not specify an audio source ID, the system default.
Step 4
From the User Locale drop-down list, choose the locale that is associated with the IP
Phone user interface. Unless additional locales are installed, only the default locale
English is available.
Step 5
From the Phone Button Template drop-down list, choose Standard 7960.
Step 6
From the Softkey Template drop-down list, choose Standard Feature.
Step 7
Click Insert.
Step 8
The window refreshes with Cisco 7960 in the Device Profile Defaults column.
Click the Subscribe/Unsubscribe Services link in the upper-right corner to add the
Cisco CallManager Extension Mobility service to this profile. The Subscribe
Cisco IP Phone services window appears.
Step 9
From the Select a Service drop-down list, choose Extension Mobility.
Step 10
Click Continue. The window displays the service that you chose.
Step 11
Click Subscribe and OK. Close the subscribe services popup window.
Task 4: Create the Device Profile for a User

The user device profile contains attributes such as name, description, phone template, add-on
modules, DNs, subscribed services, and speed-dial information. In this task, you will add a
default device profile for a new user of Cisco CallManager Extension Mobility.
Activity Procedure
126
Step 1
From Cisco CallManager Administration, choose Device > Device Settings >
Device Profile. The Find and List Device Profiles window appears.
Step 2
Click the Add a New User Device Profile link in the upper-right corner. The User
Device Profile Configuration window appears.
Step 3
Choose Cisco 7960 from the Device Type drop-down menu.
Step 4
In the User Device Profile Name field, enter rperry_EM. (You can use any word or
phrase that describes this particular user device profile.)
Step 5
In the Phone Button Template field, choose Standard 7960.
Note
You can view a phone button list at any time by choosing the View Button List link next to
the phone button template fields. A window pops up and displays the phone buttons for that
particular expansion module.
Step 6
In the Login User ID field, enter the user ID rperry.
Step 7
Click Insert.
Step 8
The message appears that states The Device Profile has been inserted in the
database. Please add a directory number for line 1 of this user device now. Click
OK.
Step 9
The Directory Number Configuration window opens. In the Directory Number field,
enter an unassigned number within the range of the pod you are working on, for
example, x555 (where x = your pod number).
Step 10
Click Add, OK, and Update. The User Device Profile Configuration window for
this device profile appears.
Step 11
Click OK.
The Directory Number Configuration window shows an association between the profile
and the number.
Task 5: Associate a User Device Profile with a User

In this task, you will associate a user device profile with the user for Cisco CallManager
Extension Mobility.
Activity Procedure
Step 1
From Cisco CallManager Administration, choose User > Global Directory.
Step 2
Enter rperry in the Search field. Click Search.
Step 3
Choose Perry to open the User Configuration window.
Step 4
Under Application Profiles of Ray, choose Extension Mobility.
Step 5
Click Select Profiles and OK.
Step 6
Check the 7960 check box and choose rperry_EM as the device name. Click
Update Selected.
The 7960 device profile is assigned to the user.
Lab Guide
127
Task 6: Subscribe Cisco IP Phones to Cisco CallManager

Extension Mobility
In this task, you will subscribe to the Cisco CallManager Extension Mobility feature.
Activity Procedure
Step 1
In Cisco CallManager Administration, choose Device > Phone and choose x002
(where x = your pod number) as the IP Phone that you want to configure.
Step 2
The Phone Configuration window opens. In the upper-right corner, click

Subscribe/Unsubscribe Services.
Step 3
The Subscribe Service window opens. Choose Extension Mobility from the Select a
Service drop-down menu.
Step 4
Click Continue. Click Subscribe. Then close the window.
Step 5
Scroll down to the bottom of the Cisco CallManager Phone Configuration window.
Check the Enable Extension Mobility Feature check box.
Step 6
In the Log Out Profile field, choose Use Current Device Settings.
Step 7
Click Update and reset the IP Phone.
On the Cisco IP Phone where Cisco CallManager Extension Mobility is enabled, press the
Services button. Highlight Extension Mobility and press Select.
Log in, and the user profile appears (for example, extension x555, where x = your pod
number). Recall that the PIN is 12345.
After 1 minute, the IP Phone logs out and resumes the original profile and DN (x002).
128

Activity Objective
In this activity, you will configure and use CMC and Call Display Restrictions. After
Add CMCs in Cisco CallManager Administration and assign them to route patterns so
users are required to enter a CMC to reach certain dialed numbers.
Configure display restrictions with requirements typical of the hospitality industry. You
will configure DNs x001 and x002 as guest room telephones and x000 as the front-desk
telephone. The call information display is restricted when guest rooms call one another.
The call information is presented to both the guest room and the lobby telephone when
either calls the other.
Visual Objective

User Features Part 2
Display call
information
x000
x001
Front Desk
Room 1
Client Matter Codes
Do not
display call
information
y000
y001
x002
Room 2
x000
To Another
Pod
ICT
Must enter
valid code to
complete call
CIPT1 v4.120
In this activity, you will enable Call Display Restrictions to display or restrict call information
based on the device that is called. Then, you will enable CMC and assign codes to route
patterns that are used to reach DNs in another pod. When you dial the number to reach the DN
in the other pod, you must enter a valid client matter code for the call to complete.
Required Resources
There are no resources required to complete this activity.
Lab Guide
129
Command List
Job Aids
Task 1: Configure Client Matter Codes

In this task, you will add CMC in Cisco CallManager Administration, assign client matter
codes to route patterns, and then use the codes to reach certain dialed numbers.
Note
Remember, you can also use BAT to add client matter codes in a bulk transaction.
Activity Procedure
Adding Client Matter Codes in Cisco CallManager Administration
Step 1
In Cisco CallManager Administration, choose Feature > Client Matter Code.
Step 2
In the upper-right corner of the window, click the Add a New Client Matter Code
link. The Client Matter Code Configuration window displays.
Step 3
Referring to the following table, add a code in the Client Matter Code field and add
its associated client name in the Description field. Click Insert when finished. (You
will use the client number later in the lab.)
Client Matter Codes

Code
Client Name
Client Number
5555
ABC Company
y000 (where y = your

partner pod number)
6666
XYZ Corporation
y001
Step 4
Repeat Steps 2 and 3 to add the remaining client matter codes.
Enabling Client Matter Codes for Route Patterns

Use the Client Number column from the table in Step 3 to add two new route patterns to reach
two DNs in your partner pod connected via intercluster trunk. For example, East 1 will add
route patterns 3000 and 3001 to reach East 3. East 3 will add 1000 and 1001 DNs to reach
East 1, and so on.
130
Step 5
Pattern.
Step 6
Choose Add a New Route Pattern.
Step 7
Insert in the Route Pattern field the client number from Step 3.
Step 8
Choose ICT_RL from the Gateway or Route List drop-down menu.
Step 9
Step 10
Check the Require Client Matter Code check box.
Step 11
Click Insert.
Step 12
Repeat Steps 6 through 11 to add the second route pattern and enable CMC for it.
Call the first DN in your partner pod connected via intercluster trunk, y000, and enter the
client matter code when prompted. Remember to enter # after the DN to bypass the
interdigit timeout and extend the call.
Call the second DN, y001.
Call the third DN, y002. The call should extend without requiring you to enter a client
matter code.
Call a valid DN in your partner pod and enter an invalid code (5432, for example). You
should receive a reorder tone.
Task 2: Enable Call Display Restrictions

In this task, you will configure display restrictions with requirements typical of the hospitality
industry. You will configure DNs x001 and x002 as guest room telephones and x000 as the
front desk telephone. The call information display is restricted when guest rooms call one
another. The call information is presented to both the guest room and the front-desk telephone
when either calls the other.
Note
This lab covers the display restrictions for internal dialing. In a production network, you
would probably want to configure display restrictions for calls to and from the PSTN. Refer to
the Call Display Restrictions section of Cisco CallManager Features and Services Guide,
Release 4.1(3) for details at:
http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_1/sys_ad/4_1_3/
ccmfeat/fshosp.htm.
Lab Guide
131
Activity Procedure
Create Partitions
Step 1
The real partitions will eventually be assigned to the guest room and front-desk
telephone lines. The translation partitions will be assigned to the translation
patterns. The procedure for adding them in Cisco CallManager Administration is
identical, so you can add all of them at the same time. Add the following partitions:
Insert the real partition P_Room.
Insert the real partition P_FrontDesk.
Insert the translation partition P_CallsFromRoomToRoom.
Insert the translation partition P_CallsFromRoomToFrontDesk.
Insert the translation partition P_CallsFromFrontDeskToRoom.
Create Calling Search Spaces

Step 2
Add the following calling search spaces in Cisco CallManager Administration and
assign the partition in parentheses to the calling search space.
Insert the calling search space CSS_Room (P_Room).
Insert the calling search space CSS_FrontDesk (P_FrontDesk).
Insert the calling search space CSS_FromRoom
(P_CallsFromRoomToFrontDesk and P_CallsFromRoomToRoom).
Insert the calling search space CSS_FromFrontDesk
(P_CallsFromFrontDeskToRoom).
Assign Partitions and Calling Search Spaces to Devices and Lines
Step 3
Configure x001 (Room 1) with the device calling search space CSS_FromRoom
and the partition P_Room. Unassign the Call Pickup group currently assigned to the
line.
Make certain to assign the partition at the line level in the Directory Number
Configuration window. Make certain to assign the calling search space at the device
level (not the line level) in the Phone Configuration window, as shown in the figure.
When you reset the IP Phones after assigning it to the new partition, watch the
telephone to ensure that it resets. If it does not, try resetting the IP Phones from the
Find and List Phones window.
132
Assign
partition
at the line
level
Assign
calling
search
space at
device
level
Step 4
Configure x002 (Room 2) with the device calling search space CSS_FromRoom
and the partition P_Room.
Step 5
Configure x000 (Front Desk) with the device calling search space
CSS_FromFrontDesk, the Ignore Presentation Indicators check box checked,
and the partition P_FrontDesk.
Lab Guide
133
Create Translation Patterns

Step 6
From the Cisco CallManager Administration Translation Pattern Configuration
window, configure the following translation patterns:
1. Insert a translation pattern xXXX (where the lowercase x = your pod number
and XXX is entered literally; do not substitute your pod numberfor example
East 1 would enter 1XXX) with the following parameters:
Partition: P_CallsFromRoomToFrontDesk
CSS: CSS_FrontDesk
Calling Line ID Presentation and Calling Name Presentation: Restricted
Connected Line ID Presentation and Connected Name Presentation: Allowed
Provide Outside Dial Tone: Unchecked
2. Insert a translation pattern xXXX with the following parameters:
Partition: P_CallsFromRoomToRoom
CSS: CSS_Room
Calling Line ID Presentation and Calling Name Presentation: Restricted
Connected Line ID Presentation and Connected Name Presentation: Restricted
3. Insert a translation pattern xXXX with the following parameters:
Partition: P_CallsFromFrontDeskToRoom
CSS: CSS_Room
Calling Line ID Presentation and Calling Name Presentation: Allowed
Connected Line ID Presentation and Connected Name Presentation: Restricted
Place a call from Room 1 to Room 2 (x001 to x002) and vice versa. The call
information display is restricted, and the IP Phone displays From Private
(Unknown Number).
Place a call from the front desk (x000) to Room 1 and then to Room 2 (x001 and
x002, respectively). The call information should be displayed to both parties
involved in the call. This is because the front desk IP Phone is set to allow the
Calling Line ID Presentation and Calling Name Presentation options and to
enable the Ignore Presentation Indicators (Internal Calls Only) option. As a
result, the Connected Line ID Presentation and Connected Name Presentation
option restrictions that were set for the room IP Phones are ignored.
Place a call from Room 1 (x001) to the front desk (x000). The call information
should be displayed to both parties involved in the call even though the Calling
Line ID Presentation and Calling Name Presentation options are restricted for
the room telephones, because the Ignore Presentation Indicators (Internal Calls
Only) option is enabled for the front desk IP Phone.
134
Cleanup
To prepare for the future labs, complete these steps:
Step 1
Delete all xXXX translation patterns.
Step 2
Assign all telephone lines (DNs) to the Employee_PT partition.
Step 3
Assign all telephones to the Unlimited Access_CSS calling search space.
Step 4
Reset all telephones.
Step 5
Ensure that you can call within and between pods.
Lab Guide
135
Lab 5-1: Configuring Cisco CallManager

Attendant Console
Activity Objective
In this activity, you will install and configure Cisco CallManager Attendant Console. After
Add a Cisco CallManager Attendant Console user
Configure pilot points
Configure a hunt group
Create the ac user account for attendant console interaction with Cisco CTIManager
Associate devices and pilot points with the ac user
Install and configure the Cisco CallManager Attendant Console client
Visual Objective

Publisher
x000
associated
with ac user
Attendant Console User: jjones

Pilot Point Number: xxxx
Hunt Group Members: jjones, x002
CIPT1 v4.121
In this activity, you will add an attendant console user, jjones, configure xxxx (where x = your
pod number) as the pilot point number to reach the hunt group, add jjones and extension 002 to
the hunt group, create the ac user account, and associate extension 000 and the pilot xxxx with
the ac user. Then you will install and configure the Cisco CallManager Attendant Console
client application on your PC, and log in to the application as user jjones. You will then make
and receive calls using the Cisco CallManager Attendant Console application.
136
Required Resources
Cisco CallManager cluster
PC or laptop
One or more IP Phones
Command List
Job Aids
Task 1: Add an Attendant Console User

In this task, you will add an attendant console user. You must add users through the Cisco
CallManager Attendant Console User Configuration window in Cisco CallManager
Administration before the user can log in to an attendant console.
Activity Procedure
Step 1
From Cisco CallManager Administration, choose Service > Cisco CM Attendant

Console > Cisco CM Attendant Console User.
Step 2
In the upper-right corner of the window, click the Add a New Attendant Console
User link.
Step 3
In the User ID field, enter jjones.
Step 4
In the Password field, enter cisco.
Step 5
In the Confirm field, enter cisco.
Step 6
Click Insert to add the new user.
Click the Back to Find/List Attendant Console Users link in the upper-right corner of the
Attendant Console User Configuration window. The Find and List Attendant Console
Users window is displayed. Click Find. The attendant console user that you created is
displayed.
Lab Guide
137
Task 2: Configure the Pilot Point

In this task, you will configure the Cisco CallManager Attendant Console server pilot point in
preparation for installing and configuring the Cisco CallManager Attendant Console client.
Activity Procedure
Step 1
In Cisco CallManager Administration, choose Service > Cisco CM Attendant

Console > Pilot Point. The Find and List Pilot Points window appears.
Step 2
At the upper-right side of the Find and List Pilot Points window, click the Add a
New Pilot Point link.
Step 3
In the Pilot Name field, enter Pilot1.
Step 4
From the Device Pool drop-down menu, select BA_Default_CMLocal_DP.
Step 5
In the Pilot Number field, enter xxxx, where x = your pod number.
Step 6
Click Insert.
Click the Back to Find/List Pilot Points link in the upper-right corner of the Pilot Point
Configuration window. The Find and List Pilot Points window appears. Click Find. The
new pilot point is listed.
Task 3: Configure the Hunt Group

You will configure the Cisco CallManager Attendant Console server hunt group in preparation
for installing and configuring the Cisco CallManager Attendant Console client.
Activity Procedure
138
Step 1
In Cisco CallManager Administration, choose Service > Cisco CM Attendant

Console > Hunt Group. The Hunt Group Configuration window appears.
Step 2
Choose Pilot1 from the Pilot Points field on the left side of the window.
Step 3
Click Add Member. The Hunt Group Members field initially displays the text Not
Configured.
Step 4
Under User Member Information, choose jjones from the User Name drop-down
menu and 1 from the Line Number drop-down menu (because you have only one
line configured on the IP Phone).
Step 5
Click Add Member. The Hunt Group Members field displays the text Not
Configured.
Step 6
Enter the DN x002, where x = your pod number. Assign this number to the
Employee_PT. (You might receive a false error message stating This is an invalid
DN.
Step 7
Check the Always Route Member check box so that the voice-mail number can
receive multiple calls at the same time.
Step 8
Click Update.
Task 4: Create the ac User Account

You must configure one user with the user ID ac in Cisco CallManager Administration and
associate the attendant IP Phones and the pilot points with this user. If you do not configure this
user, the attendant console cannot interact with Cisco CTIManager and the attendant cannot
receive calls.
Activity Procedure
Step 1
From Cisco CallManager Administration, choose User > Add a New User. The
User Configuration window appears.
Step 2
In the First Name and Last Name fields, enter ac.
Step 3
In the User ID field, enter ac.
Step 4
In the User Password field, enter 12345.
Step 5
In the Confirm Password field, enter 12345.
Step 6
In the PIN field, enter 12345.
Step 7
In the Confirm PIN field, enter 12345.
Note
By default, the Cisco CallManager Attendant Console First Name, Last Name, and User ID
fields must all be set to ac and the password must be set to 12345. The PIN is a variable
field. These fields can (and should) be changed using the Attendant Console Configuration
tool, but when you initially create the ac user, you must supply the default User ID and
password.
Step 8
Check the Enable CTI Application Use check box. You must check this check box
for the attendant console to interact with CTIManager.
Step 9
Step 10
Click Insert at the top of the window.
Lab Guide
139
Task 5: Associate Devices and Pilot Points with the ac User

Before the attendant uses the attendant console, you must associate the attendant console IP
Phones and pilot points with the ac user.
Activity Procedure
Step 1
In the User Configuration window for the ac user, click Device Association.
Step 2
Click Select Devices and OK.
Step 3
Check the Pilot1 device check box.
Step 4
Check the extension x000 check box where x = your pod number. This extension
should be the primary extension.
Step 5
Click Update to assign the telephone to the ac user.
Task 6: Install and Configure Cisco CallManager Attendant

Console Client
In this task, you will install and configure the Cisco CallManager Attendant Console client.
Activity Procedure
Change the NIC to 100-Mbps Full-Duplex
Step 1
Open a terminal services session (Remote Desktop Connection) to the publisher.
You will set the NIC to 100-Mbps full-duplex operation to ensure that Cisco
CallManager Attendant Console and other software can be quickly downloaded
from the publisher server to the client over the network.
140
Step 2
From the publisher desktop, right-click My Network Places and choose the
Properties icon to open the Network and Dial-Up Connections folder.
Step 3
Right-click the Local Area Network Connection and choose Properties to open
the Local Area Connection Properties window.
Step 4
Click the Configure button located under the NIC model (HP NC3163 Fast Ethernet
NIC, for example).
Step 5
Click the Advanced tab.
Step 6
Highlight Speed & Duplex ,and from the Value drop-down menu, choose
100Mbps/Full Duplex (or 100 Mb Full). Click OK.
Step 7
You will lose your remote connection to the publisher. Open a browser session to
Cisco CallManager Administration on the publisher.
Install the Cisco CallManager Attendant Console Plug-In

Step 8
From Cisco CallManager Administration, choose Applications > Install Plugins.
Step 9
Click the Cisco CallManager Attendant Console icon to start the installation.
Step 10
Click Open.
Step 11
When the Welcome window appears, follow the prompts, accept the license
agreement, and complete the installation.
Configure Cisco CallManager Attendant Console Settings

Step 12
From your laptop, start the Cisco CallManager Attendant Console client by choosing
Start > Programs > Cisco CallManager Attendant Console or double-click the
Cisco CallManager Console icon on the desktop.
Step 13
In the Basic Settings tab, enter your subscriber IP address in the Attendant Server
Host Name or IP Address field. The address needs to be the Cisco CallManager to
which the IP Phone is registered.
Note
You might receive an unknown error error message when you enter the required data in the
Basic Settings window. Continue to enter the data and close the Basic Settings window;
your data will be saved.
Step 14
Enter x000 in the Directory Number of Your Phone field, where x = your pod
number.
Step 15
Click Save. The Attendant Console Log In window appears.
Step 16
Enter jjones as the user ID and cisco as the password. Click Log In. The Cisco
CallManager Attendant Console application appears.
Step 17
Spend a few minutes experimenting with the features and capabilities of the
attendant console. Place calls to the IP Phone associated with the attendant console
(x000) and answer the call from the attendant console. Answer, transfer (normal
transfer and consult transfer), hold, resume, hang up, and make calls from the
attendant console to telephones in your cluster.
The Cisco CallManager Attendant Console application can be started and calls can be made
and answered from the attendant console.
Lab Guide
141
Lab 5-2: Configuring Cisco IPMA
Activity Objective
In this activity, you will configure Cisco IPMA for shared-line mode and use Cisco IPMA
Assistant Console. After completing this activity, you will be able to meet these objectives:
Configure Cisco IPMA service parameters for shared-line mode
Add Cisco IPMA managers and assistant users and associate devices with users
Add an intercom line to the manager and assistant IP Phones and select a distinctive ring
Configure the Cisco IPMA manager and assign an assistant
Configure shared and intercom lines for the assistant telephone
Install the IPMA Assistant Console application
Use the Cisco IPMA Assistant Console application to perform various call functions,
including answering, making, transferring, and joining calls for the manager
Set a divert target to a predefined number that will divert calls when the manager or
assistant presses the ImmDiv softkey
Visual Objective

Cisco IPMA
Cisco IPMA-Controlled Line

x099
xx01
x099
Intercom Line
xx02
x002
x001
Cisco IPMA Manager Cisco IPMA Assistant
142
CIPT1 v4.122
In this activity, you will first add Cisco IPMA manager and assistant users to Cisco
CallManager and associate devices with these users. Next, you will create a third line on the
manager and the assistant telephones that will be used as an intercom line. You will then
configure the manager and assistant users to use the shared line and the intercom line and to
automatically assign the appropriate softkey template to their IP Phones. Then, you will install
and use the Cisco IPMA Assistant Console application to allow the assistant to handle calls on
behalf of the manager. Finally, you will set a destination number to divert calls to the manager
or the assistant when either presses the Immediate Divert softkey.
Required Resources
Remote Cisco IP telephony server cluster
Laptop or PC
Command List
Job Aids
Task 1: Configure Cisco IPMA Service Parameters for SharedLine Support

Note
The Cisco IPMA and CTIManager services are required for proper Cisco IPMA operation.
These services were activated on the publisher in Lab 1-1, Cisco CallManager
Postinstallation Tasks.
In this task, you will enable the service parameters to initiate the Cisco IPMA service and stop
and start the service.
Activity Procedure
Step 1
Configure the applicable service parameters. In Cisco CallManager Administration,

choose Service > Service Parameters. In the Server field, choose the publisher
server. In the Service field, choose Cisco IP Manager Assistant. This action opens
the Services Parameter Configuration window.
Step 2
Cisco IPMA requires Cisco CTIManager to operate. In the CTI Manager (Primary)
IP Address field, enter the publisher IP address. Click OK when you receive the
message to restart the Tomcat service.
Lab Guide
143
Step 3
Scroll down to the Cisco IPMA Server (Primary) IP Address field and enter the
publisher IP address. Click OK when you receive the message to restart the Tomcat
service.
Step 4
Scroll down to the Clusterwide Parameters (Softkey Templates) area and view, but
do not change, the Assistant Softkey Template field and the Manager Softkey
Template for Shared Mode field. These templates will be assigned to the assistant
and manager telephones during automatic configuration later in the lab activity.
Step 5
Click Update.
Start and Stop the Cisco IPMA Service

Step 6
Browse to http://<IPMA server_IP address>/manager/list, where <IPMA
server_IP address> is the publisher IP address.
Step 7
Enter administrator as the username and cisco as the password.
Step 8
For the Cisco IPMA Assistant service, click Stop and then click Start.
Step 9
Close the Tomcat Web Application browser.
Task 2: Add Cisco IPMA Manager and Assistant Users and

Associate Devices with Users
In this task, you will add a Cisco IPMA manager and Cisco IPMA assistant to the global
directory and associate the IP Phones with the users.
Activity Procedure
Step 1
In Cisco CallManager Administration, choose User > Add a New User.
Step 2
Enter IPMA in the First Name field and Manager in the Last Name field.
Note
144
In a production environment, you would enter the actual first and last name of the user. In
this activity, you will use the names IPMA Assistant and IPMA Manager to make the
activity easier to follow.
Step 3
Enter IPMAManager as the user ID.
Step 4
Enter cisco as the password.
Step 5
Enter 12345 as the PIN.
Step 6
Enter the second-highest DN in your cluster as the telephone number (x001).
Step 7
Check the Enable CTI Application Use check box.
Step 8
Step 9
Click Insert.
Step 10
At the left side of the window, click Device Association, and then click Select
Devices and OK.
Step 11
Scroll down and choose the telephone extension (x001) of the Cisco IPMA manager.
The two extensions that belong to the Cisco IPMA manager will be checked
automatically. The lowest DN should be the primary extension.
Step 12
Click Update.
Step 13
Click Add a New User.
Step 14
Enter IPMA in the First Name field and Assistant in the Last Name field.
Step 15
Enter IPMAAssistant as the user ID.
Step 16
Enter cisco as the password.
Step 17
Enter 12345 as the PIN.
Step 18
Enter the highest DN in your cluster as the telephone number (x002).
Step 19
Enter IPMAManager as the manager user ID.
Step 20
Check the Enable CTI Application Use check box.
Step 21
Step 22
Click Insert.
Step 23
At the left side of the window, click Device Association, and then click Select
Devices and OK.
Step 24
Scroll down and choose the telephone extension (x002) of the Cisco IPMA assistant.
The two extensions that belong to the Cisco IPMA assistant will be checked
automatically. The lowest DN should be the primary extension.
Step 25
Click Update.
The Cisco IPMA manager and Cisco IPMA assistant users are visible in the global
directory when you choose User > Global Directory and Search.
Task 3: Add an Intercom Line

In this task, you will add a third DN for an intercom line between the manager and assistant
telephones.
Activity Procedure
Step 1
Choose Device > Phone > Find and choose the manager telephone (x001) to open
the Phone Configuration window.
Step 2
Choose Line 3 - Add New DN in the Directory Numbers column at the left side of
the window. You will configure this line as the intercom line.
Step 3
Assign the DN xx01 (where x = your pod number).
Step 4
Leave the Partition field set to None.
Lab Guide
145
Step 5
Note
In the Calling Search Space field, choose Unlimited Access_CSS.

Take note of the Auto Answer field but do not change the default setting (Auto Answer Off).
This setting will automatically be configured to Auto Answer with Speakerphone when you
configure the manager telephone.
Step 6
Set the No Answer Ring Duration value to 5 in the Call Forward and Pickup Settings
area.
Step 7
Click Add and OK.
Step 8
Click Add/Update Speed Dials.
Step 9
Enter xx02 as Speed Dial Number 1 and INTCM as the label.
Step 10
Click Update and Close, click OK, and click Reset Phone.
Step 11
Choose Device > Phone > Find and choose the assistant telephone (x002) to open
the Phone Configuration window.
Step 12
Click Line 3 - Add New DN from the DNs at the left side of the window. You will
configure this line as the intercom line.
Step 13
Assign the DN xx02 (where x = your pod number).
Step 14
Leave the Partition field set to None.
Step 15
In the Calling Search Space field, choose Unlimited Access_CSS.
Step 16
Set the No Answer Ring Duration value to 5 in the Call Forward and Pickup Settings
area.
Step 17
Click Add and click OK.
Step 18
Click Add/Update Speed Dials.
Step 19
Enter xx01 as Speed Dial Number 1 and INTCM as the label.
Step 20
Click Update and Close, click OK, and click Reset Phone.
Note
You can set an intercom line without enabling the Cisco IPMA feature by following the
procedure here and setting the Auto Answer field to Auto Answer with Speakerphone from
the Directory Number Configuration window.
Select a Distinctive Ring for the Intercom Line

Step 21
Select one of the telephones with the intercom line configured. Press the Settings
button, then press 2, and scroll down to the intercom line and press Select.
146
Step 22
Change the ring to one of seven distinctive types. Select the desired ring type, press
Select, and press OK. Press Exit twice.
Step 23
Repeat Steps 1 and 2 for the other telephone with an intercom line.
From the manager telephone, you can press the INTCM button to dial xx02 on the assistant
telephone. You will have to manually answer the intercom line until you complete the
configuration of the Cisco IPMA manager telephone.
From the assistant telephone, you can press the INTCM button to dial xx01 on the manager
telephone. You will have to manually answer the intercom line until you complete the
configuration of the Cisco IPMA assistant telephone.
Task 4: Configure a Cisco IPMA Manager and Assign an

Assistant
In this task, you will complete the configuration of the manager telephone by designating the
shared line and intercom line, assigning an assistant, and automatically configuring the
intercom and softkey template.
Activity Procedure
Step 1
Choose User > Global Directory and Search. Enter IPMAManager in the User
Search field. Click Manager to open the User Configuration window.
Step 2
To configure Cisco IPMA information for the manager, click Cisco IPMA from the
Application Profiles of IPMA list on the left.
Step 3
Read the information in this window and click the Continue button.
Step 4
In the User Configuration window, read the paragraph about automatic

configuration.
Step 5
Check the Uses Shared Lines check box.
Step 6
From the Intercom Line field, choose xx01 for the manager intercom.
Step 7
From the Available Lines pane, move the shared line DN (x099) to the Selected
Lines pane. This is the line to be controlled by Cisco IPMA.
Step 8
Scroll up and click the Add/Delete Assistants link to assign an assistant to the
manager. Click Search.
Step 9
Choose IPMAAssistant, and click Insert and OK. Click Update in the User
Step 10
Stop and start the Cisco IPMA service by browsing to http://<IPMA server_IP
address>/manager/list, where <IPMA server_IP address> is the publisher IP
address. Enter administrator as the username and cisco as the password. For the
Cisco IPMA assistant service, click Stop and then click Start. Close the Tomcat
web browser.
Lab Guide
147
The telephone that you assigned to the Cisco IPMA manager automatically resets and
displays the manager softkey template for shared mode. This template includes a DND (do
not disturb) softkey and bell icon, as shown in the figure. A crossed-out bell indicates that
the feature is on and the ringer on the telephone is disabled.
Task 5: Configure Shared and Intercom Lines for the Assistant

In this task, you will complete the configuration of the assistant telephone by designating the
shared line and intercom line and by automatically configuring the intercom and softkey
template.
Activity Procedure
Step 1
From Cisco CallManager Administration, choose User > Global Directory.
Step 2
Click the Search button to find the user that will be the assistant.
Step 3
Click IPMAAssistant to open the User Configuration window.
Step 4
Click Cisco IPMA from the Application Profiles of IPMA list to configure IPMA
information for the assistant.
Step 5
Choose Line 3 - xx02 as the Intercom Line.
Step 6
Click Update.
The telephone that you assigned to the IPMA assistant automatically resets and the
assistant softkey template and intercom line are automatically configured. To verify this
result in Cisco CallManager Administration, choose Device > Phone > Find and select the
assistant telephone. Scroll down to view the softkey template; it should show Standard
IPMA Assistant.
From the assistant and manager telephones, press the INTCM button and validate that
Auto Answer has been automatically configured to Auto Answer with Speakerphone.
The intercom line is operational. From the manager telephone, press the INTCM button
from the assistant telephone. Extension xx02 should ring once and then the speaker should
automatically open. Repeat this process on the manager telephone.
148
Note
If any of the lines are active on the telephone that you are calling by means of the intercom
features, it will ring only once and must be manually answered (the speaker will not open.)
Task 6: Install the Cisco IPMA Assistant Console Application

In this task, you will install the Cisco IPMA Assistant Console application on your desktop and
log in as the Cisco IPMA assistant.
Activity Procedure
Step 1
On your laptop, open the browser and enter http://<publisher IP

address>/ma/Install/IPMAConsoleInstall.jsp. This address is case-sensitive. (The
IP address that you enter must be the address of the server that has the Cisco IPMA
service running on it.)
Step 2
A security warning appears, asking you if you want to install and run Cisco IP
Manager Assistant Console Installer. Click Yes. The installation process could take
up to 5 minutes.
Step 3
When the browser window indicates that the installation was successful, close the
installation window.
Step 4
Double-click the IPMA Assistant Console shortcut on the desktop of your laptop to
launch the Cisco IPMA Assistant Console.
Step 5
The Cisco IPMA Settings window appears at initial login. Enter the publisher IP
address.
Step 6
The login window should appear. Enter IPMAAssistant in the User ID field and
cisco in the Password field and click Log In.
The Cisco IPMA Assistant Console application launches. The Cisco IPMA assistant is now
ready to handle calls on behalf of the Cisco IPMA manager.
Task 7: Use the Cisco IPMA Assistant Console

In this task, you will use the Cisco IPMA Assistant Console to perform various call functions.
Activity Procedure
Step 1
Spend a few minutes experimenting with various Cisco IPMA Assistant Console
features and options. Answer, transfer (normal transfer and consult transfer), hold,
resume, hang up, and make calls from the Cisco IPMA Assistant Console to
telephones in your cluster and remote clusters.
Step 2
Make calls to the manager telephone with the DND function enabled and disabled
and observe the behavior.
Lab Guide
149
Step 3
Join two calls and the assistant into a conference using the Call Join feature: Place a
call from the primary line of the manager (x001) to the shared line (x099) and
answer the call. From the third telephone in your pod, place a second call to the
shared line and answer the call. From the Assistant Console, highlight the two active
calls, and choose Join. You are joined in a three-way conference. Hang up from the
Cisco IPMA Assistant Console, and the two calls will remain connected as a pointto-point call (no conference resources are used).
Step 4
Using the Cisco IPMA Assistant Console, place a call to x000 from the shared line
(x099). Answer the call from x000. Place another call to the primary line of the
manager (x001) and while it is ringing, use Direct Transfer to join the two calls
together.
You can answer, transfer, hold, resume, hang up, and make calls from the Cisco IPMA
Assistant Console to telephones in your cluster and remote clusters.
You can use Call Join and Direct Transfer with the Cisco IPMA Assistant Console.
Task 8: Set a Divert Target

In this task, you will set a divert target to a predefined number when the manager or assistant
presses the ImmDiv softkey.
Activity Procedure
Step 1
On your laptop, open the browser and enter http://<Publisher IP

Address>/ma/desktop/maLogin.jsp. This address is case-sensitive. (The IP address
that you enter must be the server that has the Cisco IPMA service running on it.)
Step 2
Log in using IPMAManager as the username and cisco as the password, as

previously configured in the User Configuration windows.
Step 3
Enter x000 in the Directory Number field to divert calls to the assistant line when
you press the ImmDiv softkey.
Step 4
Click Save and Logout, and close the browser window.
Step 5
Call the shared line x099. From the manager IP Phone, press the ImmDiv softkey to
divert the call to x002.
Note
Either the manager or the assistant can use the Manager Configuration window.
Configure Manager Parameters

Step 6
From Cisco IPMA Assistant Console, choose Manager > Configuration. Enter the
third IP Phone in your pod (x000) in the Directory Number field. This action also
selects the designation for calls that are diverted by the manager and is an alternative
to using the Manager Configuration window to set the divert target. Click Save and
Close.
150
Step 7
To change the assistant divert target, choose Edit > Immediate Divert. Enter the
third IP Phone number in your pod (x000) in the Directory Number field. This action
selects the designation for calls that come in on the shared line that that are manually
diverted by the assistant using the ImmDiv softkey or Cisco IPMA Assistant
Console.
Step 8
Call the shared line, x099. From the assistant IP Phone, press the ImmDiv softkey to
divert the call to x000.
Calls can be diverted from either the manager or the assistant IP Phone.
Lab Guide
151
Answer Key
The correct answers and expected solutions for Labs 2-1, 2-2, 3-4, 3-6, and 3-7 in this guide
appear here.
Lab 2-1 Answer Key: Configuring Cisco CallManager to

Support Cisco IP Phones
When you complete this lab activity, your router configuration will be similar to the following,
with differences that are specific to your pod:
-
- -- -
- -- -
- --
- -
-
-- -
-

-

--
--

152
-
- -
-
-
--

-
-
--

-
-
--

--

Lab Guide
153
-

--- -
- -
-

-
--
154

-- -
Lab Guide
155
Lab 2-2 Answer Key: Configuring Auxiliary or Voice VLANs

When you complete this lab activity, your configuration will be similar to the following:
Cisco Catalyst 6000 Switch
- -
- -- -
- - -
-
- --
--
- --
-
- - -
- - -
-
- - -
156
- - -
-
- - -
- - -
-
- - -
- - -
-
- - -
- - -
- -
-
-
- - -
-

- -
-
- -
- -
-
--
- - -
-
- -
- -- - --
- -
- -
Lab Guide
157

-
-
-
-
-
-
-
-
-
-
-
-
- ---
-- -
- -
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
158
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- -
-
-
-
-
-
-
-

- -

- -

Lab Guide
159
- -

- -

- -

- -

- -

- -

- -

- -

- -

- -

- -
Gateway
--

-
- -- -
- -- -
- --
- -
160
-
-- -
-

-

--
--
--
--
Lab Guide
161
-
- -
-
-
--

-
-
--

-
-
--

--

162
-

--- -
- -

- -

-
--
---
Lab Guide
163

-
--
---
- -
-

-
--

164

---
-- -

---
Lab Guide
165
Lab 3-4 Answer Key: Configuring Complex Route Plans

When you complete this lab activity, your gateway configuration will be similar to the
following, with differences that are specific to your pod:
--

-
- -- -
- -- -
- --
- -
-
-- -
-

-

--
--

166
--
--
-
- -
-
-
--

-
-
--

-
-
--

--

Lab Guide
167

-

--- -
- -

- -

-
--
---
168

-
-

-
--
---
-
-

-
-

- -
-
Lab Guide
169

-
--

---
-- -

---
170
Lab 3-6 Answer Key: Configuring Call Admission Control

When you complete this lab activity, your gatekeeper configuration will be similar to the
following:
-

-
- --
- --
- --
-

-
-
- -

Lab Guide
171
--

--

--

--

-

-
---
- -
- -
- -
- -
- -
- -
- -
- -
172
- -
- -
- -
- -
- -
- -
- -
-
-
-
-

-
-
-
-
--- -
--- -
--- -
--- -
-

-- -
-

-- -
- 2005, Cisco Systems, Inc.
Lab Guide
173
174
Lab 3-7 Answer Key: Configuring SRST

When you complete this lab activity, your SRST router configuration will be similar to the
following, with differences that are specific to your pod:
--

-
- -- -
- -- -
- --
- -
-
-- -
-

-

--
--

Lab Guide
175
--
--
-
- -
-
-
--

-
-
--

-
-
--

176

--

-

--- -
- -

- -
Lab Guide
177

-
--
---

-
-

-
--
---
-
-

178
-
-

-
---
-

- -
-

-
--

---
-- -

---
Lab Guide
179
180

642-444 CIPT 4.1 Vol1

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

642-444 CIPT 4.1 Vol1

Încărcat de

Drepturi de autor:

Formate disponibile

CIPT1

2005, Cisco Systems, Inc. All rights reserved.

Getting Started with Cisco CallManager

Introducing Cisco CallManager

Identifying Cisco CallManager Cluster and Deployment Options

Establishing an On-Cluster Call

Identifying Cisco IP Telephony Endpoints

IP Phone Startup Process

Configuring Cisco CallManager to Support IP Phones

Configuring Cisco Catalyst Switches

Configuring Cisco IP Communicator

Using the Bulk Administration Tool

Cisco IP Telephony Part 1 (CIPT1) v4.1

Configuring Gateways and Trunks

Configuring Basic Route Plans

Configuring Hunt Groups and Call Coverage

Configuring Complex Route Plans

2005, Cisco Systems, Inc.

Cisco IP Telephony Part 1 (CIPT1) v4.1

Implementing Class of Control

Implementing Multiple-Site Deployments

Enabling Features and Services

Configuring Media Resources

Cisco IP Telephony Part 1 (CIPT1) v4.1

2005, Cisco Systems, Inc.

Adding Users and Customizing User Options

Configuring User Features Part 1

Configuring User Features Part 2

2005, Cisco Systems, Inc.

Cisco IP Telephony Part 1 (CIPT1) v4.1

Configuring Cisco CallManager Applications

Configuring Cisco CallManager Attendant Console

Configuring Cisco IP Manager Assistant

Cisco IP Telephony Part 1 (CIPT1) v4.1

2005, Cisco Systems, Inc.

Learner Skills and Knowledge

Learner Skills and Knowledge

Cisco Learning Offering

Working knowledge of fundamental terms Interconnecting Cisco Network

Building Cisco Multilayer

Fundamental knowledge of converged

Cisco Voice over IP (CVOICE)

Ability to configure voice interfaces on

Cisco IP Telephony Part 1 (CIPT1) v4.1

2005, Cisco Systems, Inc.

Course Goal and Objectives

This topic describes the course goal and objectives.

To prepare learners to install, configure, and

2005 Cisco Systems, Inc. All rights reserved.

2005, Cisco Systems, Inc.

This topic presents the suggested flow of the course materials.

Cisco IP Telephony Part 1 (CIPT1) v4.1

2005, Cisco Systems, Inc.

Course Icons and Symbols

Voice Multilayer Switch

2005 Cisco Systems, Inc. All rights reserved.

Course Icons and Symbols (Cont.)

2005, Cisco Systems, Inc.

Cisco Glossary of Terms

Cisco IP Telephony Part 1 (CIPT1) v4.1

2005, Cisco Systems, Inc.

Your Training Curriculum

This topic presents the training curriculum of this course.