Cisco IP Telephony-CIPT-Part 1 Student Guide v.40

CIPT1
Cisco IP Telephony Part 1

Version 4.0
Student Guide
ILSG Production Services: 9-17-04
The PDF files and any printed representation for this material are the property of Cisco Systems, Inc., for the sole use by Cisco employees for personal study. The files or printed representations may not be used in commercial training, and may not be distributed for purposes other than individual self-study.
Copyright 2004, 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 Web site 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 2004 Cisco Systems, Inc. All rights reserved. CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, 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 Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, iQ logo, the iQ Net Readiness Scorecard, LightStream, Linksys, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, 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. (0402R)
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.
Students, this letter describes important course evaluation access information!
Welcome to Cisco Systems Learning. Through the Cisco Learning Partner Program, Cisco Systems is committed to bringing you the highest-quality training in the industry. Cisco learning products are designed to advance your professional goals and give you the expertise you need to build and maintain strategic networks. Cisco relies on customer feedback to guide business decisions; therefore, your valuable input will help shape future Cisco course curricula, products, and training offerings. We would appreciate a few minutes of your time to complete a brief Cisco online course evaluation of your instructor and the course materials in this student kit. On the final day of class, your instructor will provide you with a URL directing you to a short post-course evaluation. If there is no Internet access in the classroom, please complete the evaluation within the next 48 hours or as soon as you can access the web. On behalf of Cisco, thank you for choosing Cisco Learning Partners for your Internet technology training. Sincerely, Cisco Systems Learning
Table of Contents
Volume 1 Course Introduction
Overview Course Goal and Objectives Course Outline Cisco Certifications Learner Skills and Knowledge Learner Responsibilities General Administration Course Flow Diagram Icons and Symbols Learner Introductions
1
1 2 3 4 5 6 7 8 9 10
Getting Started with Cisco CallManager

Overview Module Objectives Outline
1-1
1-1 1-1 1-2
Identifying Cisco IP Telephony Components

Overview Relevance Objectives Learner Skills and Knowledge Outline Cisco AVVID Cisco IP Communications Components Cisco IP Telephony Components Cisco CallManager Functions Example: Basic IP Telephony Call Comparing Legacy and IP Telephony Technology Cisco CallManager Operating System, Database, and Supporting Applications Supported Cisco CallManager Hardware Device Weight Units Example: Device Weights Summary References Quiz Quiz Answer Key
1-3
1-3 1-3 1-3 1-4 1-4 1-5 1-6 1-7 1-9 1-10 1-11 1-13 1-14 1-16 1-17 1-18 1-19 1-20 1-22
Identifying Cisco CallManager Cluster and Deployment Options

Overview Relevance Objectives Learner Skills and Knowledge Outline Microsoft SQL Cluster Relationship Intracluster Communication Cluster Redundancy Designs IP Telephony Deployment Models Single-Site Deployment Multisite WAN with Centralized Call Processing Multisite WAN with Distributed Call Processing Single-Cluster Distributed Call Processing Summary References Quiz Quiz Answer Key
1-23
1-23 1-23 1-23 1-24 1-24 1-25 1-27 1-28 1-30 1-31 1-33 1-36 1-39 1-41 1-42 1-43 1-45
Installing Cisco CallManager

Overview Relevance Objectives Learner Skills and Knowledge Outline Installation CD-ROMs Installation Configuration Data Example: Configuration Data Worksheet Activating Cisco CallManager Services Postinstallation Procedures Upgrading Prior Cisco CallManager Versions Summary References Quiz Quiz Answer Key
1-47
1-47 1-47 1-47 1-47 1-48 1-49 1-50 1-52 1-54 1-57 1-62 1-67 1-67 1-68 1-69
Establishing an On-Cluster Call

Overview Module Objectives Module Outline
2-1
2-1 2-2 2-2
Introducing Cisco IP Phones

Overview Relevance Objectives Learner Skills and Knowledge Outline Cisco IP Phone Overview Entry-Level Cisco IP Phones Midrange and Upper-End Cisco IP Phones Additional Cisco VoIP Devices IP Phone Startup Process Cisco IP Phone Codec Support Summary References Quiz Quiz Answer Key
2-3
2-3 2-3 2-3 2-4 2-4 2-5 2-6 2-8 2-10 2-12 2-14 2-16 2-17 2-18 2-20
Configuring Cisco CallManager to Support IP Phones

Overview Relevance Objectives Learner Skills and Knowledge Outline Server Configuration Configuring Device Pools Example: Device Pool Configuration Example: Cisco CallManager Group Configuration Example: Region Configuration IP Phone Button Templates Example: Naming an IP Phone Button Template Manual IP Phone and Directory Number Configuration Configuring IP Phone Auto-Registration Summary References Quiz Quiz Answer Key
2-21
2-21 2-21 2-21 2-22 2-22 2-23 2-24 2-25 2-27 2-30 2-32 2-33 2-34 2-36 2-38 2-38 2-39 2-40
ii
Cisco IP Telephony Part 1 (CIPT1) v4.0
Copyright 2004, Cisco Systems, Inc.
Configuring Cisco Catalyst Switches

Overview Relevance Objectives Learner Skills and Knowledge Outline Catalyst Switch Role in IP Telephony Powering the Cisco IP Phone Types of Inline Power Delivery Catalyst Family of PoE Switches Configuring Inline Power Configuring Dual VLANs Configuring Class of Service Summary References Quiz Quiz Answer Key
2-41
2-41 2-41 2-41 2-42 2-42 2-43 2-44 2-45 2-49 2-51 2-53 2-59 2-61 2-62 2-63 2-65
Adding Users and Customizing User Options

Overview Relevance Objectives Learner Skills and Knowledge Outline Adding a User User Logon 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 Example: Personal Address Book and Fast Dials 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 Quiz Quiz Answer Key
2-67
2-67 2-67 2-67 2-68 2-68 2-69 2-72 2-74 2-74 2-75 2-75 2-76 2-76 2-77 2-77 2-78 2-78 2-79 2-80 2-82 2-83 2-84 2-86
Using the Bulk Administration Tool

Overview Relevance Objectives Learner Skills and Knowledge Outline Introducing the Bulk Administration Tool Installing BAT Using the BAT Wizard Configuring BAT Templates Creating CSV Files Example: Sample CSV Data File with Customized File Format Validating Data Input Files Inserting IP Phones into Cisco CallManager Updating IP Phones with BAT Using the Tool for Auto-Registered Phones Support Summary
Copyright 2004, Cisco Systems, Inc. Cisco IP Telephony Part 1 (CIPT1) v4.0
2-87
2-87 2-87 2-87 2-88 2-88 2-89 2-92 2-94 2-98 2-101 2-103 2-104 2-105 2-106 2-108 2-112
iii
References Quiz Quiz Answer Key
2-113 2-114 2-116
Establishing an Off-Cluster Call

3-1
3-1 3-2 3-2
Configuring Gateways and Intercluster Trunks

Overview Relevance Objectives Learner Skills and Knowledge Outline 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 Configuring Intercluster Trunks Summary References Quiz Quiz Answer Key
3-3
3-3 3-3 3-3 3-4 3-4 3-5 3-6 3-7 3-8 3-10 3-12 3-15 3-18 3-21 3-22 3-23 3-24
Configuring Basic Route Plans

Overview Relevance Objectives Learner Skills and Knowledge Outline External Call Routing Route Groups Route Lists Route Patterns Digit Analysis Summary of Call Routing Example: Route Plan Summary Quiz Quiz Answer Key
3-25
3-25 3-25 3-25 3-26 3-26 3-27 3-30 3-32 3-34 3-40 3-45 3-48 3-49 3-50 3-51
Configuring Advanced Route Plans

Overview Relevance Objectives Learner Skills and Knowledge Outline Route Filters Discard Digits Instructions Transformation Masks Translation Patterns Route Plan Report Summary References Quiz Quiz Answer Key
iv Cisco IP Telephony Part 1 (CIPT1) v4.0
3-53
3-53 3-53 3-53 3-54 3-54 3-55 3-60 3-63 3-69 3-72 3-74 3-74 3-75 3-76
Configuring Telephony Class of Service

Overview Relevance Objectives Learner Skills and Knowledge Outline Class of Service Partitions Example: Assigning DNs to Partitions Calling Search Spaces Example: Assigning Partitions to Calling Search Spaces Using Partitions and Calling Search Spaces for Emergency Calls Cisco Emergency Responder Summary References Quiz Quiz Answer Key
3-77
3-77 3-77 3-77 3-78 3-78 3-79 3-82 3-83 3-84 3-85 3-86 3-87 3-91 3-92 3-93 3-94
Configuring Call Admission Control and Survivable Remote Site Telephony

Overview Relevance Objectives Learner Skills and Knowledge Outline Call Admission Control Overview Locations-Based Call Admission Control Overview Locations-Based Call Admission Control Configuration Gatekeeper Call Admission Control Overview Gatekeeper Communication Gatekeeper Call Admission Control Configuration SRST Overview SRST Configuration Summary References Quiz Quiz Answer Key
3-95
3-95 3-95 3-95 3-96 3-96 3-97 3-99 3-101 3-102 3-103 3-108 3-112 3-118 3-123 3-124 3-125 3-127
Enabling Features for Users

4-1
4-1 4-1 4-2
Configuring Media Resources

Overview Relevance Objectives Learner Skills and Knowledge Outline 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 Quiz
Copyright 2004, Cisco Systems, Inc. Cisco IP Telephony Part 1 (CIPT1) v4.0
4-3
4-3 4-3 4-3 4-4 4-4 4-5 4-7 4-13 4-16 4-17 4-20 4-23 4-34 4-37 4-45 4-45 4-46
v
Quiz Answer Key
4-47
Working with Softkey Templates

Overview Relevance Objectives Learner Skills and Knowledge Outline Overview of the Softkey Template Creating Nonstandard Softkey Templates Example: Nonstandard Softkey Template Adding Application Softkeys to Nonstandard Softkey Templates Modifying Softkey Positions Assigning Softkey Templates to Devices Deleting Softkey Templates Summary References Quiz Quiz Answer Key
4-49
4-49 4-49 4-49 4-49 4-50 4-51 4-52 4-52 4-53 4-54 4-55 4-56 4-57 4-57 4-58 4-59
Configuring User Features

Overview Relevance Objectives Learner Skills and Knowledge Outline 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 Example: MLPP Call Call Park, Call Pickup, and Cisco Call Back Example: Call Park Feature in Department Store Example: Call Pickup Groups in Sales Support Department Example: Cisco Call Back Barge and Privacy Cisco IP Phone Services Cisco IP Manager Assistant Overview Cisco IPMA for Shared-Line Support Manager Configuration and Assistant Console Summary References Quiz Quiz Answer Key
4-61
4-61 4-61 4-61 4-62 4-62 4-63 4-67 4-68 4-69 4-72 4-72 4-74 4-76 4-76 4-78 4-79 4-80 4-85 4-91 4-95 4-102 4-105 4-106 4-107 4-109
vi
CIPT1
Course Introduction
Overview
Cisco IP Telephony Part 1 (CIPT1) v4.0 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 practice where you will install 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 (CoS), numerous user telephone features, and media resources.
Course Goal and Objectives

This section 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 1
2004 Cisco Systems, Inc. All rights reserved.
CIPT1 v4.13
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 Cisco Catalyst switches to enable telephone calls between Cisco IP Phones that are located within the same Cisco CallManager cluster Configure Cisco gateways and intercluster trunks, 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 to include conferencing, music on hold, speed dials, Call Park, Call Pickup, Cisco Call Back, Barge, Privacy, Cisco IP Manager Assistant, Call Join, Direct Transfer, and Cisco IP Phone Servicesyou will also be able to use these features on Cisco IP Phones
Course Outline
The outline lists the modules included in this course.
Course Outline
Getting Started with Cisco CallManager Establishing an On-Cluster Call Establishing an Off-Cluster Call Enabling Features for Users
CIPT1 v4.14
Course Introduction
Cisco Certifications
This topic lists the certification requirements of this course.
Cisco Certifications
CIPT1 v4.15
Cisco provides three levels of general career certifications for IT professionals with several different tracks to meet individual needs. Cisco also provides a variety of Cisco Qualified Specialist (CQS) certifications, which enable learners to demonstrate knowledge in specific technologies, solutions, or job roles. In contrast to general certifications, each CQS certification is focused on a designated area such as cable communications, voice, or security. All CQS certifications are customized to meet current market needs. They may also have special focused prerequisite requirements. There are many paths to Cisco certification, but only one requirementpassing one or more exams demonstrating knowledge and skill. For details, go to http://www.cisco.com/go/certifications.
Learner Skills and Knowledge

This topic lists the course prerequisites.
Prerequisite Learner Skills and Knowledge
Cisco CCNA
Building Cisco Multilayer Switched Networks (BCMSN) Cisco Voice over IP (CVOICE)
Cisco IP Telephony Part 1 (CIPT1) Cisco IP Telephony Part 2 (CIPT2)
Microsoft Software for Cisco Voice (MSCV)

2004 Cisco Systems, Inc. All rights reserved. CIPT1 v4.16
To benefit fully from this course, you must have these prerequisite skills and knowledge: Cisco CCNA certification Building Cisco Multilayer Switched Networks (BCMSN) Cisco Voice over IP (CVOICE) Microsoft Software for Cisco Voice (MSCV)
Course Introduction
Learner Responsibilities
This topic discusses the responsibilities of the learners.
Learner Responsibilities
Complete prerequisites Introduce yourself Ask questions
CIPT1 v4.17
To take full advantage of the information presented in this course, you must have completed the prerequisite requirements. In class, you are expected to participate in all lesson exercises and assessments. In addition, you are encouraged to ask any questions relevant to the course materials. If you have pertinent information or questions concerning future Cisco product releases and product features, please discuss these topics during breaks or after class. The instructor will answer your questions or direct you to an appropriate information source.
General Administration
This topic lists the administrative issues for the course.
General Administration
Class-Related
Sign-in sheet Course materials Length and times Attire
Facilities-Related
Site emergency procedures Rest rooms Telephones/faxes Break and lunchroom locations
CIPT1 v4.18
The instructor will discuss these administrative issues: Sign-in process Starting and anticipated ending times of each class day Class breaks and lunch facilities Appropriate attire during class Materials you can expect to receive during class What to do in the event of an emergency Location of the rest rooms How to send and receive telephone and fax messages
Course Introduction
Course Flow Diagram

This topic covers the suggested flow of the course materials.
Course Flow Diagram

Day 1 Course Introduction Day 2 Day 3 Day 4 Establishing an OffCluster Call
Day 5
A M
Establishing an OnCluster Call
Establishing an OffCluster Call
Lunch
Getting Started with Cisco CallManager Establishing an On-Cluster Call
P M
Establishing an OnCluster Call

Est. an OffCluster Call
Wrap-up Establishing an OffCluster Call Enabling Features for Users
CIPT1 v4.19
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 laboratory exercises. The exact timing of the subject materials and labs depends on the pace of your specific class.
Icons and Symbols

This topic shows the Cisco icons and symbols used in this course.
Course Icons and Symbols

Router Cisco CallManager File Server
Voice Router
Traditional PBX LDAP Directory Server
SRST-Enabled Router
Phone
IP Phone Switch Router
Relational Database
Switch
Gateway
DSP
Digital Signal Processor
Voice Multilayer Switch
Switch
PSTN CO Switch
VLAN or Cluster (Color May Vary)

CIPT1 v4.110
Course Icons and Symbols (Cont.)

PC WAN
Printer
Telecommuter
Fax Mobile User
Laptop
Videoconference
Building
Video Camera
Building
CIPT1 v4.111
Course Introduction
Learner Introductions
This is the point in the course where you introduce yourself.
Learner Introductions
Your name Your company Skills and knowledge Brief history Objective
CIPT1 v4.112
Prepare to share the following information: Your name Your company If you have most or all of the prerequisite skills A profile of your experience What you would like to learn from this course
10
Module 1

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 when you are 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.
Module Objectives
Describe the role that Cisco CallManager plays in the Cisco AVVID strategy and select the appropriate Cisco CallManager server platform for your IP telephony deployment Determine the optimum Cisco CallManager cluster option and IP telephony deployment model for your enterprise Perform a complete Cisco CallManager server installation
CIPT1 v4.11-2
Outline
The outline lists the components of this module.
Module Outline
Lesson 1-1: Identifying Cisco IP Telephony Components Lesson 1-2: Identifying Cisco CallManager Cluster and Deployment Options Lesson 1-3: Installing Cisco CallManager
CIPT1 v4.11-3
1-2
Identifying Cisco IP Telephony Components

Overview
This lesson discusses the fundamental components of the Cisco IP telephony solution, of which Cisco CallManager is the most integral. The lesson begins with an overview of Cisco Architecture for Voice, Video and Integrated Data (AVVID), Cisco IP Communications, and Cisco IP telephony, and then examines Cisco CallManager functions, hardware, and software requirements.
Relevance
Examining Cisco CallManager from a solution, system, and hardware perspective prepares you to gain more in-depth knowledge and to successfully install and configure Cisco CallManager.
Objectives
Upon completing this lesson, you will be able to describe the role that Cisco CallManager plays in the Cisco AVVID strategy and select the appropriate Cisco CallManager server platform for your IP telephony deployment. This includes being able to meet these objectives: Describe the purpose and key components of each Cisco AVVID layer List the six Cisco IP Communications system components Identify the four main components of an IP telephony solution Identify the six primary Cisco CallManager functions Compare legacy PBX technologies with IP telephony technologies 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 is supported Use busy hour call attempts and device weight units to determine the maximum number of Cisco IP Phones that can be associated with a Cisco CallManager hardware platform

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: Basic working knowledge of a computer and experience installing software onto a PC Basic understanding of network connectivity
Outline
The outline lists the topics included in this lesson.
Outline
Overview Cisco AVVID Cisco IP Communications Components Cisco IP Telephony Components Cisco CallManager Functions Comparing Legacy and IP Telephony Technology Cisco CallManager Operating System, Database, and Supporting Applications Supported Cisco CallManager Hardware Device Weight Units Summary Quiz
2004 Cisco Systems, Inc. All rights reserved. CIPT1 v1.41-2
1-4
Cisco AVVID
This topic describes the Cisco AVVID strategy, the only enterprise-wide, standards-based network architecture in the industry.
Cisco AVVID
Client Adaptive
Video Cisco IP SoftPhone IP Phone PC
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, which is where applications that provide additional network functionality reside; and the client layer, which is where enduser devices reside. The key points about the four standard layers are as follows: Infrastructure layer: The infrastructure can support multiple client types, such as analog telephones, Cisco IP SoftPhones, and video. Call-processing layer: Call processing is physically independent from the infrastructure. Thus, a Cisco CallManager in Chicago can process call control for a bearer channel in Phoenix. Applications layer: Applications are physically independent from 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 SoftPhone, or a PC delivering converged messaging.
Distributed Manageable
Applications
TAPI, JTAPI, SMDI
Cisco Unity Cisco IPCC
Call Processing Open

Call Admission, Call Routing
Cisco CallManager Directory
Infrastructure
Cisco IOS Network Services
Gateway Router Switch
CIPT1 v1.41-3
1-5
Cisco IP Communications Components

This topic describes the primary Cisco IP Communications solution components.
Cisco IP Communications Components

Contact Center CallManager Express IP Conferencing IP Telephony IP Video Telephony Unified Communications
Unified Messaging IP Contact Center Conference Manager
CIPT1 v1.41-4
Cisco IP Communications is a comprehensive system of enterprise-class solutions that includes these six primary components: Cisco Contact Center: Cisco Contact Center solutions combine such services as intelligent contact routing and management, real-time web collaboration, and e-mail response management with powerful Cisco IP telephony networking solutions. Cisco CallManager Express (formerly Cisco IOS Telephony Services): Cisco now offers worldwide small-business customers and autonomous small-enterprise branch offices an entry-level IP telephony solution that is integrated directly into Cisco IOS software. IP conferencing: Maximize conference call flexibility by connecting people in different locations and time zones with Cisco IP audio conferencing. IP telephony: With Cisco IP telephony, single-site and multisite enterprises can use IP as a primary voice path. Cisco IP telephony solutions deliver high-quality IP voice and fully integrated communications. IP video telephony: The Cisco IP video telephony solution has been developed for enterprises and service providers who want a reliable, easy-to-manage, cost-effective network infrastructure for videoconferencing applications deployment. Cisco Unified Communications: Cisco Unified Communications combines personal productivity management tools, such as unified messaging, rules-based call routing, and speech recognition, to deliver an unprecedented level of communications control.
1-6
Cisco IP Telephony Components

This topic describes the Cisco IP telephony solution components.
Cisco IP Telephony Components Cisco CallManager Application Software
Endpoints
Infrastructure
CIPT1 v1.41-5
IP telephony refers to the technology for transmitting voice communications over a network using an open standards-based IP. Built on Cisco AVVID, Cisco IP telephony solutions leverage a single network infrastructure for the transmission of data, voice, and video traffic to deliver high-quality IP voice and fully integrated communications. The Cisco IP telephony solution consists of four primary components: Cisco CallManager: At the heart of the IP telephony system is Cisco CallManager, the software-based call-processing agent. CallManager software extends enterprise telephony features and capabilities to packet telephony network devices such as IP Phones, mediaprocessing devices, Voice over IP (VoIP) gateways, and multimedia applications. Additional data, voice, and video services such as unified messaging, multimedia conferencing, collaborative contact centers, and interactive multimedia response systems interact with the IP telephony solution through CallManager open Telephony Application Programming Interfaces (TAPIs). Infrastructure: The infrastructure component includes the routers and LAN switches that are necessary to support CallManager clusters, connectivity for Cisco IP Phones, gateways to the Public Switched Telephone Network (PSTN), analog phone support, and digital signal processor farms to support conferencing and transcoding. Endpoints: Endpoints are Cisco IP Phones and video devices. IP Phones have all the functions of standard telephones such as call forward, transfer, park, and conference plus new features, such as the ability to access websites and extensible markup language (XML) applications. With Cisco CallManager 4.0, video telephony gives the same administration and user experience for voice and video.
1-7
Application software: Applications are physically independent from the call-processing and voice-processing infrastructure, and they may reside anywhere within your network. Voice applications include Cisco IP Contact Center, Cisco Personal Assistant, and Cisco IP Interactive Voice Response (IVR). Video applications include Cisco VT Advantage.
1-8
Cisco CallManager Functions

This topic describes the primary Cisco CallManager functions within the Cisco IP telephony solution.
Cisco CallManager Functions
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, 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 Signaling and device control Dial plan administration Phone feature administration Directory services A programming interface to external applications such as Cisco SoftPhone, Cisco IP IVR, Cisco Personal Assistant, and Cisco CallManager Attendant Console
1-9
Cisco CallManager Functions (Cont.)

Cisco CallManager Skinny Protocol Signaling Skinny Protocol Signaling
IP Phone Party A
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.
Cisco CallManager use the Skinny signaling protocol to communicate with Cisco IP Phones for call setup and maintenance tasks. Once the call is set up, Cisco IP Phones communicate directly using the 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.
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 set 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 how to route the call. After Cisco CallManager signals the calling party over IP to initiate a ring back, Party A hears ringing. CallManager also initiates ringing the set of the destination telephone. 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 unless either Party A or Party B invoke a feature, such as call transfer or call conferencing.
1-10
Comparing Legacy and IP Telephony Technology

This topic describes the advantages and benefits of using IP telephony network design.
Legacy PBX Technology

Digital Telephones Line Connections
Call Processing
Switching
Trunk Connections
PSTN
PBX systems power the majority of voice networks around the world and enable businesses to operate and manage their own telephone systems. Depending on the size of the company, using PBX systems can save a tremendous amount of money as compared to paying an outside service provider to manage the telephone network. Individual PBX system components can be extremely complex and may require special training to manage. From a broader perspective, all PBX systems can be broken down into four major components: Line connections: Line connections are feature cards that are installed into a PBX system to provide ports that connect end-user telephones. These ports provide a dial tone for the end device. Call processing: This component is the PBX engine. It provides the call-routing table, device recognition, and telephone features. Switching: This component is the backbone of the PBX. It provides the circuit between the devices that are communicating across the PBX system. Trunk connections: Trunk connections are feature cards that are installed into a PBX system to provide trunks to other PBX systems or to the PSTN.
1-11
IP Telephony Technology
IP Phones
Cisco CallManager
Catalyst Switches
Line Connections
Call Processing
Switching
Trunk Connections
Voice-Enabled Router or Gateway
CIPT1 v1.41-9
When designing a Cisco VoIP network, you can re-engineer PBX functionality by replacing telephony-specific equipment with industry standard data processing and data networking equipment. Rather than having a single, centralized PBX system, you can distribute these functions to data equipment in a decentralized design. This distribution allows for easier management and cabling. In addition, this design eliminates a single-server point of failure. Because the call-processing portions of the telephone system now run on industry standard application servers, you can easily introduce new functionality or features into a network by installing various applications. For example, to add voice mail to a network, you can install a Cisco Unity server. Alternatively, if you want to create a receptionist console, you can install the Cisco CallManager Attendant Console on a client PC.
1-12
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 v1.41-10
The Cisco CallManager server relies on Windows 2000 (provided by Cisco) for its operating system and the Microsoft Structured Query Language (SQL) Server 2000 for its database. Cisco CallManager 4.0 requires Microsoft Server Software OS version 2000.2.4 SR2 or later and Microsoft SQL 200 SP3a or later (included in installation). You can use Data Connection Directory (DC-Directory, from the company Data Connection) for a Lightweight Directory Access Protocol (LDAP) directory of end users if no other LDAP directory structure (such as Active Directory) is available. You can also use the Cisco IP Telephony Backup and Restore System (BARS) to back up the Cisco CallManager. BARS is installed separately from Cisco CallManager.
1-13
Supported Cisco CallManager Hardware

This topic describes the major features of the supported hardware platforms for Cisco CallManager 4.0.
Supported Cisco CallManager 4.0 Hardware

High
(dual processor)
Availability
Cisco MCS 7845H-3000 Cisco MCS 7835H-3000 Cisco MCS 7835I-3000 Cisco MCS 7825H-3000 Cisco MCS 7825I-3000
Low
Cisco MCS 7815I-2000
Performance
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, HP and IBM, to create Cisco Media Convergence Servers (MCSs). HP 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. Cisco CallManager 4.0 is supported on the following MCS servers: MCS 7815-1000 and MCS 7815I-2000 MCS 7825-800, MCS 7825-1133, MCS 7825H-3000, and MCS 7825I-3000 MCS 7835, MCS 7835-1000, MCS 7835-1266, MCS 7835H-3000, and MCS 7835I-3000 MCS 7845-1400 and MCS 7845H-3000 Cisco CallManager version 4.0 is also supported on the ICS 7750. Supported HP and IBM servers are listed at http://www.cisco.com/go/swonly.
1-14
Cisco CallManager MCS Hardware Matrix

Model Processor Memory Hard Disk Hot Plug HD Redundant Power Redundant Fans Max. Phones per Server / Cluster
7815I Pentium 4 2000-MHz 512 MB 40-GB ATA No No No 300 / NA
7825H Pentium 4 3060-MHz 1 GB
7825I Pentium 4 3060-MHz 1 GB
40-GB ATA 80-GB SATA No No No No No No
1000 / 4000 1000 / 4000

CIPT1 v1.41-12
This figure shows key hardware features for primary MCS servers that support Cisco CallManager 4.0.
Cisco CallManager MCS Hardware Matrix (Cont.)
Model Processor Memory Hard Disk Hot Plug HD Redundant Power Redundant Fans Max. Phones per Server / Cluster
7835H Prestonia Xeon 3060-MHz 1 GB 2 36-GB SCSI Yes Yes No 2500 / 10,000
7835I Prestonia Xeon 3060-MHz 1 GB 2 36-GB SCSI Yes Yes No 2500 / 10,000
7845H Dual Prestonia Xeon 3060-MHz 4 GB 4 72-GB SCSI Yes Yes Yes 7500 / 30,000 CallManager version 3.3 or greater
CIPT1 v1.41-13
This figure shows key hardware features for additional primary MCS servers that support Cisco CallManager 4.0.
1-15
Device Weight Units

This topic examines the number of device weight units that a hardware platform can support.
Device Weights Table

Weight BHCA < 6 2 2 3 6 2 3 3 3 1 3 3 Weight BHCA < 12 4 4 6 12 4 N/A 3 6 2 3 N/A Weight BHCA < 18 6 6 9 18 6 N/A 3 9 3 3 N/A Weight BHCA < 24 8 8 12 24 8 N/A 3 12 4 3 N/A
CTI Server Port CTI Client Port CTI 3rd Party CTI Agent CTI Route Point Transcoder MTP H.323 Gateway H.323 Client SCCP Client MGCP Conference
BHCA = busy hour call attempts

The table shown here lists the types of devices that can register to Cisco CallManager. Each device that registers to Cisco CallManager uses the resources (CPU cycles) of the CallManager server. Each device is assigned a device weight. A device weight is a standardized measure of the load that a device is expected to put on a CallManager server. Device weights are used to calculate the number of servers that are needed based on the designed Cisco CallManager configuration. Device weights are ranked according to a measurement that is known as busy hour call attempts (BHCA). The BHCA represents the number of call attempts made during the busiest hour of the day. A device in a quiet location, which is expected to be rarely used, will not put as much load on a server (no matter what the device is) as a device in a high-traffic, high-use area. To audit the network appropriately, you must first determine the busiest hour of the day and then scale the type of devices that are going to be deployed within the Cisco IP telephony solution. Using the data supplied in the table shown here, a Skinny Client Control Protocol (SCCP) client with a BHCA of less than 6 is weighted at 1; an H.323 gateway with a BHCA of less than 6 is weighted at 3. In a Cisco CallManager cluster, a variety of devices besides Cisco IP Phones will register. In these situations, you would experience a delayed dial tone if the device weight units were oversubscribed on a server.
1-16
Cisco CallManager Server Platforms: Device Weights

Platform
MCS 7845 All Models MCS 7835 All Models Compaq DL 380 IBM xSeries 342 MCS 7825 SPE 310 Compaq DL 320 IBM xSeries 330 MCS 7815I-2000
Device Weight Units per Server

10,000 5000 5000 5000 2000 2000 2000 2000 600
Maximum IP Phones per Server

7500 2500 2500 2500 1000 1000 1000 1000 300
CIPT1 v1.41-15
The table here details the Cisco MCS platform capabilities of Cisco IP Phones and device weight units. You can easily calculate the number of Cisco IP Phones that are registered to a Cisco MCS platform. However, to account for all of the devices that are going to register to a Cisco MCS platform, you can use the device weight units from the previous table and compare them to the maximum number of device weight units that are supported by the Cisco MCS platform indicated.
Example: Device Weights

A given network has a BHCA of 16 and an MCS 7845. The MCS 7845 supports 10,000 device weights as shown in the figure. If 1000 IP Phones (SCCP client) each consuming three device weights are registered to the MCS 7845 (3000 device weights total), the MCS has 7,000 device weights remaining to support other devices.
1-17
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 IP Communications solution components consist of the Contact Center, CallManager Express, IP Conferencing, IP Telephony, IP Video Telephony, and Unified Communications. Cisco IP telephony solution components consist of Cisco CallManager, endpoints, infrastructure, and voice application software. Cisco CallManager functions include call processing, signaling and device control, dial plan administration, phone feature administration, directory services, and a programming interface.
Summary (Cont.)
Unlike legacy PBX technologies, IP technologies distribute line connections, call processing, switching, and trunk connections to network equipment in a decentralized design. Cisco CallManager server requirements include Windows 2000, Microsoft SQL Server 2000, DC-Directory for an LDAP directory of end users, and the STI backup utility. Cisco CallManager hardware requirements include the Cisco MCSs, which have been designed specifically for Cisco voice applications by HP and IBM. In order to design the network, determine the busiest hour of the day, then scale the device type you will deploy with the Cisco IP telephony solution.
CIPT1 v1.41-17
1-18
References
For additional information, refer to these resources: Cisco CallManager documentation: http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/index.htm Cisco 7800 Series Media Convergence Servers: http://www.cisco.com/en/US/partner/products/hw/voiceapp/ps378/index.html
1-19
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) What is the maximum number of Cisco IP Phones that can be added to a Cisco MCS 7835 if 3000 device weight units are already registered, and the BHCA is less than 6? A) B) C) D) Q2) 1000 1500 2000 2500
Which two of these items represent an advantage that IP telephony has over PBX technology? (Choose two.) A) B) C) D) distributed design standards-based fewer devices all components in a single device interactive voice response signaling control device control dial plan voice messaging
Q3)
Which two of these are NOT functions of Cisco CallManager? (Choose two.) A) B) C) D) E)
Q4)
Voice software, infrastructure, end points, and Cisco CallManager make up which of the following? A) B) C) D) E) Cisco AVVID layers Cisco IP telephony solution components Cisco IP Communications components client layer of Cisco AVVID CallManager functions
Q5)
A hot-swappable hard drive is a high-availability feature starting with which MCS series? A) B) C) D) Cisco MCS 7815 Cisco MCS 7825 Cisco MCS 7835 Cisco MCS 7845 Linux Windows 95 Windows NT Windows 2000
Q6)
Cisco CallManager uses which of these operating systems? A) B) C) D)
1-20
Q7)
A branch office that wants a Cisco IOS software-based IP telephony solution and has no quality of service WAN connectivity to headquarters might choose which of the following? A) B) C) D) E) CallManager Express Contact Center Unified Communications IP conferencing IP telephony client applications call-processing infrastructure
Q8)
Which layer of Cisco AVVID contains Cisco CallManager? A) B) C) D)
1-21
Quiz Answer Key

