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 1

Overview 1 Course Goal and Objectives 2 Course Outline 3

Cisco Certifications 4 Learner Skills and Knowledge 5 Learner Responsibilities 6 General Administration 7 Course Flow Diagram 8 Icons and Symbols 9 Learner Introductions 10

Getting Started with Cisco CallManager 1-1 Overview 1-1

Module Objectives 1-1 Outline 1-2

Identifying Cisco IP Telephony Components 1-3 Overview 1-3

Relevance 1-3 Objectives 1-3 Learner Skills and Knowledge 1-4 Outline 1-4

Cisco AVVID 1-5 Cisco IP Communications Components 1-6 Cisco IP Telephony Components 1-7 Cisco CallManager Functions 1-9

Example: Basic IP Telephony Call 1-10 Comparing Legacy and IP Telephony Technology 1-11 Cisco CallManager Operating System, Database, and Supporting Applications 1-13 Supported Cisco CallManager Hardware 1-14 Device Weight Units 1-16

Example: Device Weights 1-17 Summary 1-18

References 1-19 Quiz 1-20

Quiz Answer Key 1-22 Identifying Cisco CallManager Cluster and Deployment Options 1-23

Overview 1-23 Relevance 1-23 Objectives 1-23 Learner Skills and Knowledge 1-24 Outline 1-24

Microsoft SQL Cluster Relationship 1-25 Intracluster Communication 1-27 Cluster Redundancy Designs 1-28 IP Telephony Deployment Models 1-30 Single-Site Deployment 1-31 Multisite WAN with Centralized Call Processing 1-33 Multisite WAN with Distributed Call Processing 1-36 Single-Cluster Distributed Call Processing 1-39 Summary 1-41


Quiz Answer Key 1-45


ii Cisco IP Telephony Part 1 (CIPT1) v4.0 Copyright © 2004, Cisco Systems, Inc.

Installing Cisco CallManager 1-47 Overview 1-47


Installation CD-ROMs 1-49 Installation Configuration Data 1-50

Example: Configuration Data Worksheet 1-52 Activating Cisco CallManager Services 1-54 Postinstallation Procedures 1-57 Upgrading Prior Cisco CallManager Versions 1-62 Summary 1-67


Quiz Answer Key 1-69 Establishing an On-Cluster Call 2-1

Overview 2-1 Module Objectives 2-2 Module Outline 2-2

Introducing Cisco IP Phones 2-3 Overview 2-3


Cisco IP Phone Overview 2-5 Entry-Level Cisco IP Phones 2-6 Midrange and Upper-End Cisco IP Phones 2-8 Additional Cisco VoIP Devices 2-10 IP Phone Startup Process 2-12 Cisco IP Phone Codec Support 2-14 Summary 2-16


Quiz Answer Key 2-20 Configuring Cisco CallManager to Support IP Phones 2-21


Server Configuration 2-23 Configuring Device Pools 2-24

Example: Device Pool Configuration 2-25 Example: Cisco CallManager Group Configuration 2-27 Example: Region Configuration 2-30

IP Phone Button Templates 2-32 Example: Naming an IP Phone Button Template 2-33

Manual IP Phone and Directory Number Configuration 2-34 Configuring IP Phone Auto-Registration 2-36 Summary 2-38




Copyright © 2004, Cisco Systems, Inc. Cisco IP Telephony Part 1 (CIPT1) v4.0 iii

Configuring Cisco Catalyst Switches 2-41 Overview 2-41


Catalyst Switch Role in IP Telephony 2-43 Powering the Cisco IP Phone 2-44 Types of Inline Power Delivery 2-45 Catalyst Family of PoE Switches 2-49 Configuring Inline Power 2-51 Configuring Dual VLANs 2-53 Configuring Class of Service 2-59 Summary 2-61


Quiz Answer Key 2-65 Adding Users and Customizing User Options 2-67


Adding a User 2-69 User Logon and Device Selection 2-72 Call Forward 2-74

Example: Call Forwarding 2-74 Speed Dials 2-75

Example: Adding an Access Code to Speed Dial Numbers 2-75 Cisco IP Phone Services Subscription 2-76

Example: Subscribing to a Stock Quote Service 2-76 Personal Address Book 2-77

Example: Personal Address Book and Fast Dials 2-77 Message Waiting Lamp Policy 2-78

Example: Setting the Message Waiting Lamp Policy 2-78 Personalizing Device and Web Page Locale 2-79

Example: Setting the User Locale on the Phone 2-80 Summary 2-82


Quiz Answer Key 2-86 Using the Bulk Administration Tool 2-87


Introducing the Bulk Administration Tool 2-89 Installing BAT 2-92 Using the BAT Wizard 2-94 Configuring BAT Templates 2-98 Creating CSV Files 2-101

Example: Sample CSV Data File with Customized File Format 2-103 Validating Data Input Files 2-104 Inserting IP Phones into Cisco CallManager 2-105 Updating IP Phones with BAT 2-106 Using the Tool for Auto-Registered Phones Support 2-108 Summary 2-112


iv Cisco IP Telephony Part 1 (CIPT1) v4.0 Copyright © 2004, Cisco Systems, Inc.


Quiz Answer Key 2-116 Establishing an Off-Cluster Call 3-1

Overview 3-1 Module Objectives 3-2 Outline 3-2

Configuring Gateways and Intercluster Trunks 3-3 Overview 3-3


The Gateway in an IP Telephony Infrastructure 3-5 Analog and Digital Gateways 3-6 Core Gateway Requirements 3-7 Gateway Communication Overview 3-8 Configuring Access Gateways 3-10

Example: H.323 Gateway Configuration 3-12 Example: MGCP Gateway Configuration 3-15

Configuring Intercluster Trunks 3-18 Summary 3-21


Quiz Answer Key 3-24 Configuring Basic Route Plans 3-25


External Call Routing 3-27 Route Groups 3-30 Route Lists 3-32 Route Patterns 3-34 Digit Analysis 3-40 Summary of Call Routing 3-45

Example: Route Plan 3-48 Summary 3-49 Quiz 3-50

Quiz Answer Key 3-51 Configuring Advanced Route Plans 3-53


Route Filters 3-55 Discard Digits Instructions 3-60 Transformation Masks 3-63 Translation Patterns 3-69 Route Plan Report 3-72 Summary 3-74




Copyright © 2004, Cisco Systems, Inc. Cisco IP Telephony Part 1 (CIPT1) v4.0 v

Configuring Telephony Class of Service 3-77 Overview 3-77


Class of Service 3-79 Partitions 3-82

Example: Assigning DNs to Partitions 3-83 Calling Search Spaces 3-84

Example: Assigning Partitions to Calling Search Spaces 3-85 Using Partitions and Calling Search Spaces for Emergency Calls 3-86 Cisco Emergency Responder 3-87 Summary 3-91


Quiz Answer Key 3-94 Configuring Call Admission Control and Survivable Remote Site Telephony 3-95


Call Admission Control Overview 3-97 Locations-Based Call Admission Control Overview 3-99 Locations-Based Call Admission Control Configuration 3-101 Gatekeeper Call Admission Control Overview 3-102 Gatekeeper Communication 3-103 Gatekeeper Call Admission Control Configuration 3-108 SRST Overview 3-112 SRST Configuration 3-118 Summary 3-123


Quiz Answer Key 3-127 Enabling Features for Users 4-1

Overview 4-1 Module Objectives 4-1 Outline 4-2

Configuring Media Resources 4-3 Overview 4-3


Introduction to Media Resources 4-5 Conference Bridge Resources 4-7 Media Termination Point Resources 4-13 Annunciator Resources 4-16

Example: Call Completion Failure and Announcement 4-17 Transcoder Resources 4-20 Music on Hold Resources 4-23 Media Resource Management 4-34

Example: MRG Resource Allocation 4-37 Summary 4-45



vi Cisco IP Telephony Part 1 (CIPT1) v4.0 Copyright © 2004, Cisco Systems, Inc.

Quiz Answer Key 4-47 Working with Softkey Templates 4-49


Overview of the Softkey Template 4-51 Creating Nonstandard Softkey Templates 4-52

Example: Nonstandard Softkey Template 4-52 Adding Application Softkeys to Nonstandard Softkey Templates 4-53 Modifying Softkey Positions 4-54 Assigning Softkey Templates to Devices 4-55 Deleting Softkey Templates 4-56 Summary 4-57


Quiz Answer Key 4-59 Configuring User Features 4-61


Core IP Phone Features 4-63 Enhanced IP Phone Features 4-67

Example: Configuration Settings for Multiple Calls Per Line Appearance 4-68 Example: Direct Transfer Call 4-69 Example: Called Party Presses iDivert Softkey 4-72 Example: Caller Presses iDivert Softkey 4-72 Example: MLPP Call 4-74

Call Park, Call Pickup, and Cisco Call Back 4-76 Example: Call Park Feature in Department Store 4-76 Example: Call Pickup Groups in Sales Support Department 4-78 Example: Cisco Call Back 4-79

Barge and Privacy 4-80 Cisco IP Phone Services 4-85 Cisco IP Manager Assistant Overview 4-91 Cisco IPMA for Shared-Line Support 4-95 Manager Configuration and Assistant Console 4-102 Summary 4-105




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.


2 Cisco IP Telephony Part 1 (CIPT1) v4.0 Copyright © 2004, Cisco Systems, Inc.

Course Goal and Objectives This section describes the course goal and objectives.

© 2004 Cisco Systems, Inc. All rights reserved. CIPT1 v4.1—3

“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

Course Goal

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 Services—you will also be able to use these features on Cisco IP Phones


Copyright © 2004, Cisco Systems, Inc. Course Introduction 3

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



Cisco Certifications This topic lists the certification requirements of this course.


Cisco Certifications

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 requirement—passing 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)

Microsoft Software for Cisco Voice

(MSCV)

Cisco IP Telephony Part 2 (CIPT2)

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)



Learner Responsibilities This topic discusses the responsibilities of the learners.


Learner Responsibilities

• Completeprerequisites

• Introduce yourself

• Ask questions

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

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 Flow Diagram This topic covers the suggested flow of the course materials.


Course Flow Diagram

CourseIntroduction

Getting Started with

Cisco CallManager

Getting Started with

Cisco CallManager Enabling

Features for Users

Lunch

Establishing an On-

Cluster Call

Establishing an Off-

Cluster CallEnabling

Features for Users

AM

PM

Wrap-up

Day 1 Day 2 Day 3 Day 4 Day 5

Establishing an On-

Cluster CallEstablishing

an Off-Cluster Call

Establishing an Off-

Cluster Call

Establishing an On-Cluster

Call

Enabling Featuresfor Users

Est. an Off-Cluster Call

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

Switch

Voice Multilayer Switch

Voice Router

V

SRST-Enabled Router

Switch Router

Cisco CallManager

Traditional PBX

Phone

IP Phone

Gateway

SwitchSwitch PSTNCO Switch

LDAPDirectoryServer

Relational Database

DSP

Digital Signal Processor

VLAN or Cluster(Color May Vary)

File Server


PC

Fax

Printer

WAN

Telecommuter

Mobile User

Course Icons and Symbols (Cont.)

Building

Building

Laptop

Videoconference

Video Camera



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

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


Module 1

Getting Started with Cisco CallManager

Overview Cisco CallManager is the software-based, call-processing component of the Cisco IP telephony solution. This module discusses the servers that Cisco CallManager supports, explores the available deployment models 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.

© 2004 Cisco Systems, Inc. All rights reserved. CIPT1 v4.1—1-2

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


1-2 Cisco IP Telephony Part 1 (CIPT1) v4.0 Copyright © 2004, Cisco Systems, Inc.

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


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



Learner Skills and Knowledge 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


Copyright © 2004, Cisco Systems, Inc. Getting Started with Cisco CallManager 1-5

Cisco AVVID This topic describes the Cisco AVVID strategy, the only enterprise-wide, standards-based network architecture in the industry.


Cisco AVVID

Distributed M

anageable

Adaptive O

pen

Cisco CallManagerCall Admission, Call Routing

Call Processing

Applications TAPI, JTAPI, SMDI Cisco IPCCCisco Unity

Gateway Router Switch

InfrastructureCisco IOS Network Services

IP PhoneCisco IP SoftPhone PCVideo

Client

Directory

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 end-user 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.



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

IP Contact Center

Unified Messaging

ConferenceManager

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.



Cisco IP Telephony Components This topic describes the Cisco IP telephony solution components.


Cisco IP Telephony Components

Endpoints

Cisco CallManager

Application Software

Infrastructure

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, media-processing 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.



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.



Cisco CallManager Functions This topic describes the primary Cisco CallManager functions within the Cisco IP telephony solution.

© 2004 Cisco Systems, Inc. All rights reserved. Course acronym vx.x—#-6

Cisco CallManager Functions

• Call processing• Signaling and device control• Dial plan administration• Phone feature administration• Directory services• Programming interface to external

applications

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




Cisco CallManager Functions (Cont.)Cisco CallManager

IP Phone Party A

Skinny Protocol Signaling

Real-Time Transport Protocol (RTP) Media Path

Skinny Protocol Signaling

• Cisco CallManager performs call setup and maintenance tasks using Skinny.

• IP Phones stream audio using RTP.

IP Phone Party B

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.



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


Line Connections

Call Processing Switching

Trunk Connections

Digital Telephones

Legacy PBX Technology

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.




IP Telephony Technology

Line Connections

Call Processing Switching

Trunk Connections

IP Phones

Cisco CallManager

Catalyst Switches

Voice-Enabled Router or Gateway

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.



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

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.



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


Cisco MCS 7835H-3000Cisco MCS 7835I-3000

Performance

Low

Ava

ilabi

lity

Hig

h

Cisco MCS 7825H-3000Cisco MCS 7825I-3000

Cisco MCS 7815I-2000

Cisco MCS 7845H-3000

(dual processor)

Supported Cisco CallManager 4.0 Hardware

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.




Cisco CallManager MCS Hardware Matrix

1000 / 4000

No

No

No

80-GB SATA

1 GB

Pentium 4 3060-MHz

7825I

1000 / 4000300 / NAMax. Phones per Server / Cluster

NoNoRedundant Power

NoNoRedundant Fans

NoNoHot Plug HD

40-GB ATA40-GB ATAHard Disk

1 GB512 MBMemory

Pentium 4 3060-MHz

Pentium 4 2000-MHzProcessor

7825H7815IModel

This figure shows key hardware features for primary MCS servers that support Cisco CallManager 4.0.


7500 / 30,000 CallManagerversion 3.3 or greater

2500 / 10,0002500 / 10,000Max. Phones per Server / Cluster

YesYesYesRedundant PowerYesNoNoRedundant Fans

YesYesYesHot Plug HD4 72-GB SCSI2 36-GB SCSI2 36-GB SCSIHard Disk4 GB1 GB1 GBMemory

Dual Prestonia Xeon 3060-MHz

Prestonia Xeon 3060-MHz

Prestonia Xeon 3060-MHzProcessor

7845H7835I7835HModel

Cisco CallManager MCS Hardware Matrix (Cont.)

This figure shows key hardware features for additional primary MCS servers that support Cisco CallManager 4.0.



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


Device Weights Table

BHCA = busy hour call attempts

N/A3393

N/A6

18966

WeightBHCA < 18

842CTI Server Port

WeightBHCA < 24

WeightBHCA < 12

WeightBHCA < 6

1263CTI 3rd Party842CTI Client Port

N/AN/A3Conference

421SCCP Client333MGCP

1263H.323 Client333H.323 Gateway

N/AN/A3Transcoder MTP842CTI Route Point

24126CTI Agent

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.




Cisco CallManager Server Platforms:Device Weights

300600MCS 7815I-2000

10002000IBM xSeries 330

10002000Compaq DL 320

10002000SPE 310

10002000MCS 7825

25005000IBM xSeries 342

25005000Compaq DL 380

25005000MCS 7835 All Models

750010,000MCS 7845 All Models

Maximum IP Phones per Server

Device Weight Units per Server

Platform

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.



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.



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



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) 1000 B) 1500 C) 2000 D) 2500

Q2) Which two of these items represent an advantage that IP telephony has over PBX technology? (Choose two.) A) distributed design B) standards-based C) fewer devices D) all components in a single device

Q3) Which two of these are NOT functions of Cisco CallManager? (Choose two.) A) interactive voice response B) signaling control C) device control D) dial plan E) voice messaging

Q4) Voice software, infrastructure, end points, and Cisco CallManager make up which of the following? A) Cisco AVVID layers B) Cisco IP telephony solution components C) Cisco IP Communications components D) client layer of Cisco AVVID E) CallManager functions

Q5) A hot-swappable hard drive is a high-availability feature starting with which MCS series? A) Cisco MCS 7815 B) Cisco MCS 7825 C) Cisco MCS 7835 D) Cisco MCS 7845

Q6) Cisco CallManager uses which of these operating systems? A) Linux B) Windows 95 C) Windows NT D) Windows 2000



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) CallManager Express B) Contact Center C) Unified Communications D) IP conferencing E) IP telephony

Q8) Which layer of Cisco AVVID contains Cisco CallManager? A) client B) applications C) call-processing D) infrastructure



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


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 call-processing 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 call-processing deployment model

Identify the major characteristics and design guidelines of a multisite distributed call-processing deployment model

Identify the key advantages of a distributed single-cluster deployment compared to an SRST deployment


Windows 2000 navigation experience

General knowledge of Cisco CallManager



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



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

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.



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.



Intracluster Communication This topic examines the two types of intracluster communication.


Intracluster Communication

Intracluster Run-Time Data

Microsoft SQLDatabase

Publisher

Subscriber

Subscriber

Subscriber

Cluster Determination Device Registration and Redundancy

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).



Cluster Redundancy Designs This topic examines two cluster designs that provide call-processing redundancy.


1:1 Redundancy Design

• High availability (upgrade)• Increased server count• Simplified configuration

Primary

Secondary/Backup

Publisher and TFTP Server (Not Req. <1000)

Publisher and TFTP Server


2500 IP Phones(5000 Device Units)

5000 IP Phones(10,000 Device Units)

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

Primary 1 to 2500

BackupBackups Backups

Backups

1 to2500

1 to2500

5001 to7500

2501 to5000

2501 to5000

7501 to10,000

Cisco MCS 7835 Cisco MCS 7835 Cisco MCS 7835

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.




2:1 Redundancy Design

• Cost-efficient redundancy• Service impacted during upgrade

Primary

Secondary/Backup

Publisher and TFTP Server (Not Req. <1000)



2500 IP Phones(5000 Device Units)

5000 IP Phones(10,000 Device Units)

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

Primary 1 to 2500

BackupBackup Backup

Backup

1 to2500

1 to2500

5001 to7500

2501 to5000

2501 to5000

7501 to10,000

Cisco MCS 7835 Cisco MCS 7835 Cisco MCS 7835

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.



IP Telephony Deployment Models This topic lists the deployment models that Cisco IP telephony supports.


Deployment Models

Branch A

Branch B

Headquarters

Applications

GatekeeperGK

Applications

Cisco CallManagerCluster

Applications• Single-site deployment• Multisite WAN with centralized call processing• Multisite WAN with distributed call processing• Single-cluster with distributed call processing

Cisco CallManager

Cluster

Cisco CallManagerCluster

IP WAN

PSTN

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



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

Cisco CallManager

Cluster

PSTN

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.




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.



Multisite WAN with Centralized Call Processing This topic examines the multisite WAN with centralized call-processing deployment model.


Multisite Centralized Call Processing: Overview

• 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

Applications

Headquarters

Branch A

Branch B

Cisco CallManager

Cluster

SRST-EnabledRouter

IP WAN

PSTN

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.



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.




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.

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.



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


Multisite Distributed Call Processing: Overview

Headquarters

Branch A

• 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

Gatekeeper

Applications

Cisco CallManager

Cluster

GK

Applications

Cisco CallManager

Cluster

Branch B

Applications

Cisco CallManager

Cluster

IP WAN

PSTN

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



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




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.

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.



Single-Cluster Distributed Call Processing This topic examines single-cluster distributed call-processing design.


Single-Cluster Distributed Call Processing: Overview

Voice-Mail Server

Voice-Mail Server

IP PhonesIP Phones

Los Angeles San Diego

Cisco CallManager

Cluster

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.




Single-Cluster Distributed Call Processing: Design Guidelines

Publisher/TFTP

• 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)

QoS-Enabled Bandwidth

<40 ms Round-Trip Delay

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.





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.




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_design_guidances_list.html




Q1) Which of the following is NOT an IP telephony deployment model that is supported by Cisco? A) a single site with one call-processing agent B) multiple sites with centralized call processing C) multiple sites each with its own call-processing agent D) a single cluster with distributed call processing E) multiple clusters with no call-processing agent

Q2) Which three of the following enable the cluster to achieve redundancy? (Choose three.) A) local failover B) database replication C) at least two servers D) directory access

Q3) 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) completely self-contained individual sites B) WAN bandwidth cost savings C) a common dial plan across all sites D) more IP Phone features during failover E) scalability to hundreds of sites

Q4) A 1:1 redundancy design offers _________; however, ________. A) increased redundancy; the increased server cost is often prohibitive B) some redundancy; a server reboot is required after an upgrade C) maximum uptime; no more than a 20-ms round-trip delay can exist between

servers D) high availability; you may overwhelm the backup servers

Q5) Which protocol does an IP Phone use to send periodic messages to determine if its primary Cisco CallManager server is still operational? A) RTP B) Skinny C) TCP D) SQL E) H.323

Q6) What is the recommended best practice regarding WAN codecs in a distributed call- processing deployment? A) G.711 only B) G.729 and G.723 C) a single codec for the WAN D) multiple codecs between the sites



Q7) Which codec is most often used in a single-site deployment? A) G.729 B) G.723 C) GSM D) 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) 280 B) 480 C) 580 D) 680



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




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


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

• Overview• Installation CD-ROMs• Installation Configuration Data• Activating Cisco CallManager Services• Postinstallation Procedures• Upgrading Prior Cisco CallManager Versions• Summary• Quiz



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

Cisco CallManager is installed on the Cisco Media Convergence Server (MCS), a high-availability 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



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

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 (_).



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.



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.



Configuration Data for Cisco MCS

Configuration Data

Cisco product key

Username

Name of your organization

Computer name

Workgroup

Microsoft NT domain (optional)

DNS domain suffix

Current time zone, date, and time

DHCP parameters Cisco recommends that you program a fixed IP address in TCP/IP properties for the server instead of using DHCP.

TCP/IP properties (required if DHCP is not used):

• IP address

• Subnet mask

• Default gateway

DNS servers (optional):

• Primary

• Secondary

WINS servers (optional):

• Primary

• Secondary

LMHOSTS file (optional)

Database server (choose one):

• Publisher

• Subscriber

If you are configuring a subscriber server, supply the username and password of the publishing database server:

– Publisher username

– Publisher password

Backup (choose one or both):

• Server

• Target

New Windows 2000 administrator password



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

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.



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.




Cisco CallManager Service Activation

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.

Step 2 From the Application menu, choose Cisco CallManager Serviceability. The CallManager Serviceability interface appears.

Step 3 From the Tools menu, choose Service Activation. A window similar to the window shown here appears.

Step 4 Click the server that you would like to configure from the Servers column. Next, click the services that you would like to activate, and click the Update button. (You will experience a slight delay.) The Service Activation window will refresh when the process is complete.

Caution You should activate the Cisco CallManager services from the Service Activation window. If you manually start the services through the Windows 2000 Services administrative tool, unpredictable results may occur.



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.



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.




Multilevel Administration OverviewFull Access

Read-Only Access

No Access

• Functional groups • User groups • Three access levels • Login authentication to

LDAP• CCMAdministrator

superuser

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.



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.




Multilevel Administration Configuration

Configure MLA Parameters

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

Step 2 Choose User > Access Rights > Configure MLA Parameters. The MLA Enterprise Parameter Configuration page displays.

Step 3 Change the Enable MultiLevelAdmin drop-down list box to True.

Step 4 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 Set up functional groups or use standard functional groups.

Step 2 Set up user groups or use standard user groups.

Step 3 Add users to user groups.

Step 4 Assign privileges to user groups for functional groups.



Upgrading Prior Cisco CallManager Versions This topic describes the upgrade process for a Cisco CallManager server.


Upgrading to Cisco CallManager 4.0

4.0(1)3.2(c)3.2(3)3.3(2)3.3(3)

2.43.1

4.0(1)

3.2 or 3.3

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.




• Publisher database server upgrade requires system software reimage.

• System backup is required to preserve critical data.

• Ensure all MCS server hardware is in original configuration.

• Remove server from domain before the upgrade occurs.

Cisco CallManager 3.3Publisher

Cisco CallManager 4.0Publisher

Upgrading the Cisco CallManager Publisher Server

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/cgi-bin/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.



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.

Step 2 Manually disable and stop all platform agents and applications that are Cisco-verified (such as Cisco AVVID partner applications) that run on the servers in the cluster. Disabling platform agents and services—for example, performance monitoring (such as NetIQ), antivirus services (such as McAfee services, which are approved by Cisco), intrusion detection, and remote management services—ensures 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/pcgi-bin/ecoa/Search.

Step 3 Manually install and configure BARS version 4.0(1) (or later).

Step 4 Using BARS version 4.0(1) (or later), manually back up the Cisco CallManager data to either a network directory or tape drive.

Step 5 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.

Step 6 If the server supports drive removal, remove a drive from the server to save your data and configuration.

Step 7 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).

Step 8 Download and install the latest Cisco IP Telephony Server Operating System service release (2000-2-5sr2 or later) (required).

Step 9 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

Step 10 Verify that you have installed Microsoft SQL Server 2000, Service Pack 3a (or later).

Step 11 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.

Step 12 Upgrade the subscriber servers.

Caution 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.



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.




• 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 CallManagerinstallation.

Cisco CallManager 3.3Subscriber

Cisco CallManager 4.0Subscriber

Upgrading the Cisco CallManagerSubscriber Server

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.





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.


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_guides_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.




Q1) Which three of these services does Cisco recommend that you stop on a subscriber server? (Choose three.) A) FTP Publishing Service B) Cisco CallManager Service C) IIS Admin Service D) World Wide Web Publishing Service

Q2) What does the Cisco Messaging Service allow the Cisco CallManager to do? A) register IP Phones and process calls B) interface with a voice-mail system C) generate daily and on-demand reports D) act as a Media Termination Point E) write trace information to a database

Q3) If you are not using DNS, what must you configure to resolve server names? A) DHCP B) backup server C) LMHOSTS file D) DNS reverse lookup

Q4) 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) Cisco CallManager 4.0 Software Disk B) Cisco IP Telephony Server Operating System Hardware Detection Disk C) Cisco IP Telephony Server Operating System Installation and Recovery Disk 1 D) Cisco IP Telephony Server Backup and Restore Disk E) Cisco Extended Services Disk

Q5) What is the recommended order of these steps to upgrade the Cisco CallManager publisher server to 4.0? A) back up the CallManager server data B) remove the server from the NT domain C) upgrade the operating system to the latest version D) install Cisco CallManager software E) disable all platform agents and services on the server



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




Module 2

Establishing an On-Cluster Call

Overview Numerous components and considerations are involved before you can place Cisco IP Phone calls within the same cluster. This module discusses 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

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


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




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

• 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


Copyright © 2004, Cisco Systems, Inc. Establishing an On-Cluster Call 2-5

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

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.



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 7905GCisco IP Phone 7902G 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

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-PWR-CUBE [same power supply as the Cisco 7910, 7940, or 7960])

Visual message waiting indicator (MWI)

No speakerphone or headset port



Here is a brief description of the major features of each entry-level Cisco IP Phone:

Cisco IP Phone 7902G: The Cisco IP Phone 7902G is a single-line, entry–level, no-display business phone with fixed feature keys that provide one-touch access to the redial, transfer, conference, and voice-mail access features. Here is a brief description of the major features of the Cisco IP Phone 7902G:

— Ability to handle low telephone traffic

— Fixed features: redial, transfer, conference, messages

— Hard “Hold” key

— Single RJ-45 connection (no 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



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



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

Cisco IP Phone 7970:

— 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 power-compatible)

— Advanced XML development platform for more dynamic applications



Additional Cisco VoIP Devices This topic describes the features and benefits of additional Cisco VoIP devices.


Additional Cisco VoIP Devices

Cisco 7914 Expansion Module

Cisco IP SoftPhone andCisco IP Communicator

Cisco ATA 186 and 188

Cisco Conference Station 7936 Cisco VT Advantage

Cisco Wireless IP Phone 7920

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 full-featured, 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 6-foot (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.



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.



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

CCM YEILDCisco TFTPDHCP

1. Cisco prestandard PoE switch sends FLP2. Phone loads stored image3. Switch provides VLAN information to IP

Phone4. Phone sends DHCP request; receives IP

information and TFTP server address5. IP Phone gets configuration from TFTP

server6. IP Phone registers with Cisco CallManager

server

4

6

51 3

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.



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.



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

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.



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.





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.


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.323-compatible stream and compress the output to save bandwidth. Cisco IP Phones support the G.711 and G.729a codecs.




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




Q1) Which two features do the majority of Cisco IP Phones support? (Choose two.) A) G.711 and G.729 B) 802.3af C) a display D) multiple lines E) multiprotocol capability

Q2) Place these steps in the order that an IP Phone must go through before it can register with Cisco CallManager. A) obtain -48 V DC power B) get configuration from TFTP server C) load firmware image D) 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) Cisco Conference Station 7936 B) Cisco IP SoftPhone C) Cisco ATA 188 D) Cisco 7905G E) 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) Cisco IP Phone 7902G B) Cisco IP Phone 7905G C) Cisco IP Phone 7910G+SW D) Cisco IP Phone 7940 E) 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) Cisco IP Phone 7902G B) Cisco IP Phone 7905G C) Cisco IP Phone 7910G+SW D) Cisco IP Phone 7912G



Q6) Which of the following H.323 codecs do most Cisco end-user devices support? A) G.711 B) G.723 C) G.711 and G.723 D) G.711 and G.729a



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


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




An understanding of the Cisco IP Phone registration process

An understanding of the relationship between Cisco CallManager clusters and device registration



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



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.



Configuring Device Pools This topic describes device pool configuration.