Q1) C Relates to: Device Weight Units Q2) A, B Relates to: Comparing Legacy and IP Telephony Technology Q3) A, E Relates to: Cisco CallManager Functions Q4) B Relates to: Cisco IP Telephony Components Q5) C Relates to: Supported Cisco CallManager Hardware Q6) D Relates to: Cisco CallManager Operating System, Database, and Supporting Applications Q7) A Relates to: Cisco IP Telephony Components Q8) C Relates to: Cisco AVVID
1-22
Identifying Cisco CallManager Cluster and Deployment Options

Overview
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.
Relevance
To ensure the same service availability as the traditional voice network, 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 best practices.
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 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 callprocessing redundancy within the cluster Identify the four supported IP telephony 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 multisite centralized callprocessing deployment model Identify the major characteristics and design guidelines of a multisite distributed callprocessing deployment model Identify the key advantages of a distributed single-cluster deployment compared to an SRST deployment

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: Windows 2000 navigation experience General knowledge of Cisco CallManager
Outline
Outline
Overview Microsoft SQL Cluster Relationship Intracluster Communication Cluster Redundancy Designs IP Telephony Deployment Models Single-Site Deployment Multisite WAN with Centralized Call Processing Multisite WAN with Distributed Call Processing Single-Cluster Distributed Call Processing Summary Quiz
1-24
Microsoft SQL Cluster Relationship

This topic describes how the Microsoft SQL cluster relationship provides database redundancy and failover capability.
Microsoft SQL Cluster Relationship

Two or more servers share a database and support a common group of IP devices. Clustering provides redundancy for the SQL database. 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 the Microsoft SQL Server makes clustering possible by allowing the same database to be on multiple machines. Database replication makes it appear that call processing and other functions are being handled by a single machine 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 (Microsoft SQL restriction). When you make changes to the Cisco CallManager configuration, these changes get written directly to the publisher server. The publisher then replicates these changes to the subscriber servers. When the publisher server is off line, the Microsoft SQL Server 2000 database automatically locks, and thus prevents further database changes. The IP telephony network will continue to operate, but you will not be able to add or configure any devices that are managed by Cisco CallManager.
Copyright 2004, Cisco Systems, Inc. Getting Started with 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 will 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. (A cluster might need to support fewer telephones, depending on the additional tasks that CallManager performs.) This cluster limitation does not restrict the size of the VoIP network. By creating additional clusters, you can increase the network size. Intercluster trunks allow devices to communicate between cluster boundaries.
1-26
Intracluster Communication
This topic examines the two types of intracluster communication.
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 CallManagers 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 CallManagers 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 in memory to the primary server every 30 sec 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).
Copyright 2004, Cisco Systems, Inc. Getting Started with Cisco CallManager 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 Publisher and TFTP Server (Not Req. <1000) Primary 1 to 2500 Backup
High availability (upgrade) Increased server count Simplified configuration

5000 IP Phones (10,000 Device Units)
Cisco MCS 7835 Publisher and TFTP Server
10,000 IP Phones (20,000 Device Units)

Backups
1 to 2500 2501 to 5000
Backups
1 to 2500 2501 to 5000 5001 to 7500 7501 to 10,000
Backups
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 considerable network and processor load. In this example, a Cisco MCS 7835 is used because each Cisco CallManager server 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 Publisher and TFTP Server (Not Req. <1000) Primary 1 to 2500 Backup
Cost-efficient redundancy Service impacted during upgrade

5000 IP Phones (10,000 Device Units)
10,000 IP Phones (20,000 Device Units)

Backup
1 to 2500 2501 to 5000
Backup
1 to 2500 2501 to 5000 5001 to 7500 7501 to 10,000
Backup
CIPT1 v4.11-6
In a 2:1 Cisco CallManager redundancy deployment design, you have a dedicated backup server for every two primary servers. While 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
IP Telephony Deployment Models

This topic lists the deployment models that Cisco IP telephony supports.
Deployment Models
Applications Cisco CallManager Cluster Cisco CallManager Cluster Applications
PSTN
GK
IP WAN
Cisco CallManager Cluster
Branch A
Gatekeeper
Headquarters
Single-site deployment Multisite WAN with centralized call processing Multisite WAN with distributed call processing Single-cluster with distributed call processing
Applications
Branch B
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 call-processing 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 Single-cluster with distributed call processing
1-30
Single-Site Deployment
This topic describes the single-site deployment model.
Single Site: Overview
Cisco CallManagers, 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
PSTN
CIPT1 v4.11-8
In a single-site deployment model, all Cisco CallManagers, applications, and DSP resources are in the same physical location. You can implement multiple clusters, and interconnect them via intercluster trunks, if you need to deploy more IP Phones in a single-site configuration. Gateway trunks that connect directly to the 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. Use the device weight guidelines; do not oversubscribe the Cisco CallManager and clustering capability.
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 guidelines exist 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, and many voice-mail systems support only G.711. You can allocate these DSP resources to other functions, such as conferencing and Media Termination Point (MTP). While the bandwidth that G.711 consumes is higher than with all other codecs, this is not a concern in this design because the call is not traversing the WAN. 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. Use the device weight guidelines to provision resources on Cisco CallManager. Do not oversubscribe Cisco CallManager to scale larger installations.
1-32
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 SRST-Enabled Router
PSTN
IP WAN
Headquarters
Cisco CallManager at central site; applications and DSP resources are 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 A
Branch B
CIPT1 v4.11-10
The figure shown here 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. 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 deteriorating 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-33
You can provide PSTN access for the voice network through a variety of Cisco gateways. When the IP WAN is down, or when network traffic uses all of the available bandwidth on the IP WAN, the users at remote branches can dial the PSTN access code and place their calls through the PSTN. 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. Even if the branch offices lose their connections to the central Cisco CallManager cluster, you can provide call processing with the survivable remote site telephony (SRST) feature that is available for Cisco IOS gateways.
1-34
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 hub and spoke topologies because the locations-based call admission control mechanism 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 survivable remote capability that is provided by the SRST feature in the branch router limits remote branches to 480 Cisco IP Phones on a Cisco 7200 router during failover.
Note 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

Applications Cisco CallManager Cluster Cisco CallManager Cluster
Applications
PSTN
Branch A
Cisco CallManager Cluster Applications
GK
IP WAN
Gatekeeper
Headquarters
Cisco CallManager and applications located at each site IP WAN does not carry call control signaling 100+ sites Transparent use of the PSTN if the IP WAN is unavailable
Branch B
CIPT1 v4.11-12
The multisite distributed call-processing deployment model 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 other 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: 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 No loss of functionality during an IP WAN failure Scalability to hundreds of sites
1-37
Multisite Distributed Call Processing: Design Guidelines

Cisco currently recommends use of Hot Standby Router Protocol (HSRP) gatekeeper pairs. Cisco recommends use of a single WAN codec. Gatekeeper networks scale to hundreds of sites.
CIPT1 v4.11-13
The multisite WAN with distributed call-processing deployment models is a superset of the single-site and multisite WAN with centralized call-processing models. You should follow the best practices from the single site and multisite guidelines in addition to those listed here, which are specific to this deployment model. The key element is the gatekeeper device. This H.323 device serves two main functions: call admission control and E.164 dial plan resolution. Additional gatekeeper guidelines include the following: Cisco recommends using alternate gatekeeper support to provide a gatekeeper solution with high availability. Cisco also recommends using multiple gatekeepers to provide spatial redundancy within the network. Cisco recommends using 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. Gatekeeper networks scale to hundreds of sites, and are not limited to hub and spoke topologies.
1-38
Single-Cluster Distributed Call Processing

This topic examines single-cluster distributed call-processing design.
Single-Cluster Distributed Call Processing: Overview
Cisco CallManager Cluster Voice-Mail Server Voice-Mail Server IP Phones
IP Phones
Los Angeles
San Diego
CIPT1 v4.11-14
Cisco supports Cisco CallManager clusters over a WAN. While there are stringent requirements, this design offers the advantage of a unified dial plan and extends all features to all offices in the IP telephony network. 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 the remote offices to support more Cisco IP Phones than SRST, in the event that the connection to the primary Cisco CallManager is lost. Because all Cisco CallManagers are part of the same cluster, you also benefit from a single point of administration.
1-39
Single-Cluster Distributed Call Processing: Design Guidelines
Publisher/ TFTP
<40 ms Round-Trip Delay
QoS-Enabled Bandwidth
40-ms round-trip delay between any two Cisco CallManagers 900 kbps for every 10,000 BHCAs within the cluster Four active locations maximum (four active Cisco CallManagers) Failover across WAN supported (more bandwidth)
While the distributed single-cluster call-processing model offers some significant advantages, it must adhere to these strict design guidelines: Two Cisco CallManagers 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 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 busy hour call attempts (BHCAs) within the cluster, you must support an additional 900 kbps of WAN bandwidth for intracluster run-time communication. The distributed single-cluster design supports a maximum of four primary Cisco CallManagers. This number correlates directly to the maximum number of supported locations. 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. Two types of intracluster communications ensure that the Microsoft SQL Server 2000 database is synchronized: database replication and run-time data. Available design configurations to ensure call-processing redundancy are 1:1 and 2:1. The deployment models that are supported by Cisco IP telephony are single-site, multisite with centralized call processing or distributed call processing, and single-cluster with distributed call processing.
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 a single-cluster distributed call-processing model include a unified dial plan, a feature extension to all offices, more IP Phones, and central administration.
CIPT1 v4.11-17
1-41
References
For additional information, refer to these resources: Cisco CallManager documentation: http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/index.htm Cisco IP Telephony Solution Reference Network Design: http://www.cisco.com/en/US/netsol/ns340/ns394/ns165/ns268/networking_solutions_desig n_guidances_list.html
1-42
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) Which of the following is NOT an IP telephony deployment model that is supported by Cisco? A) B) C) D) E) Q2) A) B) C) D) Q3) 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 local failover database replication at least two servers directory access
Which three of the following enable the cluster to achieve redundancy? (Choose three.)
A single cluster that spans multiple sites can have which two benefits compared to a branch office that relies on SRST during failover? (Choose two.) A) B) C) D) E) 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 increased redundancy; the increased server cost is often prohibitive some redundancy; a server reboot is required after an upgrade maximum uptime; no more than a 20-ms round-trip delay can exist between servers high availability; you may overwhelm the backup servers
Q4)
A 1:1 redundancy design offers _________; however, ________. A) B) C) D)
Q5)
Which protocol does an IP Phone use to send periodic messages to determine if its primary Cisco CallManager server is still operational? A) B) C) D) E) RTP Skinny TCP SQL H.323
Q6)
What is the recommended best practice regarding WAN codecs in a distributed callprocessing deployment? A) B) C) D) G.711 only G.729 and G.723 a single codec for the WAN multiple codecs between the sites
1-43
Q7)
Which codec is most often used in a single-site deployment? A) B) C) D) G.729 G.723 GSM G.711
Q8)
What is the maximum number of IP Phones that the Cisco 7200 router can support at a remote branch location during a loss of connectivity to Cisco CallManager headquarters in a centralized deployment model? A) B) C) D) 280 480 580 680
1-44
Quiz Answer Key

Q1) E Relates to: IP Telephony Deployment Models Q2) A, B, C Relates to: Microsoft SQL Cluster Relationship Q3) C, D Relates to: Single-Cluster Distributed Call Processing Q4) A Relates to: Cluster Redundancy Designs Q5) C Relates to: Intracluster Communication Q6) C Relates to: Multisite WAN with Distributed Call Processing Q7) D Relates to: Single-Site Deployment Q8) B Relates to: Multisite WAN with Centralized Call Processing
1-45
1-46
Installing Cisco CallManager

Overview
Cisco CallManager includes the Windows 2000 operating system and the Microsoft Structured Query Language (SQL) Server 2000 relational database management system. This lesson will teach you how to install Cisco CallManager on the Cisco Media Convergence Server (MCS), which is shipped with a blank hard drive. Although the Cisco CallManager installation process is fully automated and image-based, you will learn key configuration points to consider before, during, and after the installation process.
Relevance
You must be able to install Cisco CallManager to build a working Cisco IP telephony network. This lesson covers the installation process in a step-by-step format.
Objectives
Upon completing this lesson, you will be able to perform a complete Cisco CallManager 4.0 installation following the procedures specified in the Installing Cisco CallManager Release 4.0(1) documentation. This includes being able to meet these objectives: Identify the correct Cisco CallManager CDs that are required for installation Identify all configuration data that is required to install Cisco CallManager software Activate all necessary Cisco CallManager services Perform postinstallation procedures to secure the server and optimize server resources Identify the major steps in the correct order to upgrade prior versions of Cisco CallManager to version 4.0

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: Basic working knowledge of a computer and experience installing software onto a PC Basic understanding of network connectivity Understanding of Cisco CallManager cluster design options
Outline
Outline
Overview Installation CD-ROMs Installation Configuration Data Activating Cisco CallManager Services Postinstallation Procedures Upgrading Prior Cisco CallManager Versions Summary Quiz
CIPT1 v1.41-2
1-48
Installation CD-ROMs
This topic identifies the installation CD-ROMs that you must use to install a Cisco CallManager server.
Installation CD-ROMs
CD-ROMs essential for Cisco CallManager installation:

Hardware Detection CD-ROM Operating System Installation and Recovery CD-ROMs Cisco CallManager 4.0 Software CD-ROMs
CIPT1 v1.41-3
Cisco CallManager is installed on the Cisco Media Convergence Server (MCS), a highavailability server platform. When you receive the Cisco CallManager 4.0 software, you will use a number of CD-ROMs to perform a server installation. Because the installation of a Cisco CallManager server is image-based, after you boot the server using the Hardware Detection CD-ROM, the automated installation process should prompt you for the correct CD-ROMs to use. At a minimum, you will need the following CD-ROMs to perform a new Cisco CallManager installation: Cisco IP Telephony Server Operating System Hardware Detection CD-ROM Cisco IP Telephony Server Operating System Installation and Recovery CD-ROMs Disk 1 and 2 (or DVD) Cisco CallManager 4.0 Software CD-ROMs
1-49
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 Cisco product key Username and organization name Computer name Workgroup Domain suffix
TCP/IP properties Domain Name System Database server Password for system administrator
CIPT1 v1.41-4
As you perform the Cisco CallManager installation, the automated setup process will prompt you for the information that is necessary to build Windows 2000, Microsoft SQL Server 2000, and Cisco CallManager 4.0 with a base configuration. This automated setup process takes between 30 and 45 minutes, depending on your server type. The process erases all data on the server hard disk. Before proceeding with the installation, you should have the following information available: 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 letters 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-50
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 alpha 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. 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 Cisco strongly recommends 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. If you choose to use DHCP, the Cisco Technical Assistance Center (TAC) requires that you reserve an IP address for each Cisco CallManager server in the DHCP server scope. This action prevents the release, or reassignment, of IP addresses. If you do not reserve IP addresses through the DHCP server scope, the DHCP server may assign a different address to the Cisco CallManager server when the server is disconnected from, and then reconnected to, the network. You would then have to reprogram the IP addresses of the other devices on the network to return the Cisco CallManager server to its original IP address.
DNS: You must identify a primary DNS server for this optional field. By default, the telephones will attempt to connect to Cisco CallManager using the DNS. Therefore, you must verify that the DNS contains a mapping of the IP address and the fully qualified domain name of the Cisco CallManager server. If you do not use the 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.
1-51
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 a 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 host name 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.
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 are able to 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 Release 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-52
Configuration Data for Cisco MCS

Configuration 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 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 Cisco recommends that you program a fixed IP address in TCP/IP properties for the server instead of using DHCP. Data
1-53
Activating Cisco CallManager Services

This topic explains the process of selecting and activating the 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
CIPT1 v1.41-5
When you complete the initial installation of Cisco CallManager on a given server, you must activate the required Cisco CallManager service components. All components are in the deactivated default state. Cisco recommends that you activate only the required components for each server in the cluster. Each component that you activate adds load to the server. 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. 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 MTP, a conference bridge, an MOH server, and an annunciator. Cisco CTIManager: Allows Cisco CallManager to support computer telephony integration (CTI) services and provides TAPI or Java Telephony Application Programming Interface (JTAPI) client support. Cisco CTIManager allows you to use applications such as Cisco IP SoftPhone.
1-54
Cisco Telephony Call Dispatcher: Distributes calls to multiple telephone numbers (hunt groups). Cisco WebAttendant and Auto Attendant require Telephony Call Dispatcher. 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 a Simple Network Management Protocol (SNMP) server. Cisco Database Layer Monitor: Monitors aspects of the Microsoft SQL 2000 database, as well as 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 Extension Mobility: Allows Cisco CallManager to support extension mobility functions for roaming users.
1-55
Cisco CallManager Service Activation
CIPT1 v1.41-6
You can activate the Cisco CallManager services on the Service Activation page. To activate these services, perform 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. From the Application menu, choose Cisco CallManager Serviceability. The CallManager Serviceability interface appears. From the Tools menu, choose Service Activation. A window similar to the window shown here appears. 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.
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.
Step 2
Step 3
Step 4
Caution
1-56
Postinstallation Procedures
This topic examines the tasks that Cisco recommends that you perform after installing Cisco CallManager.
Postinstallation Procedures
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, Smartcard, Smartcard Helper, Computer Browser, Distributed File System, License Logging Service Subscribers: IIS Admin Service, World Wide Web Publishing Service
Set administrator access levels

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 will gain additional resources that you can allocate to mission-critical Cisco CallManager processes. In addition, some Windows 2000 services can open security holes on Cisco CallManager. You should stop these services to prevent potential intruders from finding server vulnerabilities.
1-57
You should stop all of the following services and set them to manual-start status, unless otherwise needed on the system: DHCP Client Fax Service (CallManager 3.2 and below) FTP Publishing Service Smartcard (CallManager 3.2 and below) Smartcard Helper (CallManager 3.2 and below) Computer Browser (CallManager 3.2 and below) Distributed File System License Logging Service In addition to the services listed here, you should stop and set the following services to manual on the subscriber servers: Internet Information Server (IIS) Admin Service 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 set the startup type, stop the service, and click Apply. After you have performed these tasks, and Cisco CallManager is operational, run the Cisco MCS backup utility to back up your Cisco CallManager data.
1-58
Multilevel Administration Overview

Full Access
Functional groups User groups Three access levels Login authentication to LDAP CCMAdministrator superuser
No Access Read-Only Access
CIPT1 v1.41-8
Multilevel administration (MLA) access provides multiple levels of security to Cisco CallManager Administration. This technique permits granting only the required privileges for a selected group of users and limits the configuration functions that users in a particular user group can perform. CallManager administration functions are grouped into functional groups. Functional groups consist of groups of Cisco CallManager Administration pages. Typically, each major menu item of Cisco CallManager Administration makes up a standard (default) functional group. You can also create custom functional groups. CallManager administrators are grouped into user groups. User groups consist of lists of directory users. A user may belong to multiple user groups. After you add a user group, you then add users to the group. Standard user groups are created during Cisco CallManager installation; you can also create custom user groups. Three levels of access exist. These differ as follows: A user with full access can view and modify the Cisco CallManager Administration pages that belong to the functional groups to which the user group of the user has full access. A user with read-only access can view the Cisco CallManager Administration pages that belong to the functional groups to which the user group of the user has read-only access. A user with read-only access cannot make any changes on the administration pages. Cisco CallManager grays out all buttons and disables icons that modify Cisco CallManager configuration information. A user with no access can neither view nor change the Cisco CallManager Administration pages that belong to the functional groups to which the user group of the user has no access.
1-59
Before MLA, Cisco CallManager administrators logged in using a local NT administration account. With MLA, directory user names and passwords that are stored in LDAP provide the basis for login authentication. MLA creates a predefined superuser called the CCMAdministrator.
1-60
Multilevel Administration Configuration
Configure MLA Parameters
CIPT1 v1.41-9
To enable MLA, follow these steps:

Step 1
Browse to CallManager Administration and Cisco CallManager Serviceability with the following URL: http://<CCMServer IP Address>/ccmadmin Choose User > Access Rights > Configure MLA Parameters. The MLA Enterprise Parameter Configuration page displays.
Step 2
Step 3 Step 4
Change the Enable MultiLevelAdmin drop-down list box to True. Click Update. A message informs you that you must restart the web server in all Cisco CallManager systems in the cluster for the change to take effect.
If MLA is enabled, log in the very first time as CCMAdministrator and follow these steps:
Step 1 Step 2 Step 3 Step 4
Set up functional groups or use standard functional groups. Set up user groups or use standard user groups. Add users to user groups. Assign privileges to user groups for functional groups.
1-61
Upgrading Prior Cisco CallManager Versions

This topic describes the upgrade process for a Cisco CallManager server.
Upgrading to Cisco CallManager 4.0

3.2(c) 3.2(3) 3.3(2) 3.3(3) 2.4 3.1 3.2 or 3.3
4.0(1)
4.0(1)
Cisco supports the upgrade of the publisher database server to Cisco CallManager Release 4.0(1), a full version of Cisco CallManager, from Cisco CallManager Releases 3.2(c), 3.2(3), 3.3(2), and 3.3(3).
Tip To verify whether other versions of Cisco CallManager are compatible for upgrade to this release, refer to the Cisco CallManager Compatibility Matrix at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/index.htm.
If your server runs Cisco CallManager Release 2.4 or 3.1, you must upgrade every server in the cluster to the latest version of Cisco CallManager Release 3.2 or 3.3 before you can upgrade to a version of Cisco CallManager Release 4.0. Cisco requires that you install Cisco IP Telephony Server Operating System version 2000.2.5 (provided by Cisco) with service release 2 (2000.2.5sr2) (or later) before you upgrade to Cisco CallManager Release 4.0(1).
Note The upgrade of the publisher server can take from two to four hours, depending on your server type and the amount of Cisco CallManager data that you need to back up.
1-62
Upgrading the Cisco CallManager Publisher Server
Publisher database server upgrade requires system software reimage. System backup is required to preserve critical data.
Cisco CallManager 3.3 Publisher Cisco CallManager 4.0 Publisher
Ensure all MCS server hardware is in original configuration. Remove server from domain before the upgrade occurs.
CIPT1 v1.41-11
Cisco requires a reimage of the publisher database server during the Cisco CallManager Release 3.3(2) upgrade. Because this process erases all data on your server, you will need to back up all critical data. Cisco strongly recommends that you use the supported Cisco Backup and Restore System (BARS) utility if you are running Cisco CallManager 3.3 or later. If you are using an earlier version of Cisco CallManager, use the Cisco IP Telephony Applications Backup Utility (3.5). Before you perform an upgrade to Cisco CallManager 4.0(1), run the Cisco CallManager Upgrade Assistant Utility, a nonintrusive tool that detects the health of the servers in the Cisco CallManager cluster without changing the state of the system. The Cisco CallManager Upgrade Assistant Utility version corresponds to the Cisco CallManager version to which you plan to upgrade the server. Use Cisco CallManager Upgrade Assistant Utility Version 4.0(1) if you plan to upgrade to Cisco CallManager 4.0(1) from a compatible release of Cisco CallManager 3.2 or 3.3. You can obtain BARS from the web or from the CD-ROM that may ship with the supported application. To download the latest version of BARS from the web, go to http://cco/cgibin/tablebuild.pl/cmva-3des (Cisco.com login required).
Caution Before starting the upgrade, make sure that you perform the recommended backup procedures for all coresident software applications that are installed on the server. Failing to complete a backup causes data and configuration settings to be lost. For information on performing the backup, refer to the documentation that supports the applications.
1-63
Use the following steps when upgrading the Cisco CallManager publisher server:
Step 1
Remove all servers in the cluster from the NT Domain or the Microsoft Active Directory Domain. Manually disable and stop all platform agents and applications that are Ciscoverified (such as Cisco AVVID partner applications) that run on the servers in the cluster. Disabling platform agents and servicesfor example, performance monitoring (such as NetIQ), antivirus services (such as McAfee services, which are approved by Cisco), intrusion detection, and remote management servicesensures that the upgrade will be completed. Reboot the server. To review a list of Cisco-verified applications that Cisco supports and that you should disable before the installation, click http://www.cisco.com/pcgibin/ecoa/Search.
Step 2
Step 3 Step 4
Manually install and configure BARS version 4.0(1) (or later). Using BARS version 4.0(1) (or later), manually back up the Cisco CallManager data to either a network directory or tape drive. Run the Cisco CallManager Upgrade Assistant Utility on all servers in the cluster. You must perform this task on one server in the cluster at a time, beginning with the publisher database server. If the server supports drive removal, remove a drive from the server to save your data and configuration. Use the Cisco IP Telephony Server Operating System upgrade CD-ROM or the operating system upgrade web download to upgrade the operating system to version 2000.2.5 (or later) (provided by Cisco). Download and install the latest Cisco IP Telephony Server Operating System service release (2000-2-5sr2 or later) (required). Download and install the latest operating-system-related security hotfixes, if any (recommended). The operating-system-related security hotfixes post on the voice products operating system cryptographic software page at Cisco.com. Registered Cisco.com users with software download privileges can navigate to the site from the Voice Software downloads page on Cisco.com at: http://www.cisco.com/kobayashi/sw-center/sw-voice.shtml Verify that you have installed Microsoft SQL Server 2000, Service Pack 3a (or later). Upgrade the publisher server. Insert the Cisco CallManager 4.0(1) Installation, Upgrade, and Recovery Disk 1 of 2 into the drive. Follow the InstallShield Wizard prompts throughout the installation process. Upgrade the subscriber servers.
Before you install the operating system, Cisco strongly recommends that you configure the server hardware (such as mirrored hard drives) to the state of the original configuration. A nonstandard server hardware configuration causes the Cisco CallManager installation to fail and data or configuration settings from drive mirroring to be lost.
Step 5
Step 6
Step 7
Step 8
Step 9
Step 10
Step 11
Step 12
Caution
1-64
Tip
For all Cisco CallManager installation and upgrade guides, refer to the following URL (requires CCO login and password): http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/prod_installation_guides_ list.html.
1-65
Upgrading the Cisco CallManager Subscriber Server
Subscriber database server upgrade requires system software reimage. Data backup is not required unless server contains critical data. Upgrade process follows the same procedure as a new Cisco CallManager installation.
Cisco CallManager 3.3 Subscriber
Cisco CallManager 4.0 Subscriber
CIPT1 v1.41-12
Because the foundation operating system changes to support Cisco CallManager 4.0, you must also reimage the subscriber servers that are running a prior Cisco CallManager version. Because the subscriber servers do not typically contain critical data, you should not need to perform a complete server backup. If your subscriber server acts as the TFTP server, you may want to manually back up custom files, such as Cisco IP Phone firmware images or ring files, before performing the server upgrade. The installation process for the subscriber server follows the same procedure as a new installation of Cisco CallManager. After you build the server and install the Cisco CallManager software, the subscriber will receive a fresh copy of the Microsoft SQL database from the publisher.
Caution Before installing the subscriber server, ensure that the server has network connectivity to the publisher database. The Cisco CallManager installation will fail if you do not provide this connectivity.
1-66
Summary
Summary
Installing the operating system and Cisco CallManager IP telephony application requires a Hardware Detection CD-ROM, Operating System Installation and Recovery CD-ROMs, and Cisco CallManager 4.0 Software CD-ROM. You will need the following configuration data when installing a Cisco CallManager server: Cisco product key, username, organization name, computer name, workgroup, domain suffix, TCP/IP properties, DNS, backup server or target, and system administrator password. Cisco CallManager services include Cisco CallManager, Cisco TFTP, and Cisco Database Layer Monitor Service. After installation, you must activate all services that you want enabled on that server. Postinstallation procedures include changing passwords and stopping unnecessary services. Perform the following actions to upgrade 4.0: remove server from the domain, back up current Cisco CallManager data (publisher), rebuild the server, and restore the data into the new Cisco CallManager version.
CIPT1 v1.41-13
References
For additional information, refer to these resources: Cisco CallManager documentation: http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/index.htm. Cisco CallManager Compatibility Matrix: http://www.cisco.com/univercd/cc/td/doc/product/voice/c_callmg/index.htm. Cisco CallManager installation and upgrade guides (requires CCO login and password): http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/prod_installation_guide s_list.html. Cisco IP Telephony Backup and Restore System (BARS) Administration Guide, Version 4.0(2): http://www.cisco.com/univercd/cc/td/doc/product/voice/backup/bars40/barsad40/ Smith, Anne, Chris Peace, Delon Whetton, and John Alexander. Cisco CallManager Fundamentals: A Cisco AVVID Solution. San Jose, California: Cisco Press; 2001.
1-67
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) Which three of these services does Cisco recommend that you stop on a subscriber server? (Choose three.) A) B) C) D) Q2) A) B) C) D) E) Q3) A) B) C) D) Q4) FTP Publishing Service Cisco CallManager Service IIS Admin Service World Wide Web Publishing Service register IP Phones and process calls interface with a voice-mail system generate daily and on-demand reports act as a Media Termination Point write trace information to a database DHCP backup server LMHOSTS file DNS reverse lookup
What does the Cisco Messaging Service allow the Cisco CallManager to do?
If you are not using DNS, what must you configure to resolve server names?
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? A) B) C) D) E) Cisco CallManager 4.0 Software Disk Cisco IP Telephony Server Operating System Hardware Detection Disk Cisco IP Telephony Server Operating System Installation and Recovery Disk 1 Cisco IP Telephony Server Backup and Restore Disk Cisco Extended Services Disk
Q5)
What is the recommended order of these steps to upgrade the Cisco CallManager publisher server to 4.0? A) B) C) D) E) back up the CallManager server data remove the server from the NT domain upgrade the operating system to the latest version install Cisco CallManager software disable all platform agents and services on the server
1-68
Quiz Answer Key

Q1) A, C, D Relates to: Postinstallation Procedures Q2) B Relates to: Activating Cisco CallManager Services Q3) C Relates to: Installation Configuration Data Q4) B Relates to: Installation CD-ROMs Q5) B, E, A, C, D Relates to: Upgrading Prior Cisco CallManager Versions
1-69
1-70
Module 2

Overview
Numerous components and considerations are involved before you can place Cisco IP Phone calls within the same cluster. This module discusses how to configure the Cisco Catalyst switch to power Cisco IP Phones and support voice traffic, and the various Cisco IP Phone models that you may encounter when administering a Cisco IP telephony network. This module also discusses how to configure Cisco CallManager to add and configure IP Phones and users, and how to use Cisco CallManager tools to bulk-add and auto-register users and devices.
Module Objectives
Upon completing this module, you will be able to configure Cisco CallManager and the Catalyst switch to enable phone calls between Cisco IP Phones that are located within the same Cisco CallManager cluster.
Module Objectives
Distinguish between the various Cisco IP Phone models and how they work within a Cisco IP telephony solution Configure Cisco CallManager to support IP Phones to include server configuration, device pools, phone button templates, and directory numbers Configure a Catalyst switch port to receive voice and data traffic on different VLANs and apply a CoS to incoming frames Add users, associate devices to users, and use the Cisco CallManager User Option pages to customize IP Phones Use BAT and TAPS to bulk-add and auto-register IP phones, users, and ports to an IP telephony network
CIPT1 v4.12-2
Module Outline
The outline lists the components of this module.
Module Outline
Lesson 2-1: Introducing Cisco IP Phones Lesson 2-2: Configuring Cisco CallManager to Support IP Phones Lesson 2-3: Configuring Cisco Catalyst Switches Lesson 2-4: Adding Users and Customizing User Options Lesson 2-5: Using the Bulk Administration Tool
CIPT1 v4.12-3
2-2
Introducing Cisco IP Phones