Device Pool Configuration

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 Choose System > Device Pool.

Step 2 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.



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 Description

Device Pool Name* Describes a name for the device pool

Cisco CallManager Group* Selects a redundancy group for the device pool—this redundancy group can contain a maximum of three redundant Cisco CallManager servers

Date/Time Group* Assigns the correct time zone to the device

Region* Determines the codec selection when it is used by the device

SRST Reference Configures survivable remote site telephony (SRST) and selects the gateway that will support a device if the connection to the Cisco CallManager is lost

Media Resource Group List Assigns media resource support to a device for functions such as conferencing, transcoding, or MOH

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

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

User Locale Defines the language that the device uses

Network Locale Defines the tones and cadences that the device uses

Calling Search Space for Auto-registration

Defines whom an IP Phone is able to call if it auto-registers with the Cisco CallManager

Softkey Template* Defines the type and order of the softkeys that are displayed on the LCD of a Cisco IP Phone

MLPP Precedence and Preemption Information

Used to manage Multilevel Precedence and Preemption (MLPP) settings:

■ MLPP Indication: Specifies whether devices in the device pool that are capable of playing precedence tones will use the capability when the devices plan an MLPP precedence call

■ MLPP Preemption: Specifies whether devices in the device pool that are capable of pre-empting calls in progress will use the capability when the devices plan an MLPP precedence call

■ MLPP Domain: A hexadecimal value for the MLPP domain that is associated with the device pool

* Indicates a required field



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 If desired, update the devices to assign them to a different device pool.

Step 2 Delete the devices that are assigned to the device pool that you want to delete.




Cisco CallManager Group Configuration

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.



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.

Step 2 Choose Add New Cisco CallManager Group to create a new Cisco CallManager group.

Step 3 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.




Date/Time Group Configuration

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 Choose System > Date/Time Group; the default CMLocal group appears.

Step 2 Choose Add a New Date/Time Group to insert additional date/time groups as required.

Note For a worldwide distribution of Cisco IP Phones, you may want to create one named date/time group for each of the 24 time zones.




Region Configuration

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.

Step 2 Choose Add a New Region to configure the regions, and choose the codec and video bandwidth as appropriate between the regions.




Softkey Template Configuration

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.



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


5 lines, 1 speed dial





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.



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

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.



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.

Step 2 Choose Add a New Phone in the upper right corner of the window.

Step 3 Choose the model of the IP Phone from the drop-down list, and click Next.

Step 4 At a minimum, you must configure the MAC Address and Device Pool fields; then click Insert.

Step 5 Cisco CallManager prompts you to add a DN for line 1; then click OK.

Step 6 When the Directory Number Configuration window appears, type the DN of the IP Phone in the appropriate field, and click Insert.



Configuring IP Phone Auto-Registration This topic describes how to configure Cisco CallManager for auto-registering Cisco IP Phones.


Auto-Registration Configuration

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 auto-registration.

Perform these steps to configure the Cisco CallManager server to support auto-registration:

Step 1 From Cisco CallManager Administration, choose System > Cisco CallManager.

Step 2 From the list of Cisco CallManager servers, select the server that you want to support auto-registration.

Step 3 Under the Auto-registration Information Configuration section, type the appropriate DN range in the Starting and Ending Directory Number fields.

Step 4 Ensure that the Auto-registration Disabled on this Cisco CallManager check box is unchecked.




Device Defaults

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.

Step 2 Scroll to the Cisco IP Phone device or devices that will auto-register, and choose the device pool from the drop-down list.

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.

Step 2 Click Update to save the changes in the Cisco CallManager configuration database.

Step 3 Click the Reset icon to the left of the device name to reset all the devices of that type and load the new defaults on all Cisco 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.





Summary

• Assigning an IP address to Cisco CallManagereliminates 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.


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




Q1) Which five settings are required to configure a device pool? (Choose five.) A) media resource group list B) Cisco CallManager group C) date/time group D) region E) softkey template F) device pool name

Q2) How does Cisco CallManager tie configuration information to the IP Phones in the Microsoft SQL database? A) IP address B) unique GUID C) hostname D) MAC address E) device pool ID

Q3) Which of the following is a valid IP Phone button template configuration for a Cisco IP Phone 7960? A) 0 lines, 6 speed dials B) 2 lines, 4 speed dials C) 6 lines, 1 speed dial D) 4 lines, 4 speed dials

Q4) Which navigation path would you use to configure Cisco CallManager to automatically register an IP Phone? A) System > Server B) System > Cisco CallManager C) Service > Service Parameters D) Device > Phone E) 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) System > Server B) System > Cisco CallManager C) Service > Service Parameters D) Device > Phone E) System > Device Pool



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


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




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



Catalyst Switch Role in IP Telephony This topic describes the role of Cisco Catalyst switches in the IP telephony infrastructure.


• Supplies inline power to IP Phones

• Supports voice and data VLANs on a single port

• Prioritizes voice traffic with class of service (CoS) marking

Catalyst Switch Role in IP Telephony

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).



Powering the Cisco IP Phone This topic describes the three options for powering Cisco 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

Three Ways to Power IP Phones

110 V AC Wall Power to 48 V DC Converter

AC Source

No PowerPower Injector

Power

Power

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.



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



— 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.




Cisco Prestandard Device Detection

Switch

Cisco prestandardimplementationPD port

RX

TX

FLPFLP

It is an inline device

Pin3

Pin6

Pin1

Pin2

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.




IEEE 802.3af Device Detection

Switch

IEEE 802.3af PD

RX

TX

Detect Voltage 25K-Ohm Resistor

It is an IEEE PD

Pin3

Pin6

Pin1

Pin2

-2.8 V to -10 V

IEEE 802.3af PSE

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.



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


Catalyst Family of PoE Switches

Catalyst 3560

Catalyst 3750

Catalyst 6500 Catalyst 4500

EtherSwitch Network Module*

*Cisco prestandard PoE only

Catalyst 3550*

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 10BASE-T/100BASE-T line card and 48-port 10BASE-T/100BASE-T and 10BASE-T/100BASE-T/1000BASE-T line cards. The Catalyst 6500 Series offers a modular PoE daughter card architecture for the 96-port card and the 48-port 10/100/1000 card. The Cisco Catalyst 4500 Series delivers 48-port 10/100 and 10/100/1000 line cards. All line cards support both IEEE 802.3af and Cisco prestandard inline power. The cards are compatible with any 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.



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

PoE Configuration Options

48-, 96-port 10/100 or 48-port 10/100/1000

48-port 10/100 or 10/100/1000

24-, 48-port 10/100

24-, 48 -port 10/100

24-, 48-port 10/100

16-, 36-port 10/100

IEEE 802.3af-Compliant

Yes Yes Yes Yes No No

Cisco Prestandard PoE

Yes Yes Yes Yes Yes Yes

Note Cisco does not offer an IEEE 802.3af midspan injection product. The 48-port Cisco Catalyst Inline Power Patch Panel supports Cisco prestandard PoE.

Note The switches that are listed on this page also support multiple VLANs per port and CoS.



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


Catalyst Switch:Configuring Inline Power

CatOS>(enable) set port inlinepower <mod/port> ?auto Port inline power auto modeoff/never Port inline power off mode

Cisco CatOS:

Native Cisco IOS:

CSCOIOS(config-if)# power inline <auto/never>

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).




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 ) Device---------- ----- ---- --------------- ------FastEthernet9/1 auto on 6300 Cisco 6500 IP PhoneFastEthernet9/2 auto on 6300 Cisco 6500 IP PhoneFastEthernet9/3 auto off 0 n/a

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 Description

Port Identifies the port number on the module

Inline Powered

Admin Identifies the port configuration from using the set inlinepower <mod/port> [auto|off]

Oper Identifies if the inline power is operational

Power Allocated

Detected Identifies if power is detected

mWatt Identifies the mWatt supplied on a given port

mA @42V Identifies the mA @ 42 V supplied on a given port



Configuring Dual VLANs This topic describes the configuration of a multi-VLAN access port.


A Multi-VLAN Access Port

Tagged 802.1Q

Untagged 802.3

• An access port able to handle two VLANs• Native VLAN (PVID) and auxiliary VLAN (VVID)• Hardware set to dot1q trunk

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.



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.




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

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.




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

Use the commands in the figure shown here to configure voice and data VLANs on the single-port interface of a switch that is running native Cisco IOS software. These commands apply the same functionality as setting a port to use an auxiliary VLAN on a Catalyst switch that is running Catalyst software.

Catalyst Switch Voice Interface Commands

Command Description

switchport trunk encapsulation dot1q

Configures the trunk encapsulation protocol as 802.1Q.

switchport trunk native vlan 12

Specifies VLAN 12 as the native (data) VLAN over the trunk.

switchport mode trunk Configures the interface as a Layer 2 trunk.

switchport voice vlan 112

Specifies VLAN 112 as the voice VLAN over the trunk.

spanning-tree portfast Causes a port to enter the spanning-tree forwarding state immediately, bypassing the listening and learning states. You can use PortFast on switch ports that are connected to a single workstation or server (as opposed to another switch or network device) to allow those devices to connect to the network immediately.




Verifying Voice VLAN Configuration Using Cisco CatOS

Console> (enable)show port 2/1...Port AuxiliaryVlan AuxVlan-Status----- ------------- --------------2/1 222 active

...

Console> (enable)show port auxiliaryvlan 222AuxiliaryVlan AuxVlanStatus Mod/Ports------------- ------------- ----------222 active 1/2,2/1-3Console> (enable)

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.




Verifying Voice VLAN Configuration Using Native Cisco IOS

Switch# show interface fa0/17 switchport

Name: Fa0/17Switchport: EnabledAdministrative mode: trunkOperational Mode: trunkAdministrative Trunking Encapsulation: dot1qOperational Trunking Encapsulation: dot1q

Negotiation of Trunking: DisabledAccess Mode VLAN: 0 ((Inactive))Trunking Native Mode VLAN: 12 (VLAN0012)Trunking VLANs Enabled: ALLTrunking VLANs Active: 1-3,5,10,12Pruning VLANs Enabled: 2-1001

Priority for untagged frames: 0Override vlan tag priority: FALSEVoice VLAN: 112Appliance 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.



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 = 200CoS = 5

PC VLAN = 3CoS = 7

Desktop PC: IP Subnet A

IP Phone: IP Subnet B

CoS = 7CoS = 0

CoS = 7CoS = 2

CoS = 7CoS = 7PC is trusted

PC is not trustedCoS set to 2

PC is not trustedCoS set to 0 (normal)

VAccess port

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.




Configuring CoS

set port qos <mod/port> cos-ext <cos-value>

Switch(config)#interface FastEthernet0/1 Switch(config-if)#switchport priority extend

<cos/none/trust>

Native Cisco IOS

Cisco CatOS

set port qos <mod/port> trust-ext<untrusted/trust-cos>

• Allows you to statically configure the CoS assigned to the attached device

• Allows you to trust or not trust (set to 0) the CoS assigned to the attached device

• Choose to modify, ignore, or trust the CoS of the attached device

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.





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 powercommand (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.




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




Q1) What are three options for powering IP Phones? (Choose three.) A) -48 V DC over Ethernet data or spare pairs B) 110 V AC to -48 V DC converter C) internal DC battery D) power patch panel

Q2) Cisco Catalyst switches can provide which three functions in an IP telephony deployment? (Choose three.) A) convert SCCP signaling packets from the IP Phone to MGCP B) power IP Phones through the same Ethernet cable that carries data C) enable the classification and prioritization of voice packets at Layer 2 D) instruct the IP Phone to change the CoS of an incoming data frame E) 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) ______ send -48 V DC power over pins 1, 2, 3, and 6 B) ______ supply up to 15.4 watts per port C) ______ supply up to 6.3 to 7.7 watts per port D) ______ use FLPs to determine if the endpoint is inline-power-capable E) ______ use resistance to determine if the endpoint is inline-power-capable F) ______ 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) power inline in global configuration mode B) power inline auto in interface configuration mode C) set port inline power default D) set port inline power 3/2 802.3 E) 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) change the CoS value on the native VLAN to a number lower than 5 B) use the switchport priority extend untrust interface command C) nothing, the IP phone will automatically change the CoS to 0 for the attached

devices D) create a dual VLAN on the access port and place the data packets in the native

VLAN



Q6) Which two products support both Cisco prestandard PoE and IEEE 802.3af PoE? (Choose two.) A) Catalyst 3524-PWR-XL B) Catalyst 3750 C) Catalyst 3550-24 PWR D) Ethernet switch module for the Cisco 2600 and 3600 routers E) Catalyst Inline Power Patch Panel F) 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) configure the interface as a trunk B) tag the voice packets with an identifier C) extend the CoS boundary to the IP Phone D) ensure that the IP Phone has an internal switch E) ensure that the IP Phone is inline-power-capable



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




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


Navigation in Cisco CallManager Administration



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



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

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.




Adding a User

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.




Device Association

Multiple devices and

only one primary

extension

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 In the Application Profiles pane, click Device Association.

Step 2 Limit the list of available devices by entering the search criteria in the Available Device List Filters section, if desired, and click Select Devices.

Step 3 Check the check box of one or more devices that you want to associate with the user. You can assign one primary extension from the devices to which the user is assigned by clicking the radio button in the Primary Ext. column for that device.

Step 4 When you have completed the assignment, click Update Selected to assign the devices to the user.



User 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.




Cisco CallManager User Options:Welcome < user name >

Select a device

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.



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

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.



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

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.”



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

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.



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.

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.



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

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.



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

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.




Cisco CallManager User Options:Locale for Web Pages

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.





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.


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.




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/index.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




Q1) What are the three options that users have for setting the message waiting lamp policy? (Choose three.) A) always light when a voice message is left B) light if the call is outside the corporate network C) never light when a voice mail is received D) follow the system policy

Q2) Which two of these fields must the user complete in order to log onto the Cisco CallManager User Options page? (Choose two.) A) User ID B) Password C) PIN D) Full Name

Q3) In order to allow a user to use the Cisco IP SoftPhone, which option must you enable? A) Enable SoftPhone Use B) Enable XML Application Use C) Enable SoftPhone Access D) Enable CTI Application Use

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) go to http://<server_name>/Services.asp B) press the Services button on their IP Phone C) subscribe to the service in the User Options pages D) enable CTI Application Use

Q5) Which three options is a user able to configure from the User Options page? (Choose three.) A) call forwarding B) message waiting lamp policy C) IP Phone services D) 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) 2 B) 4 C) 6 D) 10



Q7) How do users of a Cisco IP Phone 7960 access their personal address book and fast dials? A) access the user partition of the LDAP directory B) navigate to Menu > My Address Book in the User Options pages C) press the Services button from their IP Phone D) 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) The administrator must order the correct Cisco CallManager part number for

the desired language. B) The administrator must download the desired language from Cisco.com. C) The user must select the desired language in the User Options Page. D) The user must go to User Options > Change Locale from the Serviceability

page.



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


Using the Bulk Administration Tool

Overview The lesson covers Bulk Administration Tool (BAT) Release 5.0(1) and the Tool for Auto-Registered Phones Support (TAPS). BAT is a web-based application for Cisco CallManager that allows you to add, update, or delete a large number of similar telephones, users, or ports at the same time. TAPS works in conjunction with BAT to update MAC addresses and download a predefined configuration for new phones.

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 auto-register 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


Configuration of a single Cisco IP Phone device

Cisco CallManager Administration basics



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



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

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.




BAT Components

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)

Template CSV File

+=

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.




BAT Features

• Bulk Administration Tool wizard • Flexible data input file format• Master phone templates• Validation feature• Reporting utility• Custom file support

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.



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.)




Installing BAT

These steps describe the BAT installation process:

Step 1 Using the administrator privileges, log onto the system running the publisher database for Cisco CallManager.

Note You must install BAT directly on the publisher server; do not use Window Terminal Services.

Step 2 Choose Application > Install Plugins.

Step 3 The Install Plugins window is displayed, as shown here.

Step 4 Locate Cisco Bulk Administration Tool, and double-click the Setup icon.

Step 5 A standard Windows dialog box appears.

Step 6 Determine whether to copy the BAT install executable to the system or run it from the current location.

Step 7 Choose Next when the InstallShield Welcome window appears. The InstallShield window begins installing BAT.

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.



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.

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.

Step 3 Validate the data input files with the Cisco CallManager database. Cisco CallManager runs a validation routine that checks the CSV file and the template for errors against the publisher database.

Step 4 Insert the devices into the Cisco CallManager database.




Using BAT Wizard: Step 1 of 3

Choose device or option to configure.

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)




Using the BAT Wizard: Step 2 of 3

Choose the task you want to perform.

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




Using the BAT Wizard: Step 3 of 3

Wizard guides you through steps specific to the task.

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:

Step 1 Add, view, or modify existing phone templates

Step 2 Create the CSV data file

Step 3 Validate phone records

Step 4 Insert phones

When you choose a step from the task list, you open a configuration window such as the Phone Template Configuration window. The configuration window provides the entry fields for defining a template.



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

Phone button template becomes available.

and

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.





After adding the template in the BAT utility, you can then configure necessary line settings.

Scroll down and select a line.

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.





Configure line settings for template.

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.



Creating CSV Files This topic describes how to create a CSV file to use with BAT.


Creating CSV Files

BAT spreadsheet

Text editoror

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.




Creating CVS File Using BAT Spreadsheet: Phones

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.)




Creating CSV File Using Text Editor

Using a text editor is the second way to create a CSV file. When using a text editor, follow these steps:

Step 1 Create a customized file format in the BAT File Format Configuration window.

Step 2 Use a text editor to create the CSV data file for phones that follow the file format that you want to use.

Step 3 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.

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

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.



Inserting IP Phones into Cisco CallManager This topic describes how to insert Cisco IP Phones into the Cisco CallManager database.


Inserting Phones

Inserting the device into the Cisco CallManager database is the last step in using BAT to perform bulk configurations. The following steps are involved in this procedure:

Step 1 In the File Name field, choose the CSV data file that you created for this specific bulk transaction.

Step 2 To enable the use of applications such as Cisco IP SoftPhone, check the Enable CTI Application Use check box (for CTI ports only).

Step 3 Choose the Insert option that corresponds to your CSV data file.

Step 4 In the Phone Template Name field, choose the BAT phone template that you created for this type of bulk transaction.

Step 5 If you did not enter individual MAC addresses in the CSV data file, check the Create Dummy MAC Address check box. This field automatically generates dummy MAC addresses in the following format: XXXXXXXXXXXX where the X’s 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 6 Click Insert to insert phone records.



Updating IP Phones with BAT This topic describes how to use BAT to update Cisco IP Phones and lines.


Updating IP Phones: Step 1

Choose field to query and enter search string.

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.




Updating IP Phones: Step 2

Reset or restart devices after changes are made.

Specify parameter to update.

View query results.

After you have defined the query or custom file to search for phones, follow this procedure to update the IP Phones or users to the Cisco CallManager database in bulk:

Step 1 Specify the values to be updated within Cisco CallManager.

Step 2 Click Update.

Step 3 Reset or restart the IP Phones through Cisco CallManager, or plug them in and apply power.

To check the status of your insertion, read the status line, located above the Insert button.

If the status bar indicates a failure, click View Latest Log File to display a window that will help you to determine where the operation failed.



Using the Tool for Auto-Registered Phones Support

This topic describes how to install and configure TAPS.


Introduction to TAPS

1. BAT adds dummy MAC address into Cisco CallManager Administration

2. Administrator plugs phones into network3. User or administrator dials a TAPS directory

number4. CallManager downloads configuration5. Phone updates CallManager with correct MAC

address

Phone Configuration 4

1

Call TAPS DN

5

Dummy MAC Address

Actual MAC Address

3

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.




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

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).

Step 2 Access the BAT.

Step 3 Choose Applications > Install Plugins.

Step 4 Find TAPS and double-click the setup icon.

Step 5 Determine whether to copy the TAPS install executable to the system or run it from the current location.

Step 6 The Welcome window for the installation wizard opens. This installation program installs TAPS on the Cisco CallManager publisher server and the CRS applications server at the same time, if applications are colocated on the same server. Click Next.

Note When you are installing TAPS in a network with a dedicated CRS server, you must run the TAPS installation program again on the CRS server. Use CRS online help for assistance with installation and configuration.

Step 7 Enter the private phrase for the Cisco CallManager publisher server in the Installing Cisco CallManager Components window and click Next. The Installing TAPSonCCM window displays a progress bar that shows the status of the installation.

Step 8 The Installation Completed window is displayed when the installation ends. Click Finish.




TAPS Configuration Requirements

Publisher

Install CTI Route Points

Administrator

Add a computer telephony integration (CTI) route point, CTI ports, and users in Cisco CallManager Administration.

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 To use TAPS, verify that auto-registration is enabled in Cisco CallManager.

Step 1 Create a CTI route point and assign it a unique DN.

Step 2 Choose the Call Forward Busy, Call Forward No Answer, and Call Forward on Failure options for the operator number on the TAPS CTI route point.

Step 3 Create one or more CTI ports with consecutive DNs. You can create CTI ports in BAT or Cisco CallManager Administration.

Step 4 Create a user. The TAPS route point and ports should be in the users control devices list.

Step 5 Create an auto-registration partition or calling search space or both to prevent IP Phones that have auto-registered from dialing any DN other than the number that is assigned to the TAPS CTI route point. Restricting access to this DN ensures that users download the proper configuration information for their IP Phones.

Note TAPS supports a maximum number of sessions equal to the number of CTI ports that are configured for TAPS.





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.



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




Q1) Which of these tools allows you to complete bulk adds, updates, and deletions? A) TAPS B) BAT C) CRA D) CDR

Q2) On which server must you install BAT? A) publisher server B) subscriber server C) primary server D) secondary server

Q3) In which bulk configuration step do you configure BAT to generate dummy MAC addresses? A) validating data input files B) installing BAT C) creating phone template D) 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) device pool B) directory number C) softkey template D) MAC address E) calling search space F) button template

Q5) What are the two ways to create CSV files? (Choose two.) A) choose Configure > CSV File B) use a text editor and save to correct folder C) modify BAT.xlt and export to BAT format D) save IP Phone template in CSV format

Q6) Which two items must be installed for TAPS to function properly? (Choose two.) A) CRS B) BAT C) plug-ins D) Extension Mobility

Q7) The BAT wizard guides you through which four tasks? (Choose four.) A) setting up a template B) creating CSV files C) installing BAT D) inserting phones and devices E) validating records



Q8) What are the first two tasks that are required to update IP Phones? (Choose two.) A) reset or restart IP Phones B) find the phones that you want to update C) specify the values to change D) view the log file E) view the query results

Q9) Which of the following three items are checked during the BAT validation process? (Choose three.) A) number of lines on template and device B) BAT-defined dummy MAC addresses C) valid characters in speed-dial labels D) preconfiguration of device pools if referenced



Quiz Answer Key Q1) B

Relates to: Introducing the Bulk Administration Tool

Q2) A

Relates to: Installing BAT

Q3) D

Relates to: Inserting IP Phones into Cisco CallManager

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


Module 3

Establishing an Off-Cluster Call

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 interclustertrunks 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 InterclusterTrunks

• 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


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




General navigation in Cisco CallManager Administration

Cisco Voice over IP (CVOICE) course or equivalent experience in the configuration of gateways



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


Copyright © 2004, Cisco Systems, Inc. Establishing an Off-Cluster Call 3-5

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

PSTNPSTN

IP WANIP WAN Regional CenterHeadquarters

Voice Voice GW

VoiceVoice GW

• 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.



Analog and Digital Gateways This topic describes analog and digital access gateways.


Analog and Digital Gateways

PSTNFXO

PRI, BRI,

T1 CAS,E1

Analog Trunk

Digital Trunk

FXS

FXS

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.



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.



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.



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.



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.


Device Name – IP Address

H.323 Gateway Configuration

Use these steps to configure an H.323 gateway:

Step 1 Choose Gateway from the Device menu on the Cisco CallManager Administration page.

Step 2 Click the Add a New Gateway hyperlink and choose H.323 Gateway from the Gateway Type menu.

Step 3 Cisco CallManager automatically populates the Device Protocol field with H.225. Click Next. For the device name, enter the IP address of the Cisco router that will be acting as the gateway.

Note The Gateway Configuration page has other configuration settings. Search the Cisco CallManager Help option for gateway configuration to obtain additional information regarding these settings.

Because H.323 is a peer-to-peer protocol, you must configure most of the gateway configuration using Cisco IOS software on the gateway itself. The table lists the Cisco IOS commands that are used to configure an H.323 voice gateway.



Cisco IOS Commands

Command Description

H323_GW(config)# gateway

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.

H323_GW(config)# voice class h323 <tag>

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

H323_GW(config-class)# h225 tcp timeout <seconds>

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)# dial-peer voice <tag> voip

Creates a VoIP dial peer.

H323_GW(config-dial-peer)# voice class h323 <tag>

Assigns the previous created voice class to this dial peer.

H323_GW(config-dial-peer)# destination-pattern <dial-string>

Configures the dial string that this dial peer matches.

H323_GW(config-dial-peer)# session target ipv4:ccm ip address

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.

H323_GW(config-dial-peer)# preference <0 – 10>

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).

H323_GW(config-dial-peer)# dtmf-relay h245-alphanumeric

Configures the gateway to use out-of-band DTMF relay. DTMF relay sends DTMF tones across the signaling channel, instead of as part of the voice stream. DTMF relay is needed when you are using a low-bit-rate coder-decoder (codec) for voice compression, because the potential exists for DTMF signal loss or distortion.



Example: H.323 Gateway Configuration Here is an example of an H.323 gateway that has been configured for Cisco CallManager redundancy.

H.323 Gateway Configuration for Cisco CallManager Redundancy

Command Description

dial-peer voice 101 voip

destination-pattern 1111

session target ipv4:10.1.1.101

IP address of the primary Cisco CallManager.

preference 0 Specifies this dial peer as the connection to the primary Cisco CallManager.

dtmf-relay h245-alphanumeric

dial-peer voice 102 voip

destination-pattern 1111

session target ipv4:10.1.1.102

IP address of the secondary Cisco CallManager.

preference 1 Specifies this dial peer as the connection to the secondary Cisco CallManager.

Note The CVOICE course discusses the detailed configuration of the H.323 gateway.




MGCP Configuration Information

MGCP Domain Name:Host name of gateway

1/0/01/0/11/1/01/1/1

Network Module 2 VICS

Endpoint Identifiers

Use these steps to configure an MGCP gateway:


Step 2 Click the Add a New Gateway hyperlink and select one of the various MGCP-capable devices from the Gateway Type menu.

Step 3 Cisco CallManager automatically populates the Device Protocol field. Click Next.

Step 4 For the Domain Name field, enter the unique 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.

Note 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.

After you configure the general gateway settings, you must then configure the endpoint identifiers by using Cisco IOS software on the MGCP gateway device.



The table shown here lists commands to help configure endpoint identifiers.

Cisco IOS Commands

Command Description

Router(config)# host MGCP_GW

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.

MGCP_GW(config)# mgcp Enables MGCP on the voice gateway.

MGCP_GW(config)# mgcp call-agent <ip address>

Identifies the primary Cisco CallManager for the gateway.

MGCP_GW(config)# ccm-manager mgcp

Indicates to the gateway that the Cisco CallManager is using MGCP.

MGCP_GW(config)# ccm-manager redundant-host <ip address1> <ip address2>

Specifies the secondary and tertiary Cisco CallManagers that are used for Cisco CallManager redundancy.

MGCP_GW(config)# ccm-manager switchback {graceful | immediate | schedule-time hh:mm | uptime-delay minutes}

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

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.

MGCP_GW(config)# mgcp sdp simple

Configures the voice gateway to use the simple desktop messaging protocol.

MGCP_GW(config)# dial-peer voice <tag> pots

Creates a POTS dial peer.

MGCP_GW(config-dial-peer)# application MGCP

Configures the dial peer to use the MGCP application. MGCP is case-sensitive.

MGCP_GW(config-dial-peer)# port 1/1/1

Associates the dial peer with a voice port.



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

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.




MAC Address of Port

Non-IOS MGCP Catalyst 6000, WS-X6608-x1

Use these steps to configure a non-IOS MGCP gateway:


Step 2 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.

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 disable 00-30-b6-3e-8e-c4 172.16.10.121 255.255.255.0

3/2 disable 00-30-b6-3e-8e-c5 172.16.20.122 255.255.255.0

3/3 disable 00-30-b6-3e-8e-c6 172.16.30.123 255.255.255.0

3/4 disable 00-30-b6-3e-8e-c7 172.16.40.124 255.255.255.0

3/5 disable 00-30-b6-3e-8e-c8 172.16.1.125 255.255.255.0

3/6 disable 00-30-b6-3e-8e-c9 172.16.1.126 255.255.255.0

3/7 disable 00-30-b6-3e-8e-ca 172.16.1.127 255.255.255.0

3/8 disable 00-30-b6-3e-8e-cb 172.16.1.128 255.255.255.0



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.



Configuring Intercluster Trunks This topic discusses gatekeeper-controlled and nongatekeeper-controlled intercluster trunks.


Gatekeeper and Intercluster Trunk Overview

PSTNPSTN

IP WANIP WAN

Cisco IOS Gatekeeper

H.225 RAS signaling

Voice path

VV

Intercluster trunk

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.




Gatekeeper and Trunk Configuration

Separate intercluster trunks required to communicate with each remote cluster

GK

Cluster 1

Cluster 4

Cluster 3

Cluster 2

Nongatekeeper-Controlled Trunks

Gatekeeper-Controlled Trunks

Single intercluster trunk sufficient to communicate with all remote clusters

Cluster 1

Cluster 4

Cluster 3

Cluster 2

IP WANIP WAN

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.




Intercluster Trunk Configuration

Device Name – IP Address

Use these steps to configure an intercluster trunk:

Step 1 Choose Trunk from the Device menu on the Cisco CallManager Administration page.

Step 2 Click the Add a New Trunk hyperlink and choose the appropriate intercluster trunk type (gatekeeper-controlled or nongatekeeper-controlled).

Step 3 Cisco CallManager populates the Device Protocol field with the appropriate protocol. Click Next to continue.

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.





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.


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 gatekeeper-controlled or nongatekeeper-controlled.




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