Overview
This lesson will teach you 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, and the advantages and disadvantages of each.
Relevance
You should be able to distinguish between the various Cisco IP telephony end-user devices that you may encounter during the course of administering a Cisco IP telephony network. In addition, understanding the bootup and registration communication between a Cisco IP Phone and Cisco CallManager is important for understanding normal voice network operations, and for troubleshooting purposes.
Objectives
Upon completing this lesson, you will be able to distinguish between the various Cisco IP Phone models and describe how they work within a Cisco IP telephony solution. This includes being able to meet these objectives: Describe the four features that the majority of Cisco IP Phones have in common 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 VoIP devices, 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 Identify the two H.323 audio codecs that are supported by Cisco IP Phones

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: An understanding of how network devices obtain subnet and IP addressing information An understanding of the relationship between servers in a Cisco CallManager cluster
Outline
Outline
Overview Cisco IP Phone Overview Entry-Level Cisco IP Phones Midrange and Upper-End Cisco IP Phones Additional Cisco VoIP Devices IP Phone Startup Process Cisco IP Phone Codec Support Summary Quiz
CIPT1 v4.12-2
2-4
Cisco IP Phone Overview

This topic provides an overview of Cisco IP Phones and the features that are common to the majority of Cisco Voice over IP (VoIP) end-user devices.
Cisco IP Phone Overview
The majority of Cisco IP Phones have the following enhancements:

Display-based Straightforward user customization Inline power 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 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-5
Entry-Level Cisco IP Phones

This topic describes the entry-level Cisco IP Phones that are available and provides a brief overview of their features.
Entry-Level Cisco IP Phones

Cisco IP Phone 7902G Cisco IP Phone 7905G Cisco IP Phone 7910G+SW Cisco IP Phone 7912G
Basic featured IP Phones for low to medium telephone use Single line / directory number (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 (except Cisco 7902G) user interface G.711 and G.729a codec Single line (directory number [DN]) Cisco inline power, powered patch panel, or local power option support (via CP-PWRCUBE [same power supply as the Cisco 7910, 7940, or 7960]) Visual message waiting indicator (MWI) No speakerphone or headset port
2-6
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, entrylevel, nodisplay 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 Ethernet switch)
Cisco IP Phone 7905G and Cisco 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 Cisco 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: 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
2-7
Midrange and Upper-End Cisco IP Phones

This topic describes the midrange and upper-end Cisco IP Phones and their features.
Midrange and Upper-End Cisco IP Phones

Cisco IP Phone 7940 Cisco IP Phone 7960 Cisco IP Phone 7970
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)
Cisco designed the IP Phones 7940, 7960, and 7970 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 speakerphone 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 through software upgrade XML service support An EIA/TIA-232 port for options, such as line expansion and security access
2-8
Additional details of the Cisco IP Phone 7940, 7960, and 7970 follow: Cisco IP Phone 7940: The Cisco IP Phone 7940 is for medium traffic and has these features: Ideal for transaction workers who use cubicle phones Two lines or feature buttons, and four interactive softkeys
Cisco IP Phone 7960: The Cisco IP Phone 7960 is for high or busy telephone traffic and has these features Ideal for professionals or managers Six programmable line or feature buttons, and four interactive softkeys Ideal for executives, decision makers, and environments with no PCs Eight lines or 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 Inline power-compatible (both Cisco prestandard and IEEE 802.3af powercompatible) Advanced XML development platform for more dynamic applications
Cisco IP Phone 7970:
2-9
Additional Cisco VoIP Devices

This topic describes the features and benefits of additional Cisco VoIP devices.
Additional Cisco VoIP Devices
Cisco VT Advantage
Cisco Conference Station 7936
Cisco IP SoftPhone and Cisco IP Communicator
Cisco ATA 186 and 188

Cisco 7914 Expansion Module
Cisco Wireless IP Phone 7920

CIPT1 v4.12-6
Cisco continues to create additional IP telephony devices to meet the needs of businesses. 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 now 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 like 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-sized conference rooms. The Cisco IP Conference Station 7936 offers several improvements over the existing Cisco IP Conference Station 7935: external microphone ports, optional external microphone kit, newly audio-tuned speaker grill, and new backlit LCD display. The optional microphone kit includes two microphones with 6foot (1.8288-m) cords so you can place the microphones across a 12-foot (3.6576-m) area, effectively expanding 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-10
Cisco IP SoftPhone: The Cisco IP SoftPhone is a Windows-based application for the PC. Cisco IP SoftPhones allow you to integrate a software-based telephone with the IP telephony network. You can use a headset with an attached microphone to communicate. Some manufacturers are currently producing USB-based handsets that are compatible with Cisco IP SoftPhones. Cisco IP SoftPhones integrate with Microsoft NetMeeting and Lightweight Directory Access Protocol (LDAP) directories, which provide videoconferencing capabilities and the ability to drag and drop usernames from an LDAP directory list to dial or create larger conference calls. You can use the Cisco IP SoftPhone as a standalone telephone or to control an existing IP Phone, such as the Cisco IP Phone 7960. Cisco IP Communicator: The Cisco IP Communicator is a software-based 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 line and five softkeys. Cisco IP Communicator offers handset, headset, and high-quality speakerphone modes. The major differences between the Cisco IP Communicator and Cisco IP SoftPhone are that the Cisco IP Communicator has support for multiple lines or DNs, provides call control features such as shared lines, park, pickup, and Meet-Me conference, and also provides a date and time display and support for SCCP. 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 that allows you to colocate a network device with the legacy voice equipment. The ATA 188 provides two voice ports and two 10/100 Mbps Ethernet connections. 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. 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 wireless fidelity (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-11
IP Phone Startup Process

This topic describes the process that a Cisco IP Phone uses to boot up and register with the Cisco CallManager.
IP Phone Startup Process

DHCP CCM YEILD Cisco TFTP
6 4 1 3 5
1. Cisco prestandard PoE switch sends FLP 2. Phone loads stored image 3. Switch provides VLAN information to IP Phone 4. Phone sends DHCP request; receives IP information and TFTP server address 5. IP Phone gets configuration from TFTP server 6. IP Phone registers with Cisco CallManager server
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: If you are using a Cisco switch that is capable of providing Cisco inline power, the switch will send a Fast Link Pulse (FLP) signal. The switch uses the FLP to determine if the attached device is an unpowered Cisco IP Phone. In the unpowered state, a Cisco IP Phone loops back the FLP, signaling the switch to send -48 V DC power down the line. 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 VLAN: After the IP Phone receives power and boots up, 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 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-12
5. Contact 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 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 format configuration file; otherwise, it requests a .cnf file. 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. 6. Register with Cisco CallManager: After obtaining the file from the TFTP server, the phone attempts to make a TCP connection to the highest-priority Cisco CallManager on the list.
2-13
Cisco IP Phone Codec Support

This topic describes the codecs that are supported by most Cisco IP Phones.
Cisco IP Phone Codec Support
Audio codecs:
Part of the H.323 protocol suite Potentially able to compress audio signals
Cisco IP Phones support:

G.711: 64 kbps G.729a: 8 kbps
CIPT1 v4.12-8
Before a VoIP device is able to stream audio, the device must convert audio into a digitized generic format. For this purpose, the H.323 standards committee created multiple audio codecs. These codecs function at the presentation layer of the Open Systems Interconnection (OSI) model. Their primary function is to convert voice signals into a generic standard that any H.323-compatible device can understand. 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 H.323 protocol suite defines the following audio codecs: G.711: Audio codec using 56 or 64 kbps for transmission G.722: Audio codec using 48, 56, or 64 kbps for transmission G.723: Speech codec using 5.3 or 6.4 kbps for transmission G.728: Speech codec using 16 kbps for transmission G.729: Speech codec using 8 or 13 kbps for transmission All H.323-compliant devices must support, at a minimum, the G.711 audio codec. Cisco IP Phones natively support two primary codecs: G.711 and G.729a. While transcoding enables conversion between other codecs, Cisco recommends that you design your VoIP network around these two codecs.
2-14
The G.711 and G.729a codecs deliver relatively equal sound quality, with the G.711 scoring slightly higher than G.729a in a mean opinion score (MOS) test. Because of this equality, some network administrators choose to operate an entirely G.729a native network. Others choose to implement G.729a over the WAN and keep G.711 on the LAN.
Note The G.729a (G.729 Annex A) codec is a derivative of the original G.729 codec. While they are compatible, G.729a provides simpler algorithmic calculations.
While 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 H.323 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.
Note Some first-generation Cisco IP Phones, such as the 12SP+ and 30VIP, support the G.723 codec rather than G.729a. These IP Phones are no longer in production.
2-15
Summary
Summary
Cisco VoIP end-user devices are display-based, have straightforward user customization, have inline power, and provide support for the G.711 and G.729a 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 7940, 7960, and 7970.
CIPT1 v4.12-9
Summary (Cont.)
Additional IP telephony devices include the Cisco Conference Station 7936, Cisco IP SoftPhone, 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 voice signals into an H.323compatible stream and compress the output to save bandwidth. Cisco IP Phones support the G.711 and G.729a codecs.
CIPT1 v4.12-10
2-16
References
For additional information, refer to these resources: 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 IP Phones and Services documentation: http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/index.htm
2-17
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) Which two features do the majority of Cisco IP Phones support? (Choose two.) A) B) C) D) E) Q2) G.711 and G.729 802.3af a display multiple lines multiprotocol capability
Place these steps in the order that an IP Phone must go through before it can register with Cisco CallManager. A) B) C) D) obtain -48 V DC power get configuration from TFTP server load firmware image obtain VLAN information
Q3)
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 into the VoIP network. Which device would you recommend? A) B) C) D) E) Cisco Conference Station 7936 Cisco IP SoftPhone Cisco ATA 188 Cisco 7905G Cisco 7914 Expansion Module
Q4)
A company is deploying a VoIP network for its call center of 120 employees. The call center employees require a Cisco IP Phone that is capable of supporting two directory numbers. In addition, the network administrator would like to run a single cable for the IP Phone and the computer that are colocated in each employee cubicle. Which IP Phone will meet this requirement for the least expense? A) B) C) D) E) Cisco IP Phone 7902G Cisco IP Phone 7905G Cisco IP Phone 7910G+SW Cisco IP Phone 7940 Cisco IP Phone 7960
Q5)
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? A) B) C) D) Cisco IP Phone 7902G Cisco IP Phone 7905G Cisco IP Phone 7910G+SW Cisco IP Phone 7912G
2-18
Q6)
Which of the following H.323 codecs do most Cisco end-user devices support? A) B) C) D) G.711 G.723 G.711 and G.723 G.711 and G.729a
2-19
Quiz Answer Key

Q1) A, C Relates to: Cisco IP Phone Overview Q2) A, C, D, B Relates to: IP Phone Startup Process Q3) C Relates to: Additional Cisco VoIP Devices Q4) D Relates to: Midrange and Upper-End Cisco IP Phones Q5) A Relates to: Entry-Level Cisco IP Phones Q6) D Relates to: Cisco IP Phone Codec Support
2-20
Configuring Cisco CallManager to Support IP Phones

Overview
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 number (DNs). You will 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.
Relevance
Configuring Cisco CallManager to support Cisco IP Phones is a necessary part of implementing a Cisco IP telephony network. This lesson prepares you for the initial IP Phone setup and configuration, and the maintenance of existing IP Phones.
Objectives
Upon completing this lesson, you will be able to configure Cisco CallManager to support Cisco IP Phones to include server configuration, device pools, phone button templates, and DNs. This includes being able to meet these objectives: Configure Cisco CallManager to eliminate IP Phone reliance on the Domain Name System Configure device pools in Cisco CallManager to define sets of common characteristics for IP Phones before adding them to the network Use Cisco CallManager default IP 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 DNs to new IP Phones

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: An understanding of the Cisco IP Phone registration process An understanding of the relationship between Cisco CallManager clusters and device registration
Outline
Outline
Overview Server Configuration Configuring Device Pools IP Phone Button Templates Manual IP Phone and Directory Number Configuration Configuring IP Phone Auto-Registration Summary Quiz
CIPT1 v4.12-2
2-22
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
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 connection to the DNS server. It decreases the amount of time that is required when a device attempts to contact Cisco CallManager. Perform 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 on a server name. The Server Configuration window appears.
Step 3
Remove the Host Name and enter the IP address for the server in the Host Name/IP Address field; click Update.
Establishing an On-Cluster Call 2-23
Configuring Device Pools

This topic describes device pool configuration.
Device Pool Configuration
CIPT1 v4.12-4
Use device pools to define sets of common characteristics for devices. 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 These components are covered in subsequent pages. The device pool combines all of the individual configurations that you have created into a single entity. You will eventually assign this entity to an individual device, such as an IP Phone. This process will configure that device with most of the configuration elements that it needs to operate efficiently in your IP telephony network. Perform these steps to create the device pool:
Step 1 Step 2
Choose System > Device Pool. When the Find and List Device Pools window opens, click Add a New Device Pool elect to open the Device Pool Configuration window. Choose, at a minimum, the Cisco CallManager group, date/time group, region, and softkey template that you have created.
2-24
Example: Device Pool Configuration

Configuring a hundred 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, which 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. Device Pool Configuration Items
Field Device Pool Name* Cisco CallManager Group* Description Describes a name for the device pool Selects a redundancy group for the device poolthis redundancy group can contain a maximum of three redundant Cisco CallManager servers Assigns the correct time zone to the device Determines the codec selection when it is used by the device Configures survivable remote site telephony (SRST) and selects the gateway that will support a device if the connection to the Cisco CallManager is lost Assigns media resource support to a device for functions such as conferencing, transcoding, or MOH Selects the audio that Cisco CallManager should play when a user presses the Hold button on the Cisco IP Phone Selects the audio that Cisco CallManager should play when a user presses the Transfer or Conference button on the Cisco IP Phone Defines the language that the device uses Defines the tones and cadences that the device uses Defines whom an IP Phone is able to call if it auto-registers with the Cisco CallManager Defines the type and order of the softkeys that are displayed on the LCD of a Cisco IP Phone Used to manage Multilevel Precedence and Preemption (MLPP) settings:
Date/Time Group* Region* SRST Reference
Media Resource Group List User Hold MOH Audio Source Network Hold MOH Audio Source
User Locale Network Locale Calling Search Space for Autoregistration Softkey Template* MLPP Precedence and Preemption Information
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
* Indicates a required field

Copyright 2004, Cisco Systems, Inc. Establishing an On-Cluster Call 2-25
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 devices or one that is used for Device Defaults configuration. To find out what 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 will be displayed. Before deleting a device pool that is currently in use, you must perform the following tasks:
Step 1 Step 2
If desired, 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.
2-26
Cisco CallManager Group Configuration
CIPT1 v4.12-5
A Cisco CallManager group specifies a prioritized list with a maximum of three Cisco CallManagers. 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 secondary and tertiary backup Cisco CallManagers. 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 up.
Example: Cisco CallManager Group Configuration

In the figure shown here, the Cisco CallManager group, called Arizona, has three Cisco CallManagers. 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 CallManager, the California Cisco CallManager as its secondary CallManager, and the Michigan Cisco CallManager as its tertiary CallManager. Cisco CallManager Administration will present an error message if you attempt to add a fourth CallManager (for example, the EAST1A Cisco CallManager) to the list. 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. Unless you change its configuration, this default Cisco CallManager group will have only the first CallManager installed in the selected network.
2-27
Perform 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. Choose Add New Cisco CallManager Group to create a new Cisco CallManager group. Move the existing Cisco CallManagers using the Left Arrow and Right Arrow keys, and change the order of Cisco CallManagers using the Up Arrow and Down Arrow keys.
Step 2
Step 3
2-28
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. Perform these steps to configure the date/time group:
Step 1 Step 2
Choose System > Date/Time Group; the default CMLocal group appears. Choose Add a New Date/Time Group to insert additional date/time groups as required.
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.
Note
2-29
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 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.
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 will 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 will use the G.729 codec. Cisco CallManager creates the Default region during the installation process. Rename the Default region to a more logical name to avoid confusion. Perform these steps to configure a region:
Step 1
Choose System > Region, and the default region that was created during the Cisco CallManager installation appears. Choose Add a New Region to configure the regions, and choose the codec and video bandwidth as appropriate between the regions.
Step 2
2-30
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. Choose Device > Device Settings > Softkey Templates to access the Softkey Template Configuration window in Cisco CallManager Administration.
2-31
IP Phone Button Templates

This topic discusses the configuration and application of the Cisco IP Phone button templates.
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 4 lines, 2 speed dials 5 lines, 1 speed dial 6 lines, 0 speed dials
Creating and using templates provides a fast way to assign a common button configuration to a large number of IP Phones. Cisco CallManager includes several default IP Phone button templates. When adding IP Phones, you can assign one of these templates to each IP Phone or create a new template. 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 IP 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 IP Phone button template combinations: 1 line, 5 speed dials 2 lines, 4 speed dials (default) 3 lines, 3 speed dials 4 lines, 2 speed dials 5 lines, 1 speed dial 6 lines, 0 speed dials
2-32
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
Create easily recognizable naming conventions for the IP 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 dials. 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 use this feature to create a copy of an existing template that you can then modify. 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 if 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 IP Phone button template.
Example: Naming an IP Phone Button Template

If you have a Cisco IP Phone 7960 that has three lines and three speed dials, you can use 7960 3-3 for the IP Phone button template name. If you have a special request or only a limited number of users who need three lines and three speed dials, you can quickly assign 7960 3-3 to the IP Phone, rather than creating a template for each IP Phone and then assigning the template to the IP Phone.
2-33
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
CIPT1 v4.12-11
Manually adding new IP Phones to the network is often tedious, but it can comprise 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 up 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-34
You can continue the Cisco CallManager configuration after you have the MAC address of the IP Phone. Perform these steps to configure the IP Phone:
Step 1
In Cisco CallManager Administration, choose Device > Phone to open the Find and List Phones window. Choose Add a New Phone in the upper right corner of the window. Choose the model of the IP Phone from the drop-down list, and click Next. At a minimum, you must configure the MAC Address and Device Pool fields; then click Insert. Cisco CallManager prompts you to add a DN for line 1; then click OK. When the Directory Number Configuration window appears, type the DN of the IP Phone in the appropriate field, and click Insert.
Step 2 Step 3 Step 4
Step 5 Step 6
2-35
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 how the DHCP server issues IP addresses. When a new IP Phone boots up 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 over autoregistration. Perform these steps to configure the Cisco CallManager server to support auto-registration:
Step 1 Step 2
From Cisco CallManager Administration, choose System > Cisco CallManager. From the list of Cisco CallManager servers, select the server that you want to support auto-registration. Under the Auto-registration Information Configuration section, type the appropriate DN range in the Starting and Ending Directory Number fields. Ensure that the Auto-registration Disabled on this Cisco CallManager check box is unchecked.
Step 3
Step 4
2-36
Device Defaults
CIPT1 v4.12-13
When devices auto-register with Cisco CallManager, they use the settings that are found in the Device Defaults Configuration window. The Load Information field lists the firmware load that is used with a particular type of hardware device; the Device Pool field allows you to select the device pool that is associated with each type of device, and the Phone Template field indicates the phone button template that is used by each type of device. If devices auto-register and are not registering to the intended Cisco CallManager, check the Device Defaults Configuration window to ensure that you have chosen the correct device pool. Perform these steps to confirm the device auto-registration setup:
Step 1
In Cisco CallManager Administration, choose System > Device Defaults to open the Device Defaults Configuration window. Scroll to the Cisco IP Phone device or devices that will auto-register, and choose the device pool from the drop-down list.
Step 2
Perform these steps to update the device defaults:

Step 1
From the Device Defaults Configuration window, modify the appropriate settings for the device that you want to change. Click Update to save the changes in the Cisco CallManager configuration database. 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 CallManagers 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.
Step 2 Step 3
2-37
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 issue extension numbers to new phones if the phones do not have existing extension numbers.
CIPT1 v4.12-14
References
For additional information, refer to these resources: System Configuration Overview section in Cisco CallManager System Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmsys/index.htm System-Level Configuration Settings section in Cisco CallManager System Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmsys/index.htm Cisco CallManager Administration Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmcfg/index.htm
2-38
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) Which five settings are required to configure a device pool? (Choose five.) A) B) C) D) E) F) Q2) media resource group list Cisco CallManager group date/time group region softkey template device pool name
How does Cisco CallManager tie configuration information to the IP Phones in the Microsoft SQL database? A) B) C) D) E) IP address unique GUID hostname MAC address device pool ID
Q3)
Which of the following is a valid IP Phone button template configuration for a Cisco IP Phone 7960? A) B) C) D) 0 lines, 6 speed dials 2 lines, 4 speed dials 6 lines, 1 speed dial 4 lines, 4 speed dials
Q4)
Which navigation path would you use to configure Cisco CallManager to automatically register an IP Phone? A) B) C) D) E) System > Server System > Cisco CallManager Service > Service Parameters Device > Phone System > Device Pool
Q5)
Which navigation path would you use to eliminate DNS reliance by changing the Cisco CallManager server name to an IP address? A) B) C) D) E) System > Server System > Cisco CallManager Service > Service Parameters Device > Phone System > Device Pool
2-39
Quiz Answer Key

Q1) B, C, D, E, F Relates to: Configuring Device Pools Q2) D Relates to: Manual IP Phone and Directory Number Configuration Q3) B Relates to: IP Phone Button Templates Q4) B Relates to: Configuring IP Phone Auto-Registration Q5) A Relates to: Server Configuration
2-40
Configuring Cisco Catalyst Switches

Overview
This lesson discusses the three major functions that Cisco Catalyst switches perform in an IP telephony network: powering Cisco IP Phones, enabling single-port multiple VLANs, and extending class of service (CoS) to a Cisco IP Phone. You will also learn the fundamentals of configuring a Cisco Catalyst switch to support these three functions.
Relevance
Using the Catalyst switch to power IP Phones can save on wiring costs and simplifies management. Extending CoS to the IP Phone improves voice quality by ensuring voice packets receive priority over data. 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.
Objectives
Upon completing this lesson, you will be able to configure a Catalyst switch port to receive voice and data traffic on different VLANs and apply a CoS to incoming frames. This includes being able to meet these objectives: Identify three 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 inline power delivery that Cisco Catalyst switches provide Identify the Cisco Catalyst switches that support inline power, dual VLANs, and CoS Identify the commands to configure inline power 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 the Cisco Catalyst switch models so that voice traffic has priority over data traffic as it travels throughout the network

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: VLAN routing and configuration TCP/IP networking skills
Outline
The outline lists the topics included in this lesson:
Outline
Overview Catalyst Switch Role in IP Telephony Powering the Cisco IP Phone Types of Inline Power Delivery Catalyst Family of PoE Switches Configuring Inline Power Configuring Dual VLANs Configuring Class of Service Summary Quiz
2-42
Catalyst Switch Role in IP Telephony

This topic describes the role of Cisco Catalyst switches in the IP telephony infrastructure.
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 originally 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 and allows you to prioritize certain traffic types over other traffic types. This feature is critical in IP telephony networks. Data traffic can easily overwhelm voice traffic, causing poor voice quality. You can achieve end-to-end prioritization of your voice traffic by using CoS marking (Layer 2) along with type of service (ToS) marking at the network layer (Layer 3).
2-43
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): Needs PoE line cards or PoE ports for Catalyst switches Delivers -48 V DC over data pairs (pins 1, 2, 3, and 6) Midspan power injection: 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
Power
Power Injector No Power Power
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: Power over Ethernet (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 Catalyst PoE-capable modular and fixed-configuration switches, insert power over the Ethernet cable to the powered device (PD), for example, an IP Phone or 802.11 wireless access point. The Catalyst switch uses pins 1, 2, 3, and 6 of the Ethernet cable (same as data) for delivering -48 V DC to the PD (this capability is sometimes referred to as phantom power). Midspan power injection: Because many switches do not support inline power, the PD must support a midspan power source. This midspan device sits between the LAN switch and the PD and inserts power on the Ethernet cable to the PD. 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-44
Types of Inline Power Delivery

This topic discusses the two types of inline power delivery that Cisco Catalyst switches can provide.
Two Types of Inline Power Delivery

Cisco original implementation:
Provides 48 V DC at up to 6.3 to 7.7 watts per port Supports most Cisco devices (IP Phones and wireless access points) Identifies devices that require power and delivers power only to those devices Uses Cisco Discovery Protocol to manage power delivery
IEEE 802.3af Power over Ethernet:

Specifies 48 V DC at up to 15.4 watts per port Enables a new range of Ethernet-powered devices because of increased power Uses standards-based discovery and power delivery methods Has several optional elements including power classification
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. Here is more information about each type: Cisco original implementation: 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 Supports most Cisco devices (IP Phones and wireless access points) Identifies devices that require power and delivers power only to those devices Uses Cisco Discovery Protocol to manage power delivery
IEEE 802.3af Power over Ethernet: Since first developing PoE, Cisco has been driving the evolution of this technology toward standardization by working with vendors in the IEEE 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: Specifies 48 V DC at up to 15.4 W per port Enables a new range of Ethernet-powered devices that consume additional power Uses standards-based discovery and power delivery methods
2-45
Has several optional elements, such as power classification, where PDs 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 PD, 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 oversubscribing of the available power supplies so that some devices will not be powered even though there is sufficient power available. The 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.
2-46
Cisco Prestandard Device Detection
Pin3
Cisco prestandard implementation PD port RX FLP TX
FLP Switch It is an inline device
Pin6 Pin1 Pin2
CIPT1 v4.12-6
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 FLP to the device. The Cisco PD (IP Phone) will loop 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-capable endpoint.
2-47
IEEE 802.3af Device Detection
IEEE 802.3af PSE
IEEE 802.3af PD
-2.8 V to -10 V Pin3
Switch It is an IEEE PD
Detect Voltage Pin6

Pin1 Pin2
RX TX
25K-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 (Catalyst switch) detects a PD 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 PDs must support this resistance method. If the appropriate resistance is found, the Catalyst switch delivers power.
2-48
Catalyst Family of PoE Switches

This topic describes the Cisco Catalyst PoE switch models.
Catalyst Family of PoE Switches

Catalyst 6500 Catalyst 4500 Catalyst 3750
EtherSwitch Network Module* Catalyst 3560
Catalyst 3550*
*Cisco prestandard PoE only

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 Catalyst 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: Catalyst Modular Switching: The Cisco Catalyst 6500 Series delivers a 96-port 10BASET/100BASE-T line card and 48-port 10BASE-T/100BASE-T and 10BASE-T/100BASET/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 Catalyst 6500 or 4500 chassis and Supervisor engine. The Catalyst modular chassis switches can deliver 15.4 W per port for all 48 ports on a module simultaneously. 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 Catalyst 3560 Series offers 48- and 24-port Fast Ethernet switches that support both the industry standard and Cisco standard PoE. The Catalyst 3550-24 PWR switch continues to support Cisco prestandard PoE. All 24-port configurations support 24 simultaneous full-powered PoE ports at 15.4 W for maximum PD support. The 48-port configurations support 24 ports at 15.4 Watts, 48 ports at 7.7 Watts, or any combination in-between.
2-49
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
Catalyst 6500 Catalyst 4500 Catalyst 3750 Catalyst 3560 Catalyst 3550 Cisco EtherSwitch Module 16-, 36-port 10/100
PoE Configuration Options IEEE 802.3afCompliant Cisco Prestandard PoE
48-, 96-port 10/100 or 48-port 10/100/1000 Yes Yes
48-port 10/100 or 10/100/1000 Yes Yes
24-, 48-port 10/100
24-, 48 port 10/100
24-, 48port 10/100 No Yes
Yes Yes
Yes Yes
No 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 on this page also support multiple VLANs per port and CoS.
2-50
Configuring Inline Power

This topic discusses the configuration of inline power on the Cisco Catalyst switches.
Catalyst Switch: Configuring Inline Power

Cisco CatOS: CatOS>(enable) set port inlinepower <mod/port> ? auto Port inline power auto mode off/never Port inline power off mode Native Cisco IOS: CSCOIOS(config-if)# power inline <auto/never>
CIPT1 v4.12-9
Use the set port inlinepower command on a switch that is running Cisco Catalyst command syntax (Catalyst operating systems, or Catalyst software) (examples include the Cisco Catalyst 6500, 6000, 4500, and 4000 Series). Use the power inline command on switches that are running native Cisco IOS command syntax (examples include the Catalyst 6500, 4500, 3750, 3560, and 3524 switches). The two modes are either auto or off/never. The telephone-discovery algorithm is operational in the auto mode. The telephone-discovery algorithm is disabled in the off/never mode.
Note The Catalyst 6500 and 6000 Series can run either Catalyst software or native Cisco IOS software if the switch Supervisor engine has a Multilayer Switch Feature Card (MSFC). Otherwise, they can run only Catalyst software. The Catalyst 4500 and 4000 Series can also run 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.
Note
The Catalyst 4000 and 3524 switches have enough power to supply all of their ports, so only Catalyst 6000 Series switches track the allocation of power to the IP Phone. On the Catalyst 6000 Series switches, use the set inlinepower defaultallocation value command to supply 7 W of power to an IP Phone instead of the default power setting (10 W).
Establishing an On-Cluster Call 2-51
Catalyst Switch: Show Inline Power Status

CatOS>(enable) show port inlinepower <mod| mod/port> Default Inline Power allocation per port: 10.000 Watts (0.23 Amps @42V) Total inline power drawn by module 7: 75.60 Watts (1.80 Amps @42V) Port InlinePowered PowerAllocated Admin Oper Detected mWatt mA @42V -----------------------------------7/1 auto off no 0 0 7/2 auto on yes 6300 150 7/3 auto on yes 6300 150 7/4 auto off no 0 0 7/5 auto off no 0 0 7/6 auto off no 0 0 7/7 auto off no 0 0
CSCOIOS# show power inline <mod/port> Interface Admin Oper Power ( mWatt ) ------------------------------FastEthernet9/1 auto on 6300 FastEthernet9/2 auto on 6300 FastEthernet9/3 auto off 0
Device -----Cisco 6500 IP Phone Cisco 6500 IP Phone n/a

CIPT1 v4.12-10
Use the command in the figure shown here to display a view of the power allocated on Catalyst 6000 series 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 Port Inline Powered Admin Oper Power Allocated Detected mWatt mA @42V Identifies if power is detected Identifies the mWatt supplied on a given port Identifies the mA @ 42 V supplied on a given port Identifies the port configuration from using the set inlinepower <mod/port> [auto|off] Identifies if the inline power is operational Description Identifies the port number on the module
2-52
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 Native VLAN (PVID) and auxiliary VLAN (VVID) Hardware set to dot1q trunk
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 Catalyst software command-line interface (CLI) refers to this new voice VLAN as the auxiliary VLAN for configuration purposes. You can use the new auxiliary VLAN to represent Cisco IP Phones. While you can think of it as a voice VLAN, in the future, other types of nondata devices will reside in the auxiliary VLAN. The placement of nondata devices (such as IP Phones) in an auxiliary VLAN makes it easier for customers to automate the process of deploying IP Phones. IP Phones will boot up and reside in the auxiliary VLAN if you configure the switch to support them, just as data devices boot up and reside in the native VLAN (also referred to as the default VLAN) of the switch. The IP Phone communicates with the switch via Cisco Discovery Protocol when it powers up. The switch will provide the telephone with the appropriate VLAN ID, known as the voice VLAN ID (VVID). This VVID is analogous to the data VLAN ID, known as the port VLAN ID (PVID). Administrators can implement multiple VLANs on the same port by configuring trunking. A trunk is a point-to-point link that carries two or more VLANs. A tagging mechanism must exist to distinguish between VLANs on the same trunk. 802.1Q is the IEEE standard for tagging packets on a trunk. Frames transmitted on the auxiliary VLAN (voice frames) are 802.1Q tagged, and frames transmitted on the native VLAN (data frames) are not tagged.
2-53
These are some of the advantages of 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 an introduction of 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.
2-54
Configuring Voice VLANs Using Cisco CatOS

Syntax: Console>(enable) set port auxiliaryvlan <mod/port> <vlan|untagged|dot1p|none>(vlan = 1..1000)
Example: Console>(enable) set port auxiliaryvlan 2/1-3 222 Auxiliaryvlan 222 configuration successful. AuxiliaryVlan AuxVlanStatus Mod/Ports ------------- ------------- ---------------------222 active 1/2,2/1-3
CIPT1 v4.12-12
You can configure the VVID in Cisco Catalyst software 5.5 and above using the set port auxiliaryvlan <mod/port> command. The VVID 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 VVID on a per-port basis, for a range of ports, or for an entire module.
2-55
Configuring Voice VLANs Using Native Cisco IOS
Example: Console(config)#interface FastEthernet0/1 Console(config-if)#switchport trunk encapsulation dot1q Console(config-if)#switchport trunk native vlan 12 Console(config-if)#switchport mode trunk Console(config-if)#switchport voice vlan 112 Console(config-if)#spanning-tree portfast
CIPT1 v4.12-13
Use the commands in the figure shown here to configure voice and data VLANs on the singleport 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 Catalyst switch that is running Catalyst software.
Catalyst Switch Voice Interface Commands

Command Description Configures the trunk encapsulation protocol as 802.1Q. Specifies VLAN 12 as the native (data) VLAN over the trunk. Configures the interface as a Layer 2 trunk. Specifies VLAN 112 as the voice VLAN over the trunk. 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.
switchport trunk encapsulation dot1q switchport trunk native vlan 12 switchport mode trunk switchport voice vlan 112 spanning-tree portfast
2-56
Verifying Voice VLAN Configuration Using Cisco CatOS

Console> (enable)show port auxiliaryvlan 222 AuxiliaryVlan AuxVlanStatus Mod/Ports ------------- ------------- ---------222 active 1/2,2/1-3 Console> (enable)
Console> (enable)show port 2/1 ... Port AuxiliaryVlan AuxVlan-Status ----- ------------- -------------2/1 222 active ...
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-57
Verifying Voice VLAN Configuration Using Native Cisco IOS

Switch# show interface fa0/17 switchport Name: Fa0/17 Switchport: Enabled Administrative mode: trunk Operational Mode: trunk Administrative Trunking Encapsulation: dot1q Operational Trunking Encapsulation: dot1q Negotiation of Trunking: Disabled Access Mode VLAN: 0 ((Inactive)) Trunking Native Mode VLAN: 12 (VLAN0012) Trunking VLANs Enabled: ALL Trunking VLANs Active: 1-3,5,10,12 Pruning VLANs Enabled: 2-1001 Priority for untagged frames: 0 Override vlan tag priority: FALSE Voice VLAN: 112 Appliance trust: none
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. The Catalyst 4000 and 6000 Series switches may display a more convenient output, but using this syntax will display the voice and data VLAN configurations on any interface.
2-58
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 PC is not trusted CoS set to 0 (normal) PC is not trusted CoS set to 2 PC is trusted
Desktop PC: IP Subnet A CoS = 7 CoS = 7 CoS = 7

CIPT1 v4.12-16
CoS = 0 CoS = 2 CoS = 7
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 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. 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 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 frames before sending them to the switching engine. You use input queuing only when there is congestion. The switch will use the CoS value(s) to place the frames in appropriate queues. CoS 5 frames go into the priority queue, which is serviced before other queues.
2-59
Configuring CoS
Cisco CatOS
set port qos <mod/port> cos-ext <cos-value>

Allows you to statically configure the CoS assigned to the attached device
set port qos <mod/port> trust-ext <untrusted/trust-cos>

Allows you to trust or not trust (set to 0) the CoS assigned to the attached device
Native Cisco IOS
Switch(config)#interface FastEthernet0/1 Switch(config-if)#switchport priority extend <cos/none/trust>

Choose to modify, ignore, or trust the CoS of the attached device
CIPT1 v4.12-17
You can configure the switch with different QoS settings on a per-port basis. Use the set port qos <mod/port> trust <untrusted|trust-cos> command from the CLI. You may want to trust the PC CoS if you are sending tagged packets or give it a value other than 0. Use the set port qos 2/1 trust-ext trust-cos command to extend trust out to the PC. The IP Phone will accept the PC CoS. Use the set port qos 2/1 trust-ext untrusted command to instruct the IP Phone to change the PC CoS to 0 (normal operation). Use the set port qos 2/1 cos-ext 2 command if you want to set the CoS to 2 on packets that are sent by the device that is attached to the IP Phone access port. Use the other commands that are shown in the figure to set the trust boundaries if a Catalyst switch uses Cisco IOS software, for example, a Catalyst 3750, Catalyst 3650, Catalyst 3524, or Catalyst 2900 Series XL switch.
Note The Implementing Cisco Quality of Service (QOS) course provides more information about voice QoS theory and configuration.
2-60
Summary
Summary
Cisco voice-capable switches support three primary feature sets that can assist with an IP telephony deployment: inline power, auxiliary 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.
Summary (Cont.)
The Catalyst 6500, Catalyst 4500, Catalyst 3750, and Catalyst 3560 switches support 802.3af and Cisco PoE, dual VLANs, and CoS. Configure inline power using the set port inline power command (CatOS) or power inline (native Cisco IOS) 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-61
References
For additional information, refer to these resources: Multilayer LAN Switches documentation: http://www.cisco.com/univercd/cc/td/doc/product/lan/index.htm 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-62
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) What are three options for powering IP Phones? (Choose three.) A) B) C) D) Q2) -48 V DC over Ethernet data or spare pairs 110 V AC to -48 V DC converter internal DC battery power patch panel
Cisco Catalyst switches can provide which three functions in an IP telephony deployment? (Choose three.) A) B) C) D) E) 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
Q3)
Match the items that follow with the correct inline power method. Place an I next to items that are associated with the IEEE 802.3af PoE implementation, a C next to items that are associated with the Cisco prestandard implementation, or a B next to items that are associated with both implementation types. A) B) C) D) E) F) ______ ______ ______ ______ ______ ______ send -48 V DC power over pins 1, 2, 3, and 6 supply up to 15.4 watts per port supply up to 6.3 to 7.7 watts per port use FLPs to determine if the endpoint is inline-power-capable use resistance to determine if the endpoint is inline-power-capable has an optional power classification scheme
Q4)
Which command enables inline power on port 3 of module 2 of a Catalyst 6000 Series switch that is running Catalyst software? A) B) C) D) E) 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
Q5)
What must you do if you do not want to trust the device that is attached to the IP Phone? A) B) C) D) change the CoS value on the native VLAN to a number lower than 5 use the switchport priority extend untrust interface command 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
2-63
Q6)
Which two products support both Cisco prestandard PoE and IEEE 802.3af PoE? (Choose two.) A) B) C) D) E) F) Catalyst 3524-PWR-XL Catalyst 3750 Catalyst 3550-24 PWR Ethernet switch module for the Cisco 2600 and 3600 routers Catalyst Inline Power Patch Panel Catalyst 3560
Q7)
What are three requirements for configuring dual VLANs on a single port that is attached to an IP Phone? (Choose three.) A) B) C) D) E) 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
2-64
Quiz Answer Key