Q1) Which interface does a voice gateway provide? A) X.25 to SS7 B) VoIP to H.323 C) PSTN to VoIP D) PSTN to PBX

Q2) Which type of interface is on a digital voice gateway? A) FXO B) T1 C) E&M D) FXS

Q3) What is an advantage of a gatekeeper-controlled intercluster trunk? A) server redundancy B) call survivability C) trunk configuration simplicity D) DTMF relay support

Q4) The Catalyst 6000 and WS-X6608-x1 support which gateway protocol? A) H.323 B) MGCP C) Skinny D) Non-IOS MGCP

Q5) Which item is a core gateway requirement? A) support for DTMF relay B) support for inline power C) support for multiple VLANs on single port D) support for disconnect supervision

Q6) Which protocol requires you to perform the bulk of the configuration on the router (gateway)? A) MGCP B) Non-IOS MGCP C) H.323 D) SCCP



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


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




Familiarity with the North American Numbering Plan (NANP)

Familiarity with Cisco IOS software



Outline

• Overview• External Call Routing• Route Groups• Route Lists• Route Patterns• Digit Analysis• Summary of Call Routing• Summary• Quiz



External Call Routing This topic explains external call routing in a basic route plan.


Cisco CallManager

Router/GW PSTN

1000

1001

Gatekeeper

Route Plan Call Types

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.

9.1408xxxxxxx Route

Pattern

IP WANGK

RemoteCisco 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.




RoutePattern

RouteList

RouteGroup

2nd

Choice

RouteGroup

1st

Choice2nd

Choice

Configuration O

rder

• Matches dialed number for external calls• Performs digit manipulation (optional)• Points to a route list for routing

• Chooses path for call routing• Points to prioritized route groups

• Performs digit manipulation• Points to the actual devices

PSTNIP WANGK

1st

Choice

Route pattern:

Route list:

Route group:

• Gateways (H.323, MGCP)• Gatekeeper• Intercluster Trunk

(remote Cisco CallManager)

Devices:

External Route Elements in Cisco CallManager

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.




Route Plan Configuration Process

MGCP-BasedVG200

Cat 6K GWs26003600

H.323-BasedAll IOS GWs

Device ProtocolH.225

Remote CallManagerDevice Protocol

Intercluster Trunk

Add gateway devices and trunks

1

Build route groups from available devices Route Group 1

Remote CallManager2600 (MGCP)

3640

Route Group 2Catalyst 6K Digital

2600 (MGCP) DigitalVG200

2

Build route lists from available route groups Route List 1

Route Group 1Route Group 2Route Group 3

Route List 2Route Group 2Route Group 3Route Group 1

3

Build a route pattern to available route lists or gateway devices

4

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.



Route Groups This topic describes the functions and configuration of route groups.


Route Pattern723-xxxx

Route List

1stChoice

2ndChoice

User Dials External Number723-8912

PSTN

Route groups create a prioritized list of voice

gateways.

Route Group

Digital GW 1

Digital GW 2

Route Groups Overview

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 long-distance 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.




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.

Step 2 Click the Add a New Route Group hyperlink. Give the new route group a name and click Continue.

Step 3 Choose a gateway from the Available Devices menu to add that gateway to the route group.

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.



Route Lists The topic describes the functions and configuration of route lists.


Route Pattern

Analog GW 1

1st ChoicePorts 1 - 8

2nd ChoicePorts 1 - 4

User Dials Number

Analog GW 2

IXC1

IXC2

IXC3

Analog GW 3

Route List

1stChoice

2ndChoice

1st ChoicePorts 5 - 8

2nd ChoicePorts 1 - 8

Route lists are a prioritized list of route

groups.

Route Group 1

Route Group 2

Route List Overview

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 call-routing process: at the originating device, as part of a translation pattern, as part of a route pattern, as part of a route list, or at the terminating device. Calling and called-party transformations that are set at the route list level override transformations that are set at any other level.

Note Calling and called-party transformations are covered in detail in the Building Advanced Route Plans lesson later in this module.




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.

Step 2 Click the Add a New Route/Hunt List hyperlink. Give the new route/hunt list a name and description, and click Continue.

Step 3 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.

Step 4 Click Insert to return to the Route List Configuration page. Use the arrows to prioritize the route groups.



Route Patterns This topic describes route patterns for external call routing.


Route Pattern723-xxxx

Route List

1stChoice

2ndChoice

User Dials External Number723-8912

PSTN

Route patterns match E.164 numbers and are

commonly used for external call routing.

Route Group

Digital GW 1

Digital GW 2

Route Pattern Overview

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.




Route Pattern: Commonly Used Wildcards

Terminates interdigit timeout#

Terminates access code.

Exclusion range notation[^x-y]

Generic range notation[x-y]

One or more digits (0-9)!

North American Numbering Plan@

Single digit (0-9, *, #)x

DescriptionWildcard

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 Description

0, 1, 2, 3, 4, 5, 6, 7, 8, 9, *, # Single digits that can be included in a route pattern.

[xyz] Set of matching digits. For example, [458] matches one occurrence of either 4, 5, or 8.

[x-y] Range of digits. For example, [3-9] matches one occurrence of either 3, 4, 5, 6, 7, 8, or 9. You can use the range notation along with the set notation. For example, [3-69] matches one occurrence of either 3, 4, 5, 6, or 9.

[^x-y] If the first character after the open square bracket is a carat, the expression matches one occurrence of any digit (including * and #) except those specified. For example, [^1-8] matches one occurrence of 9, 0, *, or #.

<wildcard>? A question mark that follows any wildcard or bracket expression matches zero or more occurrences of any digit that matches the previous wildcard. For example, 9[12]? matches the following dial strings: 9, 91, 92, 912, 9122, 92121, and many others.

<wildcard>+ A plus sign that follows any wildcard or bracket expression matches one or more occurrences of any digit that matches the previous wildcard. For example, 3[1-4]+ matches 31, 3141, 3333, and many others.




Route Pattern Examples

Matches any number that begins with 13, is followed by one or more digits, and ends with #; 135# and 13579# are example matches

13!#Matches 1306, 1316, 1326, 13*6, 13#613[^3-9]6Matches 1326, 1356, 1366, 1376, 138613[25-8]6Matches numbers between 1200 129912xxMatches numbers between 1*10 and 1*191*1xMatches 12341234

ResultPattern

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).



The NANP encompasses a number of dial strings, as presented in the following table.

Dial Strings

Dial String Description

Service calls Service calls are in the form of three- to four-digit numbers that are used to access telephony services such as 911, 411, 611, etc.

Local calls Local calls are in the form of a seven-digit number (xxx-xxxx) that is used to dial within your local calling area.

Expanded local calls Expanded local calls are in the form of a 10-digit number (xxx-xxx-xxxx) that is used to dial expanded-area local calls.

Long-distance calls Long-distance calls are in the form of a 10-digit number (xxx-xxx-xxxx) that is used to place the calls directly to a long-distance carrier.

Direct-dial long-distance calls Direct-dial long-distance calls are in the form of an 11-digit number (1-xxx-xxx-xxxx) that is used to place a long-distance call through a local carrier.

International calls International calls are in the form of 01 1 xx xxxxxxxxx where “xx” is the country code. The actual length of the dial string depends on which country that you are calling.

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.




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.

Step 2 Click the Add a New Route/Hunt Pattern hyperlink.

Step 3 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.

Step 4 If you configure a route pattern to route off-network calls to the PSTN (which most route patterns do), make sure to check the Provide Outside Dial Tone check box. This feature plays a second dial tone for users when they dial the outside access code.

If Cisco CallManager receives a dial string for which multiple route patterns match, 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.



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 gateway-level 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.



Digit Analysis This topic explains the digit analysis behavior of Cisco CallManager.


Dialing Behavior

Route Patterns

1001

1000Dialed Digits

<none> List Potential Matches

1 List Potential Matches



1 List Current Match

Call Setup

1XXX10XX

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.



— 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.




Digit Collection

1111

121X

1[23]XX

131

13!

13[0-4]X

User dial string: Match!

Does not match

Does not match

Does not match

Does not match

Does not match

No other patterns couldmatch; extend call.

Cisco CallManager actions:

1111

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.




Closest Match Routing

1111

121X

1[23]XX

131

13!

13[0-4]X

User dial string: Does not match

Match!

Match!

Does not match

Does not match

Does not match

1211

Matches 1 digit string

Matches 200 digit strings

Select as closest match

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.




Interdigit Timeout

1111

121X

131

User dial string: Does not match

Does not match

Match!

Does not match

Match!

Match!

1311<timeout>

Matches 200 digit strings

Matches 50 digit stringsSelect as closest match

Matches digit strings81[23]XX

13!

13[0-4]X

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.



Summary of Call Routing This topic summarizes the call-routing process.


Simple Route Plan Example

Route List Route Group

Cisco AccessDigital_GW 1

1stChoice

2ndChoice

User Dials Number

Cisco AccessDigital_GW 2

PSTN

Route Pattern can match route list or gateway.

$0.07 per min.

$0.10 per min.

RG_PSTNRL_PSTN

408-555-XXXX 723-XXXX836-XXXX868-XXXX

Route Pattern

Local_GW LECRoute

Pattern

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 408-555-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.




PSTN

IP WAN

A

A

Primary Voice PathStrip “52” and deliver61111 to remote CCM

Secondary Voice PathPrepend “1408” and send to PSTN

(408) 526-XXXX5-Digit Internal Dialing

Users required to dial7 digits for intersite calls

“526-1111”

San JosePhiladelphia(215) 555-XXXX

5-Digit Internal Dialing

Gatekeeper(s)

Route Plan Example 2

This figure details a more complex route plan, including features such as toll bypass and PSTN fallback. In this example, the ABC Company has two main offices in San Jose and Philadelphia. The users at ABC Company dial five-digit extensions to reach users within the same site (5XXXX in Philadelphia and 6XXXX in San Jose). As you can see in the figure, each site has its own Cisco CallManager cluster. You can classify these types of calls as on-cluster, or internal,, calls.

The users also dial seven-digit numbers to reach users in other sites (526-XXXX to reach San Jose and 555-XXXX to reach Philadelphia). The calls between sites are off-cluster, or external, calls and require the configuration of a route plan. In this example, when a user in Philadelphia dials 526-1111, the local Cisco CallManager cluster analyzes the dialed digits and looks for a match. In this case, 526-1111 matches the route pattern of 9.@ (which symbolizes the NANP).

At this point, the Cisco CallManager knows that it must route this external call to a gateway. Cisco CallManager now looks at the route list that is associated with the 9.@ route pattern to determine the correct gateway. In this example, Cisco CallManager uses the gateway that is connected to the IP WAN first, for cost reasons (toll bypass). Before Cisco CallManager can route the call across the IP WAN, it must perform digit manipulation (in the form of a called-party transformation) so that the remote Cisco CallManager can receive the call in a format that it understands (five-digit numbers).

If the IP WAN is down or the IP WAN does not have sufficient resources, Cisco CallManager can route the call across the gateway that is connected to the PSTN. Because a call from Philadelphia to San Jose across the PSTN is a long-distance call, Cisco CallManager must perform digit manipulation (in the form of a called-party transformation) to change the dial string of 526-1111 to 1-408-526-1111, which allows the PSTN to understand the dialed digits. The call-routing process is transparent to the end users, and they are not able to discern whether Cisco CallManager has routed the call over the IP WAN or the PSTN.




Basic Route Plan Summary

Global Switchor PBX

Global Switchor PBX

Global Switchor PBX

3rd choice

Digital Gateway .08 per minute

WS-X6608-T1.12 per minute

WS-X6624-FXS.15 per minute

1st choice

1st choiceRouteGroup A

RouteList

RouteGroup C

Route Pattern 9.@

3rd choice

1st choice

Route Pattern 8.@

Cisco Gateways

2nd choice

2nd choice

2nd choice2nd choice1st choice

RouteGroup B

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.



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.





• 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.

Summary




Q1) Which of the following contains a list of gateways to use in precedence order? A) route group B) route list C) translation pattern D) route pattern

Q2) What is the key to making toll bypass and PSTN fallback features transparent to your users? A) digit manipulation B) 10-digit dialing C) route filtering D) route summarization

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) 15 B) 150 C) 1500 D) 15000

Q5) Which of the following constitutes a basic route plan? (Choose four.) A) route groups B) voice gateways C) route lists D) route patterns E) Cisco CallManager clusters

Q6) What can be placed into a route list? A) route groups B) route patterns C) route lists D) devices



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




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




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



Route Filters This topic discusses the configuration and application of route filters in a route plan.


Route Filter BasicsThe “9.@” Route Pattern

Route Pattern

“9.@”

North American Numbering Plan:

9.[2-9]119.[2-9]XX XXXX9.1 [2-9]XX [2-9]XX XXXX9.011 !

Actual Routes in CallManager:9.[2-9]119.[2-9]XX XXXX

“INTERNATIONAL-ACCESS”DOES-NOT-EXIST

AND“AREA-CODE”

DOES-NOT-EXIST

• 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...

Route Filter“Local Only”

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.



Generally, telephone company (telco) service providers arrange many NXXs in a given area code—contiguously— 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 Example Pattern Description

AREA-CODE 1 214 555 1212 The area code in an 11-digit long-distance call

COUNTRY-CODE 011 33 123456# The country code in an international call

END-OF-DIALING 011 33 123456# The #, which terminates interdigit timeout for an international call

INTERNATIONAL-ACCESS 01 1 33 123456# The initial 01 of an international call

INTERNATIONAL-DIRECT-DIAL

01 1 33 123456# The digit that denotes the direct-dial component of an international call

INTERNATIONAL OPERATOR

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

LOCAL-AREA-CODE 214 555 1212 The area code in a 10-digit local call

LOCAL-DIRECT-DIAL 1 555 1212 The initial 1 that is required for some 7-digit calls

LOCAL-OPERATOR 0 555 1212 The initial 0 that is required for operator-assisted local calls

LONG-DISTANCE-DIRECT-DIAL

1 214 555 1212 The initial 1 that is required for long-distance direct-dialed calls

LONG-DISTANCE-OPERATOR

0 214 555 1212 The initial 0 that is required for operator-assisted long-distance calls

NATIONAL-NUMBER 011 33 123456# The national number component of an international call

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

SATELLITE-SERVICE 011 88141234# A specific value that is associated with calls to the satellite country code

SERVICE 1 411 Access to local telephony provider services

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

TRANSIT-NETWORK 101 0321 1 214 555 1212 Long-distance carrier code

TRANSIT-NETWORK-ESCAPE

101 0321 1 214 555 1212 The escape sequence that is used for entering a long-distance carrier code



The types of patterns that are included when a 9.@ route pattern is added are the following:

No filter

Service Exists

Country-code Does-Not-Exist

Area Code = 900


9 [2-9]11

9 [2-9]XX XXXX

9 [2-9]XX [2-9]XX XXXX

9 011 3[0-469] !

9 1 [2-9]XX [2-9]XX XXXX

311, 611, 911 SERVICE

7-digit dialing by OFFICE CODE

10-digit local dialing byLOCAL AREA CODE

11-digit long-distance dialing byAREA CODE

International dialing byCOUNTRY CODE

9.@ Route Pattern Without Route Filters

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




Configuring Route Filters

Filter calls when the dialed digit string associated with this tag matches the specified value==

Filter calls when the dialed digit string associated with this tag is not found.

DOES-NOT-EXIST

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

EXISTS

Do not filter calls base on the dialed digit string associated with this tag.

NOT-SELECTED DescriptionOperator

You can configure a route filter by using the Cisco CallManager Administration window.

Step 1 Choose the Route Plan menu.

Step 2 Choose Route Filter from the menu bar.

Step 3 Choose NANP from the Dial Plan menu.

Step 4 Enter a name in the Route Filter Name field. The name can consist of up to 50 alphanumeric characters, and can contain any combination of spaces, periods (.), hyphens (-), and underscore characters (_). Each route filter name must be unique to the route plan.

The tag operators in the route filter determine 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.




9.@ with Route Filter AREA CODE == 900

9 1 [2-9]XX [2-9]XX XXXX

Not added: no AREA-CODE


Not added: no AREA-CODE (It contains LOCAL-AREA-CODE)

Added: AREA-CODE constrained to 900


9 [2-9]XX XXXX

9 [2-9]XX [2-9]XX XXXX

900

9 011 3[0-469] !

9 [2-9]11

The figure here shows the patterns that Cisco CallManager adds when you apply the AREA-CODE = = 900 filter to the 9.@ route pattern. A route filter that uses the tag AREA-CODE, the operator = =, and the entry 900, selects all dialed digit strings that include the 900 area code. After you apply the route filter to the route pattern, you are given the configuration option to route this pattern or block this pattern. By choosing the Route this pattern radio button on the Route Pattern/Hunt Pilot Configuration window, you would allow all calls where AREA-CODE = 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.



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


Discard Digits Instructions

Used forDiscarded DigitsInstructions

Trailing-#

10-10-Dialing

IntlTollBypass

11D@10D

11D/10D@7DPreAt

PreDot

PSTN compatibility95 1010321 011 33 1234 #

Suppressing carrier selection

95 1010321 1 214 555 1212

Toll bypass95 011 33 1234 #

Toll bypass95 1 214 555 1212

Toll bypass95 1 214 555 1212Access codes95 1 214 555 1212

Access codes95 1 214 555 1212

If the pattern is 9.5@…

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.




Using PreDot Discard Digits Instructions

• Use discard digits instructions to strip initial digits.

• Use only NoDigits or PreDot unless the pattern contains an @ wildcard.

PBX

Cisco CallManagerMatch: 9.8XXX

Discard: PreDot

Called party: 8123

User dials: 98123

Cisco CallManager applies the PreDot DDI to the 9.8XXX route pattern, strips the 9 from the dialed digits, and sends only the 8123 to the PBX.

In Cisco CallManager Administration, you can access the Discard Digits menu shown in the figure by choosing Route Plan > Translation Pattern.




Using Compound Discard Digits Instructions

• 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

User dials: 9101028812145551212

Called party: 12145551212

Cisco CallManager

PSTN

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.



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

45000808236XXX

808236500045XXX

8082365000

45000

An X in a masklets digits passthrough.

Digits in masksreplace number digits.

Blanks blocknumber digits.

_____

Mask

Mask

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 seven-digit numbers, appending area codes and office codes to interoffice calls that are dialed as four- or five-digit extensions, and suppressing carrier access codes for equal-access calls.

A mask operation allows the suppression of leading digits, the change of some digits while leaving others unmodified, and the insertion of leading digits.

A mask operation requires two pieces of information: the number you wish to mask and the mask itself.



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.




Calling Party Transformation Order

• Apply the external phone number mask.

• Apply the calling party transformation mask.

35062

21471XXXXX

40885XX000

2147135062

4088535000

Directory number

External phonenumber mask

Calling partytransformationmask

Caller ID

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.




Called Party Transformation Order

• Apply discard digits instructions.

• Apply the called-party transformation mask.

• Apply prefix digits.

9 1010321 18085551221

10-10-Dialing

XXXXXXXXXX

9 18085551221

8085551221

Dialed number

discard digitsinstructions

Called-partytransformationmask

Prefix digits

Called number 88085551221

8

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.




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.




Route Pattern Discard DigitsInstruction

Transform Calling Number

Transform Called Number

User DialNumbersUsers

9.1XXXA - 5062

B - 5063

C - 5064

A - 91234

B - 91324

C - 91432

Discard “9”Wildcards allow all

dialed numbers to match one route pattern.

Users DialedNumbers

A – 1234B – 1324C – 1432

“X000”

User DirectoryNumbers

A – 5000B – 5000C – 5000

“X000”

User DialedNumbers

Caller IDA – 1000B – 1000C – 1000

To: 1000From: 5000

Extension “1000”Rings

1 2 3

456

Transformation Example

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:

Step 1 User A has a DN of 5062. This user dials DN 91234.

Step 2 The dialed number matches the route pattern 9.1XXX.

Step 3 The DDIs contain the instructions to discard the 9. The dialed number is now 1234.

Step 4 The calling number 5062 now passes through the calling number transformation mask, which contains instructions to change the last three digits of the calling party number to 000. The new calling number is 5000.

Step 5 Cisco CallManager then passes the called number 1234 through the called-number transformation X000 that changes this number to 1000.

Step 6 The result is a calling party number of 5000 and a called number of 1000.



Translation Patterns This topic discusses the functionality and configuration of translation patterns.


Pattern type?

Digits

Apply calling and calledparty transformations

Extend call to destination.

Route pattern

DigitsFind best match.

Apply calling and called-party transformations.

Pattern type? Translation pattern

Translation Pattern

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.




Translation Pattern Configuration

Route Pattern

Transformation Settings

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.




PSTN

EmployeePhones

A

Attendant(4111)

San Jose

Internal Extensions4XXX

PSTN DID Range408-555-1xxx

PSTN DID range does not match internal range

Translation Pattern = 1XXXCalled Party Transform Mask = 4XXX

Can be used to send calls to unassigned DID

numbers to attendant or recording

Translation Pattern = XXXXCalled Party Transform Mask = 4111

CallManager uses longest matchso “XXXX” will match any

nonconfigurednumber and get sent to 4111

(attendant)

OR

Common Uses of Digit Translation

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.



Route Plan Report This topic provides an overview of the route plan report.


Route Plan Report Overview

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.




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.

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 You may change the name of the file, but the filename must have a .csv extension.

Step 4 Select the location in which to save the file and click Save. The file should now be saved to the location that you designated.

Step 5 Locate the CSV file that you just saved and double-click its icon to view it.





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.


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




Q1) Which of these file types does Cisco CallManager create by default when generating a route plan report? A) .csv B) .doc C) .pdf D) .txt

Q2) What does Cisco CallManager do when dialed digits match a translation pattern? A) extends the call to the destination B) forwards the call to a route pattern C) selects the closest match to that pattern D) sends the transformed digits through digit analysis one more time

Q3) When DN 8500 calls and a calling transformation mask of 972555XXXX is applied, which CLID is sent? A) 8500 B) 5558500 C) 9725558500 D) 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) 98085551212 B) 5551212 C) 95551212 D) 8085551212

Q5) Network administrators use route filters with which route pattern wildcard? A) x B) ? C) ! D) @




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


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




A basic understanding of Cisco CallManager Administration and basic route plan



Outline

• Overview• Class of Service• Partitions• Calling Search Spaces• Using Partitions and Calling Search Spaces for

Emergency Calls• Cisco Emergency Responder• Summary• Quiz



Class of Service This topic provides a general definition and analogies for CoS, partitions, and calling search spaces.


General Definition

PSTN

IP WAN

Employee

Long-Distance

International

Class ofService 1

Lobby

Class ofService 2

Employee

Class ofService 3

Executive

Executive

CoS is best defined in Newton’s 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 Newton’s 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 company’s money by frivolously calling expensive numbers, so you might wish to define “Class of Service” assignments in your PBX. You could have one that’s 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.




Subnet/PartitionB

Subnet/PartitionC

Subnet/PartitionD

Subnet/PartitionA

Access List/ Calling Search Space• permit B• permit C• (implicit) deny D

Partitions and Calling Search Spaces:Analogy with Subnets and Access Lists

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

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.




Problems Addressed

• Routing by geographical location• Routing by tenant• Routing by class of user

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.



Partitions This topic discusses partitions and the configuration of partitions.


Partition Definition

• A logical grouping of DNs and route patterns • All patterns in a partition equally reachable

PartitionLobby

LobbyPT

PartitionEmployee

EmployeePT

PartitionExecutive

ExecutivePT

PartitionGateway

Local and WANGatewayPT

Directory Numbers63500635016350263503

Directory Numbers6405064051640526405x

Directory Numbers6402064021640226402x

Route Pattern9.@

[email protected]

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.




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.



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


Calling Search Space Definition

• 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

Lobby Phone Employee Phone Executive Phone Local and WANGWPT

Calling Search SpaceE911PT

EmployeePT


EmployeePTLocalGWPTWANGWPT


EmployeePTGWPT

ExecutivePT

Calling Search SpaceE911

EmployeePT

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.




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.



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

PSTN

Site 1

Site 2

IP WAN Router

IP WAN Router

Router/GW

Centralized CallManager Cluster 911911

Hub IP WAN

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.



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.


911

PSAP(City A)

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

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.



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.




Endpoint Location Operation79xx SoftPhone

65004224

3500

5000

3) SNMP Get:CDP neighbors

1) Seed switch configuration:IP address, SNMP info, etc.

4) SNMP Get:configured VLANsCAM table per VLAN

Primary Cisco ERBackup Cisco ER

2) SNMP Get:New phone registrations(MAC address info)

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



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

Manual endpoint entry:

— 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

Supported Catalyst switches:

— Cisco Catalyst 2900 XL Series

— Cisco Catalyst 2950 Series












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.




Newton, H. Newton’s 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/




Q1) Which three of these problems are addressed with calling search spaces and partitions? (Choose three.) A) routing by geographical location B) routing by tenant C) routing by class of user D) routing by device

Q2) Which of these statements best describes a partition? A) a logical grouping of route patterns B) a logical grouping of telephone devices C) a logical grouping of gateway devices D) a logical grouping of route lists

Q3) Which of these statements best describes a calling search space? A) an ordered list of partitions B) an ordered list of route patterns C) route patterns with similar calling capabilities D) route groups with similar calling capabilities

Q4) If partitions and calling search spaces are properly configured in a multisite environment, which of the following should happen during an emergency call? A) The call should be routed across the IP WAN. B) The call should be routed to the local PSTN. C) The call should not be routed. D) The call should be routed using route lists.

Q5) Which three are appropriate applications for Cisco ER? (Choose three.) A) single or multicluster installations with 48+ IP Phones per site B) E911 extension support to include extension mobility C) Cisco IP Phones that are not connected to Catalyst switches D) shared-line appearances on telephones in multiple physical locations



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


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


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



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.


Cisco CallManager

Example:WAN bandwidth can only support two calls.

What happens when the third call is attempted?

Call #1Call #2

Call #3Causes poor quality for all calls

Call #3

Why Call Admission Control?

IP WAN

Many tools give voice priority over data.Call admission control is about preventing voice oversubscription.

Cisco CallManager

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.




Two Methods of Call Admission Control

Distributed call processing: Use gatekeepers and inter-cluster (gatekeeper-controlled) trunks

PSTNPSTN

IP WANIP WAN

Cisco IOS Gatekeeper

V

Centralized call processing:Use locations feature

PSTNPSTN

IP WANIP WAN

CallManager Cluster

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.



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

64

256

Unlimited

Bandwidth (kbps)

San Jose

New York

Dallas

Location

San Jose (Main)

CallManagerCluster

New York (Remote)

Dallas (Remote)

IP WAN

• 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





GSM call uses 29 kbps

Wideband call uses 272 kbps



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/ccmsys/a08video.htm#63199



Locations-Based Call Admission Control Configuration

This topic discusses how to configure locations-based call admission control in Cisco CallManager.


Location Configuration

• Configure a region for each type of codec used• Configure a separate location for each IP WAN link

Location is then assigned to devices.

Follow these steps to configure locations in Cisco CallManager:

Step 1 Configure a region for each type of codec that is used in your system.

Step 2 Configure a separate location for each IP WAN link to which you want to apply call admission control. Allocate the maximum available bandwidth for calls across the link to that location.

Step 3 Configure the device pools for your system and choose the appropriate region for each.

Step 4 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.



Gatekeeper Call Admission Control Overview This topic discusses basic concepts of gatekeeper call admission control.


0IP WANIP WAN

Gatekeeper Zone• 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

Distributed Call Processing: Gatekeeper Call Admission Control

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 inter-cluster 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.



Gatekeeper Communication This topic describes the communication between the gatekeeper and H.323 endpoint (Cisco CallManager).


Gatekeeper Discovery

GatekeeperH.323 Endpoint

GRQ (1)

GCF/GRJ (2)

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.




Gatekeeper Registration and Unregistration


RRQ (1)

RCF/RRJ (2)Registration

Gatekeeper Initiated Unregistration Request

Endpoint Initiated Unregistration Request

URQ (1)

UCF (2)

URQ (1)

UCF/URJ (2)

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.



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.




Admission Request

Gatekeeper H.323 Endpoint 2

ARQ (1)

ACF/ARJ (2)

Setup (3)

Call Proceeding (4)

Alerting (7)

Connect (8)

H.323 Endpoint 1

ARQ (5)

ACF/ARJ (6)

RAS MessagesCall 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.




Disengage and Bandwidth Request


DRQ (1)

DCF(2)Disengage

BandwidthBRQ (1)

BCF/BRJ (2)

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.



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

Router(config)# gatekeeperRouter(config-gk)# zone local SJGK1 cisco.comRouter(config-gk)# zone prefix SJGK1 408*Router(config-gk)# gw-type-prefix 1#* default-technology!Router(config-gk)# bandwidth total zone SJGK1 512Router(config-gk)# bandwidth session zone SJGK1 256

Cisco IOS GatekeeperConfigure zones and bandwidth allocations on the gatekeeper

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.

Step 2 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.

Step 3 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.

Step 4 Configure a route pattern to route calls to each gatekeeper-controlled trunk.



Example Shown in the figure is a sample gatekeeper configuration. The commands are described in the following table.

Cisco IOS Gatekeeper Commands

Command Description

gatekeeper Enters gatekeeper configuration mode/

zone local SJGK1 cisco.com

Specifies cisco.com as the a zone controlled by gatekeeper SJGK1.

zone prefix SJGK1 408* Associates the digits 408 with the local zone SJGK1.

gw-type-prefix 1#* default-technology

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.

bandwidth total zone SJGK1 512

Specifies the maximum bandwidth available in zone SJGK1 as 512 kbps.

bandwidth session zone SJGK1 256

Specifies the maximum bandwidth allowed for a session in zone SJGK1 as 256 kbps.




Gatekeeper Configuration in CallManager

Configure gatekeeper settings and trunk in Cisco CallManager

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.



Gatekeeper Configuration in Cisco CallManager Administration

Field Description

Host Name/IP Address* Enter the IP address or host name of the gatekeeper in this required field.

Registration Request Time to Live 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.



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

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)




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)



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




Central Site Call Manager (Cisco

CallManager)

Real-Time Protocol