Q1) A, B, D Relates to: Powering the Cisco IP Phone Q2) B, C, D Relates to: Catalyst Switch Role in IP Telephony Q3) A=B, B=I, C=C, D=C, E=I, F=I Relates to: Types of Inline Power Delivery Q4) E Relates to: Configuring Inline Power Q5) C Relates to: Configuring Class of Service Q6) B, F Relates to: Catalyst Family of PoE Switches Q7) A, B, D Relates to: Configuring Dual VLANs
2-65
2-66
Adding Users and Customizing User Options

Overview
This lesson teaches you how to use Cisco CallManager to configure users and to associate devices (telephones, Cisco SoftPhones, device profiles) to users. You will learn how users can customize their IP Phones using the web.
Relevance
Adding users and associating users to devices allow for directory searches from a Cisco IP Phone 7940 or 7960, Auto Attendant, or billing association. In addition, allowing users to configure IP Phone options increases their productivity.
Objectives
Upon completing this lesson, you will be able to add users, associate devices to users, and use the Cisco CallManager User Options pages to customize Cisco IP Phones. This includes being able to meet these objectives: Use Cisco CallManager Administration to add and associate users to a device Log onto the Cisco CallManager User Options web page and select a device to personalize Activate the Call Forward option in Cisco CallManager User Options to forward all calls to an associated device Enter speed dials in the Cisco CallManager User Options web page to associate to IP Phone buttons Describe how to subscribe to Cisco IP Phone services from the Cisco CallManager User Options web page in order to access web services from IP Phones Describe how to create personal address books in Cisco CallManager User Options to store names and numbers for people who are both internal and external to your company and how to assign fast-dial codes to personal address book entries to enable you to dial those codes in place of telephone numbers.
Describe how to change the way that the voice message light on your handset works when you receive a voice-mail message Describe how to change the language for your Cisco CallManager User Options web pages or telephone

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: Navigation in Cisco CallManager Administration
Outline
Outline
Overview Adding a User User Logon and Device Selection Call Forward Speed Dials Cisco IP Phone Services Subscription Personal Address Book Message Waiting Lamp Policy Personalizing Device and Web Page Locale Summary Quiz
CIPT1 v4.12-2
2-68
Adding a User
This topic discusses how to add a user and associate a user to a device.
User Information
Cisco CallManager
User Information
Accessed by Directory Services, Cisco WebAttendant, and the User Options web pages
CIPT1 v4.12-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 pages. 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 the name and DN of that device, they can change their speed dial 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 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.
2-69
Adding a User
CIPT1 v4.12-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, go to User > Add a New User. Before adding a user, gather the following user information: First name Last name User ID Telephone number or DN Manager user ID Department If the user is going to access the Cisco SoftPhone application, 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 both 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.
2-70
Device Association
Multiple devices and only one primary extension
CIPT1 v4.12-5
After you have added a user, you can associate devices over which users 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 to many devices; however, only one of the devices can be the primary extension for that user. You can associate the user to multiple telephone devices or a Cisco SoftPhone device or both. To assign devices to a user, you must access the User Configuration window for that user and then perform the following procedure to assign the devices:
Step 1 Step 2
In the Application Profiles pane, click Device Association. Limit the list of available devices by entering the search criteria in the Available Device List Filters section, if desired, and click Select Devices. 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. When you have completed the assignment, click Update Selected to assign the devices to the user.
Step 3
Step 4
2-71
User Logon and Device Selection

This topic discusses how the user can log on and select a device from the Cisco CallManager User Options web page.
Cisco CallManager User Options: Log On
http://<server_name>/ccmuser/logon.asp
To open the Cisco CallManager User Options web page, enter this URL: http://<server_name>/ccmuser/Logon.asp The <server_name> is the host name or IP address of the Cisco CallManager server. At the Cisco CallManager User Options page, enter the user ID and password. If this is the first time that the user is logging on, the user should obtain the URL, user ID, and password from the administrator. From any page within Cisco CallManager User Options, the user can change the language of the page by selecting the language (locale) from the View page in the menu.
2-72
Cisco CallManager User Options: Welcome < user name >
Select a device
CIPT1 v4.12-7
After logging on, the user can select an associated device to configure. The user can customize multiple associated devices by choosing more than one device. By providing a web location for users to customize Cisco IP Phone settings, such as adding speed dials and forwarding calls, users can be more productive in their work environment. For example, when users are not going to be in the office to receive an important call, they can access the Cisco CallManager User Options page from home and forward calls from their IP Phone to their cellular telephone or any other DN.
2-73
Call Forward
This topic discusses how the user can forward all calls on an associated device by using the Cisco CallManager User Options page.
Cisco CallManager User Options: Call Forwarding
CIPT1 v4.12-8
A 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 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 Call Forward All 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 Call Forward All feature, apply a calling search space on the Directory Number Configuration page in the Call Forward All setting.
Example: Call Forwarding

A user may want to work from home and wants all calls to the office telephone to forward to the home number. If the user dials 92145551212 from the office to call home, the user must enter 92145551212 as the forwarding number.
2-74
Speed Dials
This topic discusses how the user can configure speed dial settings for a device using the Cisco CallManager User Options page.
Cisco CallManager User Options: Speed Dials
CIPT1 v4.12-9
Depending on the device, the number of speed dials is limited based on 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, a user must enter the number precisely as it is dialed from a device. If the number 9 is dialed before entering the home telephone number, the 9 must be part of the speed dial number that a user enters.
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 using these numbers. For example, if the home telephone number is 2145551212, the speed dial number must be entered as 123492145551212.
2-75
Cisco IP Phone Services Subscription

This topic discusses how the user can subscribe to available Cisco IP Phone services within a Cisco IP telephony solution.
Cisco CallManager User Options: IP Phone Services
CIPT1 v4.12-10
The user can use the Subscribe/Unsubscribe IP Phone Services page in CallManager User Options to subscribe to or unsubscribe from any of the Cisco IP Phone services that you have configured. You can configure a number of services for user subscription. For example, you can configure any information on the web and some applications as well. Users can subscribe to services that store telephone numbers, meeting room availability, traffic reports, and more.
Example: Subscribing to a Stock Quote Service

If you have configured a service that looks up the stock price of a company, the 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 model 7970, 7960, or 7940 and view the stock price on the IP Phone LCD.
2-76
Personal Address Book

This topic discusses how the user can access the personal address book using Cisco CallManager User Options.
Cisco CallManager User Options: Personal Address Book
To use personal address book and fast dials, user needs to subscribe to these IP Phone services.
CIPT1 v4.12-11
The user can configure the personal address book and fast dials from the Personal Address Book page in Cisco CallManager User Options. After adding these services, users can access the personal address book and fast dials from their Cisco IP Phone. With the fast-dial service, users can assign index numbers (from 1 to 99) for quick dialing from their 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 the address book. To access the personal address book and fast dials, the user presses the Services button on the IP Phone, and then selects either service.
Example: Personal Address Book and Fast Dials

Users who do not have their PC, but have a Cisco IP Phone, can still access important telephone numbers by accessing their personal address book from the IP Phone. Also, users who have configured fast dials can dial any person in their fast-dial list by pressing only three buttons on their IP Phone.
2-77
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 page.
Cisco CallManager User Options: Message Waiting Lamp
CIPT1 v4.12-12
The 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, or Never light. The default system policy is set to light the lamp. If the user wants to be sure that the message waiting lamp gets lit when a voice message is left, the Always light policy should be chosen.
Example: Setting the Message Waiting Lamp Policy

If a user is associated to multiple devices but would like to know when a voice mail is left from only one of those devices, the user can set all other devices to Never light. By setting the other devices to Never light, the user will be aware only of a voice message from one device.
2-78
Personalizing Device and Web Page Locale

This topic discusses how the user can customize the language of the Cisco IP Phone LCD and web pages by using the Cisco CallManager User Options page.
Cisco CallManager User Options: Locale for Phone
CIPT1 v4.12-13
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) Polish (Poland) Portuguese (Portugal)
Russian (Russia) Spanish (Spain) Swedish (Sweden) If a user locale is not selected, the system-wide locale will be used.
Example: Setting the User Locale on the Phone

If a user speaks Russian and is using a telephone in Italy and the system-wide locale for devices is Italian, the user can log onto the Cisco CallManager User Options page and set the locale for the device to Russia. The user can configure the IP Phone to display text in the desired language without administrator intervention.
2-80
Cisco CallManager User Options: Locale for Web Pages
CIPT1 v4.12-14
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, your users can customize the language of the Cisco IP Phone, and they can also customize the Cisco CallManager User Options web pages display.
2-81
Summary
Summary
Cisco CallManager Administration allows you to add users and associate users with specific devices. Users can log onto Cisco CallManager User Options 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.12-15
Summary (Cont.)
Users can subscribe or unsubscribe to all configured Cisco IP Phone services. Users can configure a personal address book and fast dials and access them from an IP Phone. Users can configure the message waiting lamp on Cisco IP Phones to use the system policy, always light, or never 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.12-16
2-82
References
For additional information, refer to these resources: Customizing Your Phone on the Web section in Cisco IP Phone 7960 and 7940 Series User Guide: http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/ipp7960/user/ind ex.htm The Help files within Cisco CallManager Administration Cisco IP Telephony Locale Installer documentation: http://www.cisco.com/univercd/cc/td/doc/product/voice/locinst/index.htm
2-83
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) What are the three options that users have for setting the message waiting lamp policy? (Choose three.) A) B) C) D) Q2) always light when a voice message is left light if the call is outside the corporate network never light when a voice mail is received follow the system policy
Which two of these fields must the user complete in order to log onto the Cisco CallManager User Options page? (Choose two.) A) B) C) D) User ID Password PIN Full Name Enable SoftPhone Use Enable XML Application Use Enable SoftPhone Access Enable CTI Application Use
Q3)
In order to allow a user to use the Cisco IP SoftPhone, which option must you enable? A) B) C) D)
Q4)
What are two requirements for users to be able to view weather reports, airline arrival and departure times, or stock quotes or other IP Phone services that you have made available to them? (Choose two.) A) B) C) D) go to http://<server_name>/Services.asp press the Services button on their IP Phone subscribe to the service in the User Options pages enable CTI Application Use
Q5)
Which three options is a user able to configure from the User Options page? (Choose three.) A) B) C) D) call forwarding message waiting lamp policy IP Phone services voice-mail retrieval
Q6)
By using the default 7960 phone template, how many speed dials are users able to configure on their Cisco IP Phone 7960? A) B) C) D) 2 4 6 10
2-84
Q7)
How do users of a Cisco IP Phone 7960 access their personal address book and fast dials? A) B) C) D) access the user partition of the LDAP directory navigate to Menu > My Address Book in the User Options pages press the Services button from their IP Phone press the softkey button next to the icon of an address book
Q8)
If you want your users to have the ability to view the Cisco CallManager User Options web pages display in a language other than English, which two tasks must first be done? (Choose two.) A) B) C) D) The administrator must order the correct Cisco CallManager part number for the desired language. The administrator must download the desired language from Cisco.com. The user must select the desired language in the User Options Page. The user must go to User Options > Change Locale from the Serviceability page.
2-85
Quiz Answer Key

Q1) A, C, D Relates to: Message Waiting Lamp Policy Q2) A, B Relates to: User Logon and Device Selection Q3) D Relates to: Adding a User Q4) B, C Relates to: Cisco IP Phone Services Subscription Q5) A, B, C Relates to: Call Forward Q6) B Relates to: Speed Dials Q7) C Relates to: Personal Address Book Q8) B, C Relates to: Personalizing Device and Web Page Locale
2-86
Using the Bulk Administration Tool

Overview
The lesson covers Bulk Administration Tool (BAT) Release 5.0(1) and the Tool for AutoRegistered 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.
Relevance
Manually configuring large numbers of phones, users, and ports is time-consuming and tedious. BAT and TAPS automate these tasks so that the system administrator can focus on more business- and network-critical activities.
Objectives
Upon completing this lesson, you will be able to use BAT and TAPS to bulk-add and autoregister Cisco IP Phones, users, and ports in an IP telephony network. This includes being able to meet these objectives: Identify the five major BAT features and two 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 to include changing or adding a device pool or calling search space for a group of similar phones
Describe two major requirements for proper installation of TAPS

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: Configuration of a single Cisco IP Phone device Cisco CallManager Administration basics
Outline
Outline
Overview 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 Phones Support Summary Quiz
2-88
Introducing the Bulk Administration Tool

This topic examines the Cisco Bulk Administration Tool (BAT), a product that enables the Cisco CallManager administrator to complete bulk adds, updates, and deletions for Cisco IP Phones, users, or ports.
Introduction to BAT
Add, update, or delete: IP Phones Users User device profiles Cisco IPMA managers and assistants Catalyst 6000 FSX or Cisco VG200 ports Includes TAPS
CIPT1 v4.12-3
You can use BAT to assist with the following situations: Add, update, and delete Cisco IP Phones including voice gateway chalice (VGC) phones, computer telephony integration (CTI) ports, and H.323 clients Add, update, and delete users Add, update, and delete user device profiles Add, update, and delete Cisco IPMA managers and assistants Add, update, and delete ports on a Cisco Catalyst 6000 Foreign Exchange Station (FXS) Analog Interface Module Add or delete Cisco VG200 analog gateways and ports BAT provides an optional application, the Tool for Auto-Registered Phones Support (TAPS), which retrieves the predefined configuration for auto-registered telephones. Only Cisco CallManager system administrators require access to BAT, but end users can use TAPS with permission from a system administrator in order 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.
2-89
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)
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 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 Value (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-90
BAT Features
Bulk Administration Tool wizard Flexible data input file format Master phone templates Validation feature Reporting utility Custom file support
CIPT1 v4.12-5
BAT Release 5.0(1) includes a number of useful feature enhancements including the following: 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: By using a master template, administrators can configure phones or user device profiles with a variable number of lines provided the number of lines is less than or equal to the number of lines in the master template. Validation feature: A validation routine checks for errors in the CSV data file and BAT template against the publisher database. An example of an item that is checked during the validation routine is that the number of lines that are configured on the device matches 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 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. Custom file support: Administrators can use a custom file to update and delete users when using queries is not feasible.
2-91
Installing BAT
This topic examines the BAT installation steps.
Installation Notes
Installed from plug-ins page in Cisco CallManager Administration Installation or reinstallation halts the following services: IIS Administration World Wide Web publishing FTP publishing Must be installed on the publisher server Must be logged on as administrator Excel templates in the following path: C:\CiscoWebs\BAT\ExcelTemplate
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: 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 for the BAT spreadsheet gets placed on the publisher database server at the following path: C:\CiscoWebs\BAT\ExcelTemplate\. Other BAT Release 5.0(x) specifications include the following: BAT Release 5.0(x) is compatible with Cisco CallManager Release 4.0(1). BAT supports LDAP including Cisco CallManager DC-Directory, Microsoft Active Directory, and Netscape Directory Server. You can use BAT to add users to the Cisco CallManager database LDAP Directory in batches, rather than individually. BAT Release 5.0(1) is compatible with Customer Response Solutions (CRS) version 3.5 for use with TAPS. The BAT application and the TAPS application use approximately 53 MB of disk space for the applications and the online documentation. (BAT uses 11 MB, and TAPS uses 42 MB.)
2-92
Installing BAT
CIPT1 v4.12-7
These steps describe the BAT installation process:

Step 1
Using the administrator privileges, log onto the system running the publisher database for Cisco CallManager.
You must install BAT directly on the publisher server; do not use Window Terminal Services.
Note Step 2 Step 3 Step 4 Step 5 Step 6
Choose Application > Install Plugins. The Install Plugins window is displayed, as shown here. Locate Cisco Bulk Administration Tool, and double-click the Setup icon. A standard Windows dialog box appears. Determine whether to copy the BAT install executable to the system or run it from the current location. Choose Next when the InstallShield Welcome window appears. The InstallShield window begins installing BAT.
Step 7
Step 8
When prompted, click Finish to exit the wizard.
After BAT is installed, from Cisco CallManager Administration, choose Application > BAT to access BAT.
Note If after installing BAT, it is not visible under the Application menu, refresh your browser.
2-93
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-8
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
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. 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. Insert the devices into the Cisco CallManager database.
Step 3
Step 4
2-94
Using BAT Wizard: Step 1 of 3
Choose device or option to configure.
CIPT1 v4.12-9
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 TAPS (optional, when installed)
2-95
Using the BAT Wizard: Step 2 of 3
Choose the task you want to perform.
CIPT1 v4.12-10
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
2-96
Using the BAT Wizard: Step 3 of 3
Wizard guides you through steps specific to the task.
CIPT1 v4.12-11
After choosing 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:
Add, view, or modify existing phone templates Create the CSV data file Validate phone records 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-97
Configuring BAT Templates

This topic describes how to use BAT to configure a Cisco IP Phone template.
Phone Template Configuration: Step 1
Select device type and
Phone button template becomes available.

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 step in configuring an IP Phone template is to choose an IP Phone (device) type from the Phone Template Configuration page, 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. After you have configured the initial template information, click Insert to add the template to the BAT utility.
2-98

After adding the template in the BAT utility, you can then configure necessary line settings.
Scroll down and select a line.
CIPT1 v4.12-13
After configuring the initial template settings, you can modify specific line configurations. Choose a line to configure, and a new configuration page 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 Excel spreadsheet.
2-99
Configure line settings for template.
CIPT1 v4.12-14
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-100
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-15
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 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 that 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. For experienced BAT users who are comfortable with working in a CSV formatted file, you can use a text editor to create a CSV data file.
2-101
Creating CVS File Using BAT Spreadsheet: Phones
CIPT1 v4.12-16
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. Once 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 get 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-102
Creating CSV File Using Text Editor
CIPT1 v4.12-17
Using a text editor is the second way to create a CSV file. When using a text editor, follow these steps:
Step 1 Step 2
Create a customized file format in the BAT File Format Configuration window. Use a text editor to create the CSV data file for phones that follow the file format that you want to use. 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 list. Next, you choose your file format from the File Format Name drop-down list. The data in the CSV data file must match the custom file format that you have chosen.
Step 3
Example: Sample CSV Data File with Customized File Format

A sample CSV data file follows: Device fields: MAC Address, Description, Device Pool, Calling Search Space Line fields: Directory Number, Partition, Line Text Label (moved to position after directory number in file)
NUMBER OF LINES,MAC ADDRESS,DESCRIPTION,DEVICE POOL,CSS,DIRECTORY NUMBER,LINE TEXT LABEL,PARTITION, 1,2234900AEF01,SEP2234900AEF01,DP_1,CSS_Restricted, 9725098827,Lobby Phone,Part1,
In this example, Directory Number represents the sixth field in the header, and the sixth field in the CSV data file shows 9725098827.
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, which do not have a dependency on a database table, 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 matches 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-104
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. To enable the use of applications such as Cisco IP SoftPhone, check the Enable CTI Application Use check box (for CTI ports only). Choose the Insert option that corresponds to your CSV data file. In the Phone Template Name field, choose the BAT phone template that you created for this type of bulk transaction. 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 the Xs represent any 12-character, hexadecimal (0-9 and A-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 2
Step 3 Step 4
Step 5
Step 6
Click Insert to insert phone records.
2-105
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 from 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 on 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-106
Updating IP Phones: Step 2
View query results. Specify parameter to update.
Reset or restart devices after changes are made.

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 Step 2 Step 3
Specify the values to be updated within Cisco CallManager. Click Update. 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-107
Using the Tool for Auto-Registered Phones 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. CallManager downloads configuration 5. Phone updates 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 gets 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-108
TAPS Installation
With BAT 5.0(1), TAPS is installed separately. TAPS installation prerequisites: Make sure the publisher database for Cisco CallManager is configured and running Ensure the Cisco CRS server is configured Ensure the Windows 2000 Services window is closed Ensure 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 5.0(1), TAPS is installed separately. During TAPS installation or reinstallation on the publisher database server, the setup program halts the following services: 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 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. Be sure to use the locale installer to create the country-specific TAPS prompts. Ensure that the Windows 2000 Services window is closed.
The following procedure lists the TAPS installation steps:

Step 1
Log on with administrator privileges to the system that is running the publisher database for Cisco CallManager (where you installed BAT). Access the BAT. Choose Applications > Install Plugins. Find TAPS and double-click the setup icon. Determine whether to copy the TAPS install executable to the system or run it from the current location. 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.
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 6
Note
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. The Installation Completed window is displayed when the installation ends. Click Finish.
Step 8
2-110
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 Step 2 To use TAPS, verify that auto-registration is enabled in Cisco CallManager.
Create a CTI route point and assign it a unique DN. 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. Create one or more CTI ports with consecutive DNs. You can create CTI ports in BAT or Cisco CallManager Administration. Create a user. The TAPS route point and ports should be in the users control devices list. 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.
TAPS supports a maximum number of sessions equal to the number of CTI ports that are configured for TAPS.
Step 3
Step 4
Step 5
Note
2-111
Summary
Summary
BAT enables the Cisco CallManager administrator to complete bulk adds, updates, and deletions for devices and users. 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 has three templates that you can use 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.
Summary (Cont.)
After creating the CSV file, you must validate the file and template. Inserting the IP Phones, users, or device is the last step in bulk configuration. To update phones, query to find the phones, specify the values, and reset the phones. TAPS, an optional application that BAT provides, retrieves the predefined configuration for auto-registered IP Phones.
CIPT1 v4.12-26
2-112
References
For additional information, refer to this resource: Bulk Administration Tool User Guide, Release 5.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/sw_ap_to/admin/bulk_adm /5_0_1/index.htm
2-113
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) Which of these tools allows you to complete bulk adds, updates, and deletions? A) B) C) D) Q2) A) B) C) D) Q3) TAPS BAT CRA CDR publisher server subscriber server primary server secondary server
On which server must you install BAT?
In which bulk configuration step do you configure BAT to generate dummy MAC addresses? A) B) C) D) validating data input files installing BAT creating phone template inserting phones
Q4)
Before you can create a BAT template, you must make sure which four settings have already been configured in Cisco CallManager Administration? (Choose four.) A) B) C) D) E) F) device pool directory number softkey template MAC address calling search space button template choose Configure > CSV File use a text editor and save to correct folder modify BAT.xlt and export to BAT format save IP Phone template in CSV format CRS BAT plug-ins Extension Mobility setting up a template creating CSV files installing BAT inserting phones and devices validating records
Q5)
What are the two ways to create CSV files? (Choose two.) A) B) C) D)
Q6)
Which two items must be installed for TAPS to function properly? (Choose two.) A) B) C) D)
Q7)
The BAT wizard guides you through which four tasks? (Choose four.) A) B) C) D) E)
2-114
Q8)
What are the first two tasks that are required to update IP Phones? (Choose two.) A) B) C) D) E) reset or restart IP Phones find the phones that you want to update specify the values to change view the log file view the query results
Q9)
Which of the following three items are checked during the BAT validation process? (Choose three.) A) B) C) D) number of lines on template and device BAT-defined dummy MAC addresses valid characters in speed-dial labels preconfiguration of device pools if referenced
2-115
Quiz Answer Key

Q1) B Relates to: Introducing the Bulk Administration Tool Q2) A Relates to: Installing BAT Q3) D Relates to: Q4) A, C, E, F Relates to: Configuring BAT Templates Q5) B, C Relates to: Creating CSV Files Q6) A, B Relates to: Using the Tool for Auto-Registered Phones Support Q7) A, B, D, E Relates to: Using the BAT Wizard Q8) B, C Relates to: Updating IP Phones with BAT Q9) A, C, D Relates to: Validating Data Input Files Inserting IP Phones into Cisco CallManager
2-116
Module 3

Overview
Cisco CallManager automatically routes calls to destinations within the same cluster. Calling to other CallManager clusters or the Public Switched Telephone Network (PSTN) requires that you configure a route plan, set up calling restrictions, ensure the quality of all calls across the IP WAN, and preserve calls should the WAN link or CallManager fail. This module discusses how to configure the gateways and intercluster trunks to make off-cluster calls, how to create basic and advanced route plans, how to apply a telephony class of service (CoS) using partitions and calling search spaces, and how to configure call admission control and survivable remote site telephony (SRST) to control WAN bandwidth and preserve calls.
Module Objectives
Upon completing this module, you will be able to configure Cisco gateways and intercluster trunks 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 or Cisco CallManager fails, and user calling restrictions are in place.
Module Objectives
Configure Cisco access gateways and intercluster trunks to support voice calls over the IP WAN and to the PSTN Configure a basic route plan to place inter-cluster calls and calls to analog devices attached to access gateways Configure advanced route plans to manipulate calling party and called-party numbers Configure partitions and calling search spaces to create a telephony class of service for users and locations Configure call admission control to prevent WAN link oversubscription and configure survivable remote site telephony to provide Cisco CallManager fallback
Outline
The module contains these lessons:
Module Outline
Lesson 3-1: Configuring Gateways and Intercluster Trunks Lesson 3-2: Configuring Basic Route Plans Lesson 3-3: Building Advanced Route Plans Lesson 3-4: Configuring Telephony Class of Service Lesson 3-5: Configuring Call Admission Control and Survivable Remote Site Telephony
CIPT1 v4.13-3
3-2
Configuring Gateways and Intercluster Trunks

Overview
This lesson covers Cisco access gateways and intercluster trunks in a Cisco IP telephony solution. You will learn about analog and digital gateways, recommended gateway requirements, gateway protocols, and the configuration of gateways and intercluster trunks.
Relevance
Your IP telephony solution will need a gateway to connect to the PSTN and an intercluster trunk to communicate with remote CallManager clusters. This lesson provides information about choosing a Cisco access gateway and integrating Cisco gateways and intercluster trunks in a Cisco CallManager solution.
Objectives
Upon completing this lesson, you will be able configure Cisco H.323 and Media Gateway Control Protocol (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. This includes being able to meet these objectives: 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 four core gateway requirements that a gateway must have to support an IP telephony network Describe three gateway communication protocols that Cisco CallManager supports Configure H.323, MGCP, and non-IOS MGCP gateways, and add and configure these gateways in Cisco CallManager Administration to interface to the IP WAN and PSTN, and to support analog phones and faxes Configure nongatekeeper-controlled trunks in Cisco CallManager Administration to enable calling to remote clusters across an IP WAN

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: General navigation in Cisco CallManager Administration Cisco Voice over IP (CVOICE) course or equivalent experience in the configuration of gateways
Outline
Outline
Overview The Gateway in an IP Telephony Infrastructure Analog and Digital Gateways Core Gateway Requirements Gateway Communication Overview Configuring Access Gateways Configuring Intercluster Trunks Summary Quiz
CIPT1 v4.13-2
3-4
The Gateway in an IP Telephony Infrastructure

This topic introduces the importance of Cisco access gateways in the overall design of the IP telephony infrastructure.
Cisco Gateway Role in IP Telephony
Voice GW
Voice GW
PSTN
Headquarters
IP WAN
Regional Center
Converts IP voice packets into analog or digital signals Connects IP voice network to analog or digital trunks or individual analog stations
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 This lesson provides an overview and basic configuration of the voice gateways that you can use with the Cisco CallManager system. For more complete information on configuring voice gateways, refer to the CVOICE course.
3-5
Analog and Digital Gateways

This topic describes analog and digital access gateways.
Analog and Digital 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. Here is a description of these gateways: Cisco access analog gateways: There are two categories of Cisco access analog 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 (recEive and transMit, or Ear and Mouth, or Earth and Magneto) ports for analog trunk connection to a legacy PBX. To minimize any answer and disconnect supervision issues, use digital gateways whenever possible. 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-6
Core Gateway Requirements

This topic provides an overview of the core requirements for a gateway to support an IP telephony network.
Core Gateway Requirements

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.
IP telephony gateways must meet these core feature requirements: Dual Tone Multi-Frequency (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 MGCP, Session Initiation Protocol (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-7
Gateway Communication Overview

This topic describes the gateway protocols that Cisco CallManager supports and identifies key Cisco access gateways that support these protocols.
Gateway Communication Overview

H.323: Cisco 2600, Cisco 3600, Cisco 3700 MGCP: VG200, Cisco 2600, Cisco 3600, Cisco 3700 Non-IOS MGCP: Catalyst 6000 WS-X6608-T1 and -E1 SCCP (Skinny): VG248
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 SRST. MGCP: MGCP uses a master-slave (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. Non-IOS MGCP: Non-IOS MGCP uses a master-slave (client/server) model in which the Cisco CallManager controls the gateway. Non-IOS MGCP gateways provide full support for Cisco CallManager supplementary services (hold, transfer, and conference features) and Cisco CallManager redundancy but do not support call survivability.
3-8
SCCP: Skinny Client Control Protocol (SCCP), or Skinny, 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. Once 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). The Cisco VG248 Analog Phone Gateway uses Skinny to register and communicate with Cisco CallManager. The Cisco VG248 supports 48 fully featured analog telephone lines to be used as extensions to the Cisco CallManager system in a 19-inch rack-mount chassis.
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. For analog gateway configuration, 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-9
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 Name IP Address
CIPT1 v4.13-7
Use these steps to configure an H.323 gateway:

Step 1
Choose Gateway from the Device menu on the Cisco CallManager Administration page. Click the Add a New Gateway hyperlink and choose H.323 Gateway from the Gateway Type menu. 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.
The Gateway Configuration page has other configuration settings. Search the Cisco CallManager Help option for gateway configuration to obtain additional information regarding these settings.
Step 2
Step 3
Note
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.
3-10
Cisco IOS Commands

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.
H323_GW(config)# gateway H323_GW(config)# voice class h323 <tag> H323_GW(config-class)# h225 tcp timeout <seconds>
H323_GW(config)# dialpeer voice <tag> voip H323_GW(config-dialpeer)# voice class h323 <tag> H323_GW(config-dialpeer)# destinationpattern <dial-string> H323_GW(config-dialpeer)# session target ipv4:ccm ip address H323_GW(config-dialpeer)# preference <0 10> H323_GW(config-dialpeer)# dtmf-relay h245-alphanumeric
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.
3-11
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
dial-peer voice 101 voip destination-pattern 1111 session target ipv4:10.1.1.101 preference 0 dtmf-relay h245-alphanumeric dial-peer voice 102 voip destination-pattern 1111 session target ipv4:10.1.1.102 preference 1
IP address of the secondary Cisco CallManager. Specifies this dial peer as the connection to the secondary Cisco CallManager. IP address of the primary Cisco CallManager. Specifies this dial peer as the connection to the primary Cisco CallManager.
Note
The CVOICE course discusses the detailed configuration of the H.323 gateway.
3-12
MGCP Configuration Information
MGCP Domain Name: Host name of gateway

Network Module 2 VICS
1/1/1 1/1/0 1/0/1 1/0/0
Endpoint Identifiers
CIPT1 v4.13-8
Use these steps to configure an MGCP gateway:

Step 1
Choose Gateway from the Device menu on the Cisco CallManager Administration page. Click the Add a New Gateway hyperlink and select one of the various MGCPcapable devices from the Gateway Type menu. Cisco CallManager automatically populates the Device Protocol field. Click Next. For the Domain Name field, enter the unique host name of the Cisco device that will be acting as the gateway. You must also select a Cisco CallManager group for redundancy. You must then select the type of network modules (NMs) and voice interface cards (VICs) that are used in the subunit slots of the MGCP gateway.
The MGCP Configuration page has other configuration settings. Search the Cisco CallManager Help option for MGCP gateway configuration to obtain information regarding these additional settings.
Step 2
Step 3 Step 4
Note
After you configure the general gateway settings, you must then configure the endpoint identifiers by using Cisco IOS software on the MGCP gateway device.
3-13
The table shown here lists commands to help configure endpoint identifiers. 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.
Router(config)# host MGCP_GW MGCP_GW(config)# mgcp MGCP_GW(config)# mgcp call-agent <ip address> MGCP_GW(config)# ccmmanager mgcp MGCP_GW(config)# ccmmanager redundant-host <ip address1> <ip address2> MGCP_GW(config)# ccmmanager switchback {graceful | immediate | scheduletime hh:mm | uptime-delay minutes}
Indicates to the gateway that the Cisco CallManager is using MGCP. Specifies the secondary and tertiary Cisco CallManagers 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:
graceful: Completes all outstanding calls before returning the gateway to the control of the primary Cisco CallManager server. immediate: 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. schedule-time hh:mm: 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 will occur at the specified time on the following day. uptime-delay minutes: 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).
MGCP_GW(config)# mgcp dtmf-relay voip codec all mode out-of-band MGCP_GW(config)# mgcp sdp simple MGCP_GW(config)# dialpeer voice <tag> pots MGCP_GW(config-dialpeer)# application MGCP MGCP_GW(config-dialpeer)# port 1/1/1
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. Configures the voice gateway to use the simple desktop messaging protocol. Creates a POTS dial peer. Configures the dial peer to use the MGCP application. MGCP is case-sensitive. Associates the dial peer with a voice port.
3-14
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 ccmmanager redundant-host (secondary and tertiary) commands.
MGCP_GW#show running-config mgcp mgcp call-agent 172.20.71.30 mgcp dtmf-relay codec all mode out-of-band mgcp sdp simple ! ccm-manager switchback graceful ccm-manager redundant-host 172.20.71.26 172.20.71.47 ccm-manager mgcp ! voice-port 1/1/1 ! dial-peer voice 4 pots application MGCPAPP
Note The CVOICE course discusses the complete configuration of the MGCP gateway itself.
3-15
Non-IOS MGCP Catalyst 6000, WS-X6608-x1
MAC Address of Port
CIPT1 v4.13-9
Use these steps to configure a non-IOS MGCP gateway:

Step 1
Choose Gateway from the Device menu on the Cisco CallManager Administration page. Click the Add a New Gateway hyperlink and choose one of the various non-IOS MGCP devices from the Gateway Type menu. If you have selected the Cisco Catalyst 6000 T1 VoIP Gateway module (WS-X6608), the Device Protocol field provides you with the option of either digital access PRI or digital access T1. After you have made your selection, click Next.
Step 2
Cisco CallManager associates with a non-IOS MGCP gateway (such as the 6608 blade) through the MAC address of the port. The show port <mod> command from enable mode on the 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.
Cat6000(enable)show port 3 Port DHCP MAC-Address IP-Address Subnet-Mask
-------- ------- ----------------- --------------- -------------3/1 3/2 3/3 3/4 3/5 3/6 3/7 3/8 disable 00-30-b6-3e-8e-c4 172.16.10.121 255.255.255.0 disable 00-30-b6-3e-8e-c5 172.16.20.122 255.255.255.0 disable 00-30-b6-3e-8e-c6 172.16.30.123 255.255.255.0 disable 00-30-b6-3e-8e-c7 172.16.40.124 255.255.255.0 disable 00-30-b6-3e-8e-c8 172.16.1.125 255.255.255.0 disable 00-30-b6-3e-8e-c9 172.16.1.126 255.255.255.0 disable 00-30-b6-3e-8e-ca 172.16.1.127 255.255.255.0 disable 00-30-b6-3e-8e-cb 172.16.1.128 255.255.255.0
3-16
Note
To display detailed information about a specific port on the module use the show port <mod/port> command.
Cisco recommends that you statically configure T1 and E1 ports that are used as digital gateways. In order to ensure that a particular port registers with the correct Cisco CallManager, confirm that the TFTP server IP address is the same address as the server that you want the port to register to within the Cisco CallManager cluster. After you add the gateway to the database, Cisco CallManager creates a configuration file in the cluster on the Cisco TFTP server, and this is where the T1 or E1 port downloads its configuration details, which include an ordered list of Cisco CallManagers. 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:
Cat6000 (enable) set port voice in 3/1 dhcp disable 172.16.1.121 255.255.255.0 vlan 1 tftp 172.16.1.5 gateway 172.16.1.1
Note 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.
3-17
Configuring Intercluster Trunks

This topic discusses gatekeeper-controlled and nongatekeeper-controlled intercluster trunks.
Gatekeeper and Intercluster Trunk Overview

Cisco IOS Gatekeeper
IP WAN
PSTN
Intercluster trunk H.225 RAS signaling Voice path
CIPT1 v4.13-10
A gatekeeper device provides call admission control for distributed call-processing systems. In a distributed system, each site contains its own call-processing capability. For example, the figure shows two sites, each with its own Cisco CallManager, that are connected by an IP WAN link. A gatekeeper provides call admission control over the IP WAN link in this example 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. An intercluster trunk is an H.323 connection that allows two Cisco CallManager clusters to be connected over an IP WAN. Use intercluster trunks when you are routing intercluster calls across a remote WAN link.
3-18
Gatekeeper and Trunk Configuration

NongatekeeperControlled Trunks Cluster 1 IP WAN Cluster 3 Cluster 4 Cluster 3 Cluster 2 GatekeeperControlled Trunks Cluster 1 GK Cluster 4 Cluster 2
Separate intercluster trunks required to communicate with each remote cluster
Single intercluster trunk sufficient to communicate with all remote clusters
CIPT1 v4.13-11
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 any H.323 gatekeeper-controlled endpoints. You also configure dial plans to route calls to and from the gatekeeper. 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 select 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-19
Intercluster Trunk Configuration
Device Name IP Address
CIPT1 v4.13-12
Use these steps to configure an intercluster trunk:

Step 1
Choose Trunk from the Device menu on the Cisco CallManager Administration page. Click the Add a New Trunk hyperlink and choose the appropriate intercluster trunk type (gatekeeper-controlled or nongatekeeper-controlled). Cisco CallManager populates the Device Protocol field with the appropriate protocol. Click Next to continue.
Step 2
Step 3
If you are configuring a nongatekeeper-controlled intercluster trunk, you can enter the IP addresses of up to three Cisco CallManagers in the remote cluster. If you are configuring a gatekeeper-controlled intercluster trunk, enter the gatekeeper information, such as the gatekeeper name, prefix, and zone.
Note The Trunk Configuration page has other configurations. Search the Cisco CallManager Help option for intercluster trunk configuration to obtain additional information regarding these settings.
3-20
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 must support these core requirements: DTMF relay, supplementary services, server redundancy, and call survivability.
CIPT1 v4.13-13
Summary (Cont.)
Cisco CallManager 4.0 and greater supports three types of gateway protocols: H.323, MGCP (Cisco IOS and non-IOS), and SCCP. Configuring gateways requires configuring the gateway itself and configuring CallManager. Intercluster trunks connect CallManager clusters across the IP WAN and can be either gatekeepercontrolled or nongatekeeper-controlled.
CIPT1 v4.13-14
3-21
References
For additional information, refer to these resources: Understanding Cisco CallManager Voice Gateways section in Cisco CallManager System Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmsys/index.htm Gatekeepers and Trunks subsection in Call Admission Control section in Cisco CallManager System Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmsys/index.htm Understanding Session Initiation Protocol (SIP) section in Cisco CallManager System Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmsys/index.htm Gateway Configuration section in Cisco CallManager Administration Guide, Release 4.0(1) http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmcfg/index.htm WAN Switching Products: http://www.cisco.com/warp/public/779/largeent/select_products/wan/WAN_ms.html
3-22
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) Which interface does a voice gateway provide? A) B) C) D) Q2) A) B) C) D) Q3) A) B) C) D) Q4) A) B) C) D) Q5) A) B) C) D) Q6) X.25 to SS7 VoIP to H.323 PSTN to VoIP PSTN to PBX FXO T1 E&M FXS server redundancy call survivability trunk configuration simplicity DTMF relay support H.323 MGCP Skinny Non-IOS MGCP support for DTMF relay support for inline power support for multiple VLANs on single port support for disconnect supervision
Which type of interface is on a digital voice gateway?
What is an advantage of a gatekeeper-controlled intercluster trunk?
The Catalyst 6000 and WS-X6608-x1 support which gateway protocol?
Which item is a core gateway requirement?
Which protocol requires you to perform the bulk of the configuration on the router (gateway)? A) B) C) D) MGCP Non-IOS MGCP H.323 SCCP
3-23
Quiz Answer Key

Q1) C Relates to: The Gateway in an IP Telephony Infrastructure Q2) B Relates to: Analog and Digital Gateways Q3) C Relates to: Configuring Intercluster Trunks Q4) D Relates to: Gateway Communication Overview Q5) A Relates to: Core Gateway Requirements Q6) C Relates to: Configuring Access Gateways
3-24
Configuring Basic Route Plans

Overview
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. This lesson also provides background knowledge about route plans in order for you to better understand the actual flow of a call as it is routed throughout a Cisco IP telephony network.
Relevance
In order to successfully implement or support a Cisco IP telephony environment, you must be able to configure route plans in Cisco CallManager to route internal and external calls appropriately.
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 includes being able to meet these objectives: Identify the necessary elements for creating external route plans in Cisco CallManager to include devices, 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

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: Familiarity with the North American Numbering Plan (NANP) Familiarity with Cisco IOS software
Outline
Outline
Overview External Call Routing Route Groups Route Lists Route Patterns Digit Analysis Summary of Call Routing Summary Quiz
CIPT1 v4.13-2
3-26
External Call Routing

This topic explains external call routing in a basic route plan.
Route Plan Call Types

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

Internal (on-cluster) calls Destination DN is registered with Cisco CallManager. External (off-cluster) calls External route patterns must be configured on Cisco CallManager.
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 enables you to route 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 MGCP or Skinny-based gateways. When an 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 will then search 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-27
External Route Elements in Cisco CallManager

Route pattern:
Matches dialed number for external calls Performs digit manipulation (optional) Points to a route list for routing
Route Pattern
Configuration Order
Route list:
Chooses path for call routing Points to prioritized route groups
1st Choice
Route List
2nd Choice
Route group:
Performs digit manipulation Points to the actual devices
Route Group
Route Group
1st Choice 2nd Choice
Gateways (H.323, MGCP) Gatekeeper Intercluster Trunk (remote Cisco CallManager)

Devices:
IP WAN
GK
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-28
Route Plan Configuration Process

Add gateway devices and trunks
MGCP-Based VG200 Cat 6K GWs 2600 3600 H.323-Based All IOS GWs
Device Protocol H.225
Remote CallManager
Device Protocol Intercluster Trunk Route Group 2 Catalyst 6K Digital 2600 (MGCP) Digital VG200 Route List 2 Route Group 2 Route Group 3 Route Group 1
Build route groups from available devices Build route lists from available route groups
Route Group 1 Remote CallManager 2600 (MGCP) 3640 Route List 1 Route Group 1 Route Group 2 Route Group 3
Build a route pattern to available route lists or gateway devices
CIPT1 v4.13-5
Shown here is the general process for route plan configuration. You can construct a route plan using this process: Add gateway devices: Create gateway devices using the Device menu selection. Build route groups from available devices: Select and place gateway devices in an ordered list to build a route group. Build route lists from available route groups: Select and order route groups into a route list. 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-29
Route Groups
This topic describes the functions and configuration of route groups.
Route Groups Overview
User Dials External Number
723-8912
Route Pattern
1st Choice
723-xxxx
Digital GW 1
Route List
Route Group
PSTN
Route groups create a prioritized list of voice gateways.

2nd 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 some of the common 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 (usually across the IP WAN for toll savings) and keep a backup path for external calls (usually the 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 longdistance carriers. Each long-distance carrier offers different rates for long-distance calls on their 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-30
Route Group Configuration
Add gateways from Device Name drop-down menu.

Use these steps to configure a route group:

Step 1
Choose Route Group from the Route Plan menu on the Cisco CallManager Administration page. Click the Add a New Route Group hyperlink. Give the new route group a name and click Continue. Choose a gateway from the Available Devices menu to add that gateway to the route group.
Step 2
Step 3
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 per gateway instead of groups of gateways or ports, you can set up route groups so that they can contain only one gateway.
3-31
Route Lists
The topic describes the functions and configuration of route lists.
Route List Overview
User Dials Number
1st Choice Ports 1 - 8
Analog GW 1
IXC 1
Route Pattern Route Group 1

1st Choice 2nd Choice Ports 1 - 4
Route List
2nd Choice 1st Choice Ports 5 - 8
Analog GW 2
IXC 2
Route Group 2
2nd Choice Ports 1 - 8
Route lists are a prioritized list of route groups.

Analog GW 3
IXC 3
CIPT1 v4.13-8
Route lists consist of an ordered list of route groups. Route lists expand on 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 only to a single route group, route groups can belong to any number of route lists. Route groups give you granular 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 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 callrouting 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 Building Advanced Route Plans lesson later in this module.
3-32
Route List Configuration
Add and prioritize route groups.

Use these steps to configure a route list:

Step 1
Choose Route/Hunt List from the Route/Hunt submenu under Route Plan on the main Cisco CallManager Administration page. Click the Add a New Route/Hunt List hyperlink. Give the new route/hunt list a name and description, and click Continue. Click the Add Route Group button to add the appropriate route groups. This action brings up the Route/Hunt List Detail Configuration page. You can set calling and called-party transformations at this point. Click Insert to return to the Route List Configuration page. Use the arrows to prioritize the route groups.
Step 2
Step 3
Step 4
3-33
Route Patterns
This topic describes route patterns for external call routing.
Route Pattern Overview

Route patterns match E.164 numbers and are commonly used for external call routing.
Digital GW 1
User Dials External Number
723-8912
Route Pattern
723-xxxx
1st Choice
Route List
Route Group
PSTN
2nd Choice
Digital GW 2
CIPT1 v4.13-10
In the 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: When a user dials a number, Cisco CallManager will analyze the dialed digits. If the set of digits matches a registered DN, Cisco CallManager routes the call to the internal destination. 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. 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. 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 will receive a fast busy signal.
3-34
Route Pattern: Commonly Used Wildcards

Wildcard x @ ! [x-y] [^x-y] . # Description Single digit (0-9, *, #) North American Numbering Plan One or more digits (0-9) Generic range notation 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 all numeric digits, 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
Wildcard 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, *, # [xyz] [x-y] Description Single digits that can be included in a route pattern. Set of matching digits. For example, [458] matches one occurrence of either 4, 5, or 8. 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. 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 #. 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. 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.
[^x-y]
<wildcard>?
<wildcard>+
3-35
Route Pattern Examples
Pattern 1234 1*1x 12xx 13[25-8]6 13[^3-9]6 13!# Matches 1234
Result Matches numbers between 1*10 and 1*19 Matches numbers between 1200 1299 Matches 1326, 1356, 1366, 1376, 1386 Matches 1306, 1316, 1326, 13*6, 13#6 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 of this is the 9.@ route pattern. The first digit of the route pattern matches a dialed digit of 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-36
The NANP encompasses a number of dial strings, as presented in the following table. Dial Strings
Dial String Service calls Local calls Expanded local calls Long-distance calls Direct-dial long-distance calls Description Service calls are in the form of three- to four-digit numbers that are used to access telephony services such as 911, 411, 611, etc. 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 are in the form of a 10-digit number (xxx-xxxxxxx) that is used to dial expanded-area local 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 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 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 that you are calling.
International calls
Note
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 Building Advanced Route Plans lesson.
3-37
Route Pattern Configuration
Configure a route pattern and point it to a gateway or route list.

Use these steps to configure a route pattern:

Step 1
Choose Route Pattern/Hunt Pilot from the Route Plan menu on the Cisco CallManager Administration page. Click the Add a New Route/Hunt Pattern hyperlink. To create a route pattern, type your route pattern (including wildcards if necessary) in the Route Pattern/Hunt Pilot field and select a route list or gateway from the Gateway or Route/Hunt List menu. 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.
Step 2 Step 3
Step 4
If Cisco CallManager receives a dial string for which multiple route patterns match, 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 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-38
If your route patterns point to specific gateways and not route lists, you can set calling 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 gatewaylevel transformation settings and instead uses the transformation settings that are configured on the route list. Near the bottom of the Route Pattern/Hunt Pilot Configuration page, 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.
3-39
Digit Analysis
This topic explains the digit analysis behavior of Cisco CallManager.
Dialing Behavior
1000 Dialed Digits <none> 1 0 0 1 1001 Call Setup List Potential Matches List Potential Matches List Potential Matches List Potential Matches List Current Match Route Patterns 1XXX 10XX
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, 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.
2. While performing Step 1, 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. 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 Step 1 using the new digit string.
3-40
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. Furthermore, 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.
3-41
Digit Collection
User dial string: 1111
1111 121X 1[23]XX
Match! Does not match Does not match Does not match Does not match Does not match
Cisco CallManager actions: No other patterns could match; extend call.
131 13[0-4]X 13!
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 matches a route pattern exactly. 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, any further 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-42
Closest Match Routing
User dial string: 1211
1111 121X 1[23]XX
Does not match Match! Match! Does not match Does not match Does not match
Matches 1 digit string Select as closest match Matches 200 digit strings
131 13[0-4]X 13!
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! from being 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, any further 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 1219). The route pattern 1[23]XX matches 200 destinations (1200 1299 and 1300 1399). Cisco CallManager then routes the call to the gateway or route list that is associated with the 121X route pattern.
3-43
Interdigit Timeout
User dial string: 1311<timeout>
1111 121X 1[23]XX
Does not match Does not match Match! Does not match Match! Match!
Matches 200 digit strings Matches 50 digit strings Select as closest match Matches digit strings
8
131 13[0-4]X 13!
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. The Cisco CallManager in this example includes the route patterns shown in the figure. In this example, the user has dialed a string of 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 if the user intends to keep 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 1299 and 1300 1399). The route pattern 13[0-4]X matches 50 destinations (1300 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.
Note The system interdigit timeout defaults to 15 sec. 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.
3-44
Summary of Call Routing

This topic summarizes the call-routing process.
Simple Route Plan Example

Route Pattern can match route list or gateway.
723-XXXX 836-XXXX 868-XXXX
User Dials Number 408-555-XXXX
Local_GW
LEC
$0.07 per min.
Route Pattern
Route Pattern Cisco Access Digital_GW 1

1st Choice
RL_PSTN Route List
RG_PSTN Route Group
PSTN
Cisco Access Digital_GW 2
2nd Choice
$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-45
Route Plan Example 2

Secondary Voice Path
Prepend 1408 and send to PSTN
Users required to dial 7 digits for intersite calls 526-1111

A
Gatekeeper(s)
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 CCM
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 calledparty 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-46
Basic Route Plan Summary

Cisco Gateways
Route 1st choice Group A
2n dc ho e ic ho e tc
1st choice
Digital Gateway .08 per minute

Global Switch or PBX
Route Pattern 9.@
Route List
2nd choice
Route Group B 2nd choice

3rd ch o ic e
1s
WS-X6608-T1 .12 per minute
3rd choice
Route 1st choice Group C

2nd choice
WS-X6624-FXS .15 per minute

Route Pattern 8.@
CIPT1 v4.13-20
A basic route plan consists of the following items: 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 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. Route group(s) (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 as follows: 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-47
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 not available. 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-48
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 destination. 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 the following items: voice gateways and trunks, route groups, route lists, and route patterns.
3-49
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) Which of the following contains a list of gateways to use in precedence order? A) B) C) D) Q2) route group route list translation pattern route pattern
What is the key to making toll bypass and PSTN fallback features transparent to your users? A) B) C) D) digit manipulation 10-digit dialing route filtering route summarization * ! . $ 15 150 1500 15000 route groups voice gateways route lists route patterns Cisco CallManager clusters route groups route patterns route lists devices
Q3)
Which three of the following are valid wildcards? (Choose three.) A) B) C) D)
Q4)
Which of the following sets the interdigit timeout to 15 seconds? A) B) C) D)
Q5)
Which of the following constitutes a basic route plan? (Choose four.) A) B) C) D) E)
Q6)
What can be placed into a route list? A) B) C) D)
3-50
Quiz Answer Key

Q1) A Relates to: External Call Routing Q2) A Relates to: Route Lists Q3) A, B, C Relates to: Route Patterns Q4) D Relates to: Digit Analysis Q5) A, B, C, D Relates to: Summary of Call Routing Q6) A Relates to: Route Groups
3-51
3-52
Configuring Advanced Route Plans

Overview
This lesson discusses several techniques in Cisco CallManager to change the calling number or dialed digits. The 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.
Relevance
Digit manipulation is necessary to increase employee productivity by providing abbreviated dialing and truncating the dialed digits to extend calls. It is also important to protect a Cisco IP telephony solution from toll fraud by applying route filters.
Objectives
Upon completing this lesson, you will be able to configure advanced route plans to perform functions to include blocking access to specified area codes and manipulating digits to change the 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 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 DDIs 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 security desk and 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

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: Basic route plan construction
Outline
This lesson includes these topics:
Outline
Overview Route Filters Discard Digits Instructions Transformation Masks Translation Patterns Route Plan Report Summary Quiz
CIPT1 v4.13-2
3-54
Route Filters
This topic discusses the configuration and application of route filters in a route plan.
Route Filter Basics

The 9.@ Route Pattern
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 Pattern
9.@
The @ wildcard represents all the routes defined in the national numbering plan. Cisco CallManager identifies tags in each number: INTERNATIONAL-ACCESS AREA-CODE OFFICE-NUMBER Route filters are logical expressions that operate on these tags. Useful for blocking 900, Caribbean, international...
CIPT1 v4.13-3
Route Filter
Local Only
INTERNATIONAL-ACCESS DOES-NOT-EXIST AND AREA-CODE DOES-NOT-EXIST
Actual Routes in CallManager: 9.[2-9]11 9.[2-9]XX XXXX

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 local 7-digit dialing in North America. Most 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 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 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-55
Generally, telephone company (telco) service providers arrange many NXXs in a given area codecontiguously where 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
Tag Name AREA-CODE COUNTRY-CODE END-OF-DIALING INTERNATIONAL-ACCESS INTERNATIONAL-DIRECTDIAL INTERNATIONAL OPERATOR LOCAL-AREA-CODE LOCAL-DIRECT-DIAL LOCAL-OPERATOR LONG-DISTANCE-DIRECTDIAL LONG-DISTANCEOPERATOR NATIONAL-NUMBER OFFICE-CODE SATELLITE-SERVICE SERVICE SUBSCRIBER TRANSIT-NETWORK TRANSIT-NETWORKESCAPE
3-56 Cisco IP Telephony Part 1 (CIPT1) v4.0
Example Pattern 1 214 555 1212 011 33 123456# 011 33 123456# 01 1 33 123456# 01 1 33 123456# 01 0 214 555 1212 1 555 1212 0 555 1212 1 214 555 1212 0 214 555 1212 011 33 123456# 1 214 555 1212 011 88141234# 1 411 1 214 555 1212 101 0321 1 214 555 1212 101 0321 1 214 555 1212
Description The area code in an 11-digit longdistance call The country code in an international call The #, which terminates interdigit timeout for an international call The initial 01 of an international call The digit that denotes the direct-dial component of an international call The digit that denotes the operator component of an international call The area code in a 10-digit local call The initial 1 that is required for some 7digit calls The initial 0 that is required for operatorassisted local calls The initial 1 that is required for longdistance direct-dialed calls The initial 0 that is required for operatorassisted long-distance calls The national number component of an international call The office exchange code of a North American call A specific value that is associated with calls to the satellite country code Access to local telephony provider services A particular extension that is served by a given exchange Long-distance carrier code 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 here 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 19725551234 101028819725551234 01133123456789
3-57
Configuring Route Filters
Operator NOT-SELECTED EXISTS DOES-NOT-EXIST
Description Do not filter calls base on the dialed digit string associated with this tag. Filter calls when the dialed digit string associated with this tag is found. Filter calls when the dialed digit string associated with this tag is not found. Filter calls when the dialed digit string associated with this tag matches the specified value
==
CIPT1 v4.13-5
You can configure a route filter by using the Cisco CallManager Administration window.
Choose the Route Plan menu. Choose Route Filter from the menu bar. Choose NANP from the Dial Plan menu. 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 if 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-NOT-EXIST 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-58
9.@ with Route Filter AREA CODE == 900
9 [2-9]11 9 [2-9]XX XXXX
Not added: no AREA-CODE Not added: no AREA-CODE
9 [2-9]XX [2-9]XX XXXX Not added: no AREA-CODE (It contains LOCAL-AREA-CODE) 9 1 [2-9]XX [2-9]XX XXXX Added: AREA-CODE constrained to 900 900 9 011 3[0-469] ! Not added: no AREA-CODE
CIPT1 v4.13-6
The figure here shows the patterns that Cisco CallManager adds when you apply the AREACODE = = 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 on the Route Pattern/Hunt Pilot Configuration window, you would allow all calls where AREACODE = 900, while denying all other route patterns. Generally, this is not your desired result. Instead, choose the Block this pattern radio button to prevent all calls where AREA-CODE = 900 but allow all other route patterns.
3-59
Discard Digits Instructions

This topic discusses the discard digits instructions (DDIs) that are available in Cisco CallManager.
Discard Digits Instructions

If the pattern is 9.5@
Instructions
PreDot PreAt 11D/10D@7D 11D@10D IntlTollBypass 10-10-Dialing Trailing-#
Discarded Digits
95 1 214 555 1212 95 1 214 555 1212 95 1 214 555 1212 95 1 214 555 1212 95 011 33 1234 # 95 1010321 1 214 555 1212 95 1010321 011 33 1234 #
Used for
Access codes Access codes Toll bypass Toll bypass Toll bypass Suppressing carrier selection 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. 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 here, are additive. The DDI PreDot 10-10-Dialing combines the effects of each individual identifier. If you do not want to discard digits, choose NoDigits.
3-60
Using PreDot Discard Digits Instructions

Use discard digits instructions to strip initial digits. Use only NoDigits or PreDot unless the pattern contains an @ wildcard.
User dials: 98123
Cisco CallManager
Match: 9.8XXX Discard: PreDot
Called party: 8123
PBX
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.
3-61
Using Compound Discard Digits Instructions
Cisco CallManager
Use discard digits instructions to discard whole sections of the dialed number. All discard digit instructions 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 12145551212 to the gateway device.
3-62
Transformation Masks
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 in order to extend or truncate it
An X in a mask lets digits pass through.
45000 Mask 808236XXX 8082365000
Digits in masks replace number digits.
Mask
8082365000 45XXX
_____ 45000 Blanks block number digits.
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 calling party 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 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 sevendigit numbers, appending area codes and office codes to interoffice calls that are dialed as fouror 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 you wish to mask and the mask itself.
3-63
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. Dialing transformations 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.
3-64
Calling Party Transformation Order

Directory number 35062 21471XXXXX 2147135062 40885XX000 4088535000
Apply the external phone number mask. Apply the calling party transformation mask.
External phone number mask Calling party transformation mask Caller ID
CIPT1 v4.13-11
The example here 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-65
Called Party Transformation Order

Dialed number
Apply discard digits instructions. Apply the called-party transformation mask. Apply prefix digits.
9 1010321 18085551221 10-10-Dialing 9 18085551221
discard digits instructions Called-party transformation mask Prefix digits Called number
XXXXXXXXXX 8085551221 8 88085551221
CIPT1 v4.13-12
The example here 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 occurs when Cisco CallManager must convert the long-distance number that the calling user 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-66
Configuring Transformation Masks

Transformation masks configured from: Route pattern configuration Route list configuration Transformation masks configured at route list level have priority over those configured at route pattern level.
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 network. 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-67
Transformation Example
1
Users User Dial Numbers
2
Route Pattern
3
Discard Digits Instruction
A - 5062 B - 5063 C - 5064
A - 91234 B - 91324 C - 91432
Wildcards allow all dialed numbers to match one route pattern.
9.1XXX
Discard 9
6
To: 1000 From: 5000
Users Dialed Numbers
5 A 1000 B 1000 C 1000

User Dialed Numbers
Caller ID
A 1234 B 1324 C 1432 4

X000
X000
A 5000 B 5000 C 5000

User Directory Numbers
Extension 1000 Rings
Transform Called Number
Transform Calling Number

CIPT1 v4.13-14
The figure summarizes how transformations to the called party (dialed digits) and to the calling party number 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:
User A has a DN of 5062. This user dials DN 91234. The dialed number matches the route pattern 9.1XXX. The DDIs contain the instructions to discard the 9. The dialed number is now 1234. 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. Cisco CallManager then passes the called number 1234 through the called-number transformation X000 that changes this number to 1000. The result is a calling party number of 5000 and a called number of 1000.
Step 5
Step 6
3-68
Translation Patterns
This topic discusses the functionality and configuration of translation patterns.
Translation Pattern
Digits
Find best match. Apply calling and called Apply calling and calledparty transformations party transformations.
Digits
Pattern type? Route pattern
Trans
lation
n patter
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. Cisco CallManager uses the results of the second analysis attempt to determine which destination to ring. 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-69
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, click 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.
3-70
Common Uses of Digit Translation

Can be used to send calls to unassigned DID numbers to attendant or recording
A
Translation Pattern = XXXX Called Party Transform Mask = 4111 CallManager uses longest match so XXXX will match any nonconfigured number and get sent to 4111 (attendant)
PSTN
PSTN DID Range 408-555-1xxx
Employee Attendant Phones (4111)
OR
Internal Extensions 4XXX
PSTN DID range does not match internal range Translation Pattern = 1XXX Called Party Transform Mask = 4XXX
CIPT1 v4.13-17
San Jose
The figure here shows an application for translation patterns. When the 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-71
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 Value (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-72
Generating a Route Plan Report
Choose Route Plan Report from the Route Plan menu. Click the View In File hyperlink 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 50 items per window.
Step 2
Choose View In File. A 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 Step 4
You may change the name of the file, but the filename must have a .csv extension.
Select the location in which to save the file and click Save. The file should now be saved to the location that you designated. Locate the CSV file that you just saved and double-click its icon to view it.
Step 5
3-73
Summary
Summary
A route filter permits or restricts access through a route list by using route patterns. A discard digits instruction 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 route patterns, translation patterns, and call park numbers.
References
For additional information, refer to these resources: Smith, Anne, Chris Peace, Delon Whetton, and John Alexander. Cisco CallManager Fundamentals: A Cisco AVVID Solution. San Jose, California: Cisco Press; 2001. Understanding Route Plans section in Cisco CallManager System Guide Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmsys/index.htm Route Filter Configuration, Route Group Configuration, Route/Hunt List Configuration, Route Pattern/Hunt Pilot Configuration, Translation Pattern Configuration, and Route Plan Report sections in Cisco CallManager System Guide Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmcfg/index.htm
3-74
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) Which of these file types does Cisco CallManager create by default when generating a route plan report? A) B) C) D) Q2) A) B) C) D) Q3) .csv .doc .pdf .txt 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
What does Cisco CallManager do when dialed digits match a translation pattern?
When DN 8500 calls and a calling transformation mask of 972555XXXX is applied, which CLID is sent? A) B) C) D) 8500 5558500 9725558500 19725558500
Q4)
What are the final digits that Cisco CallManager sends when the discard digits instruction PreDot is applied to the 9.8085551212 pattern? A) B) C) D) 98085551212 5551212 95551212 8085551212 x ? ! @
Q5)
Network administrators use route filters with which route pattern wildcard? A) B) C) D)
3-75
Quiz Answer Key

Q1) A Relates to: Route Plan Report Q2) D Relates to: Translation Patterns Q3) C Relates to: Transformation Masks Q4) D Relates to: Discard Digits Instructions Q5) D Relates to: Route Filters
3-76
Configuring Telephony Class of Service

Overview
This lesson discusses how to implement partitions and calling search spaces to provide a telephony class of service (CoS) that is based on users and locations. You will also learn the importance of partitions and calling search spaces as they apply to emergency call routing.
Relevance
Providing CoS in a Cisco IP telephony solution establishes levels of access for the different users in your organization. By placing calling restrictions on where users can call or forward their calls, you will increase the security and safety of your IP telephony network.
Objectives
Upon completing this lesson, you will be able configure partitions and calling search spaces in Cisco CallManager to create a telephony CoS within a Cisco IP telephony cluster. This includes being able to meet these objectives: Describe how partitions and calling search spaces solve three routing problems in a telephony network Describe how to create partitions in Cisco CallManager that consist of logical groupings of route patterns, DNs, and Cisco IP Phones Configure calling search spaces in Cisco CallManager that include ordered partitions to limit calling privileges Identify how partitions and calling search spaces can be used to ensure proper emergency call routing Identify the purpose of the Cisco Emergency Responder in enabling emergency agencies to identify the location of 911 callers

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: A basic understanding of Cisco CallManager Administration and basic route plan
Outline
Outline
Overview Class of Service Partitions Calling Search Spaces Using Partitions and Calling Search Spaces for Emergency Calls Cisco Emergency Responder Summary Quiz
CIPT1 v4.13-2
3-78
Class of Service
This topic provides a general definition and analogies for CoS, partitions, and calling search spaces.
General Definition
Class of Service 1 Class of Service 2 Class of Service 3
Lobby
Employee
Executive
IP WAN
Long-Distance International
Employee
PSTN
Executive
CIPT1 v4.13-3
CoS is best defined in Newtons Telecom Dictionary, 18th Updated and Expanded Edition. The dictionary has three definitions for CoS: 1.) Internal to a PBX, 2.) On the public switched network, and 3.) On a packet switched network, courtesy of Cisco Systems, Inc. CoS is defined by the first Newtons definition, Internal to a PBX, as follows: Each telephone in a corporation telephone system may have a different collection of privileges and features assigned to it, such as access to long distance, international calls, 900 area code calls, 976 local calls, etc. Let us say that you are concerned that your people will waste the companys money by frivolously calling expensive numbers, so you might wish to define Class of Service assignments in your PBX. You could have one thats called ability to dial everywhere except 900 area code, international calls and all 976 numbers. That could be Class of Service Assignment B. When you give a telephone to an employee, you could give that person COS B. Executives, on the other hand, might need to call internationally, but not 900 area code or 976 calls. That could be called Class of Service Assignment A. Class of Service assignments, if properly organized, can become an important tool in controlling telephone abuse. Cisco CallManager has the ability to apply the above CoS to devices by configuring partitions and calling search spaces.
3-79
Partitions and Calling Search Spaces: Analogy with Subnets and Access Lists
Access List/ Calling Search Space permit B permit C (implicit) deny D Subnet/Partition A Subnet/Partition B Subnet/Partition C Subnet/Partition D
Partition = Where you are Consists of devices with similar reachability characteristics Items placed in partitions Directory numbers (DNs), route patterns, voice-mail ports...
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 Is assigned to IP Phones, SoftPhones, and gateways
CIPT1 v4.13-4
Partitions and calling search spaces are analogous to routers with access lists. You can think of a partition as an IP subnet where you place users. In addition, you can compare a calling search space to an inbound access list that dictates the subnet that you can reach.
3-80
Problems Addressed
Routing by geographical location Routing by tenant Routing by class of user
CIPT1 v4.13-5
Partitions and calling search spaces are designed to address three specific problems: Routing by geographical location: Partitions and calling search spaces ensure that Cisco CallManager does not redirect callers to the incorrect geographical location. This is critical in the case of emergency calling. Routing by tenant: Partitions and calling search spaces dictate the numbers that tenants can reach. This is useful in a multitenant building with a centrally managed telephone system. Routing by class of user: Partitions and calling search spaces dictate the numbers that individuals are able to dial. This is useful for restricting employees or lobby telephones from dialing long-distance numbers. Partitions and calling search spaces provide a way to segregate the global dialable address space. The global dialable address space is the complete set of dialing patterns to which Cisco CallManager can respond.
3-81
Partitions
This topic discusses partitions and the configuration of partitions.
Partition Definition
Partition Lobby
Partition Employee
Partition Executive
Partition Gateway
LobbyPT
EmployeePT
ExecutivePT
Local and WAN GatewayPT
Directory Numbers 63500 63501 63502 63503
Directory Numbers 64050 64051 64052 6405x
Directory Numbers 64020 64021 64022 6402x
Route Pattern 9.@ 9.8@ 5.7xxxx
A logical grouping of DNs and route patterns All patterns in a partition equally reachable
CIPT1 v4.13-6
A partition is a logical grouping of DNs and route patterns with similar reachability characteristics. Items typically placed in partitions are IP Phones, DNs, and route patterns. For simplicity, partitions are usually named for their characteristics, such as AZ911PT, for the Arizona 911 partition. When a DN or route pattern is placed into a certain partition, a rule is created that specifies the devices that are able to call that directory number or route pattern. Partitions do not significantly impact the performance of digit analysis, but every partition that is specified in the calling search space of a device does require an additional pass through the analysis data structures. Digit analysis looks through every partition in a calling search space for the best match. Cisco CallManager uses the order of the partitions that are listed in the calling search space only to break ties when there are equally good matches in two different partitions. If you do not specify a partition for a route pattern or a DN, Cisco CallManager lists the route pattern or DN in the null partition to resolve dialed digits. Digit analysis always looks through the null partition last.
3-82
Partition Configuration
Assigned to DNs, Route Patterns, Translation Patterns

To configure partitions, click the Route Plan menu and choose Partition. When the Find and List Partition window appears, click the Add a New Partition hyperlink. The Partition Configuration window that is shown in the figure appears. From here, you can add any number of partitions using the following syntax: << partitionName >>, <<description>> 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 page 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 page, and select the partition from the menu.
3-83
Calling Search Spaces

This topic discusses the function and configuration of calling search spaces.
Calling Search Space Definition

Lobby Phone Employee Phone Executive Phone Local and WAN GWPT
Calling Search Space E911PT EmployeePT
Calling Search Space E911PT EmployeePT LocalGWPT WANGWPT
Calling Search Space E911PT EmployeePT GWPT ExecutivePT
Calling Search Space E911 EmployeePT
An ordered list of partitions Digit analysis looks through calling search space (list of partitions) when searching for the closest match for the caller-dialed number Assigned to devices, phones and gateways, and translation patterns
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 determine the partitions that calling devices (such as Cisco IP Phones, Cisco IP SoftPhones, and gateways) can reach when attempting to complete a call. When you assign a calling search space to a device, the list of partitions in the calling search space defines the route patterns and DNs that the Cisco CallManager allows the device to reach. 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.
3-84
Calling Search Space Configuration
Assigned to Devices, (Phones, Gateways, etc.) and Translation Patterns

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 page in Cisco CallManager Administration (choose Route Plan > Calling Search Space.) You can use the arrows between the Available Partitions and Selected Partitions dialog boxes 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 dialog boxes. 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-85
Using Partitions and Calling Search Spaces for Emergency Calls

This topic explains how you can use partitions and calling search spaces to force Cisco CallManager to route users dialing the 911 (or 9.911) string through a gateway that connects to the PSTN in the local area. (Although the 911 implementation is specific to the North American market, you can use the same configuration for emergency call numbers anywhere in the world.)
Emergency Call Routing
Centralized CallManager Cluster
911
911
Site 1
PSTN
Router/ GW IP WAN Router
Hub
IP WAN
Site 2
IP WAN Router
CIPT1 v4.13-10
Correct configuration of emergency call routing is critically important in any voice network. One of the benefits of IP telephony is the ability to forward voice calls over the IP WAN. In the case of emergency calls, this capability can be detrimental. The figure above shows three sites that are connected through the PSTN and the IP WAN. These sites could exist at disparate locations around the world. A serious problem can arise if a user located in site 2 dials an emergency number (such as 911) and, through poor configuration, it is forwarded across the WAN and out the PSTN connection at site 1. You can prevent this situation from occurring through the proper implementation of partitions and calling search spaces. You must place the emergency numbers for each geographic location in their own partition. Then, you should give the devices at each location the ability to reach only the partition that contains the emergency numbers for their location.
3-86
Cisco Emergency Responder

This topic discusses the Cisco Emergency Responder (ER) application that is used to provide Enhanced (E911) service in a Cisco IP telephony solution.
Cisco Emergency Responder Overview

Enhanced 911 requirements:
Emergency calls routed to the right emergency center Call taker knows the location of caller and can return the call Multiline telephone systems: Identify at least the building and floor of a 911 caller
PSAP (City A)
911
Cisco Emergency Responder:

Provides full E911 support in Cisco CallManager, gateways, Extension Mobility Automatically tracks user moves Sends correct location of 911 callers to correct PSAP Notifies onsite personnel via web/phone/e-mail/pager
Cisco ER enables emergency agencies to identify the location of 911 callers and eliminates the need for any administration when telephones or people move from one location to another. E911 extends the basic 911 emergency call standard to make it more reliable. In basic 911 in North America, if a caller dials 911, the call is routed to a public safety answering point (PSAP), also called the 911 operator. The PSAP is responsible for talking to the caller and arranging the appropriate emergency response, such as sending police, fire, or ambulance teams. E911 extends this standard with these requirements. The emergency call must be routed to the local PSAP based on the location of the caller. (In basic 911, the call simply needs to be routed to some PSAP, not necessarily the local one.) The caller location information must be displayed at the terminal of the emergency operator. This information is obtained by querying an Automatic Location Information (ALI) database. Large organizations that maintain their own phone systems (for example, PBX, Cisco CallManager) are responsible for maintaining the ALI database information.
3-87
Cisco ER is appropriate for the following: Single or multicluster Cisco CallManager installations with 48+ Cisco IP Phones per site E911 extension support to include extension mobility and IP Phones that move between cubicles, offices, floors, buildings, or campuses Shared-line appearances on telephones in multiple physical locations Cisco IP SoftPhones that run on desktops or laptops that are directly attached to Cisco Catalyst switches Cisco IP Phones that are connected to Cisco Catalyst switches Cisco ER is not necessary for the following: Stationary Cisco IP Phones that do not use extension mobility or shared-line appearances Small offices with fewer than 48 telephones
Deployment scenarios
The following are deployment scenarios that are addressed by Cisco ER: Large networks Ability to run Cisco ER on redundant dedicated Cisco Media Convergence Server (MCS) platforms Ability to communicate with multiple Cisco CallManager clusters with storage of the ER configuration information in the directory of a single Cisco CallManager cluster Each campus with one or more Cisco CallManager clusters should have a pair of ER servers. Use centralized ER servers and distributed Centralized Automatic Message Accounting (CAMA) and PRI gateways for the centralized deployment model.
3-88
Endpoint Location Operation

79xx SoftPhone
5000 4224 6500
3500
3) SNMP Get: CDP neighbors 4) SNMP Get: configured VLANs CAM table per VLAN Backup Cisco ER
2) SNMP Get: New phone registrations (MAC address info)
Primary Cisco ER
1) Seed switch configuration: IP address, SNMP info, etc.

CIPT1 v4.13-12
Locating endpoints is a crucial element in Cisco ER operation. The preferred method is to use the MAC address of the telephone; this address is obtained via Cisco Discovery Protocol. An alternate method of discovery is via the content-addressable memory (CAM) table (mapping of MAC address to Catalyst switch ports). Here are key points to consider when you are using the switch Cisco Discovery Protocol neighbors method (preferred) to find the telephone devices: Requires a list of switch IP addresses (or Domain Name System [DNS] names) with Simple Network Management Protocol (SNMP) read strings in Cisco ER Requires Cisco Discovery Protocol support in the telephone device Creates minimal impact to the switching infrastructure Here are key points to consider when you are using the CAM table method (alternate) to find telephone devices: Requires a list of switch IP addresses, Telnet and enable passwords, and SNMP read strings Is used only after the failure to discover telephones as Cisco Discovery Protocol neighbors Has a slightly increased impact on the switching infrastructure as compared to the preferred method; a per-switch option to disable exists The following are the supported endpoints that are used with Cisco ER version 1.2: Cisco Discovery Protocol neighbor search on Cisco Catalyst switches: Cisco IP Phone models 7960, 7940, 7912, 7910, 7905G, and 7902 Cisco IP Conference Station 7935 All other Skinny phones with Cisco Discovery Protocol support, with the exception of Analog Telephone Adapter (ATA) devices
3-89
CAM table search on Cisco Catalyst switches: Cisco IP SoftPhone version 1.2 and 1.3 or later, including connections via IEEE 802.11b wireless Ethernet devices Cisco IP Phone models 12 SP+ and VIP 30 All Skinny-based phones that lack Cisco Discovery Protocol support Analog phones that are connected to VG248 and ATA devices Legacy PBX or basic telephone service Generic H.323 or SIP endpoints Cisco IP Phones that are not attached to an identified Cisco Catalyst switch (for example, home-based telecommuters, within the boundaries of Public Service Automatic Location Information (PS/ALI) database service provider territories) Any telephone that is otherwise supported for automatic tracking that is connected to an unsupported switch port Cisco Catalyst 2900 XL Series Cisco Catalyst 2950 Series Cisco Catalyst 3500 Series Cisco Catalyst 3550 Series Cisco Catalyst 4000 Series Cisco Catalyst 4500 Series Cisco Catalyst 5000 Series Cisco Catalyst 5500 Series Cisco Catalyst 6500 Series
Manual endpoint entry:
Supported Catalyst switches:
3-90
Summary
Summary
Cisco CallManager implements class of service via partitions and calling search spaces. A partition consists of DNs and route patterns with similar reachability characteristics. A calling search space consists of an ordered list of partitions that users search before being allowed to place a call. Partitions and calling search spaces are used to ensure that Cisco CallManager directs callers appropriately in emergency calling. Cisco ER is a software application that works with Cisco CallManager to support E911 and real-time location tracking.
3-91
References
For additional information, refer to these resources: Newton, H. Newtons Telecom Dictionary, 18th Updated and Expanded Edition. New York, New York: CMP Books; 2002. Smith, Anne, Chris Peace, D. Whetton, and J. Alexander. Cisco CallManager Fundamentals: A Cisco AVVID Solution. San Jose, California: Cisco Press; 2001. Partitions and Calling Search Spaces section in Cisco CallManager System Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmsys/a03ptcss.htm Partition Configuration section in Cisco CallManager Administration Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmcfg/b03parti.htm Call Search Space Configuration section in Cisco CallManager Administration Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmcfg/b03csspc.htm Cisco ER: Cisco Emergency Responder product documentation: http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/respond/index.htm Cisco Emergency Responder Version 1.1 product information in Cisco Product Catalog: http://www.cisco.com/univercd/cc/td/doc/pcat/index.htm Cisco Emergency Responder Software Service & Support: http://www.cisco.com/warp/public/cc/serv/mkt/sup/svsptl/iptlsv/
3-92
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) Which three of these problems are addressed with calling search spaces and partitions? (Choose three.) A) B) C) D) Q2) A) B) C) D) Q3) A) B) C) D) Q4) routing by geographical location routing by tenant routing by class of user routing by device a logical grouping of route patterns a logical grouping of telephone devices a logical grouping of gateway devices a logical grouping of route lists an ordered list of partitions an ordered list of route patterns route patterns with similar calling capabilities route groups with similar calling capabilities
Which of these statements best describes a partition?
Which of these statements best describes a calling search space?
If partitions and calling search spaces are properly configured in a multisite environment, which of the following should happen during an emergency call? A) B) C) D) The call should be routed across the IP WAN. The call should be routed to the local PSTN. The call should not be routed. The call should be routed using route lists. single or multicluster installations with 48+ IP Phones per site E911 extension support to include extension mobility Cisco IP Phones that are not connected to Catalyst switches shared-line appearances on telephones in multiple physical locations
Q5)
Which three are appropriate applications for Cisco ER? (Choose three.) A) B) C) D)
3-93
Quiz Answer Key

Q1) A, B, C Relates to: Class of Service Q2) A Relates to: Partitions Q3) A Relates to: Calling Search Spaces Q4) B Relates to: Using Partitions and Calling Search Spaces for Emergency Calls Q5) A, B, D Relates to: Cisco Emergency Responder
3-94
Configuring Call Admission Control and Survivable Remote Site Telephony

Overview
This lesson describes call admission control and survivable remote site telephony (SRST). Call admission control controls the number of calls between two endpoints, which is important to maintain quality of service (QoS) for both new and existing calls. The SRST feature provides call-handling support if Cisco CallManager or WAN link fail.
Relevance
When an IP WAN connects two clusters, call admission control is vital to protect calls from other voice calls that can oversubscribe the IP WAN bandwidth and affect voice quality. Prior to Cisco SRST, connectivity with Cisco CallManager was lost, Cisco IP phones became unusable for the duration of the failure. Cisco SRST overcomes this problem and ensures that the Cisco IP phones offer continuous (although minimal) service by providing call-handling support for Cisco IP phones directly from the Cisco SRST router.
Objectives
Upon completing this lesson, you will be able to configure a Cisco IOS gatekeeper for call admission control to prevent oversubscribing the WAN and to configure SRST on a Cisco IOS gateway to provide call-processing redundancy. This includes being able to meet these objectives: Describe how call admission control is important to maintain voice QoS across an IP WAN Describe how the locations feature in Cisco CallManager provides a simple call admission control mechanism for hub-and-spoke topologies 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 links
Describe how a gatekeeper can reduce the number of inter-cluster trunks required in a distributed call processing environment Identify the communication procedures between an H.323 gatekeeper and H.323 endpoint to include 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 CallManager failover capabilities Configure SRST on a supported gateway and in Cisco CallManager so that the SRST router assumes call processing duties should the CallManager or WAN link fail

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: Gateway configuration in Cisco CallManager Administration Cisco IOS Configuration
Outline
This lesson includes these topics:
Outline
Overview Call Admission Control Overview Locations-Based Call Admission Control Overview Locations-Based Call Admission Configuration Gatekeeper Call Admission Control Overview Gatekeeper Communication Gatekeeper Call Admission Control Configuration SRST Overview SRST Configuration Summary Quiz
3-96
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 only support two calls. What happens when the third call is attempted?
Cisco CallManager
Call #1 Call #2 Call #3
Cisco CallManager
IP WAN
Call #3 Causes poor quality for all calls Many tools give voice priority over data. Call admission control is about preventing voice oversubscription.
Only need call admission control for calls that traverse the IP WAN.
Call admission control provides you with mechanisms to control the quantity 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 be subject 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-97
Two Methods of Call Admission Control

CallManager Cluster
Centralized call processing: Use locations feature

IP WAN
PSTN
Distributed call processing: Use gatekeepers and inter-cluster (gatekeepercontrolled) trunks
IP WAN
PSTN
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-98
Locations-Based Call Admission Control Overview

This topic discusses the locations feature in Cisco CallManager for providing call admission control.
Centralized Call Processing: Locations-Based Call Admission Control

Location San Jose CallManager Cluster New York Dallas Bandwidth (kbps) Unlimited 256 64
New York (Remote)
IP WAN
San Jose (Main)
Dallas (Remote)
Location: Defines the amount of bandwidth available Region: Defines the compression type used
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 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: G.711 call uses 80 kbps G.722 call uses 80 kbps G.723 call uses 24 kbps G.728 call uses 16 kbps G.729 call uses 24 kbps GSM call uses 29 kbps Wideband call uses 272 kbps
3-99
Locations work in conjunction with regions to define the characteristics of a network link. While locations define the amount of available bandwidth for the link, 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 (256K), and Dallas (64K). 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 our example has 256 kbps of available bandwidth, that link can support three G.711 call at 80 kbps each and ten G.723 or G.729 calls at 24 kbps each. If any additional calls try to exceed the bandwidth limit, the system rejects them, the calling party receives reorder tone, and a text message displays on the phone. Refer to the "Understanding Video Telephony" for more details: http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_1/cc msys/a08video.htm#63199
3-100
Locations-Based Call Admission Control 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
Follow these steps to configure locations in Cisco CallManager:

Step 1 Step 2
Configure a region for each type of codec that is used in your system. 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. Configure the device pools for your system and choose the appropriate region for each. Configure the phones and other devices and assign each of them to the appropriate device pool and location. To place a device in a location, choose System > Location from Cisco CallManager Administration.
Step 3
Step 4
3-101
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. CallManager registers with gatekeeper using IP address. A single gatekeeper can manage up to 100 CallManager clusters.
Gatekeeper Zone
Gatekeeper
IP WAN
CIPT1 v4.13-7
Gatekeeper call admission control reduces configuration overhead by eliminating the need to configure a separate individual inter-cluster trunk between each cluster. 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-102
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-8
The first process 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 gatekeepers that can accept a registration will return a Gatekeeper Confirmation (GCF). If a gatekeeper cannot accept a registration, it will return a Gatekeeper Reject (GRJ).
Note This lesson provides an overview and 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) course.
3-103
Gatekeeper Registration and Unregistration

H.323 Endpoint Gatekeeper
RRQ (1)
Registration
RCF/RRJ (2)
Gatekeeper Initiated Unregistration Request
URQ (1) UCF (2)
Endpoint Initiated Unregistration Request
URQ (1) UCF/URJ (2)
CIPT1 v4.13-9
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 ID, device type, and other possible parameters each time 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 or return this value unchanged.
Note You can make the returned TTL value configurable with Cisco IOS 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 results in the gatekeeper being unaware of 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 IDs or ambiguous information. 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 will become unregistered.
3-104
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 will return an RCF to the endpoint and reset 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 will respond with an Unregister Reject (URJ) to indicate the error. Cisco IOS gatekeepers, Cisco IOS Gateways, and Cisco CallManager support lightweight registration.
3-105
Admission Request
H.323 Endpoint 1
Gatekeeper
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

Telephony endpoints (IP Phones or Cisco IP SoftPhones) send an Admission Request (ARQ) to the gatekeeper to initiate a call. The ARQ contains an H.323 ID or the E.164 address of a destination or called party 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/or H.323 ID 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.
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 either bandwidth is unavailable or the called endpoint is not registered, the gatekeeper sends an ARJ.
3-106
Disengage and Bandwidth Request

H.323 Endpoint Gatekeeper
DRQ (1)
Disengage
DCF(2)
BRQ (1)
Bandwidth
BCF/BRJ (2)
CIPT1 v4.13-11
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, due to 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 will respond with a Bandwidth Confirmation (BCF) if the bandwidth is available or refuse the request with a Bandwidth Reject (BRJ) if the bandwidth is not available.
3-107
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
Router(config)# gatekeeper Router(config-gk)# zone local SJGK1 cisco.com Router(config-gk)# zone prefix SJGK1 408* Router(config-gk)# gw-type-prefix 1#* defaulttechnology ! Router(config-gk)# bandwidth total zone SJGK1 512 Router(config-gk)# bandwidth session zone SJGK1 256
CIPT1 v4.13-12
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 Enterprise Plus/H323/MCM. Following are the general steps for configuring call admission control using gatekeepers and trunks:
Step 1
On the gatekeeper device, you will need to configure the appropriate zones and bandwidth allocations for the various Cisco CallManagers that will route calls to it. Configure gatekeeper settings in Cisco CallManager Administration. Make sure the Host Name or IP Address is set the same way on each Cisco CallManager. You can register multiple gatekeepers per Cisco CallManager cluster. Configure the appropriate inter-cluster trunks or H.225 trunks to specify gatekeeper information (if gatekeeper-controlled). The H.225 trunk allows connectivity to H.323 Cisco IOS gateways. The inter-cluster trunk provides specific, Cisco functionality for calls between Cisco CallManager clusters. Configure a route pattern to route calls to each gatekeeper-controlled trunk.
Step 2
Step 3
Step 4
3-108
Example
Shown in the figure is a sample gatekeeper configuration. The commands are described in the following table. Cisco IOS Gatekeeper Commands
Command Description Enters gatekeeper configuration mode/ Specifies cisco.com as the a 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 is no E.164 addresses registered (by a gateway) that matches the called number. With the default technology prefix option, the Cisco gatekeeper assigns default gateway(s) for routing unresolved call addresses. This assignment is based on the gateways' registered technology prefix. 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 zone local SJGK1 cisco.com zone prefix SJGK1 408* gw-type-prefix 1#* default-technology
bandwidth total zone SJGK1 512 bandwidth session zone SJGK1 256
3-109
Gatekeeper Configuration in CallManager

Configure gatekeeper settings and trunk in Cisco CallManager
CIPT1 v4.13-13
In Cisco CallManager Administration, you will add gatekeepers and trunks and configure settings for each.
Gatekeeper Configuration
To add and configure a gatekeeper, perform the following procedure.
Step 1
Choose Device > Gatekeeper. The Find and List Gatekeeper Configuration window.
Step 2
Click the Add a New Gatekeeper link. The Gatekeeper Configuration window displays.
Step 3
Enter the appropriate settings as described in the following table.
3-110
Gatekeeper Configuration in Cisco CallManager Administration

Field Host Name/IP Address* Registration Request Time to Live Description Enter the IP address or host name of the gatekeeper in this required field. Do not change this value unless a Cisco 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 Time to Live 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 these two types of gatekeeper-controlled trunks. H.225 Trunk (Gatekeeper Controlled): In a 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 choose this method, use Device > Trunk and choose H.225 Trunk (Gatekeeper Controlled). Inter-Cluster Trunk (Gatekeeper Controlled): In a distributed call-processing network with gatekeepers, use an inter-cluster trunk with gatekeeper control to configure connections between clusters of Cisco CallManager systems. Gatekeepers provide call admission control and address resolution for inter-cluster calls. A single inter-cluster trunk can communicate with all remote clusters. To choose this method, use Device > Trunk and 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-111
SRST Overview
This topic discusses the survivable remote site telephony (SRST) feature used in a centralized call-processing deployment.
What is SRST?
SRST:
Capability in branch office routers for IP telephony redundancy Always available branch IP telephony (including calls from and to PSTN) Ideal for centralized Cisco CallManager deployment Licensed on number of users at remote site on Cisco IOS PLUS software Survivability scales up to 480 users dependent upon platform
CIPT1 v4.13-14
The SRST feature provides call-handling support on the gateway router for attached 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. The SRST-enabled router supports: IP Phone to IP Phone on router calls IP Phone to Public Switched Telephone Network (PSTN) calls Multiple lines per IP Phone Multiple line appearance across IP Phones Call hold and pickup on a shared line Call transfer of local calls Caller ID information Up to 24 IP Phones supported on Cisco 1751, 1760, 2600-XM, and 3620 platforms Up to 48 IP Phones supported on Cisco 2650-XM, 2651-XM platforms Up to 480 IP Phones supported on Cisco 7200 routers NPE-400 (SRST 2.0)
3-112
Sample SRST Features

Support for re-homing of IP Phones to use call processing on local router upon Cisco CallManger fallback Support for IP and POTS phones on the router Extension to extension dialing Extension to PSTN dialing Support for on-net calling Primary line 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
With the current Cisco Architecture for Voice, Video and Integrated Data (AVVID), Cisco CallManagers provide call-processing functions for IP Phones. Placing Cisco CallManagers in central locations allows this architecture to be cost-effective. In addition, the central locations can often provide call-processing functions for IP Phones located in remote locations. There is weakness in this architecture when a WAN connection fails and remote IP Phones cannot make calls. This weakness can be a serious problem when it comes to emergency calls such as E911. 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 when upon WAN failure detection. This solution is the Cisco CallManager Fallback feature. The Cisco CallManager Fallback feature is referred to as SRST. SRST telephone features include: 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 party ID (Caller ID/ANI) display Calling party name display Speed Dialing Last number redial Call transfer without consultation (local to router only)
3-113
Call hold/resume Multiple extensions (up to six extensions per IP Phone on 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
3-114
SRST: Normal Operation

Central Site Call Manager (Cisco CallManager) PSTN
Real-Time Protocol
Branch Router 1750, 2600, 3600, 7200, Cat4224 IAD2400
WAN
Headquarters
Skinny: Protocol for call set up and tear down

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-115
SRST: Network Failure

Central Site Call Manager (Cisco CallManager)
KA to CallManager
Real-Time Protocol
PSTN
WAN
Headquarters
KA to CallManager Keepalive (TCP) Skinny

When the WAN link fails, Cisco IP Phones detect that they are no longer receiving keepalive packets from the Cisco CallManager. Cisco IP Phones then register with the router. In this instance, the SRST software automatically activates and builds a local database of all Cisco IP Phones attached to it, up to the stated maximum. You can configure the IP Phones to query the router as a backup call-processing source when the central Cisco CallManager does not acknowledge keepalive packets. The SRST router now performs call setup and processing, call maintenance, and call termination.
3-116
SRST: Network Failure Repaired

Central Site Cisco CallManager PSTN
Real-Time Protocol
WAN
Headquarters
Keepalive: Ensures communication link with Cisco CallManager
CIPT1 v4.13-18
When the WAN link resumes, the IP Phones detect keepalive packets 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 only affects 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-117
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)#
call-manager-fallback Enables Cisco CallManager fallback capability and puts you in a submenu.
SRST(config)#
ip source-address <router ip address> [port <port #>] Enables router to receive Skinny messages on this particular port. The default port is 2000.
SRST(config)#
max-ephones Maximum IP Phones that will be allowed to register. Defaults to 0.

SRST(config)#
max-dn Maximum number of DNs that can be configured. Defaults to 0.

The most common application of SRST is to maintain basic IP telephony functionality for the IP Phones at the remote branch offices, in the event the WAN link fails or the Cisco CallManager at headquarters is no longer available. The remote branch router will activate SRST functions and take 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: call-manager-fallback, which is a global command with a series of subcommands.
3-118
call-manager-fallback Subcommands
Command Description Define access-codes for outgoing calls Set a command to its defaults Define/disable default destination dn for ringing on unknown called number Define E.164 telephone number prefix Stop hunting on dial peers Define IP address and port for the IP Keyswitch Define keepalive timeout period to unregister IP Phones Specify maximum directory numbers supported on IP Keyswitch Specify maximum number of IP Phones Reset IP Phones Define valid call transfer destinations Set voice-mail access number called when messages button is pressed
access-code default defaultdestination dialplan-pattern huntstop ip keepalive max-dn max-ephones reset transfer-pattern Voicemail
3-119
show call-manager-fallback
Router#show call-manager-fallback access-code fxo 9 default-destination 4312 dialplan-pattern 1 345 ip source-address 10.1.1.2 port 2000 keepalive 30 max-ephones 24 max-dn 48 transfer-pattern 525... voicemail 4001
CIPT1 v4.13-20
Below 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 to select the type of ports rather than a single port. A request to a busy port will roll 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 will route 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 a transfer target. 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 answering machine. The user can then listen to the messages.
3-120 Cisco IP Telephony Part 1 (CIPT1) v4.0 Copyright 2004, Cisco Systems, Inc.
Creating an SRST Reference in Cisco CallManager Administration
CIPT1 v4.13-21
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, select the System menu in the Cisco CallManager Administration utility and select 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. In order to create a valid SRST Reference, you must enter the following fields: SRST Reference Name: This is a logical name you can use when referencing the SRST gateway. It does not need to match the name assigned to the gateway. IP Address: This 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 is the port number that the phone should use when contacting the SRST Reference. By default, this uses TCP port 2000.
3-121
Assigning SRST References
CIPT1 v4.13-22
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, use the SRST Reference menu to select 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-122
Summary
This topic summarizes the key points you learned in this lesson.
Summary
Call admission control provides mechanisms to control the quantity 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. Configure the available bandwidth in the Locations page and the codec in the Regions page. Cisco CallManager supports gatekeeper-basic call admission control for distributed environments.
CIPT1 v4.13-23
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 gatekeeper in Cisco IOS and 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 to device pool. Configure SRST commands on the Cisco IOS router.
3-123
References
For additional information, refer to this resource: Call Admission Control, Cisco CallManager System Guide, Release 4.0(1) http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmsys/index.htm Understanding Cisco CallManager Trunk Types, , Cisco CallManager System Guide, Release 4.0(1) http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmsys/index.htm Gatekeeper Configuration, Cisco CallManager Administration Guide, Release 4.0(1) http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmcfg/index.htm Trunk Configuration, Cisco CallManager Administration Guide, Release 4.0(1) http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmcfg/index.htm H.323 VoIP Gatekeeper for Cisco Access Platforms http://www.cisco.com/en/US/products/sw/iosswrel/ps1826/products_feature_guide09186a0 080087ac0.html#xtocid1435710 Understanding Cisco IOS Gatekeeper Call Routing http://www.cisco.com/en/US/tech/tk652/tk701/tech_tech_notes_list.html Cisco SRST 3.0 System Administrator Guide http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_configuration_guide_ book09186a00801f34d6.html Cisco SRST Data Sheet http://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_data_sheet09186a008 00888ac.html Cisco Survivable Remote Site Telephony Version 2.02 Feature Guide http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1839/products_feature_guides _list.html
3-124
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Answer Key. Q1) Which is a benefit associated with gatekeeper call admission control? A) B) C) D) Q2) no requirement to configure Cisco IOS commands on the gatekeeper no requirement to configure an inter-cluster 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
Without call admission control, what happens to existing calls when the next call oversubscribes the WAN? A) B) C) D) all calls are dropped voice quality on all calls degrades voice calls on the last call degrades nothing if the router is configured for QoS
Q3)
Which two are characteristic associated with the distributed call admission control method? (Choose two.) A) B) C) D) inter-cluster trunk to each CallManager cluster gatekeeper-controlled trunks maximum bandwidth is determined on the CallManager zones and bandwidth allocation configured on the router The IP Phones stops 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 page The Device Pool contains the IP address reference to the SRST gateway.
Q4)
How do the IP Phones in a branch site know to register to the gateway running SRST? A) B) C) D)
Q5)
Which two of these options describe how endpoints achieve gatekeeper discovery? (Choose two.) A) B) C) D) autodiscovery manual discovery assigned by the voice router assigned by the call admission control server
Q6)
Which of these enable you to configure the available bandwidth within Cisco CallManager Administration for call admission control? A) B) C) D) location region device pool device default it is appropriate for centralized call-processing deployments IP Phones will drop existing calls when the WAN link resumes IP Phones listen for keepalives to know when the central CallManager is back online SRST supports Calling Search Spaces, Extension Mobility, and IP SoftPhone
Establishing an Off-Cluster Call 3-125
Q7)
Which of the following two statements are true with respect to SRST? (Choose two.) A) B) C) D)
Q8)
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? A) B) C) D) 2 3 4 5
3-126
Quiz Answer Key

Q1) B Relates to: Call Admission Control Overview Q2) B Relates to: Gatekeeper Call Admission Control Overview Q3) B, D Relates to: Gatekeeper Call Admission Control Configuration Q4) C Relates to: SRST Configuration Q5) A, B Relates to: Gatekeeper Communication Q6) A Relates to: Locations-Based Call Admission Control Configuration Q7) A, C Relates to: SRST Overview Q8) D Relates to: Locations-Based Call Admission Control Overview
3-127
3-128
Module 4

Overview
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 to include conferencing, announcements, music on hold (MOH), speed dials, Call Park, Call Pickup, Cisco Call Back, Barge, Privacy, Cisco IP Manager Assistant (IPMA), Call Join, Direct Transfer, and Cisco IP Phone Services. You will also be able use these features on Cisco IP Phones.
Module Objectives
Install, configure, and manage media resources to include the conference bridge, Media Termination Point, annunciator, transcoder, and MOH server Use standard and create nonstandard softkey templates and apply them to Cisco IP Phones Configure and use many user phone features to include speed dials, Call Park, Call Pickup, Cisco Call Back, Barge, Privacy, Cisco IPMA, and Cisco IP Phone Services
CIPT1 v4.14-2
Outline
The outline lists the components of this module:
Module Outline
Lesson 4-1 Configuring Media Resources Lesson 4-2: Working with Softkey Templates Lesson 4-3: Configuring User Features
CIPT1 v4.14-3
4-2
Configuring Media Resources

Overview
This lesson covers the media resources that are available in a Cisco IP telephony solution. You will learn how to configure and allocate conferencing, Media Termination Points (MTPs), the annunciator, transcoders, and music on hold (MOH) within a Cisco CallManager cluster.
Relevance
Cisco IP telephony functionality requires the use of media resources. Media resources provide important services such as conferencing and MOH. System administrators need to know how to configure and allocate the media resources for a Cisco IP telephony deployment.
Objectives
Upon completing this lesson, you will be able to install, configure, and manage media resources to include the conference bridge, annunciator, transcoder, and MOH server. This includes being able to meet the following objectives: Install all necessary CallManager services that are used in media resources Configure conference bridge resources to enable ad hoc and Meet-Me conferencing between IP Phones Describe how MTP resources extend supplementary services for calls that are routed through an H.323v1 gateway. 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 Media Resource Groups and Media Resource Group Lists

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: Navigation in Cisco CallManager Administration Cisco IOS and Cisco Catalyst operation system command-line basics
Outline
Outline
Overview Introduction to Media Resources Conference Bridge Resources Media Termination Point Resources Annunciator Resources Transcoder Resources Music on Hold Resources Media Resource Management Summary Quiz
CIPT1 v4.14-2
4-4
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 Transcoding Music on hold
MRM MRM
MRM
MRM
Media Resource
CIPT1 v4.14-3
Media resources provide services, such as conferencing, media termination, the annunciator, transcoding, and MOH. Media resource management provides access to media resources for all Cisco CallManagers in a cluster. 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 such as conference bridge or the annunciator. The MRM manages the following media resource types: Unicast conference bridge MTP (media streaming application server) Annunciator Transcoder MOH server Media resources are available in both hardware and software. Hardware resources on the Cisco 6000 Series gateway module provide hardware support for the IP telephony features that are offered by Cisco CallManager. These features include hardware-enabled voice conferencing, hardware-based MTP support for supplementary services, and transcoding services. Cisco CallManager servers provide the software resources.
4-5
Installing Software Media Resources
Services required for media resources
CIPT1 v4.14-4
After Cisco CallManager is installed, you must activate three CallManager services that media resources use. Descriptions of the three services that must be activated follow: 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 various coder-decoders (codecs) so the MOH feature can use them. To activate the required services in Cisco CallManager, access the administration console and choose Application > Cisco CallManager Serviceability. From the Serviceability window, choose Tools > Service Activation. You can activate the services on any server that you choose.
4-6
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.
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 talkers on the conference and distribute that composite stream to each participant (minus their own input stream if they are one of the talkers). Cisco CallManager supports both hardware and software conference devices. Hardwareenabled 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. Both hardware and software conference bridges can be active at the same time. Each conference bridge is capable of hosting several simultaneous, multiple-party conferences.
4-7
Conference bridges are designed to 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 Confirm 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 will terminate and the two remaining participants will be 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 conference controller must configure a directory number (DN) or range of DNs in the Cisco CallManager Administration graphical user interface (GUI). 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 will continue if there are least two participants on the bridge.
4-8
Conference Bridge Types

Conf. Resource Cisco Conference Bridge Hardware Cisco Conference Bridge Software Cisco IOS Conference Bridge Cisco IOS Enhanced Conference Bridge Cisco Video Conference Bridge (IPVC-35xx)
Codecs
G.711, G.723, G.729, GSM FR, GSM EFR G.711, Cisco wideband G.711, G.729 G.711, G.729, GSM FR, GSM EFR G.711, G.729, or G723 Numerous audio and video coding schemes
Max. Participants Per Conference

1 CFB32 users 10 CFB3 users 64Ad Hoc 128Meet-Me 6
WS-X6608-T1 WS-X6608-E1 Cisco IP Voice Media Streaming App. NM-HDV NM-HD-FARM NM-HD NM-HDV2 WS-SVC-CMMACT IPVC-35xx
Varies by platform
CIPT1 v4.14-6
The figure identifies 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. Brief descriptions of the conference resources follow: 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 provides conferencing, transcoding, voice termination, and a voice WAN interface card (VWIC) slot. NM-HD-FARM: The NM-HDV-FARM provides only conferencing and transcoding functions NM-HD: The NM-HD module includes the NM-HD-1V, NM-HD-2V, and NM-HD-2VE. The NM-HD-1V supports up to four channels of analog or BRI voice. NM-HDV2: The NM-HD2V supports up to eight voice channels of analog or BRI voice. The NM-HDV2 supports a voice interface card (VIC)/VWIC slot that can fitted with either digital or analog or BRI voice/WAN interface cards, supports up to 60 channels of digital voice, or four channels of analog voice. The NM-HDV2-1T1/E1 adds support for one builtin 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).
Copyright 2004, Cisco Systems, Inc. Enabling Features for Users 4-9
WS-SVC-CMM-ACT: The WS-SVC-CMM-ACT is a conference and transcoding port adapter for the WS-SVC-CMM communication media module. The Cisco Communication Media Module (CMM) is a Cisco Catalyst 6500 Series and Cisco 7600 Series line card that provides high-density T1 and E1 gateways. IPVC-35xx: The Cisco Video Conference Bridge (IPVC-35xx) is a dual multimedia bridge that provides videoconferencing. The videoconference bridge provides audio and videoconferencing functions for Cisco IP video phones, H.323 endpoints, and audio-only Cisco IP Phones. The Cisco IPVC-35xx Series includes the Cisco IP/VC 3511 and Cisco IP/VC 3520. 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.
Note Cisco CallManager supports the Cisco Catalyst 4000 and 4500 Access Gateway Module (AGM) (part number WS.x4604-GWY). An end-of-life announcement date 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 Release 1.2(2)YK or Catalyst operating system (Catalyst software) Release 7.3(1).
Note
NM -HD and NM-HDV2 require Cisco IOS Release 12.3(8)T with the IP voice feature set and Cisco CallManager version 4.0(1) for full-feature support including MTP. Cisco CallManager version 3.3(4) can be used when MTP support is not needed and conferencing and transcoding support is sufficient. NM-HD and NM-HDV2 require Cisco IOS Release 12.2(13)T with the Plus feature set for voice.
Note
NM-HD and NM-HDV2 require Cisco IOS 12.2(13)T with the Plus feature set for voice, and Cisco CallManager version 3.2(2c) or higher.
4-10
The following table provides additional detail about audio conference bridges.
Conference Type Hardware Number of Participants and Bridges For G.711 or G.729a: 256 streams total per module and 32 streams maximum per port. 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: 128 streams Ad hoc conference bridges may range from 42 bridges with 3 participants to 2 bridges with 64 participants. Meet-Me conference is 1 bridge with up to 128 participants. IP Voice Media Streaming Application coresident with Cisco CallManager: 48 streams Bridges may range from 16 bridges with 3 participants to 1 bridge with 48 participants. Cisco IOS software 3 bridges per PVDM-12 3, 6, 9, or 15 bridges per network module (NM) Maximum of 6 participants per bridge Enhanced 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/sw/voicesw/ps4 952/products_data_sheet0900aecd800f8580.html NM-HD NM-HDV2 WS-SVC-CMMACT NM-HDV NM-HDV-FARM Software Resource WS-X6608-T1 WS-X6608-E1
4-11
Hardware Conference Bridge Configuration
Catalyst 6000 port MAC address needed
CIPT1 v4.14-7
To add a hardware conference device, follow these steps:

Step 1
Choose Service > Media Resource > Conference Bridge and Add a New Conference Bridge. Choose Cisco Conference Bridge Hardware for the Conference Bridge Type. Add the MAC address of the Catalyst 6000 Series port. The port must be pointed toward the Cisco TFTP server to obtain the configuration file and a list of the Cisco CallManagers within the Cisco IP telephony network to use for registration.
Step 2 Step 3
4-12
Media Termination Point Resources

This topic examines MTP resources.
Media Termination Point

Cisco CallManager Cisco IP Voice Media Streaming Application SW MTP
IP WAN
1002 PSTN 1001

Router/GW H.323v1
Enables supplementary services for calls routed through SIP or H.323v1 gateway Supplementary services are features such as: Call Hold Call Transfer Call Park Conferencing
Incoming Stream Initial Stream Supplementary Service Stream

CIPT1 v4.14-8
A Media Termination Point (MTP) is a software device that provides supplementary services for calls that are routed through an H.323 version 1 (H.323v1) gateway. These supplementary services include Call Hold, Call Transfer, Call Park, and conferencing. They are not available when a call is routed to an H.323v1 endpoint. Cisco CallManager uses an H.323 mechanism known as Empty Capability Set (ECS) to support hold, transfer, and other supplementary features. H.323v1 endpoints do not support ECSs, so they require an MTP to provide supplementary services. H.323v2 endpoints support ECSs, which enable Cisco CallManager to extend supplementary services without an MTP. SIP and MTP Cisco CallManager requires an RFC 2833 Dual Tone Multi-Frequency (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) 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
MTP Capabilities
Up to 128 half-duplex streams are configurable. 64 full-duplex resources are available for MTP application.
CIPT1 v4.14-9
The figure and the table shown here describe the MTP limits. MTP Limits
MTP Resource Type MTP Installed with the IP Voice Media Streaming Application on a supported Cisco CallManager server platform Limitations G.711 only. Up to 128 half-duplex streams are configurable. 64 full-duplex resources are available for MTP application.
4-14
MTP Configuration
CIPT1 v4.14-10
To configure MTP, you must verify that these prerequisites are met: Configure servers Configure 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 Media Termination Point Type Description Choose the MTP type, either Cisco IOS Enhanced Software Media Termination or Cisco Media Termination Point Software. Refer to the Cisco CallManager System Guide, Release 4.0(1) for more information on each type. Choose the server to run MTP. Enter an MTP name, up to 15 alphanumeric characters. Enter a description for MTP. Choose a device pool with the highest priority in the Cisco CallManager group or choose Default.
Host Server Media Termination Point Name Description Device Pool
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
Your call cannot be completed as dialed...This is a recording.
1002
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. Ring back 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 phonethe 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 An equal or higher-precedence call is in progress. A precedence access limitation exists. A service interruption occurred. Announcement Equal or higher-precedence calls have prevented the completion of your call. Please hang up and try again. This is a recording. Precedence access limitation has prevented the completion of your call. Please hang up and try again. This is a recording. 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 x1001 dials x2503, an invalid number. The system cannot complete the call. The annunciator device plays a one-way RTP stream to x1001: Your call cannot be completed as dialed. Please consult your directory and call again or ask your operator for assistance. This is a recording.
4-17
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 255 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. Cisco recommends that you do 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. If the standalone server has dual CPU and a high-performance disk system, the annunciator can support up to 400 simultaneous announcement 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.
4-18
Annunciator Configuration
Configuration almost identical to MTP configuration

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. 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. Verify that you have activated the Cisco IP Voice Media Streaming Application service on the server where you want the annunciator to exist. Perform additional annunciator configuration tasks if you want to change the default settings. Add the new annunciators to the appropriate media resource groups and media resource lists. Reset or restart the individual annunciator on all devices that belong to the media resource group or list.
Step 2
Step 3
Step 4
Step 5
4-19
Transcoder Resources
This topic defines transcoder resources and examines transcoder limitations.
Transcoding Definition
XCODE Voice Messaging
G.729
G.711
MTP
Input Stream H.323 v1
Stream for Supplementary Services
CIPT1 v4.14-14
A transcoder device takes the output stream of one codec and converts the data 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 an MTP for H.323v1 endpoints. Cisco CallManager makes use of a transcoder device when two devices are using different codecs and are not able to communicate.
4-20
Transcoding Capabilities
Resource WS-X6608T1/E1 NM-HDV NM-HDV-FARM Maximum Number of 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
NM-HD NM-HDV2
G.711 to any other codec: WS-SVC-CMM128 streams per port adapter ACT
CIPT1 v4.14-15
The figure and table shown here describe the MTP and transcoder resource capabilities.
MTP and Transcoder Resource Capabilities

Resource Type WS-X6608-T1, WS-X6608-E1 From Codec G.723. G.729a, GSM FR, GSM EFR G.711 a-law or mu-law NM-HDV and NMHDV-FARM G.729, G.729a, G.729b, G.729ab G.711 mu-law NM-HD and NMHDV2 G.729, G.729a, G.729b, G.729ab, GSM FR, GSM EFR G.711 a-law or mu-law WS-SVC-CMMACT G. 729a, G.729 b, G.723 G.711 a-law or mu-law To Codec G.711 a-law or mu-law G.723. G.729a, GSM FR, GSM EFR G.711 a-law or mu-law G.729, G.729a, G.729b, G.729ab G.711 a-law or mu-law G.729, G.729a, G.729b, G.729ab, GSM FR, GSM EFR G.711 a-law or mu-law G. 729a, G.729 b, G.723
4-21
Transcoder Configuration
CIPT1 v4.14-16
To configure or add a new transcoder, choose Service > Media Resource > Transcoder. You need the MAC address of the Catalyst 6000 Series port to add a transcoder device.
4-22
Music on Hold Resources

This topic examines the MOH resources that are installed and configured in Cisco CallManager.
MOH
Types of hold:
User hold Network hold: Transfer hold Conference hold Call Park hold
Cisco CallManager Cisco IP Voice Media Streaming Application
Audio sources:
Recorded audio Live audio
Deployment types:
Coresident Standalone
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 Coresident server: 20 MOH sessions Standalone MOH server: 50 MOH sessions
MCS 7815 MCS 782x (all models) MCS 7830 (all models) SPE-310 HP DL320 IBM xSeries 33x (all models) MCS 7835 (all models) MCS 7845 (all models) HP DL380 IBM xSeries 34x (all models)
G.711 (a-law and mu-law) G.729a Wideband audio
G.711 (a-law and mu-law) G.729a Wideband audio
Coresident server: 20 MOH sessions Standalone MOH server: 250 MOH sessions
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.
4-24
Creating Audio Source File

3
New files are automatically detected and processed.
Audio Translator Service
MOH Master Storage Directory
Default MOH TFTP Server
4
Audio Source Input Directory C:\Cisco\DropMOHAudioSourceFilesHere
Cisco CallManager Administration copies audio source files when they are mapped.
TFTP Path Directory
Start
1
MOH Server
5
Hard-Coded MOH Server Audio Source Directory
Administrator copies audio source into this directory.
Kernel-Mode RTP Streaming Driver
DirectShow Filters
CIPT1 v4.14-19
This figure shows the interaction between 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 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
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 sec to convert a 3-MB MP3 file.
Note Step 2 Step 3
Cisco CallManager automatically detects and translates the files. 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.
Cisco does not recommend using the audio translator service during production hours because the service will consume 100 percent of the CPU.
Note
Step 4
The network administrator then assigns the audio source file to an audio source number. The proper 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. The MOH servers download the needed audio source files and store them in the hard-coded directory C:\Program Files\Cisco\MOH.
Step 5
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. These tasks are described in the next several pages.
4-26
MOH Audio Translator Configuration
Input Directory
Output Directory
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 clusterwide parameter, contains a Universal Naming Convention (UNC) name to a shared directory on the default MOH TFTP directory. For whatever directory is specified, append \MOH.
4-27
MOH Server Configuration
CIPT1 v4.14-22
This figure shows the MOH server configuration page. 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.
4-28
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 after it reaches the end and the network administrator will have to stop and start the server to reset the MOH server. The MOH Audio Source File Status window shows the conversion status and indicates if the audio file translated correctly or if it had any errors.
4-29
MOH Service-Wide Settings
CIPT1 v4.14-24
To set the MOH service-wide settings, open the Service Parameters Configuration page, choose an MOH server, and choose the Cisco IP Voice Media Streaming App option. The Service Parameters Configuration window for MOH displays, as shown here.
Note The other service parameters on this page 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 holding down 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-30
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 the Sounds and Multimedia option. 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 option is selected.
4-31
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 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 page. 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.
4-32
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 either be 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.
4-33
Media Resource Management

This topic examines media resource management within a Cisco IP telephony solution using Media Resource Groups (MRGs) and Media Resource Group Lists (MRGLs).
Media Resource Management

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 CallManagers in the 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 CallManagers 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 both hardware and software devices to coexist within a Cisco CallManager To enable Cisco CallManagers 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-34
You can group devices of the following types into a single MRG: Conference bridge MTP MOH server Transcoder Annunciator
4-35
Media Resource Design

User Needs Media Resource
Similar to Route Lists and Route Groups
Media Resource Manager
Assigned to Device Media Resource Group List 1st Choice 2nd Choice Media Resource Group
Media Resource Group
Media Resource 1
Media Resource 2
Media Resource 3
Media Resource 1
CIPT1 v4.14-29
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-36
MRG
Call 1 Call 2 Call 3 Call 4 Call 5 Call 6 Call 7
XCODE1
XCODE2
XCODE3
XCODE1
XCODE2
XCODE3
XCODE1
Default MRG MOH1 MTP1 XCODE1 XCODE2 XCODE3

Load distribution of transcoders All resources shared among Cisco CallManagers in a cluster
CIPT1 v4.14-30
MRGs define logical groupings of media servers. MRGs can be associated with a geographical location or site, and they can control the usage of servers or the desired type of service. 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 CallManagers 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. Using this figure, the default media resources for a Cisco CallManager include the following: 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-37
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.
MRGL Configuration
CIPT1 v4.14-32
Use the Media Resource Group List Configuration page to configure MRGLs. Enter a name for the MRGL and then add the MRGs.
4-38
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 on the Phone Configuration page 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 will use the MRGL that is configured at the device pool level first, and then, if there are no resources available, it will try 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-39
Group Resources by Type
Resource_List
Hardware MRG XCODE1 XCODE2 HW-CONF1 HW-CONF2 Software MRG MTP1 MTP2 SW-CONF1 SW-CONF2 MOH MRG MOH1 MOH2
I would like to have a conference with telephone C. Is there a conference resource available?
A
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 as listed: 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 has been 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 software conference resources first. The software conference resources are not used until all of the hardware conference resources are exhausted.
4-40
Group Resources by Location

Dallas_List
Dallas_MRG XCODE1 HW-CONF1 MOH2 Hub_MRG
Dallas
San Jose_List
San Jose_MRG XCODE2 HW-CONF2 MOH3 Hub_MRG
1 San Jose 2
MTP1 MTP2 MOH1 SW-CONF1 SW-CONF2 San Jose_MRG XCODE2 HW-CONF2 MOH3
MTP1 MTP2 MOH1 SW-CONF1 SW-CONF2 Dallas_MRG XCODE1 HW-CONF1 MOH2
Result Devices use resources at their location first.
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, California, locations, it is more efficient to use media resources that are physically located at their own location rather than using a resource across the WAN. Media resources are assigned to these three MRGs as listed: Hub MRG: MTP1, MTP2, MOH1, SW-CONF1, and SW-CONF2 Dallas MRG: XCODE1, HW-CONF1, and MOH2 San Jose 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 (San Jose 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 (San Jose 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 SanJose_List resources.
4-41
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. The 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-42
Restrict Access to Conference Resources

Resource_List 1
MTP MRG MTP1 MTP2
NO_CONF_List 1
MTP MRG MTP1 MTP2 XCODE MRG XCODE1 XCODE2 MOH MRG MOH1 MOH2
CONF MRG SW-CONF1 SW-CONF2 HW-CONF1 HW-CONF2 MOH MRG MOH1 MOH2 XCODE MRG XCODE1 XCODE2
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, and assigned MRGs to it in this order: MTP MRG, XCODE MRG, and MOH MRG. In the device configuration, the administrator has assigned the name NO_CONF_List for the MRGL. With this setup, the device cannot use conference resources. Only the MTP, XCODE, and MOH resources are available to the device.
4-43
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 Dazzle_MRG ServerD_MOH
Audio Source ID User 1 B Network 5
ServerS_MOH
Audio Source IDs 1 Pop Music 1 5 Thank you for holding.

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. D_List consists of the Dazzle_MRG. SD_List consists of the SuperDave_MRG and Dazzle_MRG (prioritized order). Audio source ID 1 plays the Pop Music 1 audio stream. Audio source ID 5 plays the Thank you for holding audio stream. 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).
Two MRGLs:
Two audio source IDs:
Two Cisco IP Phones:
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 will hear Thank you for holding streamed from ServerS_MOH audio source ID 5 because it is first MOH server that is listed in the SD_List MRGL. If ServerS_MOH has no resources, Cisco CallManager will instruct ServerD_MOH to play the stream.
4-44
Summary
Summary
Media resources provide services, such as transcoding, conferencing, MOH, and media termination, which are activated on the Cisco CallManager. CBF resources are software and/or hardware solutions that allow ad hoc and Meet-Me conferences. MTP resources provide supplementary services, such as call hold, call transfer, call park and conferencing, when calls are routed through an H.323v1 gateway. 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 CallManagers to share these resources.
References
For additional information, refer to these resources: Annunciator Configuration, Conference Bridge Configuration, Media Termination Point Configuration, Transcoder Configuration, Media Resource Group Configuration, and Media Resource Group List Configuration sections in Cisco CallManager Administration Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmcfg/index.htm Media Resource Management, Annunciator, Conference Bridges, Transcoders, Music On Hold, Media Termination Points sections in Cisco CallManager System Guide Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmsys/index.htm Music On Hold, Cisco CallManager Features and Services Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmfeat/index.htm Smith, Anne, Chris Pearce, Delon Whetton, and John Alexander. Cisco CallManager Fundamentals: A Cisco AVVID Solution. San Jose, California: Cisco Press; 2001.
4-45
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) Which of these services does an MTP resource provide for an H.323v1 gateway? A) B) C) D) Q2) A) B) C) D) Q3) A) B) C) D) Q4) A) B) C) D) Q5) transcoding services MOH conferencing supplementary services any time of the day during peak call-processing hours during off-peak hours during business hours 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 call dispatcher service media streaming application server transcoder multiplexer
When is it recommended to run the audio translator?
Which of these statements best describes MRGLs?
The Media Resource Manager manages which two resource types? (Choose two.)
Which of these is needed to configure the Catalyst 6000 Series hardware conference bridge? A) B) C) D) MAC address IP address port address Meet-Me number
Q6)
Which of these items takes the output stream of one codec and converts it from one compression type to another? A) B) C) D) transcoder device MTP conference bridge device pool Cisco MOH Audio Translator Cisco IP Voice Media Streaming Application Cisco Messaging Interface Cisco CDR Insert
Q7)
Annunciator resources require that which service be activated? A) B) C) D)
4-46
Quiz Answer Key

Q1) D Relates to: Media Termination Point Resources Q2) C Relates to: Music on Hold Resources Q3) C Relates to: Media Resource Management Q4) B, C Relates to: Introduction to Media Resources Q5) A Relates to: Conference Bridge Resources Q6) A Relates to: Transcoder Resources Q7) B Relates to: Annunciator Resources
4-47
4-48
Working with Softkey Templates

Overview
This lesson discusses various softkey configurations that are associated with the applications and features that Cisco IP Phones (models 7970, 7960, and 7940) support. You will learn two types of softkey configurations: standard and nonstandard.
Relevance
Softkeys enhance the functionality of Cisco IP Phones and provide convenience to users.
Objectives
Upon completing this lesson, you will be able to change the standard softkey templates and apply them to Cisco IP Phones. This includes being able to meet these objectives: Define softkey templates Configure nonstandard softkey templates Add application softkeys to nonstandard softkey templates Modify softkey positions in a nonstandard template Assign softkey templates to Cisco IP Phones Delete softkey templates

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: Navigation in Cisco CallManager Administration Cisco IOS and Cisco Catalyst operation system command-line basics
Outline
Outline
Overview Overview of the Softkey Template Creating Nonstandard Softkey Templates Adding Application Softkeys to Nonstandard Softkey Templates Modifying Softkey Positions Assigning Softkey Templates to Devices Deleting Softkey Templates Summary Quiz
4-50
Overview of the Softkey Template

This topic provides an overview of softkey templates.
Softkey Templates
Five standard templates Cannot delete or modify templates Softkeys
CIPT1 v4.14-3
Softkeys extend the functions of Cisco 7940, 7960, and 7970 IP Phones. 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 and applications. Cisco CallManager 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 a custom (nonstandard) template to meet the needs of your organization. Softkey templates are available by choosing Device > Device Settings > Softkey Templates.
4-51
Creating Nonstandard Softkey Templates

This topic describes the creation of a nonstandard softkey template.
Configuring Nonstandard Softkey Templates
Standard Softkey Template
Nonstandard Softkey Template

To create a nonstandard softkey template, you must first copy an existing standard template and make the modifications to this copy. One way to create a nonstandard template is to choose a template and click the Copy button. The Softkey Template Configuration window will display the softkey template name, description, and application 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 will be displayed.
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-52
Adding Application Softkeys to Nonstandard Softkey Templates

This topic describes the procedures for modifying a nonstandard softkey template.
Adding Application Softkeys to Nonstandard Templates
CIPT1 v4.14-5
The administrator can add a standard softkey template that is associated with a Cisco application (for example, Cisco IPMA Manager or Cisco IMPA 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. 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.
4-53
Modifying Softkey Positions

This topic describes the modification of softkey positions on Cisco IP Phones.
Modifying Softkey Positions
CIPT1 v4.14-6
You can configure 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 modify the softkey positions. In the upper right corner of the window, choose the Configure Softkey Layout link. The Softkey Layout Configuration window is displayed with Call States on the left and Selected Softkeys on the right. Select the softkeys that you want displayed. You can then use the Up Arrow and Down Arrow keys to rearrange the positions of the selected softkeys (the top position is the leftmost 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-54
Assigning Softkey Templates to Devices

This topic describes the assignment of softkey templates to devices.
Assigning Softkey Templates to Devices
Assign softkey templates through device pools, user device profiles, or on the device itself.
You can assign softkey templates to devices in several ways. The template can be assigned in the device pool settings (System > Device Pool), through a user device profile (Device > Device Settings > Device Profile), or on the device itself (Device > Phone).
4-55
Deleting Softkey Templates

This topic describes how to delete softkey templates.
Deleting Softkey Templates
Remove the template from all devices that are using it before deleting.
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 will 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 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-56
Summary
Summary
There are five standard softkey templates. Nonstandard softkey templates can be created by modifying one of the standard softkey templates. Up to 16 application softkeys can be added to a nonstandard softkey template. Softkey positions can be modified to customize the appearance of the softkeys on Cisco IP Phones. Softkey templates can be assigned to a device in device pool settings, through a user profile, or on the device itself. Nonstandard softkey templates can be deleted only if they are not in use by any device in the Cisco CallManager system.
References
For additional information, refer to these resources: Cisco IP Phones section, Cisco CallManager System Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmsys/index.htm Softkey Template Configuration, Cisco CallManager Administration Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmcfg/index.htm The Help files within Cisco CallManager Administration
4-57
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) Which two of the following are standard application softkey templates that you can add to a nonstandard softkey template? (Choose two.) A) B) C) D) Q2) A) B) C) D) Q3) A) B) C) D) Q4) A) B) C) D) Q5) Standard Phone Standard Application Standard User Standard Feature Device menu Service menu Tools menu Plug-Ins menu copy the template from a standard template create the template from the beginning you cannot create a nonstandard template add the template to the application modifying softkey buttons changing call states copying a standard template applying applications to softkeys
Where are softkey templates located?
How do you create a nonstandard softkey template?
The Softkey Layout Configuration page is used for what purpose?
Which three of these areas can you use to assign a softkey template to a device? (Choose three.) A) B) C) D) device pools user profile device region delete any devices that are using it remove all associations to devices that are using it delete the standard template parent set the Delete Softkey Template flag to TRUE
Q6)
What must you do before you can delete a softkey template? A) B) C) D)
4-58
Quiz Answer Key

Q1) C, D Relates to: Adding Application Softkeys to Nonstandard Softkey Templates Q2) A Relates to: Overview of the Softkey Template Q3) A Relates to: Creating Nonstandard Softkey Templates Q4) A Relates to: Modifying Softkey Positions Q5) A, B, C Relates to: Assigning Softkey Templates to Devices Q6) B Relates to: Deleting Softkey Templates
4-59
4-60
Configuring User Features

Overview
This lesson discusses the many 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 and Privacy; Cisco IP Manager Assistant (IPMA), and Cisco IP Phone Services. The purpose of each feature is explained and how to configure and use the feature.
Relevance
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 are properly configured.
Objectives
Upon completing this lesson, you will be able to configure and use many user phone features to include speed dials, Call Park, Call Pickup, Cisco Call Back, Barge, Privacy, Cisco IPMA, and Cisco IP Phone services. This includes being able to meet these objectives: Describe core IP Phone features of Cisco CallManager to include hold, redial, transfer, speed 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, Immediate Divert, and Multilevel Precedence and Preemption 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 Phone Identify the two Cisco IPMA modes and key capabilities of each mode Configure Cisco IPMA to include configuration of service parameters, configuration of a manager and assignment of an assistant, and creation of a telephone button template with an intercom line for managers and assistants
Use the Cisco IPMA Manager Configuration page to set a divert target for manager calls and use the Cisco CallManager Assistant Console to perform call tasks to include Direct Transfer, Call Join, and conferencing

To benefit fully from this lesson, you must have these prerequisite skills and knowledge: Navigation within Cisco CallManager Administration Cisco IOS command-line basics
Outline
Outline
Overview Core IP Phone Features Enhanced IP Phone Features Call Park, Call Pickup, and Cisco Call Back Barge and Privacy Cisco IP Phone Services Cisco IP Manager Assistant Overview Cisco IPMA for Shared-Line Support Manager Configuration and Assistant Console Summary Quiz
4-62
Core IP Phone Features

This topic discusses the core features of Cisco IP Phones.
Basic IP Phone Features
Hold* Redial* Transfer* Call Waiting

*Requires no configuration
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, VoIP gateways, and multimedia applications. Three basic IP Phone features do not require configuration in Cisco CallManager and are useractivated by pressing a softkey on the IP Phone: Hold: Places an active call on hold. Hold requires no configuration, unless you want to use 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 as 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, which is configured with Ring Setting (Phone Active) in the Directory Number Configuration window in Cisco CallManager Administration.
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 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 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. Speed dial entries that are not assigned to the speed dial buttons on the phone are used for abbreviated dialing. Administrators or users can configure speed dials or abbreviated dials in Cisco CallManager Administration (administrators only) or the CallManager User Options page (http://<server IP address>/ccmuser/logon.asp). Configure abbreviated dials just as you would configure speed dials.
4-64
Auto Answer Configuration
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 select Auto Answer Off, Auto Answer with Headset, or Auto Answer with Speakerphone.
4-65
Call Forward and Configurable Call Forward Display Configuration
Call Forward
Configurable Call Forward Display
CIPT1 v4.14-6
Call Forward 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 page covers the call forward options that the Cisco CallManager administrator can configure on the Directory Number Configuration page. Users can forward all calls in two ways only: by using a softkey or by accessing the User Options web pages.
Use call forwarding to perform the following tasks: Send incoming calls to another number: Use call forwarding to send calls to another number where they can be answered (for example, if the user is going to be working in an alternate office, at home, or with a mobile number while on the road). Send incoming calls directly to voice mail: Use call forwarding to send calls directly to the voice-mail system. The desk telephone will not ring when calls are routed to voice mail through the call-forwarding feature. The three types of call forwarding are as follows: Forward All: Indicates the DN to which all calls are forwarded Forward Busy: Indicates the DN that a call is forwarded to when the line is in use Forward No Answer: Indicates the DN that a call is forwarded to when no one answers after four rings Starting with Cisco CallManager 4.0, the administrator can configure call-forwarding information display options to the original dialed number or the redirected dialed number, or 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 gets configured for each line appearance.
4-66
Enhanced IP Phone Features

This topic discusses enhanced Cisco IP Phone features that are available in Cisco CallManager 4.0.
Multiple Calls per Line Appearance

CallManager 4.0 enhancement to increase number of calls per line appearance Configure using: Maximum Number of Calls Busy Trigger No Answer Ring Duration
Cisco CallManager 4.0 enables multiple calls to exist on the same line. This feature eliminates the need to create multiple instances of the same directory 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. CallManager will now support up to 200 active calls on a single line and one connected call per telephone at any time. A new user interaction model has been introduced to allow a user to easily manage more than one call on the line and view calling names and numbers of the calls on the line. With the multiple-calls feature, the system administrator can now do the following on a line-byline basis: Provision a call forward no answer timer Provision the maximum number of calls that will be allowed on the line Provision the maximum number of incoming calls that will be allowed on the line Three configuration settings enable multiple line appearances. All three of the following features are configured from the Directory Number Configuration page: 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 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, determines the maximum number of calls to be presented at the line. If the maximum number of calls is set for 50 and the busy trigger is set to 40, then incoming call 41 gets rejected with a busy cause code (and will get forwarded if Call Forward Busy is set). If this line is shared, all the lines must be busy before incoming calls get rejected. No Answer Ring Duration: Used in conjunction with Call Forward No Answer Destination, this field sets the timer for how long the phone will ring before it gets forwarded. Leave this setting blank to use the value that is set in the Cisco CallManager service parameter, Forward No Answer Timer.
Example: Configuration Settings for Multiple Calls Per Line Appearance

In the accompanying 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 will be forwarded to the call forward busy destination. The user, however, can place up to two more calls.
4-68
Direct Transfer
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 (defined as a call in the hold or connected state) calls 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 conference after the transaction is complete and the call is released from the IP Phone of the initiator.
Example: Direct Transfer Call

The figure and the following steps illustrate the user sequence of events in a typical Direct Transfer call:
Step 1 Step 2 Step 3 Step 4 Step 5
Sam and Kim are in an active call. Sam asks Kim to transfer him to Mary. Kim puts Sam on hold. Kim calls Mary. Kim touches Sams line (Cisco IP Phone model 7970 only) or uses the Select softkey to select Sams line. Kim hits the DirTrfr key, and Sam and Mary are immediately connected.
Step 6
4-69
Call Join
The Join softkey can join up to 15 established calls (16 parties) in a conference in a single feature request. User chooses an active or held call, selects the appropriate line, and presses The Join softkey. Selected calls and Join initiator are joined into an ad hoc conference. Initiator can leave Join session and conference stays up.
Introduced in Cisco CallManager 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 and 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 7960 and 7940 IP Phones) 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 join initiator are joined in an ad hoc conference. The initiator can leave the Call Join session at any time, and the conference stays up. Only the initiator of the Call Join session may add participants to the conference or drop them from it.
4-70
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 4.0. This feature allows you to immediately divert a call to a voice-messaging system. When the call gets 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 to operate: Cisco CallManager 4.0 or later. Cisco IP Phones (models 7905, 7912, 7920, 7940, 7960, or 7970).
Note 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.
4-71
Example: Called Party Presses iDivert Softkey

The figure and the following steps illustrate the user sequence of events in a typical Immediate Divert call when a called party presses the iDivert softkey while the call is in the call-offering state:
George calls Sam. Sam is unable to take call. Sam diverts the call to voice mail by pressing the iDivert softkey. George receives the voice-messaging mailbox 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 the information on her (the managers) voice mail box for retrieval later.
Step 1 Step 2 Step 3 Step 4 Step 5
Party A calls Party B. Party B answers the call. Party A presses the iDivert softkey. Party B hears the outgoing voice-mail greeting of Party A. Party B leaves a voice message.
4-72
Multilevel Precedence and Preemption

Allows placement of priority calls Allows authenticated users to pre-empt lowerprecedence calls Does not relate to Call Admission Control or E911 calls Works with annunciator feature to advise users that they have a highprecedence call
Phone A
Phone B
Most phone systems are designed to accommodate busy hour traffic. However, should an emergency occur, chances are that everyone would attempt to make a phone call at the same time and this behavior could overwhelm the system. Under national emergency or degraded network situations, organizations might want to give certain individuals calling precedence over others in order to implement emergency plans. The Multilevel Precedence and Preemption (MLPP) feature, introduced in Cisco CallManager 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 party are aware of an MLPP call. MLPP-indication-enabled devices can play pre-emption tones and receive MLPP pre-emption announcements that the announcement server (annunciator) generates when there is a high-precedence call. Both the precedence ringback and ringer have a different cadence than the regular ringback and ringer. MLPP indication settings are configured on the device pages in Cisco CallManager Administration. The five MLPP precedence levels that are presented in the following table are available in the Translation Pattern Configuration page of Cisco CallManager Administration (Route Plan > Translation Pattern).
4-73
MLPP Precedence Levels

MLPP Precedence Setting 0 (highest) 1 2 3 4 (lowest) Precedence Flash Override Flash Immediate Priority Routine
Calls with a precedence level higher than routine are considered precedence calls.
Example: MLPP Call

In the figure, Phone B (x3116) is on a call with no precedence. Phone A (x3101) 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 pre-emption 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-74
Malicious Call Identification

Victim receives a call from malicious caller and invokes MCID feature.
Allows a user that has received a malicious call 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
Victim
IOS GW
Malicious Caller
PSTN
CIPT1 v4.14-12
Malicious Call Identification (MCID), which was introduced in Cisco CallManager 4.0, allows users to initiate a sequence of events when they receive calls with a malicious intent. 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 Call Detail Record (CDR) with the MCID notice and sends a notification to the off-net PSTN that a malicious call is in progress.
4-75
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/Range is unique within the cluster and that each Cisco CallManager that devices are registered to has its own unique Call Park Number/Range.
CIPT1 v4.14-13
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, 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. The user will use 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, 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-76
Call Pickup/Group Call Pickup

Call Pickup Group Call Pickup
Picks up call
Group A
Group B
Group C
Call Pickup:
Allows a user to answer a call that is ringing on any telephone in their call pickup group
Group Call Pickup:

Allows a user to answer a call that is ringing on any telephone, if they know the call pickup group number associated with that call
Call groups enable users (who have been configured as part of a group) to answer calls on their own telephone or any other phone that is part of the group that come in on a DN other than their own. 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. Only Cisco IP Phones that are configured in a pickup group can use these features. Two 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 group 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. You use the same procedures to configure both of these features. The Group Call Pickup numbers apply to lines or DNs.
4-77
Call Pickup Configuration
Configure a unique Call Pickup number
Assign the Call Pickup number to a line or DN
CIPT1 v4.14-15
The first step to configure a Call Pickup group is to create a Call Pickup number. This number must be unique within a cluster. You can assign a partition to the Call Pickup number that allows access to the Call Pickup number of the pickup group that is based on the calling search space of the device. To create a Call Pickup number, choose Feature > Call Pickup in Cisco CallManager Administration. After configuring the Call Pickup number, you assign it to a line or DN of a Cisco IP Phone. On the Directory Number Configuration page in Call Forward and Pickup Settings, choose the Call Pickup number from the Call Pickup Group menu. Repeat this action for all other Call Pickup numbers that are to be assigned to this Call Pickup group.
Example: Call Pickup Groups in Sales Support Department

The ABC Company sells two widgets, one geared to consumers and the other geared to enterprises. The sales staff is broken into two Call Pickup groups, 1234 for consumers and 5678 for enterprises. When a call comes into the bank of Cisco IP Phones in Call Pickup group 1234, any one of the IP Phones that are assigned to the consumer group can answer it by pressing the PickUp softkey. The calls that are destined for group 5678 can be answered by any of the IP Phones that are configured in the enterprise group. You can use distinctive ringer options to differentiate between the two groups of IP Phones.
4-78
Cisco Call Back
Receive call-back notification when a called party becomes available

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 callback 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 feature). Cisco Call Back requires Cisco CallManager version 3.3 or later. Cisco IP Phones that support softkeys support the CallBack softkey. You can call the majority of Cisco IP Phones and have Cisco Call Back activated on them. 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. The calling IP Phone should be a model 7960 or 7940 that supports softkeys. To configure Cisco Call Back, choose the softkey template (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, and include CallBack 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 will receive an audio alert and visual notification.
4-79
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.
2 Barge Process Initiator
1. Original two-party call 2. Initiator barges into the call 3-way call If initiator hangs up, original call remains activeOR If target hangs up, initiator and other party connect point-to-pointOR If other party hangs up, original call and barged call get released.
1
Media
Media
Target
Other Party
Barge adds a user to a call that is already in progress (connected or hold state). The Barge feature supports shared lines only. You can press a softkey to automatically add the user (initiator) to the shared-line call (target). The users currently on the call will receive a tone (if the feature is configured). Two types of Barge are available in Cisco CallManager version 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). Neither a media interruption nor a display change to the original call can occur when the Barge is being set up. A spinning circle 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 access the cBarge softkey, the administrator adds it to a softkey template and then assigns 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 gets 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 get reconnected as a point-to-point call, which releases the shared conference resources.
4-80 Cisco IP Telephony Part 1 (CIPT1) v4.0 Copyright 2004, Cisco Systems, Inc.
When the initiator barges into the call, it becomes a three-way call. If the initiator hangs up, the original call remains active. If the target hangs up, the Barger and the other party connect in a point-to-point call. If the other party hangs up, the original call and the barged call get released. Privacy was introduced in Cisco CallManager 4.0. With Privacy, administrators can enable or disable the capability 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 Cisco IP Phone models 7940, 7960, and 7970. Barge and Privacy require Cisco CallManager 4.0.
4-81
Shared Line Appearance
Same DN on more than one device in same partition

Barge requires a shared line appearance. Cisco CallManager considers a DN on more than one device in the same partition as 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. To stop sharing a line appearance on a device, you can change the DN or partition number for the line and update the device. (Delete 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.
4-82
Barge Configuration
Enable at Device Level
OR
Enable Clusterwide
CIPT1 v4.14-19
To configure Barge with built-in conference bridge, follow these steps:

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. To enable Barge clusterwide for all users, choose Service > Service Parameters and set the Built-In Bridge Enable clusterwide 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. Set the Party Entrance Tone to True if you desire tones when a Barge occurs.
Step 2
Step 3
4-83
Privacy Configuration
Enable at Device Level Enable Clusterwide
OR
. . .
CIPT1 v4.14-20
To configure Privacy, follow these steps:

Step 1
Set the optional Privacy Setting clusterwide service parameter to True.

Do not set this parameter if only a few users need access to Privacy (see Step 3).
Note Step 2
For each phone button template that has Privacy, add Privacy to one of the feature buttons. For each telephone user that wants Privacy, choose On in the Privacy drop-down list box in the Phone Configuration window. If you have configured Privacy clusterwide, you can leave the Privacy setting at Default or set it to Off to selectively disable privacy. For each telephone user that wants Privacy, choose the phone button template that contains the Privacy feature button that you created in Step 2.
Step 3
Step 4
4-84
Cisco IP Phone Services

This topic discusses the Cisco IP Phone Services feature that is available in Cisco CallManager.
Cisco IP Phone Services

Cisco IP Phone Services includes XML applications that display interactive content. Two ways to access services: Button labeled Services to access a menu of services Preconfigured phone button to access a specific service
Service URL Button
Services Button
Cisco IP Phone Services includes extensible markup language (XML) applications that enable the display of interactive content with text and graphics on Cisco IP Phone models 7970, 7960, 7940, 7912, and 7905.
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 their IP Phone. A user can access a service from the supported phone model in two ways. The user can press the button labeled Services" or the user can use a preconfigured phone button. By pressing 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 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-85
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 Developers 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/
4-86
IP Phone Services Configuration
Update parameters to IP address if not using DNS

You can add services to Cisco CallManager by using the Cisco IP Phone Services Configuration page. After services are configured in Cisco CallManager Administration, users or administrators can subscribe to these services for the devices that they have access to.
Add an IP Phone Service

To add an IP Phone service, perform the following steps:
Step 1 Step 2
Choose Feature > Cisco IP Phone Services. 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. 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 Service Name or for Description, choose the character set for that language.
4-87
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:
Step 1 Step 2 Step 3 Step 4 Step 5 Step 6
Customize a telephone button template by configuring a Service URL button. Add the customized phone button template to the telephone. Choose Device > Phone. To locate a specific telephone, enter search criteria and click Find. Choose the telephone to which you want to add a service URL button. On the upper right side of the window, click the Add/Update Service URL Buttons link. From the Service drop-down list box, choose the service that you want to add to the telephone. 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.
Step 7
Step 8
4-88
Cisco IP Phone Services Examples

Meeting Room Scheduler World Clock Weather Yellow Pages Lookup
Flight Status Stock Tracker Transit Schedules
CIPT1 v4.14-23
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-89
Services Phone Display Examples
Menu
Text
Input
Image
Directory
Graphical
CIPT1 v4.14-22
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-90
Cisco IP Manager Assistant Overview

This topic includes an overview of the Cisco IP Manager Assistant (IPMA).
Overview of the Cisco IPMA Architecture

IPMA Service HTTP Tomcat IIS TCP/IP Assistant Console Apps, Manager Configuration Apps Browser
MA Servlet
HTTP Cisco Cisco CallManager CallManager DIR DB Softkey Display
Assistant IP Phone Manager IP Phone
CTI Manager
Cisco CallManager
Cisco CallManager
CIPT1 v4.14-25
The Cisco IPMA is a feature that allows company managers and assistants to effectively work together. The Cisco IPMA feature architecture comprises the Cisco IPMA service, the desktop interfaces, and the Cisco IP Phone interfaces. IPMA Service: Cisco Tomcat loads the Cisco IPMA service, a servlet. Cisco Tomcat, an NT service, gets 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 pages. Communicates to a Cisco CallManager cluster through the Cisco CTIManager for third-party call control. Cisco IPMA requires only one 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, logon, assistant preferences, monitoring the call activity of managers, 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.
4-91
The following restrictions apply to Cisco IPMA: One manager can have up to 10 assigned assistants. One assistant can support up to 33 managers (if the managers have one IPMA-controlled line each). This feature works only with Cisco IP Phone models 7970, 7960, or 7940.
Note A Cisco IP Phone model 7960 that is running Cisco IPMA may be equipped with a Model 7914 Expansion Module.
Cisco CallManager supports two IPMA modes: proxy-line mode (CallManager version 3.3 or later) and shared-line mode (CallManager version 4.0 or later).
4-92
Cisco IPMA with Proxy-Line Support

Intercepts manager calls on a proxy line Requires partitions, calling search spaces, route points, and translation patterns Uses IPMA Configuration Wizard Uses Standard IPMA Manager softkey template
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 IPMA manager telephone, the 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 4.0 supports the existing proxy-line configuration in earlier versions of Cisco CallManager, but new 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.
4-93
Cisco IPMA with Shared-Line Support

Assistants share primary line of manager No call routing IPMA Wizard need not be used No route points, partitions, calling search spaces, or translation patterns Support for new features Multiple calls per line, Direct Transfer, Call Join Uses Standard IPMA Shared Mode Manager softkey template
DND State Manager Display
Cisco IPMA with shared-line support enables the assistant to share the primary line of the manager (both assistant and manager have the same DN configured on one line). There is no call routing in shared-line mode. The calls for the manager ring on both the manager line and the assistant line. The Cisco IPMA Configuration Wizard is not used in the 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 will display the DND state. ImmDiv (Immediate Divert): Diverts the selected call to a preconfigured target. TransferToVM (Transfer to Voicemail): Redirects the selected call to the voice-mail box of the manager. A dedicated incoming intercom line is administered on the manager telephone (optional). Speed dials are administered on the manager phone for all the assistants for which the manager is configured. Cisco IP Phone Services is not supported in shared-line mode for managers.
4-94
Cisco IPMA for Shared-Line Support

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

1. Configure service parameters 2. Restart IPMA service 3. Configure an IPMA manager and assign an assistant 4. Access Manager Configuration (users or administrator)
CIPT1 v4.14-28
After you activate the Cisco IPMA service, follow these steps to configure IPMA:
Configure the appropriate service parameters. Restart the Cisco IPMA service from the Tomcat web page. Configure an IPMA manager and assign an assistant. Access Manager Configuration (users or administrator).
Activating the Cisco IPMA Service

To activate the Cisco IPMA service, follow these steps:
Step 1
From 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. Check the Cisco IP Manager Assistant check box and click Update.
Step 4
The window displays the services that you chose with an activation status of Activated.
Configuring Service Parameters
Insert IP address of CTIManager
Insert IP address of IPMA Server . . . Softkey templates preselected

Service parameters for the Cisco IPMA service consist of two categories: general and clusterwide. Specify clusterwide 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 CTIManager that will be used for call control. Cisco CTIManager (Secondary) IP Address: No default. The administrator must manually enter this IP address. Route Point Device Name: No default. Choose the Cisco IPMA route point device name (which you configure by using Device > CTI Route Point). Cisco IPMA Server (Primary) IP Address: No default. The administrator must manually enter this IP address. Cisco IPMA Server (Backup) IP Address: No default. The administrator must manually enter this IP address. Cisco IPMA RNA (Ring No Answer) Forwarding Flag: The default specifies False. If the parameter is set to True, an assistant phone that does not get answered will forward to another assistant phone.
The clusterwide parameters include the following:
4-96
Cisco IPMA RNA Timeout: The default specifies 10 sec. RNA timeout specifies how long an assistant phone can go unanswered before the call is forwarded to another assistant phone. If Call Forward No Answer (CFNA) and RNA timeout are both configured, the first timeout occurrence takes precedence. Desktop Heartbeat Interval: The default specifies 30 sec. This interval timer specifies how long it takes for the failover to occur on the assistant desktop. Desktop Request Timeout: The default specifies 30 sec. Cisco IPMA Server Port: The default specifies Port 2912.
Cisco IPMA includes the following softkey templates that must be configured as clusterwide parameters if you want to use the 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 IPMA assistant automatic configuration. Manager Softkey Template for Shared Mode: The default specifies Standard IPMA Shared Mode Manager.
Note For proxy-mode configuration, use the Standard IPMA Manager softkey template in place of the Standard IPMA Shared Mode Manager softkey template.
4-97
Stopping/Starting Cisco IPMA Service
IPMA Service
http://<IPMA server>/manager/list
The Cisco IPMA service runs as an application on Cisco Tomcat. To start or stop the Cisco IPMA service, log onto the Tomcat Web Application Manager window by using administrator privileges. The URL to 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 4.0 or later. It enables you to start or stop an existing application without having to shut down and restart Tomcat. If you have prior versions, you will need to stop and then start Tomcat by going to Start > Programs > Administrative Tools > Services > Cisco Tomcat. Right-click and choose Restart.
4-98
Configuring a Manager and Assigning an Assistant Part 1
Click Cisco IPMA from Application Profiles list
Choose Continue to configure a manager
CIPT1 v4.14-31
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. Prior to performing these steps, the managers and assistants must already exist, be associated with their respective devices, and have a shared line appearance.
Step 1 Step 2
Choose User > Global Directory. To find the user that will be the IPMA manager, click the Search button or enter the user name in the field and click the Search button. To display user information for the chosen manager, click the user name. The User Configuration window is displayed.
Step 3
Step 4
To configure IPMA information for the manager, click Cisco IPMA from the Application Profiles list box. If this is the first time that this user is configured for IPMA, the User Configuration window displays a message to continue configuration for a manager or to cancel if the user 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, IPMA-controlled lines, and intercom line.
4-99
Choose Automatic Configuration Choose Shared Lines Assign Assistants Choose Intercom Line Choose Shared Line
Follow these steps to configure manager information on the User Configuration page:
Step 1 Step 2
Click the Uses Shared Lines check box. 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
To associate a device name or device profile with a manager, choose the device name or device profile from the Device Name/Profile selection box.
If the manager telecommutes, click the Mobile Manager check box and optionally choose Device Profile.
Note
Step 4
From the Intercom Line selection box, choose the intercom line appearance for the manager, if applicable. From the Available Lines selection box, choose a line that you want to be controlled by Cisco IPMA and click the right arrow. The line appears in the Selected Lines selection box. Configure up to five IPMA-controlled lines.
The IPMA-controlled lines (selected) must always be the shared-line DN.
Step 5
Note Step 6
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.
4-100
CIPT1 v4.14-33
From the User Configuration page, 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 name of the assistant in the search field. A list of available assistants is displayed in the window.
Step 2
Click 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.
Note Step 3
To save and continue, click the Insert button; otherwise, to return to the 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.
4-101
Manager Configuration and Assistant Console

This topic discusses the two user applications that are available in Cisco IPMA: the Manager Configuration window and Assistant Console.
Accessing Manager Configuration Features

Access Cisco IPMA Manager Configuration at:
http://<ipma-serverip>/ma/desktop/maLogin.jsp
Set a divert target (must be DN)
CIPT1 v4.14-34
Both managers and assistants can modify manager preferences from the Manager Configuration window at the following URL: 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 your office phone.
4-102
Using Assistant Console

Menu Bar Call Control Buttons My Calls Panel
Speed Dials Panel
Directory Panel
My Managers Panel
Status Bar
CIPT1 v4.14-35
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. Position 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. My Calls Panel: The Assistant Console displays calls for you and for your 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 you have placed or received using your own telephone line Manager Lines: Displays active calls that you are handling or can handle on behalf of your manager Intercom: Displays the status of your intercom lines, if applicable
4-103
My Managers Panel: You can use the My Managers panel in the Assistant Console to monitor call activity and feature status for each manager. You can also enable and disable manager features from this panel. Speed Dials Panel: The speed dial feature allows you to set up a personal phone book right on the Assistant Console. You can 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/Not Connected: Indicates the status of your connection to the Cisco IPMA server Online/Offline: Indicates your availability to managers Call Control Up/Call Control Down: Indicates the availability of call-handling features Filtering Down: Indicates the availability of call-filtering features (proxy mode)
4-104
Summary
Summary
Cisco CallManager core features include hold, redial, and transfer. Cisco CallManager enhanced features include Call Join, multiple calls per line appearance, Immediate Divert, and MLPP. 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 you to receive call-back notification when a called-party line becomes available.
CIPT1 v4.14-36
Summary (Cont.)
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 displays interactive content with text and graphics. Cisco IPMA supports proxy-line mode and shared- line mode. Configuring Cisco IPMA consists of configuring service parameters and configuring an IPMA manager and assigning an assistant. The Manager Configuration window and Assistant Console are the two end-user IPMA applications.
4-105
References
For additional information, refer to these resources: Cisco CallManager Features and Services Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmfeat/index.htm Cisco CallManager Administration Guide, Release 4.0(1): http://lbj.cisco.com/push_targets1/ucdit/cc/td/doc/product/voice/c_callmg/4_0/sys_ad/4_0_ 1/ccmcfg/index.htm Cisco IP Manager Assistant User Guide for Cisco CallManager 4.0: http://www.cisco.com/univercd/cc/td/doc/product/voice/c_ipphon/english/ipma/user/4_0/ The Help files within Cisco CallManager Administration
4-106
Quiz
Use the practice items here to review what you learned in this lesson. The correct answers are found in the Quiz Answer Key. Q1) Which statement is most closely associated with IPMA shared-line mode? A) B) C) D) Q2) A) B) C) D) Q3) 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 The user must log onto the Assistant Console and set a divert target. The Cisco CallManager administrator must add a Service URL phone button. The Cisco CallManager administrator must configure the Cisco IP Phone Services. The user must have LCD-capable Cisco IP Phones (models 7940, 7960, or 7970).
What must happen before users can subscribe to Cisco IP Phone Services?
Which feature could be used in a sales support department to cover incoming calls as a group? A) B) C) D) Call Pickup Call Park Call Forward Call Back enables users who receive a malevolent call to notify authorities prevents users on a shared line from barging in on a call enables users to dial a code and get their call prioritized prevents users on a shared line from viewing call details Call Forward Call Waiting Call Park Transfer
Q4)
When the Privacy feature is enabled, it performs which two functions? (Choose two.) A) B) C) D)
Q5)
Which feature requires no administrator configuration? A) B) C) D)
Q6)
For which softkey is the initiating user NOT included in the conference after the transaction completes? A) B) C) D) Barge cBarge DirTrfr Join
Q7)
Managers can do which of the following when they access Cisco IPMA Manager Configuration in shared-line mode? A) B) C) D) configure speed dials change the divert target assign an assistant subscribe to services
Enabling Features for Users 4-107
Q8)
When you configure IPMA in shared-line mode, the IPMA-controlled line must always be which line? A) B) C) D) intercom primary line of the assistant shared DN proxy
4-108
Quiz Answer Key

Q1) A Relates to: Cisco IP Manager Assistant Overview Q2) C Relates to: Cisco IP Phone Services Q3) A Relates to: Call Park, Call Pickup, and Cisco Call Back Q4) B, D Relates to: Barge and Privacy Q5) D Relates to: Core IP Phone Features Q6) C Relates to: Enhanced IP Phone Features Q7) B Relates to: Manager Configuration and Assistant Console Q8) C Relates to: Cisco IPMA for Shared-Line Support
4-109
4-110

Cisco IP Telephony-CIPT-Part 1 Student Guide v.40

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Cisco IP Telephony-CIPT-Part 1 Student Guide v.40

Загружено:

Авторское право:

Доступные форматы

CIPT1

Cisco IP Telephony Part 1

Copyright 2004, Cisco Systems, Inc. All rights reserved.

Students, this letter describes important course evaluation access information!

Getting Started with Cisco CallManager

Identifying Cisco IP Telephony Components

Identifying Cisco CallManager Cluster and Deployment Options

Installing Cisco CallManager

Establishing an On-Cluster Call

Introducing Cisco IP Phones

Configuring Cisco CallManager to Support IP Phones

Cisco IP Telephony Part 1 (CIPT1) v4.0

Copyright 2004, Cisco Systems, Inc.

Configuring Cisco Catalyst Switches

Adding Users and Customizing User Options

Using the Bulk Administration Tool

References Quiz Quiz Answer Key

2-113 2-114 2-116

Establishing an Off-Cluster Call

Configuring Gateways and Intercluster Trunks

Configuring Basic Route Plans

Configuring Advanced Route Plans

Configuring Telephony Class of Service

Configuring Call Admission Control and Survivable Remote Site Telephony

Enabling Features for Users

Configuring Media Resources

Quiz Answer Key

Working with Softkey Templates

Configuring User Features

Cisco IP Telephony Part 1 (CIPT1) v4.0

Copyright 2004, Cisco Systems, Inc.

Course Goal and Objectives

2004 Cisco Systems, Inc. All rights reserved.

Cisco IP Telephony Part 1 (CIPT1) v4.0

Copyright 2004, Cisco Systems, Inc.

2004 Cisco Systems, Inc. All rights reserved.

Copyright 2004, Cisco Systems, Inc.

2004 Cisco Systems, Inc. All rights reserved.

Cisco IP Telephony Part 1 (CIPT1) v4.0

Copyright 2004, Cisco Systems, Inc.

Learner Skills and Knowledge

Prerequisite Learner Skills and Knowledge

Microsoft Software for Cisco Voice (MSCV)

Copyright 2004, Cisco Systems, Inc.

Complete prerequisites Introduce yourself Ask questions

2004 Cisco Systems, Inc. All rights reserved.

Cisco IP Telephony Part 1 (CIPT1) v4.0

Copyright 2004, Cisco Systems, Inc.

2004 Cisco Systems, Inc. All rights reserved.

Copyright 2004, Cisco Systems, Inc.

Course Flow Diagram

Course Flow Diagram

Getting Started with Cisco CallManager

Establishing an OnCluster Call

Establishing an OffCluster Call

Enabling Features for Users

Establishing an OnCluster Call

Wrap-up Establishing an OffCluster Call Enabling Features for Users

2004 Cisco Systems, Inc. All rights reserved.

Cisco IP Telephony Part 1 (CIPT1) v4.0

Copyright 2004, Cisco Systems, Inc.

Icons and Symbols

Course Icons and Symbols