Skinny: Protocol for call set up and tear down

HeadquartersBranch Router 1750,

2600, 3600, 7200, Cat4224 IAD2400

PSTN

WAN

SRST: Normal Operation

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.




Central Site Call Manager (Cisco

CallManager)

Real-Time Protocol

HeadquartersBranch Router 1750, 2600,

3600, 7200, Cat4224 IAD2400

PSTN

SRST: Network Failure

Keepalive (TCP)

KA to CallManager

KA to CallManager

Skinny

WAN

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.




Central Site Cisco

CallManager

Real-Time Protocol

HeadquartersBranch Router 1750,

2600, 3600, 7200, Cat4224 IAD2400

PSTN

WAN

Keepalive: Ensures communication link with Cisco CallManager

SRST: Network Failure Repaired

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.



SRST Configuration This topic discusses configuring SRST on Cisco IOS routers and assigning an SRST reference in Cisco CallManager.


call-manager-fallback

SRST(config)#

• Enables Cisco CallManager fallback capability and puts you in a submenu.

ip source-address <router ip address> [port <port #>]

SRST(config)#

• Enables router to receive Skinny messages on this particular port. The default port is 2000.

max-ephones

SRST(config)#

• Maximum IP Phones that will be allowed to register. Defaults to 0.

max-dn

SRST(config)#

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

SRST Configuration: Four Commands

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.



call-manager-fallback Subcommands

Command Description

access-code Define access-codes for outgoing calls

default Set a command to its defaults

default-destination

Define/disable default destination dn for ringing on unknown called number

dialplan-pattern Define E.164 telephone number prefix

huntstop Stop hunting on dial peers

ip Define IP address and port for the IP Keyswitch

keepalive Define keepalive timeout period to unregister IP Phones

max-dn Specify maximum directory numbers supported on IP Keyswitch

max-ephones Specify maximum number of IP Phones

reset Reset IP Phones

transfer-pattern Define valid call transfer destinations

Voicemail Set voice-mail access number called when messages button is pressed




show call-manager-fallback

Router#show call-manager-fallbackaccess-code fxo 9default-destination 4312dialplan-pattern 1 345…ip source-address 10.1.1.2 port 2000keepalive 30max-ephones 24max-dn 48transfer-pattern 525...voicemail 4001

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.




Creating an SRST Reference in Cisco CallManager Administration

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.




Assigning SRST References

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.



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.


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 CallManagerand assign to device pool. Configure SRST commands on the Cisco IOS router.



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_guide09186a0080087ac0.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_sheet09186a00800888ac.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



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) no requirement to configure Cisco IOS commands on the gatekeeper B) no requirement to configure an inter-cluster trunk between clusters C) provides emergency call-handling capability if the WAN link fails D) provides call admission control over the intranet in addition to the WAN

Q2) Without call admission control, what happens to existing calls when the next call oversubscribes the WAN? A) all calls are dropped B) voice quality on all calls degrades C) voice calls on the last call degrades D) nothing if the router is configured for QoS

Q3) Which two are characteristic associated with the distributed call admission control method? (Choose two.) A) inter-cluster trunk to each CallManager cluster B) gatekeeper-controlled trunks C) maximum bandwidth is determined on the CallManager D) zones and bandwidth allocation configured on the router

Q4) How do the IP Phones in a branch site know to register to the gateway running SRST? A) The IP Phones stops receiving keepalive packets from the SRST gateway B) The IP address is configured on the gateway and passed to the IP Phone C) The gateway IP address is specified in the SRST Reference Configuration page D) The Device Pool contains the IP address reference to the SRST gateway.

Q5) Which two of these options describe how endpoints achieve gatekeeper discovery? (Choose two.) A) autodiscovery B) manual discovery C) assigned by the voice router D) 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) location B) region C) device pool D) device default

Q7) Which of the following two statements are true with respect to SRST? (Choose two.) A) it is appropriate for centralized call-processing deployments B) IP Phones will drop existing calls when the WAN link resumes C) IP Phones listen for keepalives to know when the central CallManager is back

online D) SRST supports Calling Search Spaces, Extension Mobility, and IP SoftPhone



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) 2 B) 3 C) 4 D) 5



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




Module 4

Enabling Features for Users

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 softkeytemplates 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



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


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





Cisco IOS and Cisco Catalyst operation system command-line basics



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


Copyright © 2004, Cisco Systems, Inc. Enabling Features for Users 4-5

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

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.




Installing Software Media Resources

Services required for media resources

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.



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. Hardware-enabled conferencing provides the ability to support voice conferences in hardware. Digital signal processors (DSPs) convert multiple Voice over IP (VoIP) packets into streams that are mixed into a single conference call stream. The DSPs support both Meet-Me and ad hoc conferences. Hardware conference devices provide transcoding for G.711, G.729, G.723, Global System for Mobile Communication (GSM) Full Rate (FR), and GSM Enhanced Full Rate (EFR) codecs. 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.



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.




Numerous audio and video coding

schemes

G.711, G.729, GSM FR, GSM EFR

G.711, G.729, or G723

G.711, G.729

G.711, Cisco wideband

G.711, G.723, G.729, GSM FR, GSM EFR

Codecs

Varies by platform

8

6

64–Ad Hoc128–Meet-Me

1 CFB–32 users10 CFB–3 users

Max. Participants Per Conference

NM-HDNM-HDV2

WS-SVC-CMM-ACT

Cisco IOS Enhanced Conference Bridge

IPVC-35xxCisco Video Conference Bridge (IPVC-35xx)

NM-HDVNM-HD-FARM

Cisco IOS Conference Bridge

Cisco IP Voice Media

Streaming App. Cisco Conference Bridge Software

WS-X6608-T1 WS-X6608-E1

Cisco Conference Bridge Hardware

Conf. Resource

Conference Bridge Types

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 built-in T1 or E1 port and supports up to 90 channels of digital voice, or 30 channels of digital voice and four channels of analog voice. The NM-HDV2-2T1/E1 adds support for two built-in T1 or E1 ports and supports a maximum of 120 channels of digital voice, or 60 channels of digital voice and four channels of analog voice

NM-HD-2VE: The NM-HD-2VE supports analog, BRI, T1, E1, voice, and data WANs and up to 48 channels (G.711 codec).



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.



The following table provides additional detail about audio conference bridges.

Conference Type Number of Participants and Bridges Resource

Hardware 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

WS-X6608-T1

WS-X6608-E1

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.

Software

Cisco IOS software • 3 bridges per PVDM-12

• 3, 6, 9, or 15 bridges per network module (NM)

• Maximum of 6 participants per bridge

NM-HDV

NM-HDV-FARM

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/ps4952/products_data_sheet0900aecd800f8580.html

NM-HD

NM-HDV2

WS-SVC-CMM-ACT




Hardware Conference Bridge Configuration

Catalyst 6000 port MAC address needed

To add a hardware conference device, follow these steps:

Step 1 Choose Service > Media Resource > Conference Bridge and Add a New Conference Bridge.

Step 2 Choose Cisco Conference Bridge Hardware for the Conference Bridge Type.

Step 3 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.



Media Termination Point Resources This topic examines MTP resources.


Media Termination Point

• 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

Router/GWH.323v1

1001

1002

Cisco CallManagerCisco IP Voice Media Streaming Application

SW MTP

Incoming Stream

Initial Stream

Supplementary Service Stream

PSTN

IP WAN

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.




MTP Capabilities

• Up to 128 half-duplex streams are configurable.• 64 full-duplex resources are available for MTP

application.

The figure and the table shown here describe the MTP limits.

MTP Limits

MTP Resource Type Limitations

MTP

Installed with the IP Voice Media Streaming Application on a supported Cisco CallManager server platform

G.711 only.

Up to 128 half-duplex streams are configurable.

64 full-duplex resources are available for MTP application.




MTP Configuration

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 Description

Media Termination Point Type 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.

Host Server Choose the server to run MTP.

Media Termination Point Name Enter an MTP name, up to 15 alphanumeric characters.

Description Enter a description for MTP.

Device Pool Choose a device pool with the highest priority in the Cisco CallManager group or choose Default.



Annunciator Resources This topic discusses annunciator resources.


Annunciator

Announcement

RTP Stream

“Your call cannot be completed as dialed...This is a recording.”

• Plays prerecorded .wav files and tones

• Alerts callers as to why the call failed

• Works in conjunction with MLPP 1001

1002

Cisco IP Voice Media Streaming Application

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 phone—the annunciator plays the tone because the gateway cannot play the tone when the call is active.

To add an annunciator to the Cisco CallManager, you must activate the Cisco IP Voice Media Streaming Application service on the server where you want the annunciator to exist in the cluster.



Sample announcements follow in the table.

Sample Annunciator Announcements

Condition Announcement

An equal or higher-precedence call is in progress.

“Equal or higher-precedence calls have prevented the completion of your call. Please hang up and try again. This is a recording.”

A precedence access limitation exists.

“Precedence access limitation has prevented the completion of your call. Please hang up and try again. This is a recording.”

A service interruption occurred. “A service disruption has prevented the completion of your call. In case of emergency call your operator. This is a recording.”

Example: Call Completion Failure and Announcement In the figure, the user at 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.”




Annunciator Capabilities

• Up to 48 annunciator streams on a coresidentserver 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.

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.




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.

Step 2 Verify that you have activated the Cisco IP Voice Media Streaming Application service on the server where you want the annunciator to exist.

Step 3 Perform additional annunciator configuration tasks if you want to change the default settings.

Step 4 Add the new annunciators to the appropriate media resource groups and media resource lists.

Step 5 Reset or restart the individual annunciator on all devices that belong to the media resource group or list.



Transcoder Resources This topic defines transcoder resources and examines transcoder limitations.


Transcoding Definition

XCODE

G.729 G.711

Voice Messaging

MTP

Input Stream Stream for Supplementary

ServicesH.323 v1

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.




Transcoding Capabilities

G.711 to G.729 or G.723 codecs: 60 per moduleG.711 to GSM FR or GSM EFR codecs: 45 per module

NM-HDVNM-HDV-FARM

G.711 to any other codec:192 streams total and 24 streams per port

WS-X6608-T1/E1

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-HDNM-HDV2

G.711 to any other codec:128 streams per port adapter

Maximum Number of Transcoder or MTP Sessions

WS-SVC-CMM-ACT

Resource

The figure and table shown here describe the MTP and transcoder resource capabilities.

MTP and Transcoder Resource Capabilities

Resource Type From Codec To Codec

G.723. G.729a, GSM FR, GSM EFR G.711 a-law or mu-law WS-X6608-T1, WS-X6608-E1

G.711 a-law or mu-law G.723. G.729a, GSM FR, GSM EFR

G.729, G.729a, G.729b, G.729ab G.711 a-law or mu-law NM-HDV and NM-HDV-FARM

G.711 mu-law G.729, G.729a, G.729b, G.729ab

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

G.711 a-law or mu-law NM-HD and NM-HDV2

G.711 a-law or mu-law G.729, G.729a, G.729b, G.729ab, GSM FR, GSM EFR

G. 729a, G.729 b, G.723 G.711 a-law or mu-law WS-SVC-CMM-ACT

G.711 a-law or mu-law G. 729a, G.729 b, G.723




Transcoder Configuration

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.



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

Audio sources:• Recorded audio• Live audio

Deployment types:• Coresident• Standalone

Cisco CallManagerCisco IP Voice Media Streaming Application

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.




MOH Server Capabilities

• Coresident server: 20 MOH sessions• Standalone server: 50 or 250 MOH sessions

depending on platform• 51 audio sources per cluster

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

MCS 7815

MCS 782x (all models)

MCS 7830 (all models)

SPE-310

HP DL320

IBM xSeries 33x (all models)

G.711 (a-law and mu-law)

G.729a

Wideband audio

Coresident server: 20 MOH sessions

Standalone MOH server: 50 MOH sessions



HP DL380

IBM xSeries 34x (all models)

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.




Creating Audio Source File

Administrator copies audio source into

this directory.

Audio Translator Service

New files are automatically detected and processed.

Cisco CallManager Administration copies

audio source files when they are mapped.

Default MOH TFTP Server

MOH Server

Hard-Coded MOH Server Audio

Source Directory

DirectShow Filters

Kernel-Mode RTP Streaming

Driver

1Start

2

3

5

6

4

Audio Source Input DirectoryC:\Cisco\DropMOHAudioSourceFilesHere

MOH Master Storage Directory

TFTP Path Directory

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.

Note It takes approximately 30 sec to convert a 3-MB MP3 file.

Step 2 Cisco CallManager automatically detects and translates the files.

Step 3 The output and source files are moved into the default MOH TFTP server holding directory. This holding directory is the same as the default TFTPMOHFilePath with \MOH appended.

Note Cisco does not recommend using the audio translator service during production hours because the service will consume 100 percent of the CPU.

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.

Step 5 The MOH servers download the needed audio source files and store them in the hard-coded directory C:\Program Files\Cisco\MOH.



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 Translator2. Configure MOH Server3. Add and Configure Audio Source Files4. Set MOH Service-Wide Settings5. Find and Configure Fixed Audio Source6. Assign Audio Source IDs

The figure lists the steps to configure MOH. These tasks are described in the next several pages.




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.




MOH Server Configuration

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.




Adding and Configuring Audio Source Files

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.




MOH Service-Wide Settings

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.




Finding the Fixed Audio Source Name

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.




Configuring the Fixed Audio Source

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.




Assigning Audio Source IDs

Audio source IDs for user and network hold

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.



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

MTP_1MTP_2MTP_3

SW_CFB_1SW_CFB_2SW_CFB_3

MOH_1MOH_2MOH_3

XCODE_1XCODE_2XCODE_3

HW_CFB_1HW_CFB_2HW_CFB_3

Media Resource Manager

Cisco CallManager

Cluster

Shares all media resources among all Cisco CallManagers in the cluster

ANN_1ANN_2ANN_3

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



You can group devices of the following types into a single MRG:

Conference bridge

MTP

MOH server

Transcoder

Annunciator




Media Resource Design

Media Resource Group List

Media Resource

Group

Media Resource1

Media Resource2

Media Resource3

Media Resource1

1stChoice

2ndChoice

User Needs Media

ResourceMedia Resource Manager

Similar to Route Lists and Route Groups

Media Resource

Group

Assigned to Device

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.




MRG

Default MRGMOH1MTP1XCODE1XCODE2XCODE3

Load distribution of transcoders

Call 1 Call 2 Call 3 Call 4 Call 5 Call 6 Call 7

XCODE1 XCODE2 XCODE3 XCODE1 XCODE2 XCODE3 XCODE1

All resources shared among Cisco CallManagers in a cluster

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




MRG Configuration

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

Use the Media Resource Group List Configuration page to configure MRGLs. Enter a name for the MRGL and then add the MRGs.




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.

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.




Group Resources by Type

Software MRGMTP1MTP2SW-CONF1SW-CONF2

Hardware MRGXCODE1XCODE2HW-CONF1HW-CONF2

MOH MRGMOH1MOH2

ResultUse all hardware conference resources first, and then use

software conference resources.

“I would like to have a conference with ‘telephone

C.’ Is there a conference resource available?”

A B

C

RTP

Resource_List

1

2

3

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.




Group Resources by Location

ResultDevices use

resources at their location first.

Dallas

San Jose

Dallas_MRGXCODE1HW-CONF1MOH2

Hub_MRGMTP1MTP2MOH1SW-CONF1SW-CONF2

San Jose_MRGXCODE2HW-CONF2MOH3

Dallas_List

1

2

3

San Jose_MRGXCODE2HW-CONF2MOH3

Hub_MRGMTP1MTP2MOH1SW-CONF1SW-CONF2

Dallas_MRGXCODE1HW-CONF1MOH2

San Jose_List

1

2

3

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.




Restrict Access to All Media Resources

No Resource_List

Software MRGMTP1MTP2SW-CONF1SW-CONF2

Hardware MRGXCODE1XCODE2HW-CONF1HW-CONF2

MOH MRGMOH1MOH2

ResultDevice cannot use any

media resources.

AResource_List

1

2

3

Dummy MRGDummy 1

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.




Restrict Access to Conference Resources

NO_CONF_List

MTP MRGMTP1MTP2

XCODE MRGXCODE1XCODE2

1

2

3MOH MRGMOH1MOH2

ResultDevice cannot

use any conference resources.

AMTP MRGMTP1MTP2

CONF MRGSW-CONF1SW-CONF2HW-CONF1HW-CONF2

MOH MRGMOH1MOH2

Resource_List

1

2

3

XCODE MRGXCODE1XCODE2

4

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.




Media Resource Functionality Example

Audio Source IDs1 – Pop Music 15 – Thank you for holding.

A

B

Dazzle_MRGServerD_MOH

D_List MRGL

SD_List MRGL Audio Source IDUser – 1 Network – 5

Audio Source IDUser – 1 Network – 5

ServerD_MOH

MOH Servers

ServerS_MOHSuperDave_MRGServerS_MOHServerD_MOH

Dazzle_MRGServerD_MOH

This list describes the configuration setup shown in this figure:

Two MRGs:

— Dazzle_MRG consists of the MOH server labeled ServerD_MOH.

— SuperDave_MRG consists of a prioritized list of MOH servers labeled ServerS_MOH and ServerD_MOH.

Two MRGLs:

— D_List consists of the Dazzle_MRG.

— SD_List consists of the SuperDave_MRG and Dazzle_MRG (prioritized order).

Two audio source IDs:

— Audio source ID 1 plays the Pop Music 1 audio stream.

— Audio source ID 5 plays the “Thank you for holding” audio stream.

Two Cisco IP Phones:

— Cisco IP Phone A is assigned the D_List MRGL and the audio sources ID 1, Pop Music 1 (for user hold), and ID 5, “Thank you for holding” (for network hold).

— Cisco IP Phone B is assigned the SD_List MRGL and the audio sources ID 1, Pop Music 1 (for user hold), and ID 5, “Thank you for holding” (for network hold).

The effect of the configuration in this example is that when IP Phone A places a user on hold, pop music is streamed from audio source ID 1 on ServerD_MOH. When IP Phone B transfers a call (network hold), the user 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.





Summary

• Media resources provide services, such as transcoding, conferencing, MOH, and media termination, which are activated onthe 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 routedthrough 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 hold—user 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.


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.




Q1) Which of these services does an MTP resource provide for an H.323v1 gateway? A) transcoding services B) MOH C) conferencing D) supplementary services

Q2) When is it recommended to run the audio translator? A) any time of the day B) during peak call-processing hours C) during off-peak hours D) during business hours

Q3) Which of these statements best describes MRGLs? A) an ordered list of media resources B) an ordered list of media gateways C) an ordered list of Media Resource Groups D) an ordered list of media servers

Q4) The Media Resource Manager manages which two resource types? (Choose two.) A) call dispatcher service B) media streaming application server C) transcoder D) multiplexer

Q5) Which of these is needed to configure the Catalyst 6000 Series hardware conference bridge? A) MAC address B) IP address C) port address D) 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) transcoder device B) MTP C) conference bridge D) device pool

Q7) Annunciator resources require that which service be activated? A) Cisco MOH Audio Translator B) Cisco IP Voice Media Streaming Application C) Cisco Messaging Interface D) Cisco CDR Insert



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




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



Cisco IOS and Cisco Catalyst operation system command-line basics





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



Overview of the Softkey Template This topic provides an overview of softkey templates.


Softkey Templates

• Five standard templates• Cannot delete or modify

templates Softkeys

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.



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.



Adding Application Softkeys to Nonstandard Softkey Templates

This topic describes the procedures for modifying a nonstandard softkey template.


Adding Application Softkeys to Nonstandard Templates

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.



Modifying Softkey Positions This topic describes the modification of softkey positions on Cisco IP Phones.


Modifying Softkey Positions

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.



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).



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.





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.


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





Q1) Which two of the following are standard application softkey templates that you can add to a nonstandard softkey template? (Choose two.) A) Standard Phone B) Standard Application C) Standard User D) Standard Feature

Q2) Where are softkey templates located? A) Device menu B) Service menu C) Tools menu D) Plug-Ins menu

Q3) How do you create a nonstandard softkey template? A) copy the template from a standard template B) create the template from the beginning C) you cannot create a nonstandard template D) add the template to the application

Q4) The Softkey Layout Configuration page is used for what purpose? A) modifying softkey buttons B) changing call states C) copying a standard template D) applying applications to softkeys

Q5) Which three of these areas can you use to assign a softkey template to a device? (Choose three.) A) device pools B) user profile C) device D) region

Q6) What must you do before you can delete a softkey template? A) delete any devices that are using it B) remove all associations to devices that are using it C) delete the standard template parent D) set the Delete Softkey Template flag to TRUE



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




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


Navigation within Cisco CallManager Administration

Cisco IOS command-line basics



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



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

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 user-activated 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 index 55 will be sent to

CallManager when AbbrDial key is pressed.

AbbrDial softkey is available when user enters digits.

Assigns speed dials to phone buttons

Can be used only for abbreviated dials

Speed Dial and Abbreviated Dial Configuration

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.




Auto Answer Configuration

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.




Configurable Call Forward Display

Call Forward

Call Forward and Configurable Call Forward Display Configuration

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.



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-by-line 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.




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.

Kim’s Phone

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 Sam and Kim are in an active call.

Step 2 Sam asks Kim to transfer him to Mary.

Step 3 Kim puts Sam on hold.

Step 4 Kim calls Mary.

Step 5 Kim touches Sam’s line (Cisco IP Phone model 7970 only) or uses the Select softkey to select Sam’s line.

Step 6 Kim hits the DirTrfr key, and Sam and Mary are immediately connected.




Call Join

• The Join softkey can join up to 15 established calls (16 parties) in a conference in a single feature request.

• 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.




Immediate Divert to Voice Mail

• iDivert softkey diverts a call to the voice-mail box of the iDivertinitiator.

• Initiator can be calling party or called party.

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 call-active 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.



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:

Step 1 George calls Sam.

Step 2 Sam is unable to take call.

Step 3 Sam diverts the call to voice mail by pressing the iDivert softkey.

Step 4 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 manager’s) voice mail box for retrieval later.

Step 1 Party A calls Party B.

Step 2 Party B answers the call.

Step 3 Party A presses the iDivert softkey.

Step 4 Party B hears the outgoing voice-mail greeting of Party A.

Step 5 Party B leaves a voice message.




• Allows placement of priority calls

• Allows authenticated users to pre-empt lower-precedence calls

• Does not relate to Call Admission Control or E911 calls

• Works with annunciatorfeature to advise users that they have a high-precedence call

Phone A

Phone B

Multilevel Precedence and Preemption

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).



MLPP Precedence Levels

MLPP Precedence Setting Precedence

0 (highest) Flash Override

1 Flash

2 Immediate

3 Priority

4 (lowest) 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.




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

Cisco CallManager

Cluster

IOS GW

PSTN

Victim

Malicious Caller

Victim receives a call from malicious caller and

invokes MCID feature.

Malicious Call Identification

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.



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 clusterand that each Cisco CallManager that devices are registered to

has its own unique Call Park Number/Range.

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.




Call Pickup/Group Call Pickup

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 Pickup Group Call Pickup

Group A Group CGroup B

Picks up 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.




Call Pickup Configuration

Configure a unique Call Pickup number

Assign the Call Pickup number to a line or DN

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.




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 call-back notification on a line on a Cisco IP Phone within the same Cisco CallManager cluster as your telephone. You cannot activate call-back notification if the called party has forwarded all calls to another extension (Call Forward All 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.



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.

1. Original two-party call2. Initiator barges into the call 3-way call• If initiator hangs up, original call remains active…OR• If target hangs up, initiator and other party connect point-to-point…OR• If other party hangs up, original call and barged call get released.

Initiator Target Other Party

Media Media

12

Barge Process

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 Conference—Barge 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 Conference—cBarge 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.



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.




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.




Barge Configuration

Enable Clusterwide

Enable at Device LevelOR

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.

Step 2 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.

Step 3 Set the Party Entrance Tone to True if you desire tones when a Barge occurs.




Privacy Configuration

...

Enable Clusterwide

Enable at Device Level

OR

To configure Privacy, follow these steps:

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

Note Do not set this parameter if only a few users need access to Privacy (see Step 3).

Step 2 For each phone button template that has Privacy, add Privacy to one of the feature buttons.

Step 3 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.

Step 4 For each telephone user that wants Privacy, choose the phone button template that contains the Privacy feature button that you created in Step 2.



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

ServicesButton

Service URL

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.



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 Developer’s Kit (Cisco XML SDK).

Users can subscribe only to services that are configured through Cisco CallManager Administration.

Note For information about the Cisco XML SDK, refer to these links: http://www.cisco.com/go/developersupport/ http://www.cisco.com/pcgi-bin/dev_support/access_level/product_support (registered Cisco.com users) http://www.cisco.com/warp/public/cc/pd/unco/ippps/




IP Phone Services Configuration

Update parameters to IP address if not using DNS

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 Choose Feature > Cisco IP Phone Services.

Step 2 In the upper right corner of the window, click the Add a New IP Phone Service link. The Cisco IP Phone Services Configuration window is displayed.

Step 3 Enter the appropriate settings. This list describes the information that must be configured for each service:

Service Name: Enter the name of the service as it will be displayed on the menu of available services in the Cisco IP Phone User Options application. Enter up to 32 characters for the service name.

Service Description (optional): Enter a description of the content that the service provides to help users decide whether they want to subscribe to the service.

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.



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 Customize a telephone button template by configuring a Service URL button.

Step 2 Add the customized phone button template to the telephone.

Step 3 Choose Device > Phone.

Step 4 To locate a specific telephone, enter search criteria and click Find.

Step 5 Choose the telephone to which you want to add a service URL button.

Step 6 On the upper right side of the window, click the Add/Update Service URL Buttons link.

Step 7 From the Service drop-down list box, choose the service that you want to add to the telephone.

Step 8 To add the service to the telephone button, click Update, or click Update and Close to add the service to the phone button and return to the Phone Configuration window.




Cisco IP Phone Services Examples

Flight Status

TransitSchedules

Stock Tracker

Meeting RoomScheduler

Yellow PagesLookup

WorldClock

Weather

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




Services Phone Display Examples

Menu Text Input

Image Directory Graphical

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.



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


TCP/IP

Overview of the Cisco IPMA Architecture

Cisco CallManager

DB

Cisco CallManager

DIRCTI

Manager

Tomcat IIS

MA Servlet

Assistant Console Apps,Manager Configuration

Apps

HTTP

Cisco CallManager

Cisco CallManager

SoftkeyDisplay

HTTP AssistantIP Phone

ManagerIP Phone

IPMA Service Browser

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.



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).




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.




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

Manager Display

DND State

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.



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 parameters2. Restart IPMA service3. Configure an IPMA manager and assign an

assistant4. Access Manager Configuration

(users or administrator)

After you activate the Cisco IPMA service, follow these steps to configure IPMA:

Step 1 Configure the appropriate service parameters.

Step 2 Restart the Cisco IPMA service from the Tomcat web page.

Step 3 Configure an IPMA manager and assign an assistant.

Step 4 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.

Step 4 Check the Cisco IP Manager Assistant check box and click Update.

The window displays the services that you chose with an activation status of Activated.




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).

The clusterwide parameters include the following:

— 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.



— 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.




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.




Configuring a Manager and Assigning an Assistant – Part 1

Click Cisco IPMA from Application Profiles list

Choose Continue to configure a manager

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 Choose User > Global Directory.

Step 2 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.

Step 3 To display user information for the chosen manager, click the user name. The User Configuration window is displayed.

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.





Choose Shared Lines

Assign Assistants

Choose Intercom Line

Choose Shared Line

ChooseAutomatic Configuration

Follow these steps to configure manager information on the User Configuration page:

Step 1 Click the Uses Shared Lines check box.

Step 2 To assign an assistant to the manager, click the Add/Delete Assistants link. The Assign Assistants window is displayed. (Assigning assistants is covered in the next set of steps.)

Step 3 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.

Note If the manager telecommutes, click the Mobile Manager check box and optionally choose Device Profile.

Step 4 From the Intercom Line selection box, choose the intercom line appearance for the manager, if applicable.

Step 5 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.

Note The IPMA-controlled lines (selected) must always be the shared-line DN.

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.





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.

Note A manager can have a maximum of 10 assigned assistants.

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.



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

Set a divert target (must be DN)

Access Cisco IPMA Manager Configuration at:

http://<ipma-server-ip>/ma/desktop/maLogin.jsp

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.




Using Assistant Console

Status BarMy Managers

Panel

Speed Dials Panel

Menu Bar

My Calls Panel

Call Control Buttons

Directory Panel

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



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)





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.


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.




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/





Q1) Which statement is most closely associated with IPMA shared-line mode? A) supports newer features such as Call Join, Privacy, and Direct Transfer B) uses call filters and partitions to route calls to the assistant C) uses the Standard IPMA Manager softkey template D) uses Cisco Tomcat to load the Cisco IPMA service

Q2) What must happen before users can subscribe to Cisco IP Phone Services? A) The user must log onto the Assistant Console and set a divert target. B) The Cisco CallManager administrator must add a Service URL phone button. C) The Cisco CallManager administrator must configure the Cisco IP Phone

Services. D) The user must have LCD-capable Cisco IP Phones (models 7940, 7960, or

7970).

Q3) Which feature could be used in a sales support department to cover incoming calls as a group? A) Call Pickup B) Call Park C) Call Forward D) Call Back

Q4) When the Privacy feature is enabled, it performs which two functions? (Choose two.) A) enables users who receive a malevolent call to notify authorities B) prevents users on a shared line from barging in on a call C) enables users to dial a code and get their call prioritized D) prevents users on a shared line from viewing call details

Q5) Which feature requires no administrator configuration? A) Call Forward B) Call Waiting C) Call Park D) Transfer

Q6) For which softkey is the initiating user NOT included in the conference after the transaction completes? A) Barge B) cBarge C) DirTrfr D) Join

Q7) Managers can do which of the following when they access Cisco IPMA Manager Configuration in shared-line mode? A) configure speed dials B) change the divert target C) assign an assistant D) subscribe to services



Q8) When you configure IPMA in shared-line mode, the IPMA-controlled line must always be which line? A) intercom B) primary line of the assistant C) shared DN D) proxy




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




Documents

